[Bug testsuite/39537] overhaul printf formats and type casts in testsuite

--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-24 06:54 --- Let's look at the testcases: g++.dg/ext/align1.C: a run testcase, the printf can be removed in this case. g++.old-deja/g++.law/operators28.C: An assemble only testcase so the undefined behavior is not invoked at runt

[Bug testsuite/39537] overhaul printf formats and type casts in testsuite

--- Comment #1 from kees at outflux dot net 2009-03-24 06:34 --- Created an attachment (id=17530) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17530&action=view) testsuite updates for format strings and casts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39537

[Bug testsuite/39537] New: overhaul printf formats and type casts in testsuite

Ubuntu's builds of GCC enable non-standard options (specifically -Wformat-security and -Wformat). In an attempt to maintain parity with the upstream testsuite output, I've gone through the testsuite and located many architecture-dependent format-string/type discontinuities (e.g. %d should be %ld f

[Bug testsuite/39536] add more VERIFY() calls to certain functions in libstdc++-v3 testsuite

--- Comment #1 from kees at outflux dot net 2009-03-24 06:27 --- Created an attachment (id=17529) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17529&action=view) more VERIFY() calls in libstdc++ testsuite -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39536

[Bug testsuite/39536] New: add more VERIFY() calls to certain functions in libstdc++-v3 testsuite

This patch adds additional calls to VERIFY() on several functions to catch additional error conditions. -- Summary: add more VERIFY() calls to certain functions in libstdc++-v3 testsuite Product: gcc Version: 4.4.0 Status: UNCONFIR

[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

--- Comment #9 from aran at 100acres dot us 2009-03-24 06:16 --- Created an attachment (id=17528) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17528&action=view) Removes problematic fixincludes and defines _ANSI_H in stddef.h This is a combination of the other two patches. GCC's

[Bug debug/39527] wrong function name and line numbers with -g -O2 option

--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-24 05:16 --- *** Bug 39535 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39527

[Bug debug/39535] wrong function name and line numbers with -g -O2 option

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-24 05:16 --- Please reopen PR 39527 if it is a GCC issue. As far as I can tell it is not a GCC issue from looking at the debugging information from i686-linux-gnu. *** This bug has been marked as a duplicate of 39527 *** --

[Bug c++/38030] [4.2/4.3 Regression] name-lookup for non-dependent name in template function is wrong

--- Comment #11 from pinskia at gcc dot gnu dot org 2009-03-24 05:14 --- *** Bug 39534 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/39534] Template name lookup

--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-24 05:14 --- *** This bug has been marked as a duplicate of 38030 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c++/39534] Template name lookup

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-24 05:12 --- 4.3.3 and 4.4.0 both print 2122. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug debug/39535] New: wrong function name and line numbers with -g -O2 option

With -g -O2 option, crx-elf-gcc generates wrong line numbers and function names. == /tmp/ccrrZsJf.o: In function `090312 (experimental)': /home10/swami/test.c:5: undefined reference to `_f1' collect2: ld returned 1 exit status === Expected output could be: === /tmp/ccEJcFRs.o: In function `main':

[Bug debug/39527] wrong function name and line numbers with -g -O2 option

--- Comment #2 from MR dot Swami dot Reddy at nsc dot com 2009-03-24 04:51 --- Subject: Re: wrong function name and line numbers with -g -O2 option rguenth at gcc dot gnu dot org wrote: > > --- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-23 13:47 > --- > This is

[Bug c++/39534] New: Template name lookup

Hi, I expect this code to print 2122 but it instead prints . #include using namespace std; namespace my{ struct S{}; void f(S s, double d = 0){cout << "1";} } template void h(){ T t; my::S s; f(t, 0);// Line 1 f(s, 0);// Line 2 } namespace my{ // r

[Bug preprocessor/39533] -MM may list a header file twice

--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-24 01:50 --- If I do cat > foo.h << EOF #include EOF I get the duplicated include file but I don;t think it matters as it is included twice, how does the cpp know they are really the same include file -- pinskia at gcc dot

[Bug preprocessor/39533] -MM may list a header file twice

--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-24 01:48 --- This testcase is not complete, it does not include foo.h. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/39528] [4.0/4.1/4.2/4.3/4.4 Regression] repeated entries are not read when using list-directed input

--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-03-24 01:15 --- I will give this a shot. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added

[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution

--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-23 23:21 --- Subject: Bug 39524 Author: jakub Date: Mon Mar 23 23:21:38 2009 New Revision: 145018 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145018 Log: PR debug/39524 * dwarf2out.c (gen_variable_die):

[Bug libmudflap/38462] test libmudflap.c/fail27-frag.c fails output pattern test for ppc64

--- Comment #1 from fche at redhat dot com 2009-03-23 22:53 --- (In reply to comment #0) > Here there is only one nearby object; argv[] and environ[] are missing. [...] > Should the objects argv and environ be reported in the -m64 output. I believe so, because those globals are supposed

[Bug ada/36939] Build Failure Ada SH2e

--- Comment #13 from joel at gcc dot gnu dot org 2009-03-23 22:14 --- *** Bug 21377 has been marked as a duplicate of this bug. *** -- joel at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/21377] Error detected at a-stmaco.ads:65:4

--- Comment #3 from joel at gcc dot gnu dot org 2009-03-23 22:14 --- This is very old and most likely fixed since it looks like sh-rtems builds Ada further. Marking this as a dupe so it will die. *** This bug has been marked as a duplicate of 36939 *** -- joel at gcc dot gnu dot or

[Bug target/36834] structure return ABI for windows targets differs from native MSVC

--- Comment #11 from dannysmith at users dot sourceforge dot net 2009-03-23 22:10 --- (In reply to comment #10) > Note that C++ objects need not be larger than 8 bytes to qualify for returning > on the stack (and thus subject to this cleanup problem). Any class with a copy > constructor

[Bug preprocessor/39533] -MM may list a header file twice

--- Comment #2 from hjl dot tools at gmail dot com 2009-03-23 21:44 --- Created an attachment (id=17527) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17527&action=view) A testcase # gcc -MM x.c -Iinclude x.o: x.c foo.h include/ansidecl.h include/libiberty.h include/ansid

[Bug preprocessor/39533] -MM may list a header file twice

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-23 21:39 --- Example? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533

[Bug preprocessor/39533] New: -MM may list a header file twice

"gcc -MM" may list a header file twice. -- Summary: -MM may list a header file twice Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at g

[Bug fortran/39532] fortran 95 parsing trouble

--- Comment #4 from kargl at gcc dot gnu dot org 2009-03-23 21:30 --- Confirmed with Patrick that the source code is assumed to be fixed-form by gfortran and the code contains lines longer than 72 characters. Patrick confirmed that the option -ffixed-line-length-none allows the code to

[Bug c++/37729] function parameter pack expansion doesn't work in late-specified return type

--- Comment #1 from jason at gcc dot gnu dot org 2009-03-23 21:14 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED

[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

--- Comment #8 from prlw1 at cam dot ac dot uk 2009-03-23 21:07 --- What about the first patch, which seems less drastic? (I think it would be better to install gcc's stddef.h, so there is one thing less to remember when upgrading gcc) It seems that if our machine/ansi.h defined _MACHINE

[Bug c/39495] OMP parallel loop w/ unsigned index var rejected

--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-23 21:05 --- Subject: Bug 39495 Author: jakub Date: Mon Mar 23 21:05:30 2009 New Revision: 145014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145014 Log: PR c/39495 * c-parser.c (c_parser_omp_for_loop):

[Bug fortran/39528] [4.0/4.1/4.2/4.3/4.4 Regression] repeated entries are not read when using list-directed input

--- Comment #4 from dominiq at lps dot ens dot fr 2009-03-23 21:04 --- Jerry could you have a look at this one? TIA -- dominiq at lps dot ens dot fr changed: What|Removed |Added --

[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

--- Comment #7 from joseph at codesourcery dot com 2009-03-23 20:53 --- Subject: Re: stddef.h assumes machinee/ansi.h defines _ANSI_H_ On Mon, 23 Mar 2009, prlw1 at cam dot ac dot uk wrote: > --- Comment #6 from prlw1 at cam dot ac dot uk 2009-03-23 20:45 --- > (In reply to

[Bug c++/39526] [4.4 Regression] -Wshadow reports shadowed declarations for parameters of unnamed temp objects

--- Comment #5 from jason at gcc dot gnu dot org 2009-03-23 20:52 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

--- Comment #6 from prlw1 at cam dot ac dot uk 2009-03-23 20:45 --- (In reply to comment #5) > The patch is obviously wrong (it changes the installed headers for all > targets instead of setting USER_H to adjust the list for the target with > this issue) Care to explain more re USER_H

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

--- Comment #47 from danglin at gcc dot gnu dot org 2009-03-23 20:39 --- I hate PCH! The reason a small change inhibits PCH file loading is the following: /* If the text segment was not loaded at the same address as it was when the PCH file was created, function pointers loaded

[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

--- Comment #5 from joseph at codesourcery dot com 2009-03-23 20:35 --- Subject: Re: stddef.h assumes machinee/ansi.h defines _ANSI_H_ The patch is obviously wrong (it changes the installed headers for all targets instead of setting USER_H to adjust the list for the target with this

[Bug c++/39526] [4.4 Regression] -Wshadow reports shadowed declarations for parameters of unnamed temp objects

--- Comment #4 from jason at gcc dot gnu dot org 2009-03-23 20:33 --- Subject: Bug 39526 Author: jason Date: Mon Mar 23 20:32:53 2009 New Revision: 145012 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145012 Log: PR c++/39526 * name-lookup.c (pushdecl_maybe_frie

[Bug fortran/39532] fortran 95 parsing trouble

--- Comment #3 from kargl at gcc dot gnu dot org 2009-03-23 20:25 --- (In reply to comment #2) > I just tried > > ifort -warn stderrors -std95 modules.f > > which didn't complain. It seems gfortran is unhappy about the parentheses > in that declaration. I included the parts before, so

[Bug fortran/39532] fortran 95 parsing trouble

--- Comment #2 from prlw1 at cam dot ac dot uk 2009-03-23 20:23 --- I just tried ifort -warn stderrors -std95 modules.f which didn't complain. It seems gfortran is unhappy about the parentheses in that declaration. I included the parts before, so you can see that nREBOspecies is define

[Bug fortran/29962] Initialization expressions

--- Comment #13 from dfranke at gcc dot gnu dot org 2009-03-23 20:03 --- Transformational intrinsics, one down: PACK (PR32890). Left: * all, any, count * maxloc, minloc * maxval, minval (generic case) * product, sum * dot_product, matmul, transpose * unpack, spread * cshift, eosh

[Bug fortran/39532] fortran 95 parsing trouble

--- Comment #1 from kargl at gcc dot gnu dot org 2009-03-23 20:01 --- Please attach the offending code. Also, ifort has an option for fairly strict conformance to the Fortran 95 standard. Does the code compile with this option. -- kargl at gcc dot gnu dot org changed: W

[Bug fortran/39532] New: fortran 95 parsing trouble

Program extract: ... module brennerdata use datatypes use element,only : maxele integer(i4), save :: nbrennertype = 3 integer(i4),parameter :: nREBOspecies = 4 integer(i4), save :: nREBOspecies2 logical, save

[Bug fortran/29962] Initialization expressions

--- Comment #12 from dfranke at gcc dot gnu dot org 2009-03-23 19:56 --- *** Bug 38205 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962

[Bug fortran/38205] Tranformational function SUM rejected in initialization expressions

--- Comment #8 from dfranke at gcc dot gnu dot org 2009-03-23 19:56 --- *** This bug has been marked as a duplicate of 29962 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/32890] Compile-time detect of LHS/RHS missmatch for PACK

--- Comment #3 from dfranke at gcc dot gnu dot org 2009-03-23 19:33 --- Subject: Bug 32890 Author: dfranke Date: Mon Mar 23 19:33:39 2009 New Revision: 145011 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145011 Log: gcc/fortran/: 2009-03-23 Daniel Franke PR fortran

[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

--- Comment #4 from prlw1 at cam dot ac dot uk 2009-03-23 19:31 --- Just hit this bug. Either solution looks good (am about to test, but spent ages reaching the same conclusion, so expect success for both) Anyone from gcc listening? -- prlw1 at cam dot ac dot uk changed:

[Bug fortran/39528] [4.0/4.1/4.2/4.3/4.4 Regression] repeated entries are not read when using list-directed input

--- Comment #3 from jv244 at cam dot ac dot uk 2009-03-23 19:26 --- good old Fortran.. (fine with NAG as well) -- jv244 at cam dot ac dot uk changed: What|Removed |Added O

[Bug target/39531] m68k gcc does not convert andil to bclr when compiled on a 64bit host

--- Comment #1 from radford at blackbean dot org 2009-03-23 19:13 --- Created an attachment (id=17526) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17526&action=view) Fix output_andsi3 to correctly convert andil to bclr when compiler runs on a 64bit host -- http://gcc.gnu.org

[Bug c/39531] New: m68k gcc does not convert andil to bclr when compiled on a 64bit host

The following function will use a bclr on a 32 bit host and a andil on a 64bit host. int f(int x) { return x & 0x7fff; } This is caused by a missing & 0x the expression exact_log2 (~ INTVAL (operands[2]))) in output_andsi3. -- Summary: m68k gcc does not convert and

[Bug c++/14912] Do not print default template arguments in error messages

--- Comment #48 from pluto at agmk dot net 2009-03-23 19:00 --- with the latest patch applied on top of 4.4-svn i get following diagnostic for simple code snippet: $ cat 14912-2.cpp #include std::string s = 7; $ /opt/gcc44/bin/g++ -c -Wall -O2 14912-2.cpp 14912-2.cpp:2: error: invalid

[Bug c++/39530] [regression] runtime_error text not shown

--- Comment #1 from shadow2531 at gmail dot com 2009-03-23 18:49 --- Created an attachment (id=17525) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17525&action=view) .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39530

[Bug c++/39530] New: [regression] runtime_error text not shown

#include using namespace std; int main() { throw runtime_error("ouch"); } // g++ -Wall -Wextra test.cc -o test -O3 -s // g++ (GCC) 4.3.3-dw2-tdm-1 // WinXP SP3 // CMD.exe Result: This application has requested the Runtime to terminate it in an unusual way. Plea

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

--- Comment #7 from gbarnt at student dot dtu dot dk 2009-03-23 18:42 --- Created an attachment (id=17524) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17524&action=view) Same as previous - except for the -lib error. This patch replaces my old patch and does not break the --with

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

--- Comment #6 from gbarnt at student dot dtu dot dk 2009-03-23 18:38 --- (From update of attachment 17522) Sorry, too much copy-paste in the patch... re-uploading a new patch that does not break --with-(gmp|mpfr)-lib. -- gbarnt at student dot dtu dot dk changed: What

[Bug tree-optimization/39529] ICE on valid code

--- Comment #1 from edmar at freescale dot com 2009-03-23 18:36 --- Created an attachment (id=17523) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17523&action=view) Here is the patch I used -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39529

[Bug tree-optimization/39529] New: ICE on valid code

The compiler gives ICE on valid code. Invocation: gcc -O3 -S x.c Test case: void foo (void) { char a[1024]; char *p = &a[0]; char *p2; p2 = p + 1024; do { p += 2; *(p-2) = 1; *(p-1) = 1; } while (p < p2); } Output: x.c: In function 'foo': x.c:3: erro

[Bug bootstrap/39470] [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable

--- Comment #7 from basile at starynkevitch dot net 2009-03-23 18:16 --- fopencookie is removed in rev145010 of MELT branch. I'm using a temporary kludge , calling an unstable function inside PPL. So You'll need a recent PPL snapshot (obtained thru GIT). http://www.cs.unipr.it/piperm

[Bug target/35180] built-in-setjmp.x2

--- Comment #11 from joel at gcc dot gnu dot org 2009-03-23 17:56 --- Closing. This found an issue in the RTEMS ta 3 trap handler. Resolved on the RTEMS side. -- joel at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/39528] gfortran: repeated entries are not read when using list-directed input

--- Comment #2 from dominiq at lps dot ens dot fr 2009-03-23 17:39 --- It is a regression with respect to g77. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39528

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

--- Comment #5 from gbarnt at student dot dtu dot dk 2009-03-23 17:23 --- Sadly my skills with bugzilla's haven't improved. I meant to have the following accompany the patch above: This issue is also present on an x86_64 red hat linux in gcc-4.3.3. Usage of --with-gmp and --with-mpfr

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

--- Comment #4 from gbarnt at student dot dtu dot dk 2009-03-23 17:22 --- Created an attachment (id=17522) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17522&action=view) Patch adding -Wl,-R,[dir] to --with-gmp/mpfr(-lib)? Patch that adds linker flags "-Wl,-R,[dir]" to the linke

[Bug rtl-optimization/24319] [4.2/4.3/4.4 regression] amd64 register spill error with -fschedule-insns

--- Comment #12 from vmakarov at redhat dot com 2009-03-23 17:04 --- I started my work on register pressure sensitive insn scheduling recently. This bug will be fixed as byproduct of this work. I hope the code will be available for gcc4.5. -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug target/38549] [avr] eicall not properly set for > 128K program space

-- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last r

[Bug target/38057] [AVR] ATMega2561 wrong addressing (probably eicall).

--- Comment #2 from eric dot weddington at atmel dot com 2009-03-23 16:42 --- *** This bug has been marked as a duplicate of 38549 *** -- eric dot weddington at atmel dot com changed: What|Removed |Added -

[Bug target/38549] [avr] eicall not properly set for > 128K program space

--- Comment #4 from eric dot weddington at atmel dot com 2009-03-23 16:42 --- *** Bug 38057 has been marked as a duplicate of this bug. *** -- eric dot weddington at atmel dot com changed: What|Removed |Added --

[Bug target/38549] [avr] eicall not properly set for > 128K program space

--- Comment #3 from thiago dot correa at gmail dot com 2009-03-23 16:33 --- Bug #38057 reports the same issue. Perhaps this should be changed to CONFIRMED and one of the bug reports set as duplicate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549

[Bug c++/39526] [4.4 Regression] -Wshadow reports shadowed declarations for parameters of unnamed temp objects

--- Comment #3 from jason at gcc dot gnu dot org 2009-03-23 15:32 --- The problem is that we're pushing declarations for parameters while tentatively parsing that as a function declaration. Oops. -- jason at gcc dot gnu dot org changed: What|Removed

[Bug target/32348] ICE on valid code

--- Comment #3 from edmar at freescale dot com 2009-03-23 15:13 --- Ben, this bug is almost 2 years old. I don't remember what we did to resolve the issue. I am surprised to find it is still open. I am going try to close it. Edmar -- edmar at freescale dot com changed: W

[Bug fortran/39528] gfortran: repeated entries are not read when using list-directed input

--- Comment #1 from dominiq at lps dot ens dot fr 2009-03-23 15:10 --- Confirmed on powerpc-apple-darwin9 for trunk, 4.3.3, and 4.2.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39528

[Bug fortran/39528] New: gfortran: repeated entries are not read when using list-directed input

When I read repeated entries using list-directed input and I use a slash to terminate the read, the number of entries read in the last series depends on the position of the closing slash. In addition, an additional entry at the end corrects the problem. The test program: program rread implici

[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution

--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-23 14:30 --- Created an attachment (id=17521) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17521&action=view) gcc44-pr39524.patch Argh, sorry, actually this patch, not the one I've attached in the previous comment. -- j

[Bug tree-optimization/39516] [4.4 Regression] internal compiler error: in copy_to_mode_reg, at explow.c:623

--- Comment #13 from jakub at gcc dot gnu dot org 2009-03-23 14:08 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug tree-optimization/39516] [4.4 Regression] internal compiler error: in copy_to_mode_reg, at explow.c:623

--- Comment #12 from jakub at gcc dot gnu dot org 2009-03-23 14:00 --- Subject: Bug 39516 Author: jakub Date: Mon Mar 23 14:00:34 2009 New Revision: 145008 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145008 Log: PR tree-optimization/39516 * lambda-code.c (perf

[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution

--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-23 13:52 --- Created an attachment (id=17520) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17520&action=view) gcc44-pr39524.patch Modified Dodji's patch I've actually bootstrapped/regtested (neither of the patches caused an

[Bug c/39525] [easy to fix bug] Docs for C99 "designated initializers" isn't clear what happens to omitted field members

--- Comment #2 from mnemo at minimum dot se 2009-03-23 13:48 --- If you could just add that info in a single sentence to the GCC docs, it would be very helpful for end users. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39525

[Bug debug/39527] wrong function name and line numbers with -g -O2 option

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-23 13:47 --- This is a binutils issue. The error is reported with the location of the calling function, not the call. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c++/39526] [4.4 Regression] -Wshadow reports shadowed declarations for parameters of unnamed temp objects

--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-23 13:45 --- Regressed in r140120 (PR37302). Similar testcase where infoo is a global variable also starts failing at that revision. Jason, can you please have a look at this? Isn't infoo just an argument passed to a ctor, not a

[Bug c/39525] [easy to fix bug] Docs for C99 "designated initializers" isn't clear what happens to omitted field members

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-23 13:30 --- Hmm, how so? The C standard is clear that these fields are zero initialized if omitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39525

[Bug debug/39527] New: wrong function name and line numbers with -g -O2 option

With -g -O2 option, crx-elf-gcc generates wrong line numbers and function names. == /tmp/ccrrZsJf.o: In function `090312 (experimental)': /home10/swami/test.c:5: undefined reference to `_f1' collect2: ld returned 1 exit status === Expected output could be: === /tmp/ccEJcFRs.o: In function `main':

[Bug c++/39526] -Wshadow reports shadowed declarations for parameters of unnamed temp objects

--- Comment #1 from caolanm at redhat dot com 2009-03-23 12:22 --- Created an attachment (id=17519) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17519&action=view) trivial demo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39526

[Bug c++/39526] New: -Wshadow reports shadowed declarations for parameters of unnamed temp objects

for the parameters passed to a C++ constructor when an unnamed temporary object is created and a method called on it i.e. following test-case reports... $ g++ -c -Wshadow demo.cxx demo.cxx: In function ‘int foo(int)’: demo.cxx:10: warning: declaration of ‘INetURLObject infoo’ shadows a parameter

[Bug middle-end/39514] [4.4 Regression] unreported change to packed bitfields

--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-03-23 11:47 --- > I'd like to see this message, which is on by default, for the change > introduced in r132614. I haven't figured out how to determine if the offset > for a field has changed, just the alignment. I'll attach my

[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution

--- Comment #3 from jan dot kratochvil at redhat dot com 2009-03-23 11:32 --- One fix should be enough next time, thanks. Going to gdb-regression test both the patches (in Fedora GCC on Fedora 11). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524

[Bug middle-end/39514] [4.4 Regression] unreported change to packed bitfields

--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-03-23 11:25 --- > Did behavior change if you remove the aligned (2) attribute from d? No, it didn't change without the attribute, it was and still is (10, 12). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39514

[Bug target/39482] [4.3 Regression] ICE in inline_secondary_memory_needed, at config/i386/i386.c:25478

--- Comment #7 from ubizjak at gmail dot com 2009-03-23 11:21 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED

[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution

--- Comment #2 from dodji at gcc dot gnu dot org 2009-03-23 11:20 --- Created an attachment (id=17518) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17518&action=view) another candidate fix I was looking at this bug when I saw Jakub's patch :) After talking with Jakub a little bit

[Bug target/39482] [4.3 Regression] ICE in inline_secondary_memory_needed, at config/i386/i386.c:25478

--- Comment #6 from uros at gcc dot gnu dot org 2009-03-23 11:19 --- Subject: Bug 39482 Author: uros Date: Mon Mar 23 11:19:41 2009 New Revision: 145005 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145005 Log: Backport from mainline: 2009-03-17 Uros Bizjak

[Bug c/39525] New: [easy to fix bug] Docs for C99 "designated initializers" isn't clear what happens to omitted field members

The documentation for C99 "designated initializers" is not clear what happens to omitted field members. I'm fairly sure omitted field members get initialized to the same value they would get if they were static but it would be very nice to have this explicitly called out in the docs. The documenta

[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++

--- Comment #3 from singler at gcc dot gnu dot org 2009-03-23 11:00 --- A parallelized std::copy was also suggested. -- singler at gcc dot gnu dot org changed: What|Removed |Added

[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution

--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-23 10:14 --- Created an attachment (id=17517) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17517&action=view) gcc44-pr39524.patch Could you please test this with gdb/archer testsuite? I'm going to bootstrap/regtest it in g

[Bug tree-optimization/39516] [4.4 Regression] internal compiler error: in copy_to_mode_reg, at explow.c:623

--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-23 09:30 --- Created an attachment (id=17516) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17516&action=view) gcc44-pr39516.patch Patch I'm going to bootstrap/regtest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39

[Bug tree-optimization/39516] [4.4 Regression] internal compiler error: in copy_to_mode_reg, at explow.c:623

-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org

[Bug debug/39524] New: Duplicite C++ DW_TAG_variable breaking its DW_AT_location resolution

Tested on: GNU C++ 4.4.0 20090323 (experimental) Testcase: -- namespace A { static int var2 = 2; } int func (void) { using A::var2; return var2

[Bug tree-optimization/39516] [4.4 Regression] internal compiler error: in copy_to_mode_reg, at explow.c:623

--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-23 08:48 --- Even more reduced testcase: C { dg-options "-O2 -ftree-loop-linear" } SUBROUTINE SUB(A, B, M) IMPLICIT NONE DOUBLE PRECISION A(20,20), B(20) INTEGER*8 I, J, K, M DO I=1,M DO J=1,M

[Bug c/39369] ioquake3 SIGSEGVs when compiled with SSE optimizations

--- Comment #3 from ubizjak at gmail dot com 2009-03-23 08:25 --- As a workaround, can you try to compile with -fno-common? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39369

[Bug c/39369] ioquake3 SIGSEGVs when compiled with SSE optimizations

--- Comment #2 from ubizjak at gmail dot com 2009-03-23 08:24 --- This is probably the dup of PR37216. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39369