[Bug rtl-optimization/37534] [4.4 Regression] IRA causes 17% degradation in 187.facerec benchmark
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization, ra Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37534
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at gcc dot gnu dot ||org Summary|gcc/libgcc2.c:404: internal |[4.4 Regression] |compiler error: Floating|gcc/libgcc2.c:404: internal |point exception |compiler error: Floating ||point exception Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug fortran/37536] [4.3/4.4 Regression] a mfcr is produced instead of branches for DO loops
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-16 13:02 --- Created an attachment (id=16338) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16338action=view) gcc44-pr37536.patch So far untested patch to optimize slightly integer type non-simple do loops. At least on x86_64 it results in smaller and hopefully faster code. Still testing it with make check-gfortran, but will probably need a SPEC testing too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37536
[Bug fortran/37536] [4.3/4.4 Regression] a mfcr is produced instead of branches for DO loops
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-16 13:10 --- ifcombine would be a place to do this CFG re-writing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Severity|enhancement |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.2.4 Last reconfirmed|-00-00 00:00:00 |2008-09-16 13:10:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37536
[Bug tree-optimization/37537] mfcr is produced when a branch should be done
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-16 13:10:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37537
[Bug c/37538] 4.3.1 compiler crash at function call
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-16 13:11 --- There is no such target as rpine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37538
[Bug fortran/37527] conftest.c:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'me'
--- Comment #5 from reuben dot kraft at gmail dot com 2008-09-16 13:13 --- My problem looks very similar to this bug report which does not seem to be full resolved: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36349 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37527
[Bug c++/37539] Hang for -O3
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-16 13:14 --- There's a dup for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37539
[Bug tree-optimization/37526] [4.4 Regression] ICE using --combine -O2
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-09-16 13:20 ---
./cc1 -quiet -O2 t1.i t2.i
t2.i: In function 'Node_print':
t2.i:2: error: non-trivial conversion at assignment
struct _IO_FILE *
struct _IO_FILE *
# LOADS: { stderr }
stderr.0_3 = stderr;
t2.i:2: error: non-trivial conversion at assignment
struct _IO_FILE *
struct _IO_FILE *
# LOADS: { stderr }
stderr.0_4 = stderr;
t2.i:2: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
So we have wrong GIMPLE here. GIGO.
Value numbering stderr.0_3 stmt = stderr.0_3 = stderr;
Setting value number of stderr.0_3 to stderr.0_3
...
Value numbering stderr.0_4 stmt = stderr.0_4 = stderr;
Inserting name stderr.0_17 for expression (struct _IO_FILE *) stderr.0_3
Setting value number of stderr.0_4 to stderr.0_17
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37526
Re: [Bug tree-optimization/37526] [4.4 Regression] ICE using --combine -O2
Sent from my iPhone
On Sep 16, 2008, at 6:20 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED]
wrote:
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-09-16
13:20 ---
./cc1 -quiet -O2 t1.i t2.i
t2.i: In function 'Node_print':
t2.i:2: error: non-trivial conversion at assignment
struct _IO_FILE *
struct _IO_FILE *
# LOADS: { stderr }
stderr.0_3 = stderr;
t2.i:2: error: non-trivial conversion at assignment
struct _IO_FILE *
struct _IO_FILE *
# LOADS: { stderr }
stderr.0_4 = stderr;
No those two types should compatible. If they are not then there is a
bug in the middle-end. I think this is why there was the Lang hook in
the first place.
t2.i:2: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
So we have wrong GIMPLE here. GIGO.
Value numbering stderr.0_3 stmt = stderr.0_3 = stderr;
Setting value number of stderr.0_3 to stderr.0_3
...
Value numbering stderr.0_4 stmt = stderr.0_4 = stderr;
Inserting name stderr.0_17 for expression (struct _IO_FILE *) stderr.
0_3
Setting value number of stderr.0_4 to stderr.0_17
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
---
--
CC||rguenth at gcc dot
gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37526
[Bug tree-optimization/37526] [4.4 Regression] ICE using --combine -O2
--- Comment #8 from pinskia at gmail dot com 2008-09-16 13:29 ---
Subject: Re: [4.4 Regression] ICE using --combine -O2
Sent from my iPhone
On Sep 16, 2008, at 6:20 AM, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED]
wrote:
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-09-16
13:20 ---
./cc1 -quiet -O2 t1.i t2.i
t2.i: In function 'Node_print':
t2.i:2: error: non-trivial conversion at assignment
struct _IO_FILE *
struct _IO_FILE *
# LOADS: { stderr }
stderr.0_3 = stderr;
t2.i:2: error: non-trivial conversion at assignment
struct _IO_FILE *
struct _IO_FILE *
# LOADS: { stderr }
stderr.0_4 = stderr;
No those two types should compatible. If they are not then there is a
bug in the middle-end. I think this is why there was the Lang hook in
the first place.
t2.i:2: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
So we have wrong GIMPLE here. GIGO.
Value numbering stderr.0_3 stmt = stderr.0_3 = stderr;
Setting value number of stderr.0_3 to stderr.0_3
...
Value numbering stderr.0_4 stmt = stderr.0_4 = stderr;
Inserting name stderr.0_17 for expression (struct _IO_FILE *) stderr.
0_3
Setting value number of stderr.0_4 to stderr.0_17
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
---
--
CC||rguenth at gcc dot
gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37526
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37526
Gimple ICE for MIPS ports
Hi Guys, Sometime during the last month building newlib for any of the MIPS ports broke with a gimple verification error: .../newlib/libc/stdio/vfprintf.c:480: error: type mismatch in binary expression unsigned char unsigned char int D.3477 = D.3438 -8; [...] .../newlib/libc/stdio/vfprintf.c:480: internal compiler error: verify_gimple failed This is from a mips64vr-elf target, but I have the same failure with mipsisa32-elf and mipsisa64-elf targets as well. Cheers Nick
[Bug objc/34310] new objc testsuite failures from expected ';' before '__attribute__' under darwin9
--- Comment #1 from dominiq at lps dot ens dot fr 2008-09-16 14:41 --- As far as I can tell, all the lines corresponding to ...error: expected... start with a '-', but the same is true for Darwin8. Does anyone know what has changed in Darwin9 that can explain the errors? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34310
[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2008-09-16 15:02 --- Subject: Re: [4.4 regression] All Solaris/x86 eh tests fail jakub at gcc dot gnu dot org writes: gas 2.15 is helplessly outdated and buggy. Can you retry with -fno-dwarf2-cfi-asm ? Unfortunately, passing in BOOT_CFLAGS='-g -O2 -fno-dwarf2-cfi-asm' didn't help (the value wasn't picked up from the environment). Even if I manually set BOOT_CFLAGS like that in the toplevel Makefile, it isn't passed down to the libgcc and libstdc++-v3 builds, and manually compiling an individual testcase with -fno-... isn't enough. If I add -fno-... to i386-pc-solaris2.10/libgcc/Makefile, rebuild libgcc and a testcase with -fno-..., the test passes. On the other hand, I tried bootstrapping with the current binutils 2.18 release, which makes no difference, so this doesn't seem to be a gas problem. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37463
[Bug middle-end/37499] [4.4 Regression] Scheduling pass 2 time increases by order of magnitude
--- Comment #4 from amonakov at gcc dot gnu dot org 2008-09-16 15:12 --- A patch for this bug has been posted at http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01135.html Running the testcase on similarly configured compiler shows 2.47 seconds spent in scheduling2, out of 151.27 total time (2.2GHz Opteron 8354). Unpatched times are 32.43 sched2/180.89 total. -- amonakov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|abel at gcc dot gnu dot org |amonakov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37499
[Bug tree-optimization/37542] New: PRE doesn't simplify during phi-translation
Related to the XFAIL of gcc.dg/tree-ssa/ssa-pre-15.c (PR37145). The general
issue is that PRE doesn't simplify expressions during phi-translation
which can be seen for example for
int foo (int i, int b)
{
int j = 1;
if (b)
j = i;
return j - i;
}
where j - i is partially redundant.
--
Summary: PRE doesn't simplify during phi-translation
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37542
[Bug tree-optimization/37542] PRE doesn't simplify during phi-translation
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-16 15:22 --- Mine. I have some patches. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-16 15:22:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37542
[Bug fortran/37536] [4.3/4.4 Regression] a mfcr is produced instead of branches for DO loops
--- Comment #5 from pault at gcc dot gnu dot org 2008-09-16 15:29 --- (In reply to comment #2) Hi Andrew, Does this do it for you or is this all to rarified for this Bear-of-little-brain to follow? D.1359 = *start - *offset; D.1360 = *end + *offset; D.1361 = *step; D.1364 = D.1361 0 ? D.1360 D.1359 : D.1360 D.1359; /* Fix the result*/ if (D.1364) goto L.2;/* Then branch */ countm1.0 = (D.1361 0 ? (character(kind=4)) (D.1360 - D.1359) : (character(kind=4)) (D.1359 - D.1360)) / (character(kind=4)) ABS_EXPR D.1361; i = D.1359; while (1) Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37536
[Bug tree-optimization/37542] [4.4 Regression] PRE doesn't simplify during phi-translation
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-16 15:34 ---
Hm, actually this is a regression :/ 4.3 produces
foo (i, b)
{
int prephitmp.7;
int pretmp.6;
int j;
int D.1550;
bb 2:
if (b_3(D) != 0)
goto bb 3;
else
goto bb 5;
bb 5:
pretmp.6_8 = 1 - i_4(D);
goto bb 4;
bb 3:
bb 4:
# prephitmp.7_9 = PHI pretmp.6_8(5), 0(3)
# j_1 = PHI 1(5), i_4(D)(3)
D.1550_6 = prephitmp.7_9;
return D.1550_6;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.2
Summary|PRE doesn't simplify during |[4.4 Regression] PRE doesn't
|phi-translation |simplify during phi-
||translation
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37542
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #28 from dje at gcc dot gnu dot org 2008-09-16 15:52 --- The AIX systems to which I have access also are AIX 5.3.0.0 TL 07. My GCC configure command only specifies the languages and where to find GMP and MRPF. I had been using gmp-4.1.4 static archive library, but recently upgraded to gmp-4.2.3 dynamic library. I am using mpfr-2.3.1 static archive library. I build GCC as a 32 bit application, which is the default. I assume that you are compiling the OpenFOAM as 32 bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug fortran/37536] [4.3/4.4 Regression] a mfcr is produced instead of branches for DO loops
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-16 15:55 --- (In reply to comment #5) (In reply to comment #2) Hi Andrew, Does this do it for you or is this all to rarified for this Bear-of-little-brain to follow? D.1359 = *start - *offset; D.1360 = *end + *offset; D.1361 = *step; D.1364 = D.1361 0 ? D.1360 D.1359 : D.1360 D.1359; /* Fix the result*/ if (D.1364) goto L.2;/* Then branch */ The issue is that D.1364 is used to the store of the result of a comparison. Since GCC does not currently optimize that case, the front-end could rewrite the if statement to begin with; this is what Jabuk's patch does (Thanks Jabuk!). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37536
[Bug ada/37543] New: Assembler error during compilation
bash-2.05b$ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.4-20080912/configure --enable-languages=ada,c++,fortran --with-mpfr=/home/voax/linux/tools/mpfr-2.2.1 Thread model: posix gcc version 4.4.0 20080912 (experimental) (GCC) when compiling the hello.adb program below, the compiler fails as indication by bash-2.05b$ gcc -c hello.adb /tmp/ccV7MEis.s: Assembler messages: /tmp/ccV7MEis.s:11: Error: unknown pseudo-op: `.cfi_personality' with GNAT.IO; use GNAT.IO; procedure Hello is begin Put_Line (Hello World. Welcome to GNAT); end Hello; -- Summary: Assembler error during compilation Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anhvofrcaus at gmail dot com GCC host triplet: RH GCC target triplet: RH http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37543
[Bug ada/37543] Assembler error during compilation
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-16 16:12 --- Did you compile the compiler yourself? If not, do know what version of binutils they used? Also what version of as/binutils are you are using? cfi_personality is only in supported in newer versions of binutils. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING GCC build triplet||i686-pc-linux-gnu GCC host triplet|RH |i686-pc-linux-gnu GCC target triplet|RH |i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37543
[Bug rtl-optimization/37263] [4.3 Regression] extra code for doloop with unsigned 32bit types on LP64
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-16 16:21 --- Fixed at least on the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 Known to work||4.1.1 Summary|[4.3/4.4 Regression] extra |[4.3 Regression] extra code |code for doloop with|for doloop with unsigned |unsigned 32bit types on LP64|32bit types on LP64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37263
[Bug rtl-optimization/37263] [4.3 Regression] extra code for doloop with unsigned 32bit types on LP64
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-16 16:23 --- Subject: Bug 37263 Author: pinskia Date: Tue Sep 16 16:21:35 2008 New Revision: 140395 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140395 Log: 2008-09-16 Andrew Pinski [EMAIL PROTECTED] PR middle-end/37263 * tree-ssa-loop-ivopts.c (determine_use_iv_cost_condition): Prefer the eliminate IV if the cost are the same. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37263
[Bug ada/37543] Assembler error during compilation
--- Comment #2 from anhvofrcaus at gmail dot com 2008-09-16 16:34 --- Yes, I built the compiler myself. In fact, the configuration for this build is: bash-2.05b$ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.4-20080912/configure --enable-languages=ada,c++,fortran --with-mpfr=/home/voax/linux/tools/mpfr-2.2.1 Thread model: posix gcc version 4.4.0 20080912 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37543
[Bug tree-optimization/37539] Hang for -O3
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-16 16:36 --- It is hanging in vectorizable_load. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37539
[Bug c/37544] New: Conversion double - unsigned long long - unsigned - double gives wrong results
Consider the following line of the attached test case, where a is double with value 4294967296.0. double b = (unsigned int)((unsigned long long int)a % 4294967296ULL); Then (unsigned long long int)a % 4294967296ULL should be equal to 0ULL, and therefore b should be 0.0. However, when compiled with -O1 -march=pentium4, b gets the wrong value of 4294967296.0 (the same as a). Note that the error only occurs with -march=pentium4. To compile the testcase: gcc -std=c99 -O1 -march=pentium4 convert-bug.i -o convert-bug gcc -v: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --enable-checking=release --prefix=/home/jdemeyer/local CC=gcc-4.1.2 Thread model: posix gcc version 4.4.0 20080916 (experimental) (GCC) -- Summary: Conversion double - unsigned long long - unsigned - double gives wrong results Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jdemeyer at cage dot ugent dot be GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug c/37544] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #1 from jdemeyer at cage dot ugent dot be 2008-09-16 16:40 --- Created an attachment (id=16339) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16339action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
--- Comment #6 from vmakarov at redhat dot com 2008-09-16 16:47 --- John, thanks for detail analysis. IRA uses 25 for p171 because there is no recorded conflicts for p171 and hard register 25. The problem was introduced by recent patch 2008-09-04 Richard Sandiford [EMAIL PROTECTED] PR middle-end/37243 * ira-build.c (form_loop_tree): Reverse BB walk. (create_bb_allocnos): Likewise. * ira-lives.c (make_regno_born_and_dead, regs_set): Delete. (mark_reg_store): Rename to... (mark_ref_live): ...this and take a df_ref argument instead of note_stores arguments. Assert that we have a register. (mark_reg_clobber): Delete. (def_conflicts_with_inputs_p): New function. (mark_reg_conflicts): Delete. (mark_reg_death): Rename to... (mark_ref_dead): ...this and take a df_ref argument instead of a register. Assert that we have a register. (process_bb_node_lives): Hoist frequency calculation out of instruction walk. Convert from a forwards scan to a backwards scan. Use DF_REF_USES and DF_REF_DEFS instead of register notes and note_stores. Remove EH_RETURN_DATA_REGNO and regs_set handling. (create_allocno_live_ranges): Don't create regs_set. I'll work on a fix. Unfortunately using DF for building conflicts became more complicated that it was before based on REG notes. So it will take some time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug target/37544] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-16 16:52 --- This works correctly for i386-darwin. In fact I tried -std=c99 -O1 -mfpmath=387 -march=pentium4 -mno-sse too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
Re: Gimple ICE for MIPS ports
On Tue, Sep 16, 2008 at 03:33:21PM +0100, Nick Clifton wrote: Hi Guys, Sometime during the last month building newlib for any of the MIPS ports broke with a gimple verification error: ../newlib/libc/stdio/vfprintf.c:480: error: type mismatch in binary expression unsigned char unsigned char int D.3477 = D.3438 -8; [...] ../newlib/libc/stdio/vfprintf.c:480: internal compiler error: verify_gimple failed This is from a mips64vr-elf target, but I have the same failure with mipsisa32-elf and mipsisa64-elf targets as well. Cheers Nick Were the mips backend properly converted to tuples? Off the top of my head would be to check the vaarg stuff to make it is converted and doesn't have any tree sharing problems.
[Bug c++/37540] [4.4 regression] ICE on __decltype of method call in function template
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-16 17:09 --- ICEs in finish_decltype_type. Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.4.0 Known to work||4.3.0 Last reconfirmed|-00-00 00:00:00 |2008-09-16 17:09:22 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37540
[Bug target/37538] 4.3.1 compiler crash at function call
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-16 17:12 --- (In reply to comment #1) There is no such target as rpine. More to the point, bug reports submitted against a non supported target is not the correct thing to do. You should debug the compiler and maybe write an email to gcc@ asking questions if needed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37538
[Bug middle-end/37499] [4.4 Regression] Scheduling pass 2 time increases by order of magnitude
--- Comment #5 from lucier at math dot purdue dot edu 2008-09-16 17:16 --- Your patch fixes the problem for me, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37499
[Bug tree-optimization/37031] [4.4 Regression] ICE for h264ref in gather_interchange_stats with -ftree-loop-linear
--- Comment #6 from janis at gcc dot gnu dot org 2008-09-16 17:21 --- Valgrind no longer complains for this testcase, but the I still get the reported ICE compiling q_matrix.c with -O3 -ftree-loop-linear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37031
[Bug target/37524] gcc build fail after some compile with --target=amigaos
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-16 17:23 --- I doubt the FSF GCC has ever supported the AmigaOS as a target. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37524
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #29 from dje at gcc dot gnu dot org 2008-09-16 17:40 --- I bootstrap GCC using GCC 4.1. I assume you use GCC 4.2 distributed by IBM. I do not understand your comment in the initial report about forward porting of the 4.2.0 patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug fortran/37536] [4.3/4.4 Regression] a mfcr is produced instead of branches for DO loops
--- Comment #7 from pault at gcc dot gnu dot org 2008-09-16 17:51 --- (In reply to comment #2) Hi Andrew, Does this do it for you or is this all to rarified for this Bear-of-little-brain to follow? D.1359 = *start - *offset; D.1360 = *end + *offset; D.1361 = *step; D.1364 = D.1361 0 ? D.1360 D.1359 : D.1360 D.1359; /* Fix the result*/ if (D.1364) goto L.2;/* Then branch */ countm1.0 = (D.1361 0 ? (character(kind=4)) (D.1360 - D.1359) : (character(kind=4)) (D.1359 - D.1360)) / (character(kind=4)) ABS_EXPR D.1361; i = D.1359; while (1) Cheers Paul (In reply to comment #6) (In reply to comment #5) (In reply to comment #2) Hi Andrew, Does this do it for you or is this all to rarified for this Bear-of-little-brain to follow? D.1359 = *start - *offset; D.1360 = *end + *offset; D.1361 = *step; D.1364 = D.1361 0 ? D.1360 D.1359 : D.1360 D.1359; /* Fix the result*/ if (D.1364) goto L.2;/* Then branch */ The issue is that D.1364 is used to the store of the result of a comparison. Since GCC does not currently optimize that case, the front-end could rewrite the if statement to begin with; this is what Jabuk's patch does (Thanks Jabuk!). Ah! Thanks P. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37536
[Bug target/37524] gcc build fail after some compile with --target=amigaos
--- Comment #3 from nospamname at web dot de 2008-09-16 18:13 --- thanks for info, i look and see that in gcc/config.gcc is no amigaos target.also in gcc3.4 source here is not. I see 2.95 have this file not. but on other files 4.3.2 here the target is. Is there somewhere listet if it is planed to remove amigaos support ? I hope not, i compile with gcc3.4 the future enhancement of Amiga OS 68k called AFA OS (Aros for Amiga OS) available since 2 years. But now i like to use gcc4, also to get sometimes OWB running. I look now to find the working 3.4 sources for the amiga os, they seem on http://ftp.back2roots.org/geekgadgets but currently the server is down. then i hope i can build a patch to current gcc and send -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37524
[Bug fortran/37545] New: impossible to link with -fopenmp
gfortran -fopenmp test.f90 /home/lcoul/download/irun/bin/../lib/gcc/i586-pc-linux-gnu/4.4.0/../../../libgomp.so: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status Simple test program : PROGRAM test INTEGER,PARAMETER :: n=100 INTEGER :: a(n),b(n),i DO i=1,n a(i)=i ENDDO !$OMP PARALLEL DO DO i=1,n b(i)=a(i)**2 ENDDO !$OMP END PARALLEL DO WRITE(*,*) b END PROGRAM Notice that the same problem occurs on another similar computer (Debian etch) but with different undefined references (few pthread routines) -- Summary: impossible to link with -fopenmp Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: francois dot jacq at irsn dot fr GCC build triplet: 20080916 (experimental) [trunk revision 140386] GCC host triplet: i686-pc-linux-gnu Mandriva 2007.1 GCC target triplet: GNU Fortran (GCC) 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37545
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #30 from jorn dot amundsen at ntnu dot no 2008-09-16 18:23 --- (In reply to comment #29) I bootstrap GCC using GCC 4.1. I assume you use GCC 4.2 distributed by IBM. I usually use the currently installed gcc-version, which might be more recent than 4.2. I do not understand your comment in the initial report about forward porting of the 4.2.0 patches. Probably means you don't do this. Might be a key point. I apply the patches listed in ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/SPECS/gcc-4.2.0-3.spec to a more recent release. Most of the patches install with a small fuzz factor. I correct failing hunks, or remove a hunk if it appears to be present. Hence the wording forward porting. -- jorn dot amundsen at ntnu dot no changed: What|Removed |Added Status|WAITING |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug fortran/37545] impossible to link with -fopenmp
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-16 18:26 --- Did you compile gfortran yourself or are you using a prebuilt package? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37545
[Bug fortran/18584] --std=f would be nice
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-09-16 18:27 --- Closing as WONTFIX. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18584
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #31 from dje at gcc dot gnu dot org 2008-09-16 18:34 --- No, I do not use any patches from IBM. The patches seem to be focussed on packaging and layout, but I would recommend using the standard FSF GCC 4.3.2 release plus the pt.c patch that now is upstream in the FSF GCC sources. We cannot help you with a compiler that diverges from the FSF tree. Again, I am not sure which versions of GMP and MPFR you are using. I would recommend that you configure and build those packages with --disable-shared and ABI=32. You also can try running cc1plus inside GDB and compiling the files to see where the ICE occurs. Right now we cannot reproduce the failures and are flying blind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug c/37544] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #3 from jdemeyer at cage dot ugent dot be 2008-09-16 18:39 --- In fact, with -mno-sse the problem disappears for me too. I *do* get the problem with gcc -std=c99 -O1 -march=i386 -msse2 -mfpmath=387 -- jdemeyer at cage dot ugent dot be changed: What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug c/37544] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-16 18:44 --- Still works correctly on i386-darwin but that might be because PIC is turned on by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug fortran/37545] impossible to link with -fopenmp
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-09-16 18:50 --- Mandriva 2007.1 What's the version of your glibc? If less than 2.6, try upgrading. I guess this is a downloaded package that meets an (somewhat) outdated system ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37545
[Bug middle-end/37280] [4.4 Regression] weak symbol regression breaks linux kernel
--- Comment #9 from chaoyingfu at gcc dot gnu dot org 2008-09-16 18:54 --- Hi, I tried the following patch. http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00195.html .weak symbol can be emitted, but with two same lines. Thanks! Ex: .file 1 152.c .section .mdebug.abi32 .previous .gnu_attribute 4, 1 .text .align 2 .globl test .setnomips16 .enttest .type test, @function test: .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0 .mask 0x,0 .fmask 0x,0 .setnoreorder .setnomacro lui $2,%hi(arr) addiu $2,$2,%lo(arr) sll $4,$4,2 addu$4,$4,$2 j $31 lw $2,0($4) .setmacro .setreorder .endtest .size test, .-test .weak arr .weak arr .ident GCC: (GNU) 4.4.0 20080915 (experimental) [trunk revision 131984 ] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37280
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #32 from jorn dot amundsen at ntnu dot no 2008-09-16 19:09 --- (In reply to comment #31) No, I do not use any patches from IBM. The patches seem to be focussed on packaging and layout, but I would recommend using the standard FSF GCC 4.3.2 release plus the pt.c patch that now is upstream in the FSF GCC sources. We cannot help you with a compiler that diverges from the FSF tree. I will step back to GCC 4.3.2 + pt.c only, leaving out any IBM RPM patches. So a recompile is on its way. Will take some time. Again, I am not sure which versions of GMP and MPFR you are using. I would recommend that you configure and build those packages with --disable-shared and ABI=32. I use gmp 4.2.2 (compiling 4.2.3 just now) and mpfr 2.3.1. Both are compiled as 32- and 64-bit shared libs packaged in one .a-file. I usually compile everything except 64-bit libs with OBJECT_MODE=32. I doubt gcc even is possible to build 64-bit. You also can try running cc1plus inside GDB and compiling the files to see where the ICE occurs. Right now we cannot reproduce the failures and are flying blind. Yes, I have installed the latest gdb. Also, other GCC applications I've compiled works just fine in the Etnus Totalview debugger, which we have installed. However, main focus right now is to step back towards your build configuration and duplicate your build effort. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug middle-end/37280] [4.4 Regression] weak symbol regression breaks linux kernel
--- Comment #10 from aldot at gcc dot gnu dot org 2008-09-16 19:15 --- (In reply to comment #9) Hi, I tried the following patch. http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00195.html .weak symbol can be emitted, but with two same lines. Thanks! So that would bring you into the same situation as PR31537 is in (FE emits duplicate asm directives, quick workaround in the BE for weakrefs is attached to PR31537). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37280
[Bug target/37544] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-16 19:17 --- Confirmed on i686-linux with -std=c99 -O -msse2 -mfpmath=387 -march=i386. Fails since GCC 3.4 at least. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||3.4.6 Last reconfirmed|-00-00 00:00:00 |2008-09-16 19:17:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug c/31537] duplicate weakref emitted with IMA
--- Comment #10 from aldot at gcc dot gnu dot org 2008-09-16 19:17 --- unassigning. The BE workaround bypasses it for me, no time to look further. -- aldot at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|aldot at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31537
[Bug fortran/37546] New: impossible to link with -fopenmp
gfortran -fopenmp test.f90 /home/lcoul/download/irun/bin/../lib/gcc/i586-pc-linux-gnu/4.4.0/../../../libgomp.so: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status Simple test program : PROGRAM test INTEGER,PARAMETER :: n=100 INTEGER :: a(n),b(n),i DO i=1,n a(i)=i ENDDO !$OMP PARALLEL DO DO i=1,n b(i)=a(i)**2 ENDDO !$OMP END PARALLEL DO WRITE(*,*) b END PROGRAM Notice that the same problem occurs on another similar computer (Debian etch) but with different undefined references (few pthread routines) -- Summary: impossible to link with -fopenmp Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: francois dot jacq at irsn dot fr GCC build triplet: 20080916 (experimental) [trunk revision 140386] GCC host triplet: i686-pc-linux-gnu Mandriva 2007.1 GCC target triplet: GNU Fortran (GCC) 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37546
[Bug fortran/37546] impossible to link with -fopenmp
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-16 19:34 --- *** This bug has been marked as a duplicate of 37545 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37546
[Bug fortran/37545] impossible to link with -fopenmp
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-16 19:34 --- *** Bug 37546 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37545
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #33 from dje at gcc dot gnu dot org 2008-09-16 20:00 --- I have not tried MPFR as a shared library. One thing to be careful about with shared libraries on AIX is libpath. libtool configured for gmp and mpfr decides to hardcode the path and finds all of the GCC build directory paths. I manually edit the configured libtool to cleanup libpath. libgmp.a and libmpfr.a only need /usr/lib:/lib because they do not depend on shared libgcc.a. libgmpxx.a depends on the directories where libstdc++.a and libgcc_s.a are installed. cc1, cc1plus, etc. generally end up with sane libpaths, but libstdc++ (again built by libtool) includes a lot of junk directories. These latter dependencies would not affect the ICEs when building OpenFOAM, but you might want to be aware for the application itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug middle-end/37053] [4.3/4.4 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #5 from schwab at suse dot de 2008-09-16 21:00 --- Reverting this change in commutative_operand_precedence fixes the testcase: case RTX_OBJ: /* Complex expressions should be the first, so decrease priority - of objects. */ - return -1; + of objects. Prefer pointer objects over non pointer objects. */ + if ((REG_P (op) REG_POINTER (op)) + || (MEM_P (op) MEM_POINTER (op))) + return -1; + return -2; case RTX_COMM_ARITH: /* Prefer operands that are themselves commutative to be first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug middle-end/37053] [4.3/4.4 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #6 from bonzini at gnu dot org 2008-09-16 21:02 --- But that was the meat of fixing PR28690. :-( The insn should satisfy the constraints of alternative 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug testsuite/36889] [4.4 regression] gfortran.fortran-torture/execute/execute.exp tries to run sse2 execute tests without checking for host support
--- Comment #7 from jakub at gcc dot gnu dot org 2008-09-16 22:04 --- Subject: Bug 36889 Author: jakub Date: Tue Sep 16 22:02:37 2008 New Revision: 140398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140398 Log: PR testsuite/36889 * lib/fortran-torture.exp (get-fortran-torture-options): Only set test_tree_vectorize on i?86/x86_64 resp. sparc* if sse2 resp. ultrasparc hw is available. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/fortran-torture.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36889
[Bug c++/37532] [4.4 regression] ICE with decimal floating point data types
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-16 22:05 --- Subject: Bug 37532 Author: jakub Date: Tue Sep 16 22:03:57 2008 New Revision: 140399 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140399 Log: PR c++/37532 * lex.c (init_reswords): Don't populate ridpointers for D_CONLY reserved words. * g++.dg/parse/crash46.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/crash46.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/lex.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37532
[Bug c++/37531] [4.4 regression] ICE with invalid array initialization
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-16 22:06 --- Subject: Bug 37531 Author: jakub Date: Tue Sep 16 22:05:15 2008 New Revision: 140400 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140400 Log: PR c++/37531 * semantics.c (finish_compound_literal): Return error_mark_node if type is errorneous. * g++.dg/parse/crash47.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/crash47.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37531
[Bug c++/37530] [4.4 regression] ICE with invalid catch
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-16 22:07 --- Subject: Bug 37530 Author: jakub Date: Tue Sep 16 22:06:28 2008 New Revision: 140401 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140401 Log: PR c++/37530 * gimplify.c (gimplify_expr) case TRY_CATCH_EXPR: Don't create GIMPLE_TRY if cleanup sequence is empty. * g++.dg/parse/crash48.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/crash48.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37530
[Bug testsuite/36889] [4.4 regression] gfortran.fortran-torture/execute/execute.exp tries to run sse2 execute tests without checking for host support
--- Comment #8 from jakub at gcc dot gnu dot org 2008-09-16 22:09 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36889
[Bug c/37529] [4.4 regression] ICE with invalid goto
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-16 22:09 --- Subject: Bug 37529 Author: jakub Date: Tue Sep 16 22:08:01 2008 New Revision: 140402 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140402 Log: PR c/37529 * gimplify.c (gimplify_expr) case GOTO_EXPR: If gimplification of GOTO_DESTINATION failed, don't create GIMPLE_GOTO. * gcc.dg/pr37529.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr37529.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37529
[Bug c++/37532] [4.4 regression] ICE with decimal floating point data types
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-16 22:09 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37532
[Bug c++/37531] [4.4 regression] ICE with invalid array initialization
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-16 22:09 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37531
[Bug c++/37530] [4.4 regression] ICE with invalid catch
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-16 22:10 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37530
[Bug c/37529] [4.4 regression] ICE with invalid goto
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-16 22:10 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37529
[Bug c++/37530] [4.4 regression] ICE with invalid catch
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-16 22:16 --- And in fact the patch which fixed this one also fixed PR 37505. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37530
[Bug fortran/37536] [4.3/4.4 Regression] a mfcr is produced instead of branches for DO loops
--- Comment #8 from jakub at gcc dot gnu dot org 2008-09-16 22:17 --- An ifcombine optimization is certainly desirable, still IMHO it makes sense to do something about it in the FE too. The vanilla f951 generated code contains essentially 3 different conditional expressions on step 0, and one of those is assigned to a var to be used by another COND_EXPR. One is the empty COND_EXPR, another is step 0 ? to - from : from - to and another is ABS_EXPR step. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37536
[Bug rtl-optimization/37483] [4.4 Regression] Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional
--- Comment #8 from nemet at gcc dot gnu dot org 2008-09-16 22:17 --- Subject: Bug 37483 Author: nemet Date: Tue Sep 16 22:15:49 2008 New Revision: 140403 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140403 Log: PR rtl-optimization/37483 * ifcvt.c (noce_try_sign_mask): Use if_info-test_bb instead of if_info-insn_b's bb as argument to optimize_bb_for_speed_p. Rearrange code to better match the original comment. Check t_unconditional first. Improve comment. testsuite/ * gcc.c-torture/compile/pr37483.c: New test. * gcc.c-torture/compile/pr37395.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr37395.c trunk/gcc/testsuite/gcc.c-torture/compile/pr37483.c Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37483
[Bug rtl-optimization/37483] [4.4 Regression] Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional
--- Comment #9 from jakub at gcc dot gnu dot org 2008-09-16 22:17 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37483
[Bug c++/37505] [4.4 Regression] ICE after forgetting a catch after a try
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-16 22:20 --- *** This bug has been marked as a duplicate of 37530 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37505
[Bug c++/37530] [4.4 regression] ICE with invalid catch
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-16 22:20 --- *** Bug 37505 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37530
[Bug objc/34310] new objc testsuite failures from expected ';' before '__attribute__' under darwin9
--- Comment #2 from dominiq at lps dot ens dot fr 2008-09-16 22:21 --- /opt/gcc/i686-darwin/gcc/xgcc -B/opt/gcc/i686-darwin/gcc/ /opt/gcc/gcc-4.4-work/gcc/testsuite/objc/execute/bycopy-1.m -w -O0 -fnext-runtime -lobjc -lm -o /opt/gcc/i686-darwin/gcc/testsuite/objc/bycopy-1.x1 -save-temps gives In file included from /opt/gcc/gcc-4.4-work/gcc/testsuite/objc/execute/bycopy-1.m:8: /usr/include/objc/Protocol.h:46: error: expected ';' before '__attribute__' /usr/include/objc/Protocol.h:50: error: expected ';' before '__attribute__' /usr/include/objc/Protocol.h:54: error: expected ';' before '__attribute__' /usr/include/objc/Protocol.h:55: error: expected ';' before '__attribute__' I'll attach the preprocessed source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34310
[Bug objc/34310] new objc testsuite failures from expected ';' before '__attribute__' under darwin9
--- Comment #3 from dominiq at lps dot ens dot fr 2008-09-16 22:22 --- Created an attachment (id=16340) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16340action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34310
[Bug objc/34310] Attribute support for method
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-16 22:30 --- *** This bug has been marked as a duplicate of 7098 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34310
[Bug objc/7098] ObjC front end doesn't understand attributes on method parameters
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-16 22:30 --- *** Bug 34310 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||howarth at nitro dot med dot ||uc dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7098
[Bug objc/7098] ObjC front end doesn't understand attributes on method parameters
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-16 22:31 --- Grrr, looks like Apple's Runtime headers in Mac OS X 10.5 have attributes on the methods :(. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7098
[Bug c++/36741] [4.3/4.4 regression] Bogus large integer implicitly truncated passing size_t constant to new
--- Comment #22 from jakub at gcc dot gnu dot org 2008-09-16 22:59 --- Created an attachment (id=16341) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16341action=view) gcc44-pr36741.patch Only lightly tested patch that reverts the tree.c change and instead does size computation in build_new_1 in size_t instead of sizetype. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741
[Bug testsuite/25241] [C++] DejaGNU does not distinguish between errors and warnings
--- Comment #62 from janis at gcc dot gnu dot org 2008-09-17 00:08 --- Subject: Bug 25241 Author: janis Date: Wed Sep 17 00:06:57 2008 New Revision: 140405 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140405 Log: PR testsuite/25241 * testsuite/g++.dg/charset/attribute2.c: Replace dg-error with dg-warning or vice versa. * testsuite/g++.dg/conversion/dr195.C: Ditto. * testsuite/g++.dg/cpp0x/variadic60.C: Ditto. * testsuite/g++.dg/expr/cast2.C: Ditto. * testsuite/g++.dg/ext/anon-struct4.C: Ditto. * testsuite/g++.dg/ext/member-attr.C: Ditto. * testsuite/g++.dg/ext/utf-array.C: Ditto. * testsuite/g++.dg/ext/utf-array-short-wchar.C: Ditto. * testsuite/g++.dg/ext/utf-typedef-cxx0x.C: Ditto. * testsuite/g++.dg/ext/visibility/redecl1.C: Ditto. * testsuite/g++.dg/ext/visibility/warn4.C: Ditto. * testsuite/g++.dg/parse/defarg11.C: Ditto. * testsuite/g++.dg/template/error17.C: Ditto. * testsuite/g++.dg/warn/pedantic2.C: Ditto. * testsuite/g++.dg/warn/pr21983.C: Ditto. * testsuite/g++.dg/warn/return-reference2.C: Ditto. * testsuite/g++.old-deja/g++.bob/inherit1.C: Ditto. * testsuite/g++.old-deja/g++.brendan/crash13.C: Ditto. * testsuite/g++.old-deja/g++.brendan/crash17.C: Ditto. * testsuite/g++.old-deja/g++.brendan/crash52.C: Ditto. * testsuite/g++.old-deja/g++.brendan/crash55.C: Ditto. * testsuite/g++.old-deja/g++.brendan/enum7.C: Ditto. * testsuite/g++.old-deja/g++.brendan/operators4.C: Ditto. * testsuite/g++.old-deja/g++.brendan/template17.C: Ditto. * testsuite/g++.old-deja/g++.brendan/warnings1.C: Ditto. * testsuite/g++.old-deja/g++.bugs/900205_03.C: Ditto. * testsuite/g++.old-deja/g++.bugs/900227_01.C: Ditto. * testsuite/g++.old-deja/g++.ext/arrnew.C: Ditto. * testsuite/g++.old-deja/g++.ext/attrib4.C: Ditto. * testsuite/g++.old-deja/g++.jason/cond.C: Ditto. * testsuite/g++.old-deja/g++.jason/operator.C: Ditto. * testsuite/g++.old-deja/g++.jason/report.C: Ditto. * testsuite/g++.old-deja/g++.law/friend5.C: Ditto. * testsuite/g++.old-deja/g++.law/temps1.C: Ditto. * testsuite/g++.old-deja/g++.law/union4.C: Ditto. * testsuite/g++.old-deja/g++.martin/pure1.C: Ditto. * testsuite/g++.old-deja/g++.mike/empty.C: Ditto. * testsuite/g++.old-deja/g++.mike/for2.C: Ditto. * testsuite/g++.old-deja/g++.mike/misc9.C: Ditto. * testsuite/g++.old-deja/g++.mike/p10769b.C: Ditto. * testsuite/g++.old-deja/g++.mike/p2855.C: Ditto. * testsuite/g++.old-deja/g++.mike/p3060c.C: Ditto. * testsuite/g++.old-deja/g++.mike/p700.C: Ditto. * testsuite/g++.old-deja/g++.mike/p9732c.C: Ditto. * testsuite/g++.old-deja/g++.mike/pmf6.C: Ditto. * testsuite/g++.old-deja/g++.mike/warn1.C: Ditto. * testsuite/g++.old-deja/g++.mike/warn5.C: Ditto. * testsuite/g++.old-deja/g++.niklas/t141.C: Ditto. * testsuite/g++.old-deja/g++.other/cast6.C: Ditto. * testsuite/g++.old-deja/g++.other/cond5.C: Ditto. * testsuite/g++.old-deja/g++.other/conv8.C: Ditto. * testsuite/g++.old-deja/g++.other/decl5.C: Ditto. * testsuite/g++.old-deja/g++.other/delete2.C: Ditto. * testsuite/g++.old-deja/g++.other/delete4.C: Ditto. * testsuite/g++.old-deja/g++.other/linkage1.C: Ditto. * testsuite/g++.old-deja/g++.other/ptrmem8.C: Ditto. * testsuite/g++.old-deja/g++.other/typename1.C: Ditto. * testsuite/g++.old-deja/g++.pt/typename14.C: Ditto. * testsuite/g++.old-deja/g++.pt/typename4.C: Ditto. * testsuite/g++.old-deja/g++.pt/typename5.C: Ditto. * testsuite/g++.old-deja/g++.pt/typename7.C: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/charset/attribute2.c trunk/gcc/testsuite/g++.dg/conversion/dr195.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic60.C trunk/gcc/testsuite/g++.dg/expr/cast2.C trunk/gcc/testsuite/g++.dg/ext/anon-struct4.C trunk/gcc/testsuite/g++.dg/ext/member-attr.C trunk/gcc/testsuite/g++.dg/ext/utf-array-short-wchar.C trunk/gcc/testsuite/g++.dg/ext/utf-array.C trunk/gcc/testsuite/g++.dg/ext/utf-typedef-cxx0x.C trunk/gcc/testsuite/g++.dg/ext/visibility/redecl1.C trunk/gcc/testsuite/g++.dg/ext/visibility/warn4.C trunk/gcc/testsuite/g++.dg/parse/defarg11.C trunk/gcc/testsuite/g++.dg/template/error17.C trunk/gcc/testsuite/g++.dg/warn/pedantic2.C trunk/gcc/testsuite/g++.dg/warn/pr21983.C trunk/gcc/testsuite/g++.dg/warn/return-reference2.C trunk/gcc/testsuite/g++.old-deja/g++.bob/inherit1.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash13.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash17.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash52.C
[Bug libstdc++/37547] New: [c++0x] minmax with initializer_list gives incorrect results
The following testcase fails (with -std=gnu++0x):
#include utility
#include algorithm
#include vector
using namespace std;
int main()
{
vectorint v{1,2,3,4,5};
auto p = minmax({v});
if (p.first != v) std::abort();
return 0;
}
The value of v is something like [random number, 0, 3, 4, 5] for both p.frist
and p.second.
Chris
--
Summary: [c++0x] minmax with initializer_list gives incorrect
results
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris dot fairles at gmail dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37547
[Bug c/37548] New: printf does not process correctly the (bounded) conversion specification of strings
The C program below prints the full string xyz both times. I am using
GNU C version 4.1.2 20070925 (Red Hat 4.1.2-27) (x86_64-redhat-linux)
compiled by GNU C version 4.1.2 20070925 (Red Hat 4.1.2-27).
---
#include stdio.h
#include string.h
int main ( void )
{
char xyz[256];
strcpy(xyz,a not so random string);
printf(\n the string xyz is: \%s\\n\n,xyz);
printf(\n the 4 leftmost characters of xyz are: \%4s\\n\n,xyz);
return 0;
}
--
Summary: printf does not process correctly the (bounded)
conversion specification of strings
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paulo dot nogueira at ist dot utl dot pt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37548
[Bug c/37548] printf does not process correctly the (bounded) conversion specification of strings
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-17 01:00 --- The field width is not taken into account if there is more than that width. You also need to specify the precision. printf(\n the 4 leftmost characters of xyz are: \%.4s\\n\n,xyz); Will work. Note the . there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37548
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
--- Comment #7 from vmakarov at redhat dot com 2008-09-17 01:10 --- The patch I mentioned contains the following code at the end of ira-lives.c::process_bb_node_lives for all uses: mark uses as live for all clobbers: mark them as live for all clobbers: mark them dead The r25 are in uses and clobbers, so this code makes r25 dead on traversing to bb start which is quite wrong and results in that p171 does not conflict with r25. Besides the part of code for building conflicts is wrong, it is also too conservative. The input should conflict only with *early* clobbers. Processing only early clobbers on the two last line solves the problem (regular clobbers are still processed in ira-lives.c::process_bb_node_lives with defs). I'll sent the patch soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug preprocessor/37549] New: gcc -E -dD prints predefined macros, contrary to docs
The docs for preprocessor -dD flag states `D' Like `M' except in two respects: it does _not_ include the predefined macros So one would expect -dD and -dM to differ substantially. But ([EMAIL PROTECTED]) ~ $ gcc -E -dM -x c /dev/null | sort /tmp/t1 ([EMAIL PROTECTED]) ~ $ gcc -E -dD -x c /dev/null | sort /tmp/t2 ([EMAIL PROTECTED]) ~ $ diff /tmp/t[12] 0a1,4 # 1 built-in # 1 command-line # 1 /dev/null # 1 /dev/null ([EMAIL PROTECTED]) ~ $ wc /tmp/t[12] 111 340 3482 /tmp/t1 115 352 3552 /tmp/t2 226 692 7034 total ([EMAIL PROTECTED]) ~ $ gcc --version gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) -- Summary: gcc -E -dD prints predefined macros, contrary to docs Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37549
[Bug preprocessor/37550] New: Please document predefined sub-architecture support macros
The preprocessor symbol __MMX__ indicates whether this gcc includes mmx support. This is extremely useful, but undocumented. I only found out by finding the symbol in other peoples' code. The particular symbol __MMX__ should be documented in the obvious place, namely where the -mmmx flag is documented in the x86-specific page. And of course, similarly for other such predefined flags. I assume there's one for sse, but I haven't actually tried to find out. Here's a shell transcript, again compiling my favorite source file, /dev/null: ([EMAIL PROTECTED]) ~ $ gcc -mmmx -E -dD -x c /dev/null | sort /tmp/t1 ([EMAIL PROTECTED]) ~ $ gcc -mno-mmx -E -dD -x c /dev/null | sort /tmp/t2 ([EMAIL PROTECTED]) ~ $ diff /tmp/t[12] 92d91 #define __MMX__ 1 -- Summary: Please document predefined sub-architecture support macros Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37550
[Bug driver/37551] New: gcc help should provide subarchitecture details
How do I find out whether a particular gcc supports a particular subarchitecture, e.g. MMX instructions, by default? If the gcc has been configured --with-arch=, I can get that value using: gcc -v --help 21 | grep 'Configured with' but if the arch has defaulted based on the target triplet, it is less obvious. Is it documented that configure i486-xx is equivalent to configure --with-arch=i486 ? Even better, it would be nice if gcc -v --help said something like: mmx support is enabled (use -mno-mmx to disable it) sse support is disabled (use -msse to enable it) I would have guessed gcc -dumpspecs would give me this kind of information, but it appears not to. -- Summary: gcc help should provide subarchitecture details Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37551
Re: [Bug driver/37551] New: gcc help should provide subarchitecture details
Sent from my iPhone On Sep 16, 2008, at 7:44 PM, martinrb at google dot com [EMAIL PROTECTED] wrote: How do I find out whether a particular gcc supports a particular subarchitecture, e.g. MMX instructions, by default? If the gcc has been configured --with-arch=, I can get that value using: gcc -v --help 21 | grep 'Configured with' but if the arch has defaulted based on the target triplet, it is less obvious. Is it documented that configure i486-xx is equivalent to configure --with-arch=i486 ? Even better, it would be nice if gcc -v --help said something like: mmx support is enabled (use -mno-mmx to disable it) sse support is disabled (use -msse to enable it) I would have guessed gcc -dumpspecs would give me this kind of information, but it appears not to. This is already done in 4.3.0 where it shows the options and what are enabled already. -- Summary: gcc help should provide subarchitecture details Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37551
[Bug driver/37551] gcc help should provide subarchitecture details
--- Comment #1 from pinskia at gmail dot com 2008-09-17 03:09 --- Subject: Re: New: gcc help should provide subarchitecture details Sent from my iPhone On Sep 16, 2008, at 7:44 PM, martinrb at google dot com [EMAIL PROTECTED] wrote: How do I find out whether a particular gcc supports a particular subarchitecture, e.g. MMX instructions, by default? If the gcc has been configured --with-arch=, I can get that value using: gcc -v --help 21 | grep 'Configured with' but if the arch has defaulted based on the target triplet, it is less obvious. Is it documented that configure i486-xx is equivalent to configure --with-arch=i486 ? Even better, it would be nice if gcc -v --help said something like: mmx support is enabled (use -mno-mmx to disable it) sse support is disabled (use -msse to enable it) I would have guessed gcc -dumpspecs would give me this kind of information, but it appears not to. This is already done in 4.3.0 where it shows the options and what are enabled already. -- Summary: gcc help should provide subarchitecture details Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37551 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37551
Re: [Bug preprocessor/37550] New: Please document predefined sub-architecture support macros
Sent from my iPhone On Sep 16, 2008, at 7:35 PM, martinrb at google dot com [EMAIL PROTECTED] wrote: The preprocessor symbol __MMX__ indicates whether this gcc includes mmx support. This is extremely useful, but undocumented. I only found out by finding the symbol in other peoples' code. Some targets actually define this based some specifications of the target. Spu and -mcpu=cell on powerpc define __SPU__/__PPU__ as specified by the C/C++ language extension for the cbea document. I bet x86 has this specified in their documentation rather than in GCC's documentation. The particular symbol __MMX__ should be documented in the obvious place, namely where the -mmmx flag is documented in the x86-specific page. And of course, similarly for other such predefined flags. I assume there's one for sse, but I haven't actually tried to find out. Here's a shell transcript, again compiling my favorite source file, /dev/null: ([EMAIL PROTECTED]) ~ $ gcc -mmmx -E -dD -x c /dev/null | sort / tmp/t1 ([EMAIL PROTECTED]) ~ $ gcc -mno-mmx -E -dD -x c /dev/null | sort /tmp/t2 ([EMAIL PROTECTED]) ~ $ diff /tmp/t[12] 92d91 #define __MMX__ 1 -- Summary: Please document predefined sub-architecture support macros Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37550
Re: [Bug preprocessor/37549] New: gcc -E -dD prints predefined macros, contrary to docs
Sent from my iPhone On Sep 16, 2008, at 7:25 PM, martinrb at google dot com [EMAIL PROTECTED] wrote: The docs for preprocessor -dD flag states `D' Like `M' except in two respects: it does _not_ include the predefined macros I think what it means by predefines are the ones included on the command line that are defined by the user via -D. So one would expect -dD and -dM to differ substantially. But ([EMAIL PROTECTED]) ~ $ gcc -E -dM -x c /dev/null | sort /tmp/t1 ([EMAIL PROTECTED]) ~ $ gcc -E -dD -x c /dev/null | sort /tmp/t2 ([EMAIL PROTECTED]) ~ $ diff /tmp/t[12] 0a1,4 # 1 built-in # 1 command-line # 1 /dev/null # 1 /dev/null ([EMAIL PROTECTED]) ~ $ wc /tmp/t[12] 111 340 3482 /tmp/t1 115 352 3552 /tmp/t2 226 692 7034 total ([EMAIL PROTECTED]) ~ $ gcc --version gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) -- Summary: gcc -E -dD prints predefined macros, contrary to docs Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37549
[Bug preprocessor/37550] Please document predefined sub-architecture support macros
--- Comment #1 from pinskia at gmail dot com 2008-09-17 03:12 --- Subject: Re: New: Please document predefined sub-architecture support macros Sent from my iPhone On Sep 16, 2008, at 7:35 PM, martinrb at google dot com [EMAIL PROTECTED] wrote: The preprocessor symbol __MMX__ indicates whether this gcc includes mmx support. This is extremely useful, but undocumented. I only found out by finding the symbol in other peoples' code. Some targets actually define this based some specifications of the target. Spu and -mcpu=cell on powerpc define __SPU__/__PPU__ as specified by the C/C++ language extension for the cbea document. I bet x86 has this specified in their documentation rather than in GCC's documentation. The particular symbol __MMX__ should be documented in the obvious place, namely where the -mmmx flag is documented in the x86-specific page. And of course, similarly for other such predefined flags. I assume there's one for sse, but I haven't actually tried to find out. Here's a shell transcript, again compiling my favorite source file, /dev/null: ([EMAIL PROTECTED]) ~ $ gcc -mmmx -E -dD -x c /dev/null | sort / tmp/t1 ([EMAIL PROTECTED]) ~ $ gcc -mno-mmx -E -dD -x c /dev/null | sort /tmp/t2 ([EMAIL PROTECTED]) ~ $ diff /tmp/t[12] 92d91 #define __MMX__ 1 -- Summary: Please document predefined sub-architecture support macros Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37550 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37550
[Bug preprocessor/37549] gcc -E -dD prints predefined macros, contrary to docs
--- Comment #1 from pinskia at gmail dot com 2008-09-17 03:13 --- Subject: Re: New: gcc -E -dD prints predefined macros, contrary to docs Sent from my iPhone On Sep 16, 2008, at 7:25 PM, martinrb at google dot com [EMAIL PROTECTED] wrote: The docs for preprocessor -dD flag states `D' Like `M' except in two respects: it does _not_ include the predefined macros I think what it means by predefines are the ones included on the command line that are defined by the user via -D. So one would expect -dD and -dM to differ substantially. But ([EMAIL PROTECTED]) ~ $ gcc -E -dM -x c /dev/null | sort /tmp/t1 ([EMAIL PROTECTED]) ~ $ gcc -E -dD -x c /dev/null | sort /tmp/t2 ([EMAIL PROTECTED]) ~ $ diff /tmp/t[12] 0a1,4 # 1 built-in # 1 command-line # 1 /dev/null # 1 /dev/null ([EMAIL PROTECTED]) ~ $ wc /tmp/t[12] 111 340 3482 /tmp/t1 115 352 3552 /tmp/t2 226 692 7034 total ([EMAIL PROTECTED]) ~ $ gcc --version gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) -- Summary: gcc -E -dD prints predefined macros, contrary to docs Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37549 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37549
[Bug fortran/37498] [4.4 Regression] Incorrect array value returned
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-09-17 04:13
---
Created an attachment (id=16342)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16342action=view)
Partial patch - reordering of st_parameter_dt structure
I think I may know why the attached patch does not completely work. Runtime
library side is fine. In trans-io.c (build_dt) we are not actually building
the pad structure which is a character array. We do build the type declaration
for this structure elsewhere.
I think that without building the code for the pad, building of the
componenets after pad get messed up because they are not getting chained onto
the end of anything. I am not a tree expert but it seems intuitive to me that
this or something similar is the problem.
Using gdb you can view the runtime and you can see some of the pieces of
attempts to set the dtparms after the union of p and pad, but they are miss
placed or misaligned.
Test case I use:
real a
a = 3.141591
open(10, file='mydata', asynchronous=yes, blank=null)
write(10,'(10f8.6)', asynchronous=yes, decimal=point, id=j) a
end
gdb view: break at data_transfer_init and I print this after the pad is cleared
to shorton the output.
(gdb) p *dtp
$2 = {common = {flags = 1380352, unit = 10,
filename = 0x400a00 f2003_io_1.f03, line = 8, iomsg_len = 32681,
iomsg = 0x0, iostat = 0x1}, rec = 25769803782, size = 0x400a0f,
iolength = 0x3fef4091f1, internal_unit_desc = 0x7fffa8611770,
format = 0x400a21 (10f8.6), format_len = 8, advance_len = 32767,
advance = 0x4f0603b38 Address 0x4f0603b38 out of bounds,
internal_unit = 0x400a15 nullyespoint(10f8.6),
internal_unit_len = -1470031696, namelist_name_len = 32767,
namelist_name = 0x7fa9a0614000 , u = {p = {transfer = 0,
current_unit = 0x0, item_count = 0, mode = READING,
blank_status = BLANK_NULL, sign_status = SIGN_S, scale_factor = 0,
max_pos = 0, skips = 0, pending_spaces = 0, sf_seen_eor = 0,
advance_status = ADVANCE_YES, reversion_flag = 0, first_item = 0,
seen_dollar = 0, eor_condition = 0, no_leading_blank = 0, char_flag = 0,
input_complete = 0, at_eol = 0, comma_flag = 0, namelist_mode = 0,
nml_read_error = 0, sf_read_comma = 0, line_buffer_enabled = 0,
unit_is_internal = 0, at_eof = 0, last_char = 0 '\0',
nml_delim = 0 '\0', repeat_count = 0, saved_length = 0, saved_used = 0,
saved_type = BT_NULL, saved_string = 0x0, scratch = 0x0,
line_buffer = 0x0, fmt = 0x0, eof_jump = 0x0, ionml = 0x0,
expanded_read = 0, value = '\0' repeats 31 times, size_used = 0,
pad_status = PAD_YES, decimal_status = DECIMAL_POINT,
delim_status = DELIM_NONE}, pad = '\0' repeats 255 times},
id = 0x3fef40d185, pos = 1, asynchronous = 0x7fffa8611908 ,
asynchronous_len = 256, blank_len = 0,
blank = 0x3 Address 0x3 out of bounds,
decimal = 0x400a19 yespoint(10f8.6), decimal_len = 1, delim_len = 0,
delim = 0x5a8611a18 Address 0x5a8611a18 out of bounds,
pad = 0x400a1c point(10f8.6), pad_len = -258655760, round_len = 63,
round = 0x400900 L\211d$#65533;L\211l$#65533;L\215%\033\002 ,
sign = 0x7fffa8611a28 #65533;6a#65533;#65533;\177, sign_len =
-1470031336}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
[Bug preprocessor/37549] gcc -E -dD prints predefined macros, contrary to docs
--- Comment #2 from martinrb at google dot com 2008-09-17 04:27 --- I tried to check how -dM and -dD treats macros defined on the command line and in the source file: ([EMAIL PROTECTED]) ~/src/toy $ cat foo.c #define FOO 1 ([EMAIL PROTECTED]) ~/src/toy $ gcc -E -dM -x c -DBAR=1 foo.c | sort /tmp/t1 ([EMAIL PROTECTED]) ~/src/toy $ gcc -E -dD -x c -DBAR=1 foo.c | sort /tmp/t2 ([EMAIL PROTECTED]) ~/src/toy $ diff /tmp/t[12] 0a1,4 # 1 built-in # 1 command-line # 1 foo.c # 1 foo.c = No difference in the treatment of various classes of macros. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37549
