I get the following ICE on IA-64:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O
libnasl-capture_packet.c
libnasl-capture_packet.c: In function 'capture_next_packet':
libnasl-capture_packet.c:19: internal compiler error: in expand_expr_real_1, at
expr.c:8786
Please submit a full bug rep
--- Comment #1 from tbm at cyrius dot com 2007-03-09 08:30 ---
Testcase:
typedef long unsigned int size_t;
__extension__ typedef long int __time_t;
__extension__ typedef long int __suseconds_t;
typedef struct
{
}
__sigset_t;
struct timeval
{
__time_t tv_sec;
__suseconds_t tv_usec;
}
--- Comment #9 from bonzini at gnu dot org 2007-03-09 08:44 ---
Zdenek, any chance that your aliasing oracle can be used to fix these?
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |middle-end
Target Milestone|--- |4.3.0
ht
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-03-09 08:54
---
Alias oracle could be used for this; but my patch only uses it in loop
optimizers. So some changes to make ccp use it would be necessary.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
The following two functions should be equzlivant when overflow is undefined:
int f(int a, int b)
{
return a * 10 == b*10;
}
int f1(int a, int b)
{
return a==b;
}
--
Summary: a*C == b*C where C is a constant is not optimized to a
== b
Product: gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||19987
nThis||
Sev
The following two functions should be equalivant with --fast-math:
int f(float a, float b)
{
return a/10 == b/10;
}
int f1(float a, float b)
{
return a == b;
}
--
Summary: a/C == b/C is not foldded to a == b with --fast-
math/floating point
Product:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||19987
nThis||
Sev
The following two functions should be equalivant with --fast-math:
int f(float a, float b)
{
return a*10 == b*10;
}
int f1(float a, float b)
{
return a == b;
}
--
Summary: a*C == b*C is not foldded to a == b with --fast-
math/floating point
Product:
--- Comment #8 from Andreas dot Kowarz at tu-dresden dot de 2007-03-09
09:37 ---
It seems that the bug triggers only when returning NULL in the new operators.
Returning something different ( tested with (void *)1 ) is a workaround for the
problem. Checking for not returning NULL in the
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot
|dot org
$ cat a.f90
PROGRAM TEST
INTEGER :: A
OPEN(10, FORM="UNFORMATTED", RECL=1024)
A = -1
WRITE(10) A
END PROGRAM TEST
$ gfortran a.f90 && ./a.out
At line 5 of file a.f90
Fortran runtime error: I/O past end of record on unformatted file
$ pgf90 a.f90 && ./a.out && xxd fort.10
The macro ASM_OUTPUT_ALIGN_WITH_NOP on sparc contains an explicit filler on the
align statement. This is given as a word representing the NOP. The GNU
assembler only uses the last byte of the filler. This generates wrong code. The
original SUN assembler needs this word to insert NOPs instead of zer
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-09 10:06
---
This one hurts. Nevertheless, it's probably too late for 4.2.0...
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from ubizjak at gmail dot com 2007-03-09 10:22 ---
This problem is fixed in 4.3.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Sta
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-09 10:32 ---
It looks like a no-op change. For reference:
--- ChangeLog (revision 121301)
+++ ChangeLog (revision 121302)
@@ -1,3 +1,41 @@
+2007-01-28 Daniel Berlin <[EMAIL PROTECTED]>
+
+ * tree.h (struct tree_memo
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:33 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:35 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:36 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:37 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #29 from baldrick at free dot fr 2007-03-09 10:41 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
> > Sure, it's just that overloading V_C_E like this feels somehow wrong to me.
>
> Why? It's not "overloading". V_C_E of an expression E of type X to
> type Y means "
--- Comment #8 from tbm at cyrius dot com 2007-03-09 10:52 ---
I definitely think this should be an error, not a warning. I only saw this
problem by luck. I'm compiling the entire Debian archive (ie 7000 packages)
on IA64 with GCC 4.3 and I cannot look at every log file (especially whe
This testcase:
double t (double a, double b)
{
return fmod (a, b);
}
generates wrong code when compiled with -O2 -funroll-all-loops
(-ffast-math -fomit-frame-pointer is used here only for clarity):
:
fldl4(%esp)
fldl12(%esp)
fxch%st(1)
.L2:
fpr
--- Comment #2 from tbm at cyrius dot com 2007-03-09 11:11 ---
I've confirmed that this doesn't happen with 4.2.0 20070309.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-03-09 11:11
---
Well, the only problem with V_C_E is that if you assert on the range of the
base type like
if (V_C_E (y) > 5)
abort();
that you still want VRP to infer that V_C_E (y) is <= 5 after this
check (to eliminat
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2007-03-09 11:19
---
> All the mess would be way easier if the FE would not expose the subtypes to
> the middle-end...
I personally agree, but there is no clear consensus among the Ada maintainers.
--
http://gcc.gnu.org/bugzill
--- Comment #9 from tbm at cyrius dot com 2007-03-09 11:21 ---
This warning is really frequent. I can find 2200 warnings that mention "const"
and "same canonical type node for different types". Some don't mention
"const";
I'll look at them and file separate bugs.
--
http://gcc.gnu
--- Comment #10 from ubizjak at gmail dot com 2007-03-09 11:22 ---
(In reply to comment #8)
> Anyway, are there any other "warning" messages like this one? If so, I can
> search my log files.
Yes, the one reported in PR middle-end/30666.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #5 from v dot lesk at ic dot ac dot uk 2007-03-09 11:28 ---
Can anyone suggest a workaround?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
--- Comment #32 from baldrick at free dot fr 2007-03-09 11:34 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
> Well, the only problem with V_C_E is that if you assert on the range of the
> base type like
>
> if (V_C_E (y) > 5)
> abort();
>
> that you still want VRP to i
--- Comment #33 from baldrick at free dot fr 2007-03-09 11:50 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
> My suggested use of a builtin would allow multiple redundant validity checks
> to be safely eliminated, because the builtin would be a "pure" function.
This is presuma
--- Comment #2 from joseph at codesourcery dot com 2007-03-09 12:06 ---
Subject: Re: New: a*C == b*C where C is a constant
is not optimized to a == b
On Fri, 9 Mar 2007, pinskia at gcc dot gnu dot org wrote:
> The following two functions should be equzlivant when overflow is undefin
)':
bug.cc:9: internal compiler error: Segmentation fault
> g++ --version
g++ (GCC) 4.3.0 20070309 (experimental)
--
Summary: ICE with -O2 -ftracer
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #11 from tbm at cyrius dot com 2007-03-09 12:13 ---
Another problem is that this warning does not always occur, even when I use
the same source and options.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-09 12:29 ---
The error setting happens in io/transfer.c's write_buf:
/* Unformatted sequential. */
have_written = 0;
if (dtp->u.p.current_unit->flags.has_recl
&& (gfc_offset) nbytes > dtp->u.p.cur
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-09 12:29 ---
Subject: Bug 30904
Author: rguenth
Date: Fri Mar 9 12:29:09 2007
New Revision: 122748
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122748
Log:
2007-03-09 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-03-09 12:29
---
Subject: Bug 31058
Author: rguenth
Date: Fri Mar 9 12:29:09 2007
New Revision: 122748
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122748
Log:
2007-03-09 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-09 12:29
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #25 from rguenth at gcc dot gnu dot org 2007-03-09 12:30
---
The original issue is fixed. The rest belongs in a different bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from Zarathustra at gentlemansclub dot de 2007-03-09 12:35
---
(In reply to comment #5)
> So, the way I read this is that gcc3.3 and icc9.0 agree that the call is
> ambiguous. I must admit that I don't know whether this is the correct
> behavior.
Also the SunCC yields the
--- Comment #11 from patchapp at dberlin dot org 2007-03-09 12:40 ---
Subject: Bug number PR30643
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00545.html
--
http://gcc.gnu.org/bugzilla/s
warning: same canonical type node for different types - with long int
% /usr/lib/gcc-snapshot/bin/g++ -c -g -O2 icu-dtfmtsym.ii
dtfmtsym.cpp: In member function 'void
icu_3_6::DateFormatSymbols::setMonths(const icu_3_6::UnicodeStr
ing*, int32_t, icu_3_6::DateFormatSymbols::DtContextType,
icu_3_6
--- Comment #1 from tbm at cyrius dot com 2007-03-09 12:46 ---
Created an attachment (id=13176)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13176&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
warning: same canonical type node for different types - anonymous
% /usr/lib/gcc-snapshot/bin/g++ -c -g -O2 dosbox-sdl_mapper.ii
sdl_mapper.cpp: In function 'void CreateBindGroups()':
sdl_mapper.cpp:1554: warning: same canonical type node for different types
CBindList [(long int)] and CBindList [(
--- Comment #12 from tbm at cyrius dot com 2007-03-09 12:49 ---
PR31103 - same canonical type node for different types with long int
PR31104 - same canonical type node for different types with anonymous
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
--- Comment #1 from tbm at cyrius dot com 2007-03-09 12:50 ---
Created an attachment (id=13177)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13177&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31104
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-09 12:55 ---
I was checking where bytes_left is set:
open.c: u->bytes_left = 0;
This is the default setting in new_unit (/* Open an unused unit. */)
It is also set to 0 in file_pos.c (two places).
In list_read.c's next_char i
--- Comment #2 from tbm at cyrius dot com 2007-03-09 13:06 ---
Created an attachment (id=13178)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13178&action=view)
testcase
I should mention that this warning doesn't show up all the time, but it'll
eventually show when you try long en
--- Comment #2 from droessle at us dot ibm dot com 2007-03-09 13:25 ---
Thanks for the direction. I will take the issue up at RH.
--
droessle at us dot ibm dot com changed:
What|Removed |Added
---
/home/Marco/Desktop/compile-lin-lin/gcc-build/./prev-gcc/xgcc
-B/home/Marco/Desktop/compile-lin-lin/gcc-build/./prev-gcc/
-B/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/i686-pc-linux-gnu/bin/ -c
-O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-pr
1) fesetexcept(FE_EXCEPT_ALL) sets the control fpu control word to 0x342, so
that the denormal operand exeption is masked, by definition all exceptions are
supposed to be enabled so it should be using 0x340.
2) If I establish a signal handler for FPEs the fpu is being reset to its
default state be
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 13:58 ---
These are all not compiler issues but glibc and/or kernel issues.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #34 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09
13:59 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
> You may well respond that you are only supposed to forget
> information you deduced from the range of the type, not information
> you worked out by s
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 13:59 ---
Fixed by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122746
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 14:03 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from mtrudel at gmx dot ch 2007-03-09 14:05 ---
I close this bug as "WONTFIX" because there's no active cygwin maintainer for
libjava. So, if it's not fixed already, it probably won't be fixed anyway.
I just once tested it for fun :-)
--
mtrudel at gmx dot ch changed:
--- Comment #2 from mtrudel at gmx dot ch 2007-03-09 14:12 ---
Thanks. But actually I also tried to start a discussion why such compilation
errors can happen:
This strongly remembers me to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
Is it possible that some flags trigger the "warn
--- Comment #35 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09
14:18 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
> All the mess would be way easier if the FE would not expose the subtypes to
> the middle-end...
I don't see how giving *additional* information coul
--- Comment #36 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09
14:29 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
> I don't think this is a very serious problem. My understanding is
> that the checks can be divided into two classes: normal checks and
> validity ch
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3 Regression] same |[4.3 Regression] same
|canonical type node for
--target-help shows compiler, assembler and linker options together, without
saying which is which. It can confuse users (see PR31073 for example).
Example: on i686-pc-linux-gnu, with mainline:
$ gcc --target-help | tail -n 35
-mtune= Schedule code for given CPU
-muclibc
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known t
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-03-09 15:23
---
(In reply to comment #6)
> when typing gfortran --target-help those options are all listed as compiler
> options.
We all agree it's a bug: compiler, assembler and linker options are listed
there indifferently. I
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-09 15:23 ---
I think gas should be fixed instead of the driver.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31107
--- Comment #4 from manu at gcc dot gnu dot org 2007-03-09 15:30 ---
(In reply to comment #3)
> I close this bug as "WONTFIX" because there's no active cygwin maintainer for
> libjava. So, if it's not fixed already, it probably won't be fixed anyway.
> I just once tested it for fun :-)
>
The ACATS failure occurs with gcc-4.2-20070307 bootstrapped from
gcc-4.2-20061226.
I was not able to build any 4.0 or 4.1 Ada compiler on MinGW, so this is a
regression against gcc-3.4.
,.,. C35507M ACATS 2.5 07-03-09 15:15:52
C35507M CHECK THAT THE ATTRIBUTES 'POS' AND 'VAL' YIELD THE CORRE
--- Comment #13 from mueller at gcc dot gnu dot org 2007-03-09 16:16
---
Subject: Bug 17946
Author: mueller
Date: Fri Mar 9 16:16:35 2007
New Revision: 122751
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122751
Log:
2007-03-09 Dirk Mueller <[EMAIL PROTECTED]>
PR c+
--- Comment #14 from mueller at gcc dot gnu dot org 2007-03-09 16:17
---
Fixed for 4.3.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status
gcc 3.3 is working fine in Interix (Services for Unix under Windows) on other
Windows XP machines that I use (both laptop and desktop)
A new installation of SFU35SEL_EN.exe (SFU/Interix) on a new IBM ThinkPad
laptop with Centrino Duo procesor does not seem to allow compilation of any
program (I
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |target
http:
--- Comment #4 from mstein at phenix dot rootshell dot be 2007-03-09 17:05
---
Created an attachment (id=13179)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13179&action=view)
from SVN revision: 122728
Commandline used to create libgcc2.i:
/home/mstein/sim/score-elf/build/./gc
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-09 17:05 ---
This is not that much of a blocker, really.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-09 17:08 ---
In fact this is an enhancement and really there just needs a new win32 option
for this feature.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from hjl at lucon dot org 2007-03-09 17:11 ---
Gcc 4.3 revision 122738 has the same issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-09 17:14 ---
> Of course I could be completely wrong. But if I'm right, there would be an
> easy
> way to prevent such build breaks...
People make mistakes, this was just one of them.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #4 from hjl at lucon dot org 2007-03-09 17:40 ---
Created an attachment (id=13180)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13180&action=view)
A breakdown testcase
xxx.f90 is the problem. -fdump-tree-all shows that revision 121302
generates very different alias in
--- Comment #5 from dberlin at gcc dot gnu dot org 2007-03-09 17:51 ---
Subject: Re: Revision 121302 causes 30% performance regression
Could you attach dumps for fdump-tree-alias-vops-details-blocks-stats
(tarr'ing up the resulting dumps is fine) for before and after?
I don't have a c
--- Comment #20 from dberlin at gcc dot gnu dot org 2007-03-09 17:55
---
Uh, i think i accidentally fixed the reduced testcase with my recent alias
patch (r122741).
Are the others still failing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
--- Comment #6 from hjl at lucon dot org 2007-03-09 17:57 ---
Created an attachment (id=13181)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13181&action=view)
Dumps of -fdump-tree-alias-vops-details-blocks-stats
121301 is from revision 121301 and 121302 is from revision 121302.
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-03-09 18:02
---
I believe I have a fix. I am testing now. We were not initializing a few
things when we have a record length given.
Index: io/open.c
===
--- io/op
Hello,
there seems to be a gcc problem with the target 'mn10300-elf':
/home/mstein/sim/mn10300-elf/build/./gcc/xgcc
-B/home/mstein/sim/mn10300-elf/build/./gcc/ -nostdinc
-B/home/mstein/sim/mn10300-elf/build/mn10300-elf/newlib/ -isystem
/home/mstein/sim/mn10300-elf/build/mn10300-elf/newlib/targ-in
--- Comment #7 from amacleod at redhat dot com 2007-03-09 18:11 ---
Subject: Bug 29877
Author: amacleod
Date: Fri Mar 9 18:11:40 2007
New Revision: 122754
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122754
Log:
2006-03-09 Mark Shinwell <[EMAIL PROTECTED]>
Andre
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-03-09 18:16
---
Created an attachment (id=13182)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13182&action=view)
from SVN revision: 122728
Commandline used to create ldtoa.i:
/home/mstein/sim/mn10300-elf/build/./gc
--- Comment #7 from simartin at gcc dot gnu dot org 2007-03-09 18:21
---
Fixed in 4.1, 4.2 and 4.3.
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2007-03-09 18:21 ---
No, this is not a target problem. I have traced the problem down to
reload_cse_simplify(), where insn that loads flags (either test or sahf) gets
cleared. This is highly suspicious part of code (why value is set to 0 ?):
--- Comment #6 from sebor at roguewave dot com 2007-03-09 18:25 ---
(In reply to comment #5)
Good point! I hadn't thought of that. Since that option is out and __FUNCTION__
should simply behave identically to __func__ and be disallowed in global or
namespace scope function argument list
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-09 18:33 ---
(In reply to comment #1)
> 4.1.0 fails the same way.
>
4.3.0 revision 122287 says:
pr27030.c: In function f:
pr27030.c:3: warning: __weakref__ attribute ignored
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30857
Hello,
there seems to be a gcc problem with the target 'sh-elf':
/home/mstein/sim/sh-elf/build/./gcc/xgcc -B/home/mstein/sim/sh-elf/build/./gcc/
-nostdinc -B/home/mstein/sim/sh-elf/build/sh-elf/newlib/ -isystem
/home/mstein/sim/sh-elf/build/sh-elf/newlib/targ-include -isystem
/n/07/mstein/combine
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-03-09 19:16
---
Created an attachment (id=13183)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13183&action=view)
from SVN revision: 122728
Commandline used to create libgcc2.i:
/home/mstein/sim/sh-elf/build/./gcc/x
--- Comment #21 from tbm at cyrius dot com 2007-03-09 19:28 ---
(In reply to comment #20)
> Uh, i think i accidentally fixed the reduced testcase with my recent alias
> patch (r122741).
> Are the others still failing?
Yes, conf.i is still failing at -O2
--
http://gcc.gnu.org/bugzil
--- Comment #22 from tbm at cyrius dot com 2007-03-09 19:34 ---
Testcase based on conf.i:
struct symbol
{
char *help;
};
struct menu
{
struct menu *next;
struct menu *list;
struct symbol *sym;
};
enum
{
ask_all,
}
input_mode = ask_all;
static char line[128];
static char nohelp
Hello,
there seems to be a gcc problem with the target 'm32c-elf':
When I use make -j 1 it works, whith make -j 2 it fails.
gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall
-Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-o
--- Comment #9 from aldyh at gcc dot gnu dot org 2007-03-09 20:05 ---
Subject: Bug 30375
Author: aldyh
Date: Fri Mar 9 20:05:08 2007
New Revision: 122758
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122758
Log:
PR tree-optimization/30375
* tree-ssa-dse.c (dse_
This is a feature request.
It stems from a discussion on gcc-help ("RE: Internal representation of double
variables - 3.4.6 vs 4.1.0").
There is no general, high-level option to enforce any particular arithmetic
model. Thus running floating point code on different CPUs may give different
results
--- Comment #1 from dj at redhat dot com 2007-03-09 20:08 ---
Subject: Re: New: Problem while compiling gcc for m32c-elf
Fixed via revision 122759.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31113
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-09 20:11 ---
-ffloat-store
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #91 from pinskia at gcc dot gnu dot org 2007-03-09 20:11
---
*** Bug 31114 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
1 - 100 of 173 matches
Mail list logo
