[Bug fortran/47494] .MOD files: Consider removing the time stamp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47494 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.20 09:34:06 CC||jb at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Janne Blomqvist 2011-02-20 09:34:06 UTC --- Confirmed. While AFAICS this is not a problem wrt removing the timestamp, one should make sure to not break the avoid-recompilation-cascade feature, see e.g. discussion in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495
[Bug lto/47822] New: [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 Summary: [4.6 Regression] Multiple test suite failures due to revision 170321 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: h...@gcc.gnu.org, rguent...@suse.de Revision 170321 caused a lot of failures on the test suite on x86_64-apple-darwin10 and moxie-unknown-elf (see http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg02205.html). They are all of the form: [macbook] f90/bug% gcc46 /opt/gcc/work/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c /opt/gcc/work/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c /opt/gcc/work/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -flto lto1: fatal error: target specific builtin not available compilation terminated. lto-wrapper: gcc46 returned 1 exit status collect2: lto-wrapper returned 1 exit status Reverting the revision fixes the failures. This is pr seems related to pr47820.
[Bug c++/44118] ICE: in instantiate_decl, at cp/pt.c:16657
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44118 --- Comment #6 from paolo at gcc dot gnu.org 2011-02-20 11:11:08 UTC --- Author: paolo Date: Sun Feb 20 11:11:05 2011 New Revision: 170336 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170336 Log: 2011-02-20 Paolo Carlini PR c++/44118 * g++.dg/template/crash105.C: New. Added: trunk/gcc/testsuite/g++.dg/template/crash105.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/44118] ICE: in instantiate_decl, at cp/pt.c:16657
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44118 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Paolo Carlini 2011-02-20 11:13:04 UTC --- Thanks Jakub. Done.
[Bug c++/44118] ICE: in instantiate_decl, at cp/pt.c:16657
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44118 Paolo Carlini changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/45077] ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45077 Paul Thomas changed: What|Removed |Added AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org |gnu.org | --- Comment #6 from Paul Thomas 2011-02-20 11:21:14 UTC --- Created attachment 23410 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23410 fix for the version of the problem in comments #4 and #5 Fixes the problem. Bootstraps and regtests OK. How do I write a testcase to exercise this? dg-additional-sources is not sufficient is it? That is does it generate: gfortran source1.f90 source2.f90 or gfortran -c source1.f90 -o source1.o gfortran source2.f90 source1.0 ?? The second is what is needed. Paul
[Bug fortran/45077] ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45077 --- Comment #7 from Tobias Burnus 2011-02-20 11:39:56 UTC --- (In reply to comment #6) > Fixes the problem. Bootstraps and regtests OK. I glanced at it and it looks OK. > dg-additional-sources is not sufficient is it? That is does it generate: > gfortran source1.f90 source2.f90 > or > gfortran -c source1.f90 -o source1.o > gfortran source2.f90 source1.0 I think both are effectively the same: For "gfortran source2.f90 source1.f90", the driver (gfortran) calls twice the compiler (f951) which generates in /tmp/... the assembler files, the driver then calls the assembler (as) twice and, finally, the linker (collect1). The driver only combined the two source files when "-combined" is used, though I think that feature was not available for Fortran and will not work with dg-additional-sources. That can be seen when running "gfortran -v source2.f90 source1.f90" by looking for the f951 lines. Note: The file specified by dg-additional-sources is compiled after the one which has the "dg-additional-sources" specified. Additionally, one needs to provide a fall-back compilation as the second file is also compiled independently. See pr37287-1.f90 and pr37287-2.F90 as an example.
[Bug fortran/47797] Debug: Odd first break point for subroutine breakp w/ allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47797 --- Comment #1 from Tobias Burnus 2011-02-20 13:45:15 UTC --- Created attachment 23411 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23411 Draft patch
[Bug bootstrap/47820] [4.6 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47820 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.0 --- Comment #2 from Richard Guenther 2011-02-20 14:18:40 UTC --- I will try to reproduce on monday. Please also specify your binutils version and whether you use gold or GNU ld and your exact configure options. How many parallel links did you allow?
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822
Richard Guenther changed:
What|Removed |Added
Target||*-darwin*
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.02.20 14:48:01
Component|lto |target
Target Milestone|--- |4.6.0
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther 2011-02-20
14:48:01 UTC ---
Hm. The target builtins appear in BLOCK_VARs of DECL_INITIAL of the
TRANSLATION_UNIT_DECL.
There is appearantly a builtin for IX86_BUILTIN_MAX, which is obviously bogus.
Does darwin define additional target specific builtins that are not
covered by the builtin_decl target hook (that would be a bug anyway)?
It seems to do via
do {\
darwin_init_cfstring_builtins ((unsigned) (IX86_BUILTIN_MAX));\
darwin_rename_builtins ();\
} while(0)
which will result in all programs using those builtins fail with LTO
in the same way (that all builtins are streamed in now via the
TU decl isn't optimal, but per-se not a bug). The code doesn't even
save the builtin somewhere retrievable, so the following is obviously
not correct but solves the ICE:
Index: config/i386/i386.c
===
--- config/i386/i386.c(revision 170336)
+++ config/i386/i386.c(working copy)
@@ -25821,7 +25821,11 @@
static tree
ix86_builtin_decl (unsigned code, bool initialize_p ATTRIBUTE_UNUSED)
{
+#ifdef TARGET_MACHO
if (code >= IX86_BUILTIN_MAX)
+return implicit_built_in_decls[BUILT_IN_MEMSET];
+#endif
+ if (code >= IX86_BUILTIN_MAX)
return error_mark_node;
return ix86_builtins[code];
I think the darwin machinery should simply arrange to append to the
existing array, reserving an enum value if TARGET_MACHO (or sth other
appropriate) and store the decl there.
I will look into stripping out builtins from the TU BLOCK_VARS
(that won't solve the ICE when someone really uses that darwin builtin).
[Bug objc++/47711] [4.5/4.6 Regression] (even trivial) PCH fails for Objective-C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47711 Nicola Pero changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.20 14:53:13 CC||nicola at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Nicola Pero 2011-02-20 14:53:13 UTC --- Confirmed. Patch to fix it submitted at http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01318.html Thanks
[Bug objc/47813] Some ObjC tests failing on ia6-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47813 --- Comment #2 from Nicola Pero 2011-02-20 14:54:47 UTC --- This is fixed in trunk (but not really, the problem is just hidden). The following patch -- http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01297.html fixes it for real though. Thanks
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822
--- Comment #2 from Richard Guenther 2011-02-20
15:05:00 UTC ---
Huh. WTF is this builtin used for at all??
int main()
{
return __builtin___CFStringMakeConstantString ("Hello");
}
and at gimple stage we already have
main ()
{
int D.2718;
long int D.2719;
D.2719 = (long int) &C.1605;
D.2718 = (int) D.2719;
return D.2718;
}
!? It appearantly relies on folding, huh, another brokeness - there is
no way it would survive through expansion (well, it'll get a libcall ...).
I wonder where it is actually _used_ from!? Not from any header I have
installed on x86_64-darwin, not from any GCC code either.
Feels like a darwin hack again ... don't feel like wasting my Sunday on this
one either.
[Bug fortran/45077] ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45077 --- Comment #8 from Dominique d'Humieres 2011-02-20 15:08:18 UTC --- Although pr40440 has been marked as fixed the original test in comment #0 (i.e., using a non included iso_varying_string.mod) is still yielding an ICE with trunk: pr40440.f90: In function 'syntax_init_from_ifile': pr40440.f90:719:0: internal compiler error: in fold_convert_loc, at fold-const.c:2028 This ICE is fixed by the patch in comment #6. All the other problems reported in this pr and in pr44945 have been silenced on trunk for x86_64-apple-darwin10, making difficult to say that the patches have fixed them. Otherwise the patch works as expected without regressions.
[Bug tree-optimization/31849] [4.3/4.4/4.5/4.6 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 Steven Bosscher changed: What|Removed |Added Status|WAITING |RESOLVED CC||steven at gcc dot gnu.org Resolution||WORKSFORME --- Comment #54 from Steven Bosscher 2011-02-20 15:14:14 UTC --- No response for more than a year.
[Bug preprocessor/39029] #pragma once is not "exported" from the precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029 Olaf van der Spek changed: What|Removed |Added CC||olafvdspek at gmail dot com --- Comment #1 from Olaf van der Spek 2011-02-20 15:15:08 UTC --- Could you attach a minimal testcase?
[Bug preprocessor/47823] New: #pragma once not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47823 Summary: #pragma once not documented Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: olafvds...@gmail.com #pragma once appears to be undocumented http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Pragmas.html
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #3 from Dominique d'Humieres 2011-02-20 15:19:41 UTC --- Well, the problem does not seem fully darwin specific. It also shows on moxie-unknown-elf and may be to some extent on powerpc64-unknown-linux-gnu (see http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg02232.html the failures on gcc.dg/vmx/*).
[Bug other/47824] New: Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 Summary: Option to enable all warning (-Wall-real?) Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: olafvds...@gmail.com Could an option be added that enables all warnings?
[Bug rtl-optimization/37534] [4.4/4.5/4.6 Regression] IRA causes 17% degradation in 187.facerec benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37534 Steven Bosscher changed: What|Removed |Added Status|NEW |WAITING CC||dje at gcc dot gnu.org, ||steven at gcc dot gnu.org --- Comment #13 from Steven Bosscher 2011-02-20 15:20:37 UTC --- Ping? No reconfirmation, no progress, no movement of _any_ kind for two years. Can anyone tell whether there is still a regression here?
[Bug target/38306] [4.4/4.5/4.6 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 Steven Bosscher changed: What|Removed |Added Status|NEW |WAITING CC||steven at gcc dot gnu.org --- Comment #18 from Steven Bosscher 2011-02-20 15:22:26 UTC --- Hello Joost, could you please check if this is still a problem in GCC 4.6?
[Bug middle-end/47735] [4.5/4.6 Regression] Unnecessary adjustments to stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47735 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.20 15:24:07 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #1 from Olaf van der Spek 2011-02-20 15:33:21 UTC --- It would also be nice to list all warnings not included in -Wall -Wextra.
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822
--- Comment #4 from Richard Guenther 2011-02-20
15:33:56 UTC ---
It will show on all targets without a builtin_decl hook and target builtins.
x86 is no such target, it shows there because of the darwin builtin not
playing by the rules.
I will fix (hide) the issue again, but it will (re-)cause decls of builtins
not to appear in gdb. Thus,
void *malloc(long);
int main() {}
and you'll not be able to (gdb) ptype malloc.
Thus, darwin people - if you continue to let this kind of hacks sneak in,
then, well, you will continuously get beaten by this kind of problems.
If it "works" it doesn't mean its right.
[Bug rtl-optimization/37534] [4.4/4.5/4.6 Regression] IRA causes 17% degradation in 187.facerec benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37534 --- Comment #14 from Richard Guenther 2011-02-20 15:41:32 UTC --- It would also be interesting if with profile-feedback and/or LTO this particular problem vanishes, given that both should result in better static branch predictions.
[Bug target/47487] ICE in rs6000_output_function_epilogue, at config/rs6000/rs6000.c:21782 building 64bit libgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47487 Matthias Klose changed: What|Removed |Added Target|powerpc-linux-gnu |powerpc-linux-gnu ||powerpc64-linux-gnu --- Comment #1 from Matthias Klose 2011-02-20 15:49:19 UTC --- still seen on trunk 20110220, powerpc-linux-gnu and powerpc64-linux-gnu targets
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822
Dominique d'Humieres changed:
What|Removed |Added
CC||iains at gcc dot gnu.org,
||mikestump at comcast dot
||net
--- Comment #5 from Dominique d'Humieres 2011-02-20
16:03:22 UTC ---
> do {\
> darwin_init_cfstring_builtins ((unsigned) (IX86_BUILTIN_MAX));\
> darwin_rename_builtins ();\
> } while(0)
>
> ...
> Huh. WTF is this builtin used for at all??
My guess is that it is related to
> Darwin/Mac OS X
>
> General
> Initial support for CFString types has been added.
> ...
in http://gcc.gnu.org/gcc-4.6/changes.html#objective-c. CCing Iain Sandoe and
Mike Stump.
[Bug target/38306] [4.4/4.5/4.6 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 --- Comment #19 from Joost VandeVondele 2011-02-20 16:17:33 UTC --- (In reply to comment #18) > Hello Joost, could you please check if this is still a problem in GCC 4.6? I think it still is a minor problem, but (without -fschedule-insns) somewhat less pronounced (the old hardware is gone, this might make a difference): 4.3 branch > gfortran -O3 -march=native -funroll-loops -ffast-math -fschedule-insns > test.f90 ; ./a.out Time for evaluation [s]:3.478 > gfortran -O3 -march=native -funroll-loops -ffast-math test.f90 ; ./a.out Time for evaluation [s]:4.367 4.5 branch > gfortran -O3 -march=native -funroll-loops -ffast-math -fschedule-insns > test.f90 ; ./a.out Time for evaluation [s]:4.839 > gfortran -O3 -march=native -funroll-loops -ffast-math test.f90 ; ./a.out Time for evaluation [s]:4.524 4.6 branch > gfortran -O3 -march=native -funroll-loops -ffast-math -fschedule-insns > test.f90 ; ./a.out Time for evaluation [s]:4.997 > gfortran -O3 -march=native -funroll-loops -ffast-math test.f90 ; ./a.out Time for evaluation [s]:4.547 FYI: -march=amdfam10 -mcx16 -msahf -mpopcnt -mabm model name : AMD Opteron(tm) Processor 6176 SE
[Bug fortran/45077] ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45077 --- Comment #9 from Paul Thomas 2011-02-20 16:23:57 UTC --- Author: pault Date: Sun Feb 20 16:23:50 2011 New Revision: 170337 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170337 Log: 2011-02-20 Paul Thomas PR fortran/45077 PR fortran/44945 * trans-types.c (gfc_get_derived_type): Remove code that looks for decls in gsym and add call to gfc_get_module_backend_decl. * trans.h : Add prototype for gfc_get_module_backend_decl. * trans-decl.c (gfc_get_module_backend_decl): New function. (gfc_get_symbol_decl): Call it. 2011-02-20 Paul Thomas PR fortran/45077 PR fortran/44945 * gfortran.dg/whole_file_28.f90 : New test. * gfortran.dg/whole_file_29.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_28.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_29.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44945 --- Comment #33 from Paul Thomas 2011-02-20 16:23:57 UTC --- Author: pault Date: Sun Feb 20 16:23:50 2011 New Revision: 170337 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170337 Log: 2011-02-20 Paul Thomas PR fortran/45077 PR fortran/44945 * trans-types.c (gfc_get_derived_type): Remove code that looks for decls in gsym and add call to gfc_get_module_backend_decl. * trans.h : Add prototype for gfc_get_module_backend_decl. * trans-decl.c (gfc_get_module_backend_decl): New function. (gfc_get_symbol_decl): Call it. 2011-02-20 Paul Thomas PR fortran/45077 PR fortran/44945 * gfortran.dg/whole_file_28.f90 : New test. * gfortran.dg/whole_file_29.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_28.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_29.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog
[Bug target/38306] [4.4/4.5/4.6 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 --- Comment #20 from Joost VandeVondele 2011-02-20 16:28:00 UTC --- additionally for trunk, lto/profile-use seem not to help: > gfortran -O3 -march=native -funroll-loops -ffast-math -flto -fprofile-use > test.f90 ; ./a.out Time for evaluation [s]:4.664 > gfortran -O3 -march=native -funroll-loops -ffast-math -fprofile-use > test.f90 ; ./a.out Time for evaluation [s]:4.665
[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44945 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #34 from Paul Thomas 2011-02-20 16:28:09 UTC --- I think that we can close this one now. Thanks to all involved in reporting and fixing. Fixed on trunk. Paul
[Bug target/38306] [4.4/4.5/4.6 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 --- Comment #21 from Joost VandeVondele 2011-02-20 16:32:38 UTC --- ... however, the following works great: > gfortran -O2 -march=native -funroll-loops -ffast-math -ftree-vectorize > test.f90 ; ./a.out Time for evaluation [s]:2.700 (notice -O2 instead of -O3, -O2 is thus twice as fast as -O3)
[Bug fortran/45077] ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45077 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Paul Thomas 2011-02-20 16:36:55 UTC --- Fixed on trunk. Thanks for the report. Paul
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 --- Comment #12 from Mikael Morin 2011-02-20 16:49:48 UTC --- Created attachment 23412 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23412 Patch, no regression modulo an error message change in null_1.f90
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 Mikael Morin changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.20 16:50:19 Ever Confirmed|0 |1
[Bug c/47825] New: SSE bitwise operations on floats work -g, fail -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47825 Summary: SSE bitwise operations on floats work -g, fail -O3 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: cck0...@yahoo.com Created attachment 23413 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23413 .i file Hi folks, I'm trying the vec_sel() example using SSE (bitwise and, or, andnot) to select bits from two vectors to build a third. It works under -g, but fails under -O3. What am I missing? thanks. gcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux Thread model: posix gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) works under: cc -g -o setel setel.c -msse -mmmx -pedantic -Wall fails under: cc -O3 -o setel setel.c -msse -mmmx -pedantic -Wall .i file attached
[Bug fortran/46818] [4.6 Regression] ICE on pointer assignment (-fwhole-file)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46818 --- Comment #7 from Paul Thomas 2011-02-20 17:00:50 UTC --- Author: pault Date: Sun Feb 20 17:00:47 2011 New Revision: 170338 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170338 Log: 2011-02-20 Paul Thomas PR fortran/46818 * gfortran.dg/whole_file_30.f90 : New test. * gfortran.dg/whole_file_31.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_30.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_31.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/46818] [4.6 Regression] ICE on pointer assignment (-fwhole-file)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46818 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Paul Thomas 2011-02-20 17:03:43 UTC --- This was in fact put right by the fix for pr45077. However, I have added the reduced testcase of comment #1. Fixed on trunk. Thanks for the report Martien! Paul
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #6 from Richard Guenther 2011-02-20 17:15:55 UTC --- Author: rguenth Date: Sun Feb 20 17:15:53 2011 New Revision: 170339 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170339 Log: 2011-02-20 Richard Guenther PR lto/47822 * tree.c (free_lang_data_in_decl): Clean builtins from the TU decl BLOCK_VARS. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther 2011-02-20 17:19:04 UTC --- "Fixed".
[Bug c/47825] SSE bitwise operations on floats work -g, fail -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47825 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther 2011-02-20 17:22:58 UTC --- You are violating aliasing rules. Add may_alias to the attributes of your float array.
[Bug objc++/47711] [4.5/4.6 Regression] (even trivial) PCH fails for Objective-C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47711 Nicola Pero changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.5.3 |4.6.0 --- Comment #3 from Nicola Pero 2011-02-20 17:27:57 UTC --- Fixed in trunk. Thanks
[Bug c/47825] SSE bitwise operations on floats work -g, fail -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47825 --- Comment #2 from cck0011 at yahoo dot com 2011-02-20 17:35:56 UTC --- Created attachment 23414 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23414 source file with _may_alias_ attribute added Hi Richard, thanks for replying. I added _may_alias_; no change in results. What am I missing? Source attached. Thanks!
[Bug c++/46394] [C++0X] [4.6 Regression] no matching function with default template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46394 --- Comment #6 from Dodji Seketeli 2011-02-20 17:37:06 UTC --- Author: dodji Date: Sun Feb 20 17:37:03 2011 New Revision: 170341 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170341 Log: PR c++/46394 gcc/cp/ PR c++/46394 * pt.c (tsubst_pack_expansion): do not use cp_tree_equal/same_type_p to detect an expansion of a parameter pack. gcc/testsuite/ PR c++/46394 * g++.dg/template/typedef38.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/typedef38.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug objc/47784] Internal compiler error in dot notation assignment of const value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47784 Nicola Pero changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.6.0 Resolution||FIXED Target Milestone|--- |4.6.0 Known to fail|4.6.0 | --- Comment #3 from Nicola Pero 2011-02-20 17:42:17 UTC --- Fixed in trunk. Thanks
[Bug c/47825] SSE bitwise operations on floats work -g, fail -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47825 --- Comment #3 from Richard Guenther 2011-02-20 17:42:41 UTC --- Probably the same on maskarray. You should also try to update GCC to 4.3.5.
[Bug objc/47813] Some ObjC tests failing on ia64-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47813 Nicola Pero changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Nicola Pero 2011-02-20 17:53:54 UTC --- This is fixed in trunk, and the patch was applied. An explicit testcase that -Wpadded generates no warnings even when ObjC metadata is generated was added. Thanks
[Bug c++/46394] [C++0X] [4.6 Regression] no matching function with default template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46394 --- Comment #7 from Dodji Seketeli 2011-02-20 18:08:14 UTC --- Fixed in trunk (4.6).
[Bug c++/46394] [C++0X] [4.6 Regression] no matching function with default template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46394 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Dodji Seketeli 2011-02-20 18:09:04 UTC --- Really close the bug.
[Bug bootstrap/47826] New: r170321 breaks bootstrap-lto on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47826 Summary: r170321 breaks bootstrap-lto on x86_64-apple-darwin10 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu The commit... r170321 | rguenth | 2011-02-19 14:50:36 -0500 (Sat, 19 Feb 2011) | 8 lines 2011-02-18 Richard Guenther PR lto/47647 * lto-streamer-in.c (lto_input_ts_decl_minimal_tree_pointers): Remove lazy BLOCK_VARS streaming. (lto_input_ts_block_tree_pointers): Likewise. * lto-streamer-out.c (lto_output_ts_block_tree_pointers): Likewise. breaks the bootstrap-lto on x86_64-apple-darwin10. At r170320, the bootstrap-lto bootstrap configured with... ../gcc/configure --enable-checking=yes --prefix=/Users/howarth/dist --with-gmp=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-build-config=bootstrap-lto --enable-stage1-languages=c,lto --enable-languages=c,lto --enable-cloog-backend=legacy works fine. At r170321, it fails at... Configuring stage 2 in ./intl configure: loading cache ./config.cache checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether NLS is requested... yes checking for msgfmt... /sw/bin/msgfmt checking for gmsgfmt... /sw/bin/msgfmt checking for xgettext... /sw/bin/xgettext checking for msgmerge... /sw/bin/msgmerge checking for x86_64-apple-darwin10.6.0-gcc... /Users/howarth/darwin_objdir/./prev-gcc/xgcc -B/Users/howarth/darwin_objdir/./prev-gcc/ -B/Users/howarth/dist/x86_64-apple-darwin10.6.0/bin/ -B/Users/howarth/dist/x86_64-apple-darwin10.6.0/bin/ -B/Users/howarth/dist/x86_64-apple-darwin10.6.0/lib/ -isystem /Users/howarth/dist/x86_64-apple-darwin10.6.0/include -isystem /Users/howarth/dist/x86_64-apple-darwin10.6.0/sys-include checking for C compiler default output file name... configure: error: in `/Users/howarth/darwin_objdir/intl': configure: error: C compiler cannot create executables See `config.log' for more details. make[2]: *** [configure-stage2-intl] Error 77 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #8 from mrs at gcc dot gnu.org 2011-02-20 18:10:06 UTC --- Created attachment 23415 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23415 darwin patch (moxie is unrelated) Here is a darwin patch. Not my code, but if I understand the problem, this should fix the darwin problems. This doesn't fix the moxie problems, nor any other non-darwin problems.
[Bug c/47825] SSE bitwise operations on floats work -g, fail -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47825 --- Comment #4 from cck0011 at yahoo dot com 2011-02-20 18:22:46 UTC --- (In reply to comment #3) > Probably the same on maskarray. You should also try to update GCC to > 4.3.5. Hi Richard, added to maskarray as well: no change in results. Adding option -fno-strict-aliasing fixes it as well. I'm confused: since _mm_store_ps explicitly copies into floatarray why is aliasing an issue? thanks!
[Bug target/38306] [4.4/4.5/4.6 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 Steven Bosscher changed: What|Removed |Added Status|WAITING |NEW
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 m...@gcc.gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #9 from mrs at gcc dot gnu.org 2011-02-20 18:57:24 UTC --- The Objective and Objective-C++ testsuites look good to me on darwin10. Dominique, can you try a build on ppc? I did a build on my franken ppc (x86_64 running rosetta), and it looked fine. I ran the RUNTESTFLAGS=builtins.exp=builtins/20010124-1.c testcase, and I saw it go from not working to working.
[Bug bootstrap/47826] r170321 breaks bootstrap-lto on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47826 --- Comment #1 from Jack Howarth 2011-02-20 18:59:39 UTC --- The bootstrap-lto failure is "fixed" at r170339. r170339 | rguenth | 2011-02-20 12:15:53 -0500 (Sun, 20 Feb 2011) | 6 lines 2011-02-20 Richard Guenther PR lto/47822 * tree.c (free_lang_data_in_decl): Clean builtins from the TU decl BLOCK_VARS.
[Bug bootstrap/47826] r170321 breaks bootstrap-lto on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47826 --- Comment #2 from Jack Howarth 2011-02-20 19:02:52 UTC --- Created attachment 23416 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23416 config.log from stage2 in intl on x86_64-apple-darwin10 at r170320
[Bug bootstrap/47826] r170321 breaks bootstrap-lto on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47826 --- Comment #3 from Jack Howarth 2011-02-20 19:03:23 UTC --- Created attachment 23417 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23417 config.log from stage2 in intl on x86_64-apple-darwin10 at r170321
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #10 from Dominique d'Humieres 2011-02-20 19:12:31 UTC --- > Dominique, can you try a build on ppc? Mike, could you be more precise: do you want me to test the patch in comment #8 before or after updating to revision 170339 (which fix this pr, at least on x86_64-apple-darwin10)?
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #11 from Mike Stump 2011-02-20 19:23:07 UTC --- Could you try building with the patch on a ppc box if you have one, without the "Fix" to tree.c in it, so that it will fail, if the problem isn't really fixed. If you don't, then a second set of hands testing would be nice, if we want to put this into the tree before stage1. Richard, should the darwin fix go in now, or wait til stage1?
[Bug bootstrap/47826] r170321 breaks bootstrap-lto on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47826 --- Comment #4 from Mike Stump 2011-02-20 19:35:26 UTC --- Is this a dup of PR47822? If so, that's been fixed twice over already.
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #12 from Dominique d'Humieres 2011-02-20 19:40:18 UTC --- > Could you try building with the patch on a ppc box if you have one, without > the > "Fix" to tree.c in it, so that it will fail, if the problem isn't really > fixed. I have applied the patch in comment #8 on top of revision 170338 on my ppc box. This box is quite slow, so don't expect results before tomorrow morning (GMT).
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 Jack Howarth changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #13 from Jack Howarth 2011-02-20 19:52:57 UTC --- The patch from Comment 8 does resolve the bootstrap-lto failures on x86_64-apple-darwin10 (PR47822) at r170338 (in absence of the r170339 workaround).
[Bug bootstrap/47826] r170321 breaks bootstrap-lto on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47826 --- Comment #5 from Jack Howarth 2011-02-20 19:54:16 UTC --- (In reply to comment #4) > Is this a dup of PR47822? If so, that's been fixed twice over already. Apparently as the proposed patch from http://gcc.gnu.org/bugzilla/attachment.cgi?id=23415 solves the bootstrap-lto failures in the absence of r170339 workaround.
[Bug preprocessor/47823] #pragma once not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47823 --- Comment #1 from Andrew Pinski 2011-02-20 20:40:03 UTC --- At one point it was documented in the C preprocessor manual but it is no longer documented there.
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #2 from Andrew Pinski 2011-02-20 20:40:57 UTC --- (In reply to comment #1) > It would also be nice to list all warnings not included in -Wall -Wextra. The list in the manual already.
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Andrew Pinski 2011-02-20 20:42:02 UTC --- Dup of bug 31573. *** This bug has been marked as a duplicate of bug 31573 ***
[Bug c++/31573] -Wall-all to enable all warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 Andrew Pinski changed: What|Removed |Added CC||olafvdspek at gmail dot com --- Comment #4 from Andrew Pinski 2011-02-20 20:42:02 UTC --- *** Bug 47824 has been marked as a duplicate of this bug. ***
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 --- Comment #13 from Dominique d'Humieres 2011-02-20 20:49:44 UTC --- I have applied the patch in comment #12 on top of revision 170344. > Patch, no regression modulo an error message change in null_1.f90 The error is changed from Error: Different types in pointer assignment at (1); attempted assignment of REAL(8) to REAL(4) to Error: Different kind type parameters in pointer assignment at (1) Although I prefer the first form, if it is proven that it is too much work to recover it, the second one requires only to adjust the tests. More annoying the patch breaks the 'move_alloc()' calls, e.g., pr42274 comment #1 or pr42769 comment #1 (apparently this new feature is not tested in the test suite). While looking at the code I have noticed something odd at lines 408 of gcc/fortran/interface.c (patched file): if (derived1 != NULL && derived2 != NULL && strcmp (derived1->name, derived2->name) == 0 && derived1->module != NULL && derived2->module != NULL && strcmp (derived1->module, derived2->module) == 0) return 1; /* Compare type via the rules of the standard. Both types must have the SEQUENCE attribute to be equal. */ if (strcmp (derived1->name, derived2->name)) return 0; If the test 'derived1 != NULL && derived2 != NULL' is really required (i.e., derived1 or derived2 can be NULL when entering the proc), is not it also required later in the code (e.g., strcmp (derived1->name, derived2->name))?
[Bug preprocessor/39029] #pragma once is not "exported" from the precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.02.20 21:10:59 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Manuel López-Ibáñez 2011-02-20 21:10:59 UTC --- We need more information. Please follow the instructions here: http://gcc.gnu.org/bugs/#report
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #4 from Olaf van der Spek 2011-02-20 21:07:07 UTC --- (In reply to comment #2) > (In reply to comment #1) > > It would also be nice to list all warnings not included in -Wall -Wextra. > > The list in the manual already. Where?
[Bug bootstrap/47827] New: gcc fails to bootstrap on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47827 Summary: gcc fails to bootstrap on i386-pc-solaris2.10 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: gsean...@gmail.com Somewhere between revision 170122 and now, gcc no longer bootstraps on Solaris 10. Here is the error from the build log: libtool: compile: /BUILD/gcc/obj-170344/./gcc/xgcc -B/BUILD/gcc/obj-170344/./gcc/ -B/BUILD/gcc/170344/i386-pc-solaris2.10/bin/ -B/BUILD/gcc/170344/i386-pc-solaris2.10/lib/ -isystem /BUILD/gcc/170344/i386-pc-solaris2.10/include -isystem /BUILD/gcc/170344/i386-pc-solaris2.10/sys-include -m64 -DHAVE_CONFIG_H -I. -I/SOURCES/gcc-trunk/libquadmath -g -O2 -m64 -MT strtod/strtoflt128.lo -MD -MP -MF strtod/.deps/strtoflt128.Tpo -c /SOURCES/gcc-trunk/libquadmath/strtod/strtoflt128.c -fPIC -DPIC -o strtod/.libs/strtoflt128.o In file included from /SOURCES/gcc-trunk/libquadmath/strtod/strtoflt128.c:44:0: /SOURCES/gcc-trunk/libquadmath/strtod/strtod_l.c: In function ‘strtoflt128_internal’: /SOURCES/gcc-trunk/libquadmath/strtod/strtod_l.c:556:19: error: ‘NAN’ undeclared (first use in this function) /SOURCES/gcc-trunk/libquadmath/strtod/strtod_l.c:556:19: note: each undeclared identifier is reported only once for each function it appears in make[6]: *** [strtod/strtoflt128.lo] Error 1
[Bug c++/46472] [4.6 Regression] [C++0X] constexpr is not constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46472 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Jason Merrill 2011-02-20 21:46:49 UTC --- Looking.
[Bug bootstrap/47827] gcc fails to bootstrap on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47827
--- Comment #1 from Jakub Jelinek 2011-02-20
21:59:30 UTC ---
Author: jakub
Date: Sun Feb 20 21:59:28 2011
New Revision: 170346
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170346
Log:
PR bootstrap/47827
* printf/quadmath-printf.h (NAN): Redefine to __builtin_nanf ("").
Modified:
trunk/libquadmath/ChangeLog
trunk/libquadmath/printf/quadmath-printf.h
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 --- Comment #14 from Dominique d'Humieres 2011-02-20 22:01:54 UTC --- > (apparently this new feature is not tested in the test suite) This wrong, there are several tests;-) The one that is missing is of the form: module psb_base_mat_mod type :: psb_base_sparse_mat integer, private :: m, n integer, private :: state, duplicate logical, private :: triangle, unitd, upper, sorted end type psb_base_sparse_mat end module psb_base_mat_mod module psb_d_base_mat_mod use psb_base_mat_mod integer, parameter :: psb_dpk_ = kind(1.d0) type, extends(psb_base_sparse_mat) :: psb_d_base_sparse_mat end type psb_d_base_sparse_mat type, extends(psb_d_base_sparse_mat) :: psb_d_coo_sparse_mat integer :: nnz integer, allocatable :: ia(:), ja(:) real(psb_dpk_), allocatable :: val(:) end type psb_d_coo_sparse_mat end module psb_d_base_mat_mod module psb_d_mat_mod use psb_d_base_mat_mod type :: psb_d_sparse_mat class(psb_d_base_sparse_mat), allocatable :: a contains procedure, pass(a) :: d_csclip generic, public:: csclip => d_csclip end type psb_d_sparse_mat contains subroutine d_csclip(a,b,info) use psb_d_base_mat_mod implicit none class(psb_d_sparse_mat), intent(in) :: a class(psb_d_sparse_mat), intent(out) :: b integer,intent(out) :: info type(psb_d_coo_sparse_mat), allocatable :: acoo info = 0 allocate(acoo,stat=info) if (info == 0) call move_alloc(acoo,b%a) end subroutine d_csclip end module psb_d_mat_mod
[Bug fortran/47797] Debug: Odd first break point for subroutine breakp w/ allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47797 --- Comment #2 from Tobias Burnus 2011-02-20 22:16:51 UTC --- Author: burnus Date: Sun Feb 20 22:16:47 2011 New Revision: 170347 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170347 Log: 2011-02-20 Tobias Burnus PR fortran/47797 * trans-decl.c (gfc_trans_deferred_vars): Use gfc_set_backend_locus and gfc_restore_backend_locus to have better debug locations. * trans-array.c (gfc_trans_deferred_array): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c
[Bug fortran/47797] Debug: Odd first break point for subroutine breakp w/ allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47797 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Tobias Burnus 2011-02-20 22:19:46 UTC --- FIXED on the 4.6 trunk.
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez 2011-02-20 22:38:42 UTC --- (In reply to comment #4) > (In reply to comment #2) > > (In reply to comment #1) > > > It would also be nice to list all warnings not included in -Wall -Wextra. > > > > The list in the manual already. > > Where? It is implicitly in the manual as those that are not mentioned as enabled by Wall or Wextra. It would be nice to have a list of options enabled by default and another list of options never enabled by default or by other option. However, I doubt that any of the current GCC devs will ever bother to create such lists, so if you are interested, please send a documentation patch. It is a matter of reading about all warning options mentioned in http://gcc.gnu.org/onlinedocs/gcc/ and creating the lists.
[Bug c++/47703] [4.6 Regression] [C++0x] ICE: std::sort chokes on simple lambda function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47703 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org --- Comment #5 from Jason Merrill 2011-02-20 23:07:27 UTC --- Got it.
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 --- Comment #15 from Mikael Morin 2011-02-20 23:13:32 UTC --- (In reply to comment #13) > Although I prefer the first form, if it is proven that it is too much work to > recover it, the second one requires only to adjust the tests. I didn't notice there was a second part in the error message, so I thought the new message was better (more precise). It is just a gfc_compare_type VS gfc_TK_compatible change, I believe. Actually none of the gfc_compare_type/gfc_TK_compatible changes are absolutely necessary to fix this bug. It is just I found it odd that gfc_compare_type was calling gfc_type_compatible (compatible types are not necessary equal/equivalent), so I changed it so that gfc_type_compatible calls gfc_compare_type instead. And then the new gfc_TK_compatible function to not upset the testsuite. Maybe I just don't understand what "compare types" means. :-( > More annoying the > patch breaks the 'move_alloc()' calls, e.g., pr42274 comment #1 or pr42769 > comment #1 (apparently this new feature is not tested in the test suite). Will look into it later. > > While looking at the code I have noticed something odd at lines 408 of > gcc/fortran/interface.c (patched file): > > if (derived1 != NULL && derived2 != NULL > && strcmp (derived1->name, derived2->name) == 0 > && derived1->module != NULL && derived2->module != NULL > && strcmp (derived1->module, derived2->module) == 0) > return 1; > > /* Compare type via the rules of the standard. Both types must have > the SEQUENCE attribute to be equal. */ > > if (strcmp (derived1->name, derived2->name)) > return 0; > > If the test 'derived1 != NULL && derived2 != NULL' is really required (i.e., > derived1 or derived2 can be NULL when entering the proc), is not it also > required later in the code (e.g., strcmp (derived1->name, derived2->name))? Hem, yes, who wrote this? ( I hope it's not me ;-) ).
[Bug c++/46472] [4.6 Regression] [C++0X] constexpr is not constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46472 --- Comment #4 from Jason Merrill 2011-02-20 23:18:06 UTC --- Author: jason Date: Sun Feb 20 23:18:01 2011 New Revision: 170348 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170348 Log: PR c++/46472 * method.c (process_subob_fn): Instantiate constexpr templates. * optimize.c (maybe_clone_body): Propagate DECL_DECLARED_CONSTEXPR_P. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-synth1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c trunk/gcc/cp/optimize.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47703] [4.6 Regression] [C++0x] ICE: std::sort chokes on simple lambda function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47703 --- Comment #6 from Jason Merrill 2011-02-20 23:18:16 UTC --- Author: jason Date: Sun Feb 20 23:18:11 2011 New Revision: 170349 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170349 Log: PR c++/47703 * error.c (location_of): Handle non-tagged types. Added: trunk/gcc/testsuite/g++.dg/overload/conv-op1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47703] [4.6 Regression] [C++0x] ICE: std::sort chokes on simple lambda function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47703 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jason Merrill 2011-02-20 23:19:57 UTC --- Fixed.
[Bug c++/46472] [4.6 Regression] [C++0X] constexpr is not constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46472 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jason Merrill 2011-02-20 23:20:45 UTC --- Fixed.
[Bug c++/46831] [4.6 Regression][C++0x] Crash when it tries to do an invalid ICS with a conversion function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46831 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Jason Merrill 2011-02-20 23:26:03 UTC --- Got it.
[Bug c++/47774] [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774 --- Comment #5 from Paolo Carlini 2011-02-20 23:33:24 UTC --- Please double check that now that 46472 is fixed this is also fixed.
[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #5 from Steven Bosscher 2011-02-21 00:10:21 UTC --- (In reply to comment #4) Adjusting the minimum required binutils version to what? For modifying GCC, relatively new versions of libraries and tools are often required. GMP 4.3.2 for example is from January 2010, autoconf 2.64 was released in July 2009, and automake 1.11.1 is from December 2009. But IMHO it should be possible to build and use GCC with relatively old tools. For example, gmake 3.80 is sufficient, and that's from October 2002. Likewise for other "Tools/packages necessary for building GCC". GNU binutils 2.18 is from August 2007, which is not really that old. But disabling a feature in the compiler depending on a configuration check on the installed version of a linker it also seems strange to me. You end up with the same GCC version generating different code depending on the linker. FWIW, quick link to the revision mentioned to have causes this problem: http://gcc.gnu.org/viewcvs?view=revision&revision=167085 http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02154.html
[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek 2011-02-21 00:23:09 UTC --- So what do you suggest then, if you dislike both updating the minimum version and disabling the feature based on ld version? Just document that --gc-sections will not work with old binutils?
[Bug c++/46831] [4.6 Regression][C++0x] Crash when it tries to do an invalid ICS with a conversion function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46831 --- Comment #8 from Jason Merrill 2011-02-21 01:50:44 UTC --- Author: jason Date: Mon Feb 21 01:50:39 2011 New Revision: 170354 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170354 Log: PR c++/46831 * call.c (convert_class_to_reference): Don't try to set up a second conv sequence for non-viable candidates. Added: trunk/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47774] [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #6 from Jason Merrill 2011-02-21 02:12:11 UTC --- Yep, this is fixed too. *** This bug has been marked as a duplicate of bug 46472 ***
[Bug c++/46472] [4.6 Regression] [C++0X] constexpr is not constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46472 Jason Merrill changed: What|Removed |Added CC||dev.lists at jessamine dot ||co.uk --- Comment #6 from Jason Merrill 2011-02-21 02:12:11 UTC --- *** Bug 47774 has been marked as a duplicate of this bug. ***
[Bug target/47764] The constant load instruction should be hoisted out of loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47764
--- Comment #3 from Carrot 2011-02-21 03:15:45 UTC
---
> Any ideas of how this improvement could be implemented, Carrot?
The root cause of this problem is that arm/thumb store instruction can't
directly store a immediate number to memory, but gcc doesn't realize this early
enough. In most part of the rtl phase, the following form is kept.
(insn 41 38 42 3 (set (mem:HI (plus:SI (reg/f:SI 169)
(const_int 60 [0x3c])) [2 MEM[(struct deflate_state *)D.2085
_3 + 60B]+0 S2 A16])
(const_int 0 [0])) src/trees.c:45 696 {*thumb2_movhi_insn}
(expr_list:REG_DEAD (reg/f:SI 169)
(nil)))
Until register allocation it finds the restriction of the store instruction and
split it into two instructions, load 0 into register and store register to
memory. But it's too late to do a loop optimization.
One possible method is to split this insn earlier than loop optimization (maybe
directly in expand pass), and let loop and cse optimizations do the rest. It
may increase register pressure in part of the program, we should rematerialize
it in such cases.
[Bug bootstrap/47826] r170321 breaks bootstrap-lto on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47826 m...@gcc.gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mrs at gcc dot gnu.org Resolution||DUPLICATE --- Comment #6 from mrs at gcc dot gnu.org 2011-02-21 04:09:52 UTC --- Ok, thanks. *** This bug has been marked as a duplicate of bug 47822 ***
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #14 from mrs at gcc dot gnu.org 2011-02-21 04:09:52 UTC --- *** Bug 47826 has been marked as a duplicate of this bug. ***
[Bug c/47796] The code to write to a bit_field data strucuture will be removed unexpectedly with gcc 4.5.1 -O2 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47796
qihua.dai at intel dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Comment #3 from qihua.dai at intel dot com 2011-02-21 04:58:48 UTC ---
(In reply to comment #1)
> You are violating C/C++ aliasing rules:
> pData = (unsigned int *)pTmp;
> data = *pData;
> printf("data = 0x%x\n", data);
> You access a tmp_t via an unsigned int which is undefined.
If it's not a bug, why is there the different behavior for -O0 and -O2
[Bug c++/47828] New: GCC instantiates function template with "auto" type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47828
Summary: GCC instantiates function template with "auto" type
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com
The following causes GCC to instantiate a function template using "auto" as a
template argument:
template T *f() {
// funny: T is auto here
return 0;
}
int main() {
auto *(*g)() = f;
g();
}
No error is generated: The compiled code runs. My best guess is, when taking
the address of an overloaded function, GCC deduces the overloaded function
against the target type, which apparently still is "auto*()" at that point, and
therefor deduces "T" to auto, and then when it declares variable "g" deduces
its type to "auto*(*)()".
Frankly, I'm not sure what the Standard says how such cases need to be handled.
A reasonable action is to not do deduction against the target type "auto*()"
and keep 'f' being a set of overloaded functions until initialization. Then,
when it deduces the type of 'g', it would deduce it against a set of overloaded
functions containing function templates, thus creating a non-deduced context
and error out at that point. This matches clang's behavior, which accepts the
following:
void f();
void f(int);
int main() {
auto (*g)() = f;
}
GCC rejects that currently, because it tries to deduce 'f' against the target
type early on, when "g"'s function type is still "auto()", while clang waits
and first deduces g's type using a set of overloaded functions, deducing the
"auto" to 'void'.
[Bug c++/47199] [4.6 Regression] [C++0x] ICE: expected class 'type', have 'declaration' (function_decl) in same_type_ignoring_top_level_qualifiers_p, at cp/typeck.c:1407 with -fno-elide-constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47199 --- Comment #2 from Jason Merrill 2011-02-21 05:26:01 UTC --- Author: jason Date: Mon Feb 21 05:25:56 2011 New Revision: 170356 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170356 Log: PR c++/47199 * semantics.c (cxx_eval_call_expression): Call cxx_eval_constant_expression in trivial shortcut. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 --- Comment #7 from Jason Merrill 2011-02-21 05:30:18 UTC --- We control lots of things based on whether or not the other tools support a particular feature. Doing the same for this issue doesn't seem strange at all to me.
[Bug target/47829] New: no .eh_frame_hdr table will be created.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47829
Summary: no .eh_frame_hdr table will be created.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ka...@gcc.gnu.org
FreeBSD updated its ancient version of in-system binutils
to 2.17. In doing so, an assert is firing in ld. The
problem was addressed in the in FreeBSD's ancient gcc with
this commit
--
laptop:root[211] svn log -r 209294 | more
r209294 | kib | 2010-06-18 04:09:51 -0700 (Fri, 18 Jun 2010) | 16 lines
Often reported issue with newer ld is:
error in /usr/lib/crtendS.o(.eh_frame); no .eh_frame_hdr table will be created.
The issue is that crtend is compiled with unwind table, and also it
places the special CIE into the .eh_frame indicating the end of section,
that is located before generated unwind table. New ld has assertion that
verifies that closing CIE is indeed the last CIE, causing the crypting
message to be issued, and refusing to generate dwarf unwind.
Add -fno-asynchronous-unwind-tables to disable unwind table generation
for crtbegin/crtend. While there, disable omitting the frame pointer [1].
This patch fixes the issue for GCC trunk on i686-*-freebsd.
laptop:kargl[246] svn diff gcc/config.gcc
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 170344)
+++ gcc/config.gcc (working copy)
@@ -1210,6 +1210,7 @@ x86_64-*-elf*)
;;
i[34567]86-*-freebsd*)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
${fbsd_tm_file} i386/freebsd.h"
+ tmake_file="${tmake_file} i386/t-crtstuff"
;;
x86_64-*-freebsd*)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
${fbsd_tm_file} i386/x86-64.h i386/freebsd.h i386/freebsd64.h"
[Bug c/47796] The code to write to a bit_field data strucuture will be removed unexpectedly with gcc 4.5.1 -O2 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47796 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Andrew Pinski 2011-02-21 06:58:03 UTC --- (In reply to comment #3) > If it's not a bug, why is there the different behavior for -O0 and -O2 Because strict aliasing is not enabled at -O0, only at -O2 and above (-Os included).
