[Bug libfortran/35293] New: [4.4 Regression] truncation errors with gfortran.dg/streamio_11.f90, 3, 4 and 15.

With a commit in the range 132503:132513, gfortran.dg/streamio_11.f90 gfortran.dg/streamio_3.f90 and gfortran.dg/streamio_4.f90 started to fail, besides the new test gfortran.dg/streamio_15.f90. The failure is just a call to abort. The patch exposing the failure seems to be

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

--- Comment #20 from ubizjak at gmail dot com 2008-02-22 06:54 --- (In reply to comment #18) > call this single target hook: Paolo, Uros, could you work that bit out? (It's I'll look into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477

[Bug middle-end/35290] New: Missing dead store elimination

void foo(int*p, int*q) { *p = 10; // <<--- dead, but not removed *q = 20; *p = 30; } int g; void bar(int* p) { *p = 10; // Dead -- not removed. g = 1; *p = 10; } -- Summary: Missing dead store elimination Product: gcc Version: unknown

[Bug middle-end/35292] New: Missing Const Prop -- union fields

union U { struct C { char c[4]; }cc; int ii; } u ; int foo(int i) { u.ii = 20; return u.cc.c[0] + u.cc.c[1]; // Const prop target -- not performed } -- Summary: Missing Const Prop -- union fields Product: gcc Version: unknown

[Bug middle-end/35291] New: Missing DCE for union fields

union U { struct C { char c[4]; }cc; int ii; } u ; void foo(int i) { u.cc.c[0] = 10; // Dead u.cc.c[1] = 10; // Dead too u.cc.c[i] = 10; // Dead too u.ii = 20; } -- Summary: Missing DCE for union fields Product: gcc Version: unknow

[Bug middle-end/35289] New: missing CSE of division (lack of reassociation)

double a,b,c,d,e,f; // int a,b,c,d,e,f; void foo() { e = b*c/d; f = b/d*a; } Compile with -O3 -ffast-math, b/d should be CSEed. -- Summary: missing CSE of division (lack of reassociation) Product: gcc Version: unknown Status: UNCONFIRMED

[Bug middle-end/35288] New: Expression reassociation problem

The second instance of a1+a2 is not PREed due to missing expression reassociation. int foo(int a1, int a2, int a3) { int b1,b2; b1 = a3 + a2 + a1; b2 = a1 + a2; return b1 + b2; } -- Summary: Expression reassociation problem Product: gcc Version: unk

[Bug middle-end/35287] New: Missing PRE for indirect load

Daniel is aware of the problem. In the followign example, *gp at return is partially redundant. Not eliminated. int *gp; int g, g2; int foo(int p) { int t = 0; if (p) t = *gp + 1; return (*gp + t); } -- Summary: Missing PRE for indirect load Product: gcc

[Bug middle-end/35286] New: Missing PRE for globals

This was discussed with Dan Berlin. File this report as a place holder for the problem. In the following example, load of g1.a at return statement is fully redundant, but not removed. int g2; struct A { int a; int b; }g1; int foo(int a, int b) { if (a > 0) { g1.a = a+ b; } els

[Bug fortran/34907] valgrind error indication from testsuite trans-types.c: gfc_typenode_for_spec

--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-02-22 06:22 --- Subject: Bug 34907 Author: jvdelisle Date: Fri Feb 22 06:21:47 2008 New Revision: 132541 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132541 Log: 2008-02-20 Jerry DeLisle <[EMAIL PROTECTED]>

[Bug c/19999] -Wfloat-equal does not warn for complex numbers

--- Comment #4 from rwild at gcc dot gnu dot org 2008-02-22 06:19 --- Fixed in 4.4. -- rwild at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug c/19999] -Wfloat-equal does not warn for complex numbers

--- Comment #3 from rwild at gcc dot gnu dot org 2008-02-22 06:18 --- Subject: Bug 1 Author: rwild Date: Fri Feb 22 06:17:46 2008 New Revision: 132540 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132540 Log: gcc/: PR c/1 * c-typeck.c (build_binary_op): Warn about float

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

--- Comment #19 from howarth at nitro dot med dot uc dot edu 2008-02-22 04:08 --- FX, I posted a modified version of Andrew's proposed patch awhile back... http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01809.html which had additional changes to gcc/config/rs6000/darwin.h and gcc/

[Bug target/34790] [avr] no sibling call optimisation

--- Comment #3 from eric dot weddington at atmel dot com 2008-02-22 04:02 --- Can you try using linker relaxation?: -Wl,--relax Linker relaxation is implemented in ld for the AVR port, even though the documentation doesn't say so. IIRC, tail call optimization is implemented in linker r

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

--- Comment #13 from janis at gcc dot gnu dot org 2008-02-22 01:58 --- Subject: Bug 34526 Author: janis Date: Fri Feb 22 01:57:56 2008 New Revision: 132538 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132538 Log: PR target/34526 * config/rs6000/rs6000.c (rs6000

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

--- Comment #12 from janis at gcc dot gnu dot org 2008-02-22 01:56 --- Subject: Bug 34526 Author: janis Date: Fri Feb 22 01:55:40 2008 New Revision: 132537 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132537 Log: PR target/34526 * config/rs6000/rs6000.c (rs6000

[Bug target/34790] [avr] no sibling call optimisation

--- Comment #2 from hutchinsonandy at aim dot com 2008-02-22 01:43 --- We have not gotten around to adding support for tail calls for avr. So nothing happens. So it is not a bug - but a still a valid feature request. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34790

[Bug target/34789] [avr] sometimes the compiler keeps addresses in registers unnecessarily

--- Comment #1 from hutchinsonandy at aim dot com 2008-02-22 01:22 --- This appears to be due to avr_rtx_costs not assigning same cost to SYMBOL_REF and CONST_INT. So SYMBOL_REF looks expensive - so is held in register to avoid "recalculating" it. Quick change to make SYMBOL_REF same co

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

--- Comment #18 from fxcoudert at gcc dot gnu dot org 2008-02-22 00:34 --- Created an attachment (id=15203) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15203&action=view) Partial patch Another approach, maybe more efficient, is to offer a target hook to "fix builtins" after the

[Bug ada/35284] Branch to 0x0 from Ada run-time

--- Comment #7 from joel dot sherrill at oarcorp dot com 2008-02-21 23:55 --- Subject: Re: Branch to 0x0 from Ada run-time laurent at guerby dot net wrote: > --- Comment #6 from laurent at guerby dot net 2008-02-21 22:59 --- > Could you post the exact backtrace on my testcase

[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected

--- Comment #2 from pcarlini at suse dot de 2008-02-21 23:13 --- Never mind, I did something wrong in my quick check. I can confirm it's my patch. I'll try to look a bit into it, but beyond reverting it, I cannot promise to be able to fix the present issue without regressing on 28743...

[Bug fortran/35285] New: Failures in the NIST test suite FM827 with -m64

I noticed today (gcc version 4.4.0 20080221) two failures in FM827 when running the NIST test suite with -m64. I have reduced the code to: PROGRAM FM827 DOUBLE PRECISION AVD, BVD, CVD, DVD, DVCORR IVPASS = 0 IVFAIL = 0 IVDELE = 0 IVINSP = 0

[Bug ada/35284] Branch to 0x0 from Ada run-time

--- Comment #6 from laurent at guerby dot net 2008-02-21 22:59 --- Could you post the exact backtrace on my testcase? It purposely doesn't use the complex Text_IO so things should be clearer. Also if you could use gdb to get an understanding of what is done during adainit execution befor

[Bug ada/35284] Branch to 0x0 from Ada run-time

--- Comment #5 from joel at gcc dot gnu dot org 2008-02-21 22:53 --- Created an attachment (id=15202) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15202&action=view) generated from Laurent's t.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284

[Bug ada/35284] Branch to 0x0 from Ada run-time

--- Comment #4 from joel at gcc dot gnu dot org 2008-02-21 22:52 --- Runs OK on powerpc/psim and sparc/sis built from the same source tree for GCC and RTEMS. Fails like a99006a on i386. Are there only ~300 tests which rely on tasking? I posted this URL: http://gcc.gnu.org/ml/gcc-test

[Bug ada/35284] Branch to 0x0 from Ada run-time

--- Comment #3 from laurent at guerby dot net 2008-02-21 22:32 --- The great majority of FAIL are tests with an Ada task so my guess is that tasking is broken. I'm not a specialist but GNAT soft links are pointers to function which are set by the elaboration code to point to tasking or

[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected

--- Comment #1 from pcarlini at suse dot de 2008-02-21 22:25 --- Please double check, but I don't think it's my patch: I tried quickly reverting it and interestingly nothing changes: 28743 doesn't ICE and this one is rejected. It seems something new is going on in this area... Maybe Jani

[Bug ada/35284] Branch to 0x0 from Ada run-time

--- Comment #2 from joel at gcc dot gnu dot org 2008-02-21 22:11 --- Created an attachment (id=15201) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15201&action=view) numerically sorted symbol table matching qemu.log This is the numerically sorted symbol table matching the attache

[Bug ada/35284] Branch to 0x0 from Ada run-time

--- Comment #1 from joel at gcc dot gnu dot org 2008-02-21 22:10 --- Created an attachment (id=15200) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15200&action=view) QEMU trace up to branch to 0x0 Search for "^0x" and then scroll backwards to see the indirect call in ques

[Bug ada/35284] New: Branch to 0x0 from Ada run-time

As reported in http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00747.html, I am seeing a few hundred failures for ACATS on i386-rtems4.9. The failure set appears to be about the same for 5.3.4, 4.3-branch, and SVN trunk. I am trying to debug this on the SVN trunk. I have finally captured the fa

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

--- Comment #7 from tege-gcc at swox dot com 2008-02-21 22:01 --- Sorry, but you ought to read and understand what I write before you comment, otherwise it becomes rather pointless. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271

[Bug rtl-optimization/35281] [4.3 regression] multiply with 0 generated for 64*32->64

--- Comment #2 from astrange at ithinksw dot com 2008-02-21 21:58 --- Created an attachment (id=15199) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15199&action=view) source Oh, I forgot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281

[Bug fortran/35280] ICE on invalid print statement

--- Comment #1 from dfranke at gcc dot gnu dot org 2008-02-21 21:58 --- Confirmed ICE with 4.1.2 and 4.2.4. However, 4.3 (20080210) gives: pr35280.f90:3.7: print n 1 Error: Constant expression in FORMAT tag at (1) must be of type default CHARACTER Closing. -- dfranke at gcc

[Bug tree-optimization/26069] [4.0/4.1/4.2/4.3/4.4 Regression] Runtime endian-ness check is no longer optimized out.

--- Comment #21 from ubizjak at gmail dot com 2008-02-21 21:54 --- (In reply to comment #20) > Here are 2 alternatives I've been playing with: Any news on this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26069

[Bug rtl-optimization/35281] [4.3 regression] multiply with 0 generated for 64*32->64

--- Comment #1 from ubizjak at gmail dot com 2008-02-21 21:35 --- I know that the test sources are probably trivial, but can you post them here for reference? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

--- Comment #17 from ubizjak at gmail dot com 2008-02-21 21:28 --- (In reply to comment #16) > So this line of add_builtin_function > > tree libname = get_identifier (library_name); > > should instead invoke a target hook (defaulting to get_identifier)? And IMO http://gcc.gnu.or

[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected

-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282

[Bug c++/35282] New: [4.3/4.4 regression] Template specialization rejected

The following valid testcase is rejected on mainline and 4.3 branch: = template struct A { template void foo(); }; template<> template void A<0>::foo() {} = The regression was introduced between 2

[Bug c++/34824] [4.1/4.2 Regression] ICE with explicit copy constructor

--- Comment #11 from reichelt at gcc dot gnu dot org 2008-02-21 21:07 --- Adjust target milestone. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added GCC b

[Bug rtl-optimization/35281] New: [4.3 regression] multiply with 0 generated for 64*32->64

> /usr/local/gcc43/bin/gcc -v Using built-in specs. Target: i386-apple-darwin9.2.0 Configured with: ../gcc/configure --prefix=/usr/local/gcc43 --enable-threads=posix --with-arch=core2 --with-tune=core2 --with-gmp=/sw --with-mpfr=/sw --disable-nls --disable

[Bug bootstrap/35273] [4.3 Regression] Bootstrap of mingw32 using non-MSYS shell broken

--- Comment #7 from rwild at gcc dot gnu dot org 2008-02-21 20:07 --- (In reply to comment #3) > > Yes, it was approved by Jakub. > > To be precise, approved by Paolo in > http://gcc.gnu.org/ml/gcc/2008-02/msg00410.html > and acked for 4.3 by me. Yes, sorry for being imprecise. > Anyw

[Bug bootstrap/35273] [4.3 Regression] Bootstrap of mingw32 using non-MSYS shell broken

--- Comment #6 from rwild at gcc dot gnu dot org 2008-02-21 20:05 --- Subject: Bug 35273 Author: rwild Date: Thu Feb 21 20:05:11 2008 New Revision: 132530 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132530 Log: PR bootstrap/35273 * config.build (build_file_translate): Set to

[Bug fortran/35280] New: ICE on invalid print statement

If you leave out the format of a print statement, as in program test integer, parameter :: n = 2 print n end program test ...you get an ICE instead of an error message. I can't run the latest version of gfortran now, so please close if this is already fixed. -- Summar

[Bug bootstrap/35273] [4.3 Regression] Bootstrap of mingw32 using non-MSYS shell broken

--- Comment #5 from rwild at gcc dot gnu dot org 2008-02-21 19:57 --- Subject: Bug 35273 Author: rwild Date: Thu Feb 21 19:56:23 2008 New Revision: 132529 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132529 Log: PR bootstrap/35273 * config.build (build_file_translate): Set to

[Bug bootstrap/35273] [4.3 Regression] Bootstrap of mingw32 using non-MSYS shell broken

--- Comment #4 from rwild at gcc dot gnu dot org 2008-02-21 19:56 --- Subject: Bug 35273 Author: rwild Date: Thu Feb 21 19:55:39 2008 New Revision: 132528 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132528 Log: PR bootstrap/35273 * config.build (build_file_translate): Set to

[Bug target/10901] non-local goto's don't work on powerpc-darwin

--- Comment #18 from mrs at apple dot com 2008-02-21 19:48 --- Nope. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901

[Bug c/35279] incorrect "array subscript is above array bounds" warning in loop at -O3

--- Comment #1 from rjpeters at klab dot caltech dot edu 2008-02-21 19:47 --- Created an attachment (id=15197) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15197&action=view) test case; compile with "-Wall -O3" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35279

[Bug c/35279] New: incorrect "array subscript is above array bounds" warning in loop at -O3

With -O3, I get an apparently incorrect "array subscript is above array bounds" warning when a multidimensional array is passed to a function and accessed in a loop: $ /home/tmp/u/rjpeters/gcc-svn-install/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /home/tmp/

[Bug bootstrap/35273] [4.3 Regression] Bootstrap of mingw32 using non-MSYS shell broken

--- Comment #3 from jakub at gcc dot gnu dot org 2008-02-21 19:34 --- > Yes, it was approved by Jakub. To be precise, approved by Paolo in http://gcc.gnu.org/ml/gcc/2008-02/msg00410.html and acked for 4.3 by me. Anyway, AFAIK the http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00877.html

[Bug target/10901] non-local goto's don't work on powerpc-darwin

--- Comment #17 from fxcoudert at gcc dot gnu dot org 2008-02-21 18:47 --- (In reply to comment #16) > Our positron branch has the fix for this in it. We should dig it out and > submit it. Mike, any news on that? You can still make it in time for the 5th anniversary of this PR! :) -

[Bug target/29660] get 'internal compiler error' when building numerical recipes

--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-02-21 18:44 --- gfortran-4.0.1 is really old, this code works fine for 4.3.0 so I suggest we close it as WONTFIX. Please reopen if you can reproduce this with a more recent compiler. Thanks for the bug report. -- fxcoudert a

[Bug c++/35278] New: extern declaration causes uninitialized reference to go unnoticed

The following program correctly generates an error: --- int& g_foo; --- $ ~/gcc/bin/g++ -c -Wall test.cpp test.cpp:1: error: 'g_foo' declared as reference but not initialized The following program fails to generate an error (which seemingly is a violation of the C++ standard) but also doesn't even

[Bug libstdc++/34797] [parallel mode] Settings are separated for each compilation unit

--- Comment #7 from pcarlini at suse dot de 2008-02-21 17:06 --- I understand this is fixed now. Otherwise, please reopen (and sorry ;) -- pcarlini at suse dot de changed: What|Removed |Added

[Bug libstdc++/35256] Bad link on http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html

--- Comment #2 from bkoz at gcc dot gnu dot org 2008-02-21 16:52 --- Mine. I need to redo this page anyway. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added

[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop

--- Comment #4 from aldot at gcc dot gnu dot org 2008-02-21 16:44 --- -frtl-abstract-sequences should IMHO be turned on per default for at least -Os in 4.4 Otherwise literally nobody will notice if it's broken. thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

--- Comment #16 from bonzini at gnu dot org 2008-02-21 16:32 --- So this line of add_builtin_function tree libname = get_identifier (library_name); should instead invoke a target hook (defaulting to get_identifier)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

--- Comment #6 from pinskia at gcc dot gnu dot org 2008-02-21 15:53 --- > int variable; This variable does not have be aligned 16byte. > long long ebi, windowsize, last_windowsize; Or even these. The first one is word aligned. The second one just has to be 8 byte aligned. --

[Bug rtl-optimization/34522] inefficient code for long long multiply when only low bits are needed

--- Comment #5 from bonzini at gnu dot org 2008-02-21 15:52 --- I want to clear 17236 first (and Jakub's tweaks are needed anyway). Feel free to beat me to it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

--- Comment #15 from pinskia at gcc dot gnu dot org 2008-02-21 15:50 --- (In reply to comment #14) > How does the header manage to fix this? The normal functions have the asm extension on them which causes the builtins to change also. -- Pinski -- http://gcc.gnu.org/bugzilla/show

[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop

--- Comment #3 from loki at gcc dot gnu dot org 2008-02-21 15:48 --- I can confirm the infinite loop too (r132521). I am going to look into it. -- loki at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

--- Comment #14 from rguenth at gcc dot gnu dot org 2008-02-21 15:48 --- How does the header manage to fix this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477

[Bug rtl-optimization/34522] inefficient code for long long multiply when only low bits are needed

--- Comment #4 from ubizjak at gmail dot com 2008-02-21 15:41 --- (In reply to comment #1) > Prototype untested patch. Produces Paolo, do you plan to test your patch and submit it to gcc-patches@ ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522

[Bug c/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs

-- rwild at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fa

[Bug c/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs

--- Comment #6 from rwild at gcc dot gnu dot org 2008-02-21 15:32 --- *** Bug 35277 has been marked as a duplicate of this bug. *** -- rwild at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug other/35277] x86_64 configure option combo yields broken compiler

--- Comment #1 from rwild at gcc dot gnu dot org 2008-02-21 15:32 --- *** This bug has been marked as a duplicate of 32415 *** -- rwild at gcc dot gnu dot org changed: What|Removed |Added --

[Bug other/35277] New: x86_64 configure option combo yields broken compiler

This might be a dumb user error but since it works on 32-bit Fedora's, I thought it best to file a PR and let you folks decide. On Fedora 7 or 8, when you configure like this, the libgcc_s.o files do not end up in an install directory that gcc can find afterwards. So you end up getting a link err

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

--- Comment #13 from fxcoudert at gcc dot gnu dot org 2008-02-21 14:12 --- Still there with on trunk (4.4) and MacOS 10.5.2: $ cat s.c int main (void) { long double x; double y; x = -0.24; y = x; __builtin_printf ("%g %g %g\n", (float) __builtin_asinl(x), (

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

--- Comment #5 from tege-gcc at swox dot com 2008-02-21 14:01 --- The attachment is not the right file. I tried to "edit" it but I cannot find out how to do it. The proper test case is in the comment before this one. Sorry, I am bugzilla challenged. -- http://gcc.gnu.org/bugzilla/sh

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

--- Comment #4 from tege-gcc at swox dot com 2008-02-21 13:57 --- (From update of attachment 15196) #include long align; foo (int flag) { int variable; if (flag == 0) return (((long)&variable ^ align) & 0xf); align = (long)&variable; foo (flag - 1); } main () { if (foo

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

--- Comment #3 from tege-gcc at swox dot com 2008-02-21 13:53 --- Testcase? Because we do align it for both x86_64-* and i386-darwin. Well, not as mandated in the 64-bit ABI. Now the SVSV i386 ABI says it should be aligned at 4 (word) bytes boundary. This is hardly

[Bug libfortran/32841] [4.3/4.4 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

--- Comment #28 from fxcoudert at gcc dot gnu dot org 2008-02-21 13:50 --- That 27-headed (and counting!) monster PR is really hard to deal with. Here is some more information: -- On powerpc-apple-darwin-9.2.0 (MacOS 10.5.2), the testcases in comments #0 (original report) and #10 giv

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

--- Comment #2 from tege-gcc at swox dot com 2008-02-21 13:49 --- Created an attachment (id=15196) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15196&action=view) Alignment test This is not a strictly correct test case, it may fail even if the compiler aligns the stack properly,

[Bug target/35264] [4.3/4.4 regression] ntfs-3g miscompiled

--- Comment #6 from matz at gcc dot gnu dot org 2008-02-21 12:41 --- Fixed in 4.3 and trunk. -- matz at gcc dot gnu dot org changed: What|Removed |Added Statu

[Bug target/35264] [4.3/4.4 regression] ntfs-3g miscompiled

--- Comment #5 from matz at gcc dot gnu dot org 2008-02-21 12:39 --- Subject: Bug 35264 Author: matz Date: Thu Feb 21 12:38:35 2008 New Revision: 132521 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132521 Log: PR target/35264 * config/i386/i386.c (ix86_expand_b

[Bug target/35264] [4.3/4.4 regression] ntfs-3g miscompiled

--- Comment #4 from matz at gcc dot gnu dot org 2008-02-21 12:30 --- Subject: Bug 35264 Author: matz Date: Thu Feb 21 12:30:00 2008 New Revision: 132520 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132520 Log: PR target/35264 * config/i386/i386.c (ix86_expand_b

[Bug fortran/35276] Doc should described how to compile mixed-language programs

-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276

[Bug target/35264] [4.3/4.4 regression] ntfs-3g miscompiled

--- Comment #3 from cnstar9988 at gmail dot com 2008-02-21 10:26 --- confirmed. Checked out revision 132515 gcc version 4.3.0 20080221 (prerelease) (GCC) gcc -O1 -m32 test.c aborted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35264

[Bug fortran/35276] Doc should described how to compile mixed-language programs

--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-02-21 10:07 --- I've posted explanations and examples on comp.lang.fortran that might be used as a starting point: http://groups.google.com/group/comp.lang.fortran/msg/a62f1aa0c1592838 Linking to C++ and other languages might al

[Bug fortran/35276] New: Doc should described how to compile mixed-language programs

I think "Part I: Invoking GNU Fortran" of the gfortran documentation should have a section on "Compiling (and linking) mixed-language programs". Whether this should be a section or a subsection I don't know, but it's really a commonly asked question and we ought to have explanations and examples of

[Bug c++/35275] New: Operator<< for embedded class of templetized class isn't found

The following code produces an error on the second line inside of main: error: no match for 'operator<<' in 'std::cout << C::E()' C++ frontend fails to find the templetized operator<<. -- begin code #include using namespace std; template struct C { struct E { }; }; tem

[Bug fortran/35259] -fassociative-math not enabled by default; No option to associate with PAREN_EXPRs

--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-21 09:56 --- Summary slightly changed. There are two issues now: - We still do not allow re-association by default, even if we would honor PAREN_EXPR - There is no way to allow re-association in the face of PAREN_EXPR -

[Bug fortran/34685] Honour parentheses in expressions

--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-21 09:53 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug bootstrap/35273] [4.3 Regression] Bootstrap of mingw32 using non-MSYS shell broken

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keyw

[Bug c/28319] sentinel attribute should support non-NULL sentinels

--- Comment #2 from ludo at gnu dot org 2008-02-21 09:00 --- (In reply to comment #1) > The only time I can think this comes up is that the sentinel is -1. As another example, GNU Guile has a number of variadic functions (e.g., `scm_list_n ()') whose sentinel is `SCM_UNDEFINED' (which h

[Bug bootstrap/25672] [4.1/4.2/4.3 regression] cross build's libgcc picks up CFLAGS

--- Comment #21 from bonzini at gnu dot org 2008-02-21 08:13 --- fixed in 4.4.0 -- bonzini at gnu dot org changed: What|Removed |Added Known to work|4.0.2