>From PR38572, but unrelated to it:
void f (long long int p)
{
int x;
static unsigned char g;
long long int min = -9223372036854775807LL - 1;
g = 1;
x = (signed char) (g | 249) / 4;
if (p >= min - (long long int) x)
p = 1;
if (p)
abort ();
}
gives
small.c: In function 'f':
--- Comment #26 from bonzini at gnu dot org 2009-01-22 08:08 ---
This is a separate bug. The reduced testcase does not have a single && or || so
it probably existed also before my patch.
It is now bug 38932.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|000
--- Comment #1 from bonzini at gnu dot org 2009-01-22 08:09 ---
Can anyone check if this is a regression, and if so from which version?
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from bonzini at gnu dot org 2009-01-22 08:17 ---
Actually, there is no overflow in -9223372036854775807LL - 1 so this is a third
bug. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
--- Comment #3 from bonzini at gnu dot org 2009-01-22 08:23 ---
ah no there's no overflow bit on min
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
--- Comment #3 from ubizjak at gmail dot com 2009-01-22 08:25 ---
Looking into it.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|uros at gcc
--- Comment #4 from bonzini at gnu dot org 2009-01-22 09:00 ---
In PRE there is a fold_convert_const_int_from_int call simplifying "(signed
char) 249" to -7, but setting the TREE_OVERFLOW flag in the meanwhile. I
don't think it makes sense to set the overflow flag on a NOP:
* `The
Sent from my iPhone
On Jan 22, 2009, at 1:00 AM, "bonzini at gnu dot org" > wrote:
--- Comment #4 from bonzini at gnu dot org 2009-01-22 09:00
---
In PRE there is a fold_convert_const_int_from_int call simplifying
"(signed
char) 249" to -7, but setting the TREE_OVERFLOW flag
--- Comment #5 from pinskia at gmail dot com 2009-01-22 09:17 ---
Subject: Re: ICE in set_value_range, at tree-vrp.c:398
Sent from my iPhone
On Jan 22, 2009, at 1:00 AM, "bonzini at gnu dot org" wrote:
>
>
> --- Comment #4 from bonzini at gnu dot org 2009-01-22 09:00
>
--- Comment #6 from rguenther at suse dot de 2009-01-22 09:29 ---
Subject: Re: ICE in set_value_range, at
tree-vrp.c:398
On Thu, 22 Jan 2009, bonzini at gnu dot org wrote:
> --- Comment #4 from bonzini at gnu dot org 2009-01-22 09:00 ---
> In PRE there is a fold_convert_cons
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-01-22 10:03
---
I am going to make this a P1 for 4.5, but it's too late for 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from ubizjak at gmail dot com 2009-01-22 10:32 ---
Created an attachment (id=17160)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17160&action=view)
Patch to fix insn attributes
Patch in testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38931
--- Comment #5 from burnus at gcc dot gnu dot org 2009-01-22 10:53 ---
> Thus: '(1pD24.15)' is valid
Fully agreed - that version is valid and accepted with gfortran, ifort, NAG f95
etc.
> While: '(1pD24.15e4)' is invalid
It is, but as written sunf95/openf95/gfortran 4.1 accept it at
--- Comment #7 from bonzini at gnu dot org 2009-01-22 11:04 ---
mine.
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
the attached test case builds with 4.3.2 and 4.4.0, but not with 4.2.4 and
4.3.3.
$ g++ -c SmartSearcher.ii
In file included from SmartSearcher.cc:23:
Printer.h: In member function 'CollPrinter& CollPrinter::operator=(const
std::pair<_T1, _T2>&)':
Printer.h:103: error: expected primary-expression
--- Comment #1 from doko at ubuntu dot com 2009-01-22 11:57 ---
Created an attachment (id=17161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17161&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38933
--- Comment #8 from bonzini at gnu dot org 2009-01-22 12:10 ---
Fixing FRE still causes an ICE for this:
/* { dg-do compile } */
/* { dg-options "-O2 --std=gnu99" } */
/* This variable needed only to exercise FRE instead of CCP. */
unsigned char g;
extern void abort();
void f (long
--- Comment #7 from amonakov at gcc dot gnu dot org 2009-01-22 12:19
---
(In reply to comment #6)
> -static bool code_motion_path_driver (insn_t, av_set_t, ilist_t,
> - cmpd_local_params_p, void *);
> +static int code_motion_path_driver (insn_t, av_se
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-22 12:24 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #9 from rguenther at suse dot de 2009-01-22 12:28 ---
Subject: Re: [4.4 Regression] ICE in set_value_range,
at tree-vrp.c:398
On Thu, 22 Jan 2009, bonzini at gnu dot org wrote:
> --- Comment #8 from bonzini at gnu dot org 2009-01-22 12:10 ---
> Fixing FRE still c
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-22 12:32 ---
HJ, can you track down this to the revision that broke it? Thx.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2009-01-22 12:33 ---
This has a trivial fix:
expr.c: 2913 becomes
if (have_pointer && lvalue->symtree->n.sym->attr.data)
Sorry about the lack of a diff - I will remedy this on submission:-)
paul
--
pault at gcc dot gnu dot org chan
--- Comment #4 from doko at ubuntu dot com 2009-01-22 12:38 ---
20090111 is ok, 20090117 not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38933
--- Comment #5 from pault at gcc dot gnu dot org 2009-01-22 12:39 ---
(In reply to comment #4)
> (In reply to comment #3)
>In the latter case, it is non-empty if ubound > lbound only. Comparing
> ubound and lbound according to the stride to check for zero-sized arrays
> doesn't make
--- Comment #5 from uros at gcc dot gnu dot org 2009-01-22 12:48 ---
Subject: Bug 38931
Author: uros
Date: Thu Jan 22 12:48:03 2009
New Revision: 143567
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143567
Log:
PR target/38931
* config/i386/i386.md (*movsi_1): U
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-22 12:57 ---
Hm, I don't think this is valid:
enum Type { NAME, FACETS, TAGS, QUIET };
...
template
CollPrinter& operator=(const std::pair& data)
{
...
switch (m_type)
{
...
case TAGS:
is it? EDG rejects it with
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P1 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38933
--- Comment #6 from ubizjak at gmail dot com 2009-01-22 13:12 ---
Fixed in mainline, latent on 4.3.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Mile
This failure is not "worked around" by FRE unlike 38932.
/* { dg-do compile } */
/* { dg-options "-O2 --std=gnu99" } */
/* This variable needed only to work around earlier optimizations than VRP. */
unsigned char g;
extern void abort();
void f (long long int p)
{
g = 255;
/* { dg-warning "
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|000
When using openmp reduction with minus the results are added instead of
substracted.
Small test programm to verify:
#include
int main(int argc, char* argv[]) {
int result = 15;
#pragma omp parallel reduction(-:result) num_threads(4)
{
result += 2;
--- Comment #10 from thutt at vmware dot com 2009-01-22 13:59 ---
(In reply to comment #7)
> The problem here is that you are using unitialized local register variables so
> the register allocator does not know any better. Anyways it works correctly
> on
> the trunk and I don't have an
ASSOCIATE is a nice Fortran 2003 feature. I found the following at
comp.lang.fortran and I want to make sure it gets tested when ASSOCIATE is
implemented. Thus I opened this PR.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ebf1e5abedc91cdc
Test case:
implicit none
integer
--- Comment #7 from rob1weld at aol dot com 2009-01-22 14:50 ---
Self Confirmed. Attempting to execute 64 bit code when booted 32 bit:
# gmake
...
/bin/sh ./libtool --tag=GCJ --mode=link /usr/share/src/gcc_build/gcc/gcj
-B/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/
-B/us
--- Comment #2 from pault at gcc dot gnu dot org 2009-01-22 15:00 ---
(In reply to comment #1)
> Confirm. ICE with 4.1.x and 4.2.x and wrong code with 4.3.x and 4.4.
>
> Thanks for the report.
>
The character length is being incorrectly set to 1 for the failing assignments;
ie. the las
--- Comment #8 from rob1weld at aol dot com 2009-01-22 15:12 ---
Applying "gcc_trunk/gcc/config/sol2.h" hack from this post:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38924
That is confirmed to "workaround" the problem but not "fix" it. Afterwards
it makes Bug 38728 by _far_ much wors
--- Comment #12 from dodji at gcc dot gnu dot org 2009-01-22 15:27 ---
I have reverted the patch.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-22 15:53 ---
It won't ICE for me with revision 143448 on Linux/x86-64:
[...@gnu-27 rrs]$ ./143448/usr/bin/gcc -O2 -S pr38934.c -m32 --std=gnu99
pr38934.c:14:13: warning: integer constant is so large that it is unsigned
[...@gnu-
--- Comment #9 from rob1weld at aol dot com 2009-01-22 16:03 ---
Created an attachment (id=17162)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17162&action=view)
Screenshot of build shows libgcj_tools building (after patch from 38924)
Description of the Screenshot:
At the far le
--- Comment #10 from hjl dot tools at gmail dot com 2009-01-22 16:09
---
It is caused by revision 126434:
http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00290.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-01-22
16:42 ---
Created an attachment (id=17163)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17163&action=view)
Fix shared libgcc naming scheme.
Patch now in testing, fixes DLL naming scheme for both Cygwin and
--- Comment #1 from sje at gcc dot gnu dot org 2009-01-22 17:02 ---
Subject: Bug 38615
Author: sje
Date: Thu Jan 22 17:02:21 2009
New Revision: 143570
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143570
Log:
PR middle-end/38615
* gimplify.c (gimplify_init_const
--- Comment #2 from sje at gcc dot gnu dot org 2009-01-22 17:03 ---
Subject: Bug 38615
Author: sje
Date: Thu Jan 22 17:03:35 2009
New Revision: 143571
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143571
Log:
PR middle-end/38615
* gcc.dg/pr38615.c: New test.
Ad
--- Comment #11 from dberlin at gcc dot gnu dot org 2009-01-22 17:12
---
Subject: Re: [4.3/4.4 Regression] ICE in
set_value_range, at tree-vrp.c:398
Uh, well, that would be tricky since none of this code still exists in 4.4.0
On Thu, Jan 22, 2009 at 11:09 AM, hjl dot tools a
--- Comment #1 from domob at gcc dot gnu dot org 2009-01-22 17:27 ---
I always liked the idea of associate... Maybe I'll volunteer to work on it for
gfortran, but don't take my word on it ;) And of course, things like CLASS get
higher priority.
--
domob at gcc dot gnu dot org chang
--- Comment #13 from hjl dot tools at gmail dot com 2009-01-22 17:43
---
Fixed by revision 143562, which reverted revision 143546.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #41 from r dot emrich at de dot tecosim dot com 2009-01-22
18:15 ---
(In reply to comment #40)
> Subject: Re: link/execute fails for cross gcc from linux to target
> hppa64-hp-hpux11.00
> > configuring with
> >
> > --disable-symvers
>
> GNU symbol versioning is not suppo
--- Comment #42 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-22
18:42 ---
Subject: Re: link/execute fails for cross gcc from linux to target
hppa64-hp-hpux11.00
> configuring with --disable-symvers --disable-shared solves the problem for
> now.
> So in fact --disable-shared sh
On s390x, there are some libstdc++ failures that are not present on other
platforms.
Here is a representative test run:
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02102.html
And here is the failure analysis:
http://gcc.gnu.org/ml/libstdc++/2009-01/msg00109.html
The following fails appear
--- Comment #43 from joel at gcc dot gnu dot org 2009-01-22 19:23 ---
(In reply to comment #42)
> Fixed.
>
Did the test case get added to the suite?
This does appear to be fixed to me as well.
C/C++: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02243.html
Ada: http://gcc.gnu.or
--- Comment #44 from hjl dot tools at gmail dot com 2009-01-22 19:33
---
(In reply to comment #43)
> (In reply to comment #42)
> > Fixed.
> >
>
> Did the test case get added to the suite?
>
> This does appear to be fixed to me as well.
There are no suitable testcases in this PR. May
--- Comment #2 from pault at gcc dot gnu dot org 2009-01-22 20:16 ---
I am just about to post a fix.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-22 21:30 ---
(In reply to comment #1)
> It won't ICE for me with revision 143448 on Linux/x86-64:
Most likely this is HWI 32 only issue as this works on i386-darwin which
defaults HWI to be 64bits.
--
pinskia at gcc dot gnu
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-22 21:33 ---
Yes this is invalid code, see PR 36019 for the reason why.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #43 from bkoz at gcc dot gnu dot org 2009-01-22 21:40 ---
Subject: Bug 38384
Author: bkoz
Date: Thu Jan 22 21:40:23 2009
New Revision: 143576
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143576
Log:
2009-01-22 Benjamin Kosnik
PR libstdc++/38384
--- Comment #44 from bkoz at gcc dot gnu dot org 2009-01-22 22:01 ---
Hey. I couldn't stop myself: since Dave said that HPUX doesn't support symbol
versioning, (no way, no how) I have changed libstdc++ configure to reflect
this.
:)
Ranier, great to see you got something working. I've
--- Comment #45 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-22
22:36 ---
Subject: Re: shared link/execute fails for cross gcc from linux to target
hppa64-hp-hpux11.00
> Hey. I couldn't stop myself: since Dave said that HPUX doesn't support symbol
> versioning, (no way, no how)
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-22 22:44 ---
This is likely because of different inlining decisions which is possibly
because
of different insn costs which depend on MOVE_MAX_PIECES and MOVE_RATIO.
The warning itself hints at either an alias problem in the tes
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-22 23:10
---
Hm, the first forwprop dump looks sane:
VIEW_CONVERT_EXPR(c64).u.lo32.u.lo16.u.hi8 ={v} 1;
but then addressables1 comes along and rewrites c64 into SSA form ... and if
you fix it then the duplicate in tree-ssa-
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-01-22 23:20
---
>Maybe I should merge the split of addressables from tree-ssa-alias.c from
the alias-improvements branch.
There are two things, first c64 really should not be TREE_ADDRESSABLE but
rather !DECL_GIMPLE_REG_P. But t
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-01-22 23:21
---
non-optimal tree-ssa-alias.c part:
Index: tree-ssa-alias.c
===
--- tree-ssa-alias.c(revision 143555)
+++ tree-ssa-alias.c(working copy)
@@ -2
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-01-22 23:23
---
Hm? Non-TREE_ADDRESSABLE non-SSA vars are fine. It isn't DECL_GIMPLE_REG_P
either of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38745
[...@gnu-6 pr36159]$ cat f.c
/* foo /* */
int *
foo (unsigned int *x)
{
return x;
}
[...@gnu-6 pr36159]$ /export/build/gnu/gcc-avx/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/gcc/ -c f.c
[...@gnu-6 pr36159]$ /export/build/gnu/gcc-avx/build-x86_64-linux/gcc/xgcc
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-22 23:54 ---
This patch
Index: gcc/c-opts.c
===
--- gcc/c-opts.c(revision 5064)
+++ gcc/c-opts.c(working copy)
@@ -425,7 +425,7 @@ c_common_handle_o
--- Comment #3 from hjl dot tools at gmail dot com 2009-01-23 00:06 ---
(In reply to comment #2)
> (In reply to comment #1)
> > It won't ICE for me with revision 143448 on Linux/x86-64:
>
> Most likely this is HWI 32 only issue as this works on i386-darwin which
> defaults HWI to be 64b
The following snippet runs about 25% faster on my 1333MHz 7447A with -Os than
-O2, even if compiled with -mcpu=G4:
const unsigned c=0x1010101;
unsigned z=0;
for(int i=c; i>=2; i*=c)
{
z+=i&1;
}
With -mcpu=G4 -O2 it gives:
lis 0,0x101
mr 31,3
ori 10,0,257
.L4:
sl
The following snippet runs about 25% faster on my 1333MHz 7447A with -Os than
-O2, even if compiled with -mcpu=G4:
const unsigned c=0x1010101;
unsigned z=0;
for(int i=c; i>=2; i*=c)
{
z+=i&1;
}
With -mcpu=G4 -O2 it gives:
lis 0,0x101
mr 31,3
ori 10,0,257
.L4:
sl
On x86, CX is used for shift. If CX is used for a variable, it
may not be preserved with shift:
[...@gnu-9 reg-1]$ cat r.c
extern void abort (void);
void
foo (int x)
{
if (x != 8)
abort ();
}
void
bar (int g)
{
register int x __asm__("ecx");
x = 5;
foo (1 << g);
if (x != 5)
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-23 02:58 ---
*** This bug has been marked as a duplicate of 38939 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-23 02:58 ---
*** Bug 38940 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38939
G'Day Prof. Peter Morgan
This is Jason Zhang from RSES ANU. While I was recompiling the GAMIT due to
change of my laptop (x-86-64), I encounterred an internal compiling bug which
occurs when doing
gfortran -O3 -Wuninitialized -fno-f2c -ffast-math -fno-automatic -fno-backslash
tssum.f ../gen_ut
Seen using r143582 on Ubuntu Hardy. I'm pretty sure this is a miscompilation
at -O2.
The safe_* macros are basically just macroizations of safe math functions from
here:
https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+
Sent from my iPhone
On Jan 22, 2009, at 5:54 PM, "hjl dot tools at gmail dot com" > wrote:
On x86, CX is used for shift. If CX is used for a variable, it
may not be preserved with shift:
[...@gnu-9 reg-1]$ cat r.c
extern void abort (void);
void
foo (int x)
{
if (x != 8)
abort ();
}
vo
--- Comment #1 from pinskia at gmail dot com 2009-01-23 04:24 ---
Subject: Re: New: CX isn't preserved with shift
Sent from my iPhone
On Jan 22, 2009, at 5:54 PM, "hjl dot tools at gmail dot com"
wrote:
> On x86, CX is used for shift. If CX is used for a variable, it
> may not be
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-23 04:34 ---
How about this one:
---
extern void abort (void);
void
foo (int x)
{
if (x != 8)
abort ();
}
void
bar (int g)
{
register int x __asm__("ecx");
register int y __asm__("eax");
x = 5;
foo (1 <<
Sent from my iPhone
On Jan 22, 2009, at 8:34 PM, "hjl dot tools at gmail dot com" > wrote:
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-23
04:34 ---
How about this one:
---
extern void abort (void);
void
foo (int x)
{
if (x != 8)
abort ();
}
void
bar (int g
--- Comment #3 from pinskia at gmail dot com 2009-01-23 04:39 ---
Subject: Re: CX isn't preserved with shift
Sent from my iPhone
On Jan 22, 2009, at 8:34 PM, "hjl dot tools at gmail dot com"
wrote:
>
>
> --- Comment #2 from hjl dot tools at gmail dot com 2009-01-23
> 04:34
--- Comment #4 from hjl dot tools at gmail dot com 2009-01-23 05:14 ---
(In reply to comment #3)
> Again still undefined because there is still inbetween the assignment
> and the inline-asm.
>
Where is this documented? There is
bash-3.2$ cat ./gcc.target/mips/asm-1.c
/* PR target/1
--- Comment #5 from hjl dot tools at gmail dot com 2009-01-23 05:16 ---
./gcc.target/i386/attr-returns_twice-1.c has no asm statements at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
--- Comment #6 from hjl dot tools at gmail dot com 2009-01-23 05:45 ---
gcc.target/i386/pr20204.c is another example without asm statement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-01-23 05:46
---
gfortran's current format parser is completely lost by the time an error is
thrown. I have a patch that detects the actual error and the locus is spot on.
I am fixing both compile time and run time to reject the
83 matches
Mail list logo
