[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #4 from vincenzo Innocente 2011-06-11 07:06:24 UTC --- Thanks for the clarification, waiting for some patch/branch to test. please keep me posted (or let me know with PR I shall watch).
[Bug tree-optimization/49352] [4.7 Regression] -fcompare-debug failure with -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352 --- Comment #8 from Ira Rosen 2011-06-11 07:54:55 UTC --- Created attachment 24490 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24490 an updated patch I updated your patch: - call vect_is_slp_reduction only if check_reduction is true - removed COND_EXPR and GIMPLE_BINARY_RHS checks - replaced !is_pattern_stmt_p with !STMT_VINFO_IN_PATTERN_P for use_stmt, because we actually want the pattern stmt and not the stmt it replaced Bootstrapped and tested on powerpc64-suse-linux. Thanks, Ira
[Bug libfortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49296 Janne Blomqvist changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | --- Comment #8 from Janne Blomqvist 2011-06-11 08:41:40 UTC --- Assigning to myself. I'm pretty busy at the moment, though.. :( Anyways, seems the problem is that we hit EOF before the end of the record; that is, read.dat doesn't contain a \n at the end of the line. Shouldn't be too hard to fix.
[Bug driver/49371] New: xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 Summary: xgcc: error: unrecognized option '-pie' on *-apple-darwin* Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: mikest...@comcast.net, jos...@codesourcery.com, r...@cebitec.uni-bielefeld.de, ia...@gcc.gnu.org Host: *-apple-darwin* Target: *-apple-darwin* Build: *-apple-darwin* On *-apple-darwin* revisions 174909 and 174910 introduced several failures in gcc.dg/torture/tls/* with '-pie -fPIE' (see http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg01259.html ). The errors are all (AFAICT) of the kind. FAIL: gcc.dg/torture/tls/thr-init-1.c -O0 -pie -fpie (test for excess errors) Excess errors: xgcc: error: unrecognized option '-pie' My understanding of -pie is that it is a linker option supported by *-apple-darwin9 and later. Apparently this option is not recognized by gcc since at least version 4.4.4, this is why I mark this PR as a driver one (please change it if you disagree). A short term fix will be to remove darwin from proc check_effective_target_pie { } { if { [istarget *-*-darwin\[912\]*] || [istarget *-*-linux*] } { return 1; } return 0 } in gcc/testsuite/lib/target-supports.exp, but I think the darwin driver should be fixed.
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 --- Comment #1 from Dominique d'Humieres 2011-06-11 12:07:39 UTC --- It seems that there are the same failures on i686-pc-linux-gnu (see http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg01202.htm ).
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 --- Comment #2 from Dominique d'Humieres 2011-06-11 12:17:24 UTC --- > It seems that there are the same failures on i686-pc-linux-gnu In this case it is runtime failures of the kind: ./run-le.exe: error while loading shared libraries: cannot restore segment prot after reloc: Permission denied FAIL: gcc.dg/torture/tls/run-le.c -O0 -pie -fpie execution test (see http://glutton.geoffk.org/HEAD/native-logsum/gcc/testsuite/gcc/gcc.log.gzip ).
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #8 from Mikael Pettersson 2011-06-11 12:33:09 UTC --- Created attachment 24491 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24491 patch fixing m68k function call abi issues in gnat WRT the the m68k function call ABI issues, I believe there are only a few cases where gnat does something which breaks m68k: - __gnat_malloc is defined in Ada to return Address (integer, so in d0), but it's called from a couple of places via fake "extern" declarations that pretend it returns void* (pointer, so in a0). The attached patch fixes the two call sites affected (in Interfaces.C.Strings and build_call_alloc_dealloc), as well as the internal fake prototype (init_gigi_decls). - Source code inspection showed that get_jmpbuf_address probably suffers from the same issue (mismatching decl and use via wrong intermediate fake prototype) so I fixed that too. There are a number of pointer-returning C library routines that are imported as-is with fake prototypes that declare them as returning Address. While wrong, this should work since the ABI returns pointers in both d0 and a0. With these fixes in place I can bootstrap gnat et al and the resulting binaries can be executed: aranym5_21_~/gnatroot/bin/gnat GNAT 4.4.7 20110419 (prerelease) Copyright 1996-2008, Free Software Foundation, Inc. List of available commands gnat bind gnatbind gnat chop gnatchop gnat clean gnatclean gnat compilegnatmake -f -u -c gnat check gnatcheck gnat sync gnatsync gnat elim gnatelim gnat find gnatfind gnat krunch gnatkr gnat link gnatlink gnat list gnatls gnat make gnatmake gnat metric gnatmetric gnat name gnatname gnat preprocess gnatprep gnat pretty gnatpp gnat stack gnatstack gnat stub gnatstub gnat xref gnatxref Commands find, list, metric, pretty, stack, stub and xref accept project file switches -vPx, -Pprj and -Xnam=val However, compiling the most trivial Ada program now fails with an assertion: aranym5_22_cat conftest.adb procedure conftest is begin null; end conftest; aranym5_23_~/gnatroot/bin/gcc -S conftest.adb +===GNAT BUG DETECTED==+ | 4.4.7 20110419 (prerelease) (m68k-unknown-linux-gnu) Assert_Failure einfo.adb:1748| | Error detected at system.ads:153:5 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. conftest.adb compilation abandoned In case I missed some return value ABI fixups I hacked the m68k backend to return pointers in a0+d0 as before but always fetch them from d0, but it made no difference. The only potential issues I'm aware of now are endianess and alignment differences between the bootstrap host (i686-linux in my case) and m68k. That's because the bootstrap has to run the host's gnatmake a couple of times to generate the einfo/sinfo/etc thingys, which might not work correctly if the host and target have different endianess or alignment rules. Since I've bootstrapped gnat for big-endian ARM from little-endian i686 before, I don't think endianess is the problem, so I'm leaning towards m68k's unique alignment rules.
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.11 12:48:38 Ever Confirmed|0 |1 --- Comment #3 from Iain Sandoe 2011-06-11 12:48:38 UTC --- (In reply to comment #0) > in gcc/testsuite/lib/target-supports.exp, but I think the darwin driver should > be fixed. agreed, (-pie is silently ignored by Apple's gcc and gcc-4.2). we just need an 'ignore' line in the appropriate .opt I guess.. FWIW: -fpie is working correctly: $ ./gcc/xgcc -Bgcc ../tests/hello.c -o hc -fpie $ otool -hv hc hc: Mach header magic cputype cpusubtype capsfiletype ncmds sizeofcmds flags MH_MAGIC PPCppc7400 0x00 EXECUTE12 1168 NOUNDEFS DYLDLINK TWOLEVEL PIE
[Bug c++/49372] New: Temporaries evaluated for arguments of a default constructors of array elements not destructed properly (?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49372 Summary: Temporaries evaluated for arguments of a default constructors of array elements not destructed properly (?) Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: schaub.johan...@googlemail.com This testcase outputs a surprising result: struct A { A() { std::cout << "C" << std::endl; } ~A() { std::cout << "D" << std::endl; } }; struct B { B(A const& a = A()) { } }; typedef B array[2]; int main() { array{}; } GCC prints "CCDD". I would have expected "CDCD", as it seems that is the intent of the wording in the spec (FDIS). The FDIS however seems to be contradicting here, but it appears to me that GCC should better print "CDCD", so as to follow the intent. Originated from http://stackoverflow.com/questions/6315670/when-an-array-is-created-by-a-subexpression-what-happens-with-the-temporaries-th .
[Bug c++/49372] Temporaries evaluated for arguments of a default constructors of array elements not destructed properly (?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49372 --- Comment #1 from Johannes Schaub 2011-06-11 13:46:46 UTC --- To elaborate on it, I have the following weird behavior: - GCC4.6 outputs nothing for the program (on my linux machine). That seems definitely wrong in any case. - GCC4.7 "4.7.0 20110517 (experimental)", using a mingw nightly build, generates an executable that crashes when running: [js@HOST2 cpp]$ ~/w64/bin/i686-w64-mingw32-g++ -std=c++0x -O1 -o a.exe main1.cpp [js@HOST2 cpp]$ wine ./a.exe Cwine: Unhandled page fault on read access to 0x at address (nil) (thread 0025), starting debugger... - The same GCC4.7 when using -O2 does not crash and print "CCDD": [js@HOST2 cpp]$ ~/w64/bin/i686-w64-mingw32-g++ -std=c++0x -O2 -o a.exe main1.cpp [js@HOST2 cpp]$ wine ./a.exe fixme:ntoskrnl:KeInitializeSpinLock stub: 0x5477a4 C C D D I don't know precisely whether this is a problem with wine or a temporary problem with that nightly build of GCC I was using. My apologies if GCC trunk works differently!
[Bug middle-end/49373] New: [4.7 Regression] Many testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49373 Summary: [4.7 Regression] Many testcase failures Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 174952 gave FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link, -O0 -flto FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link, -O0 -flto -flto-partition=1to1 FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link, -O0 -flto -flto-partition=none FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link, -O2 -flto FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link, -O2 -flto -flto-partition=1to1 FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link, -O2 -flto -flto-partition=none FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2 FAIL: g++.dg/torture/pr40389.C -O2 -flto execution test FAIL: g++.dg/torture/pr40389.C -O2 -flto -flto-partition=none execution test FAIL: g++.dg/torture/pr43879-1_1.C -O1 execution test FAIL: g++.dg/torture/pr43879-1_1.C -O2 execution test FAIL: g++.dg/torture/pr43879-1_1.C -O3 -fomit-frame-pointer execution test FAIL: g++.dg/torture/pr43879-1_1.C -O3 -g execution test FAIL: g++.dg/torture/pr43879-1_1.C -Os execution test FAIL: gcc.c-torture/execute/builtins/strlen-3.c execution, -O2 -flto FAIL: gcc.c-torture/execute/builtins/strlen-3.c execution, -O2 -flto -flto-partition=none FAIL: gcc.dg/guality/vla-1.c -O2 -flto line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -O2 -flto -flto-partition=none line 17 sizeof (a) == 6 Revision 174911 is OK.
[Bug middle-end/49373] [4.7 Regression] Many testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49373 H.J. Lu changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.7.0 --- Comment #1 from H.J. Lu 2011-06-11 16:07:50 UTC --- Revision 174952: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00441.html caused: FAIL: g++.dg/torture/pr43879-1_1.C -O1 execution test FAIL: g++.dg/torture/pr43879-1_1.C -O2 execution test FAIL: g++.dg/torture/pr43879-1_1.C -O3 -fomit-frame-pointer execution test FAIL: g++.dg/torture/pr43879-1_1.C -O3 -g execution test FAIL: g++.dg/torture/pr43879-1_1.C -Os execution test
[Bug middle-end/49373] [4.7 Regression] Many testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49373 --- Comment #2 from H.J. Lu 2011-06-11 16:13:38 UTC --- All most all failures are caused by revision 174952: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00441.html
[Bug target/49374] New: [4.5 Regression] x86 backend is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49374 Summary: [4.5 Regression] x86 backend is broken Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: ubiz...@gmail.com On Linux/ia32, revision 174953 gave: New failures: FAIL: ./array-1.H -O2 (test for excess errors) FAIL: ./array-1.H -O2 -g (test for excess errors) FAIL: ./array-1.H -g (test for excess errors) FAIL: ./empty.H -O2 (test for excess errors) FAIL: ./empty.H -O2 -g (test for excess errors) FAIL: ./empty.H -g (test for excess errors) FAIL: ./externc-1.H -O2 (test for excess errors) FAIL: ./externc-1.H -O2 -g (test for excess errors) FAIL: ./externc-1.H -g (test for excess errors) FAIL: ./local-1.H -O2 (test for excess errors) FAIL: ./local-1.H -O2 -g (test for excess errors) FAIL: ./local-1.H -g (test for excess errors) FAIL: ./pch.H -O2 (test for excess errors) FAIL: ./pch.H -O2 -g (test for excess errors) FAIL: ./pch.H -g (test for excess errors) FAIL: ./static-1.H -O2 (test for excess errors) FAIL: ./static-1.H -O2 -g (test for excess errors) FAIL: ./static-1.H -g (test for excess errors) FAIL: ./system-1.H -O2 (test for excess errors) FAIL: ./system-1.H -O2 -g (test for excess errors) FAIL: ./system-1.H -g (test for excess errors) FAIL: ./system-2.H -O2 (test for excess errors) FAIL: ./system-2.H -O2 -g (test for excess errors) FAIL: ./system-2.H -g (test for excess errors) FAIL: ./template-1.H -O2 (test for excess errors) FAIL: ./template-1.H -O2 -g (test for excess errors) FAIL: ./template-1.H -g (test for excess errors) FAIL: ./uninst.H -O2 (test for excess errors) FAIL: ./uninst.H -O2 -g (test for excess errors) FAIL: ./uninst.H -g (test for excess errors) FAIL: ./wchar-1.H -O2 (test for excess errors) FAIL: ./wchar-1.H -O2 -g (test for excess errors) FAIL: ./wchar-1.H -g (test for excess errors) FAIL: c-c++-common/asmgoto-1.c (test for excess errors) FAIL: c-c++-common/asmgoto-2.c (test for errors, line 10) FAIL: c-c++-common/asmgoto-2.c (test for errors, line 11) FAIL: c-c++-common/asmgoto-2.c (test for errors, line 12) FAIL: c-c++-common/asmgoto-2.c (test for errors, line 13) FAIL: c-c++-common/asmgoto-2.c (test for errors, line 14) FAIL: c-c++-common/asmgoto-2.c (test for errors, line 15) FAIL: c-c++-common/asmgoto-2.c (test for errors, line 16) FAIL: c-c++-common/asmgoto-2.c (test for errors, line 17) FAIL: c-c++-common/asmgoto-2.c (test for errors, line 18) FAIL: c-c++-common/asmgoto-2.c (test for excess errors) FAIL: c-c++-common/asmgoto-3.c (test for excess errors) FAIL: c-c++-common/asmgoto-4.c (test for excess errors) FAIL: c-c++-common/attr-used-2.c (test for warnings, line 8) FAIL: c-c++-common/attr-used-2.c (test for excess errors) FAIL: c-c++-common/attr-used.c (test for excess errors) FAIL: c-c++-common/builtin-offsetof.c (test for errors, line 21) FAIL: c-c++-common/builtin-offsetof.c (test for errors, line 28) FAIL: c-c++-common/builtin-offsetof.c (test for warnings, line 25) FAIL: c-c++-common/builtin-offsetof.c (test for excess errors) FAIL: c-c++-common/dwarf2/pr43190.c (test for excess errors) FAIL: c-c++-common/dwarf2/vla1.c (test for excess errors) FAIL: c-c++-common/pr36513-2.c (test for excess errors) Revision 174635 is OK. It may be caused by revision 174951: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00440.html
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 --- Comment #4 from Dominique d'Humieres 2011-06-11 16:22:20 UTC --- What is the meaning of %{fpie:-pie} in gcc/config/darwin.h?
[Bug target/49374] [4.5 Regression] x86 backend is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49374 --- Comment #1 from H.J. Lu 2011-06-11 16:27:59 UTC --- It could be my setup problem.
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 --- Comment #5 from Iain Sandoe 2011-06-11 16:52:59 UTC --- (In reply to comment #4) > What is the meaning of %{fpie:-pie} in gcc/config/darwin.h? that causes '-pie' to be placed on sub-command lines when '-fpie' is seen (and thus -pie is forwarded to sub-processes of the driver - including the linker). one could use 'fpie|pie' which would substitute -pie for either input - however, I am not sure if there are different intentions for '-pie', '-fpie' and '-fPIE'. I googled briefly, but without much light shed. In the case of the Apple/system compilers: -pie and -fPIE are ignored (silently). The only option that produces PIE executables is -fpie.
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 Jack Howarth changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #6 from Jack Howarth 2011-06-11 17:04:21 UTC --- This came from http://gcc.gnu.org/viewcvs?view=revision&revision=125270 and proposed patch was discussed in these messages... http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00070.html http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00072.html http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00073.html http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00083.html http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00296.html If -pie is darwin9 later, shouldn't its passage to the linker be in darwin9.h instead?
[Bug middle-end/49373] [4.7 Regression] Many testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49373 --- Comment #3 from Jan Hubicka 2011-06-11 17:08:08 UTC --- The patch is expected to cause g++.dg/torture/pr43879-1_1.C. I do not get the other LTO failures. Perhaps it depends whether or not one use linker plugin. The final testing was done on gccfarm machines, so w/o plugin. What kind of error do you get there? I will look into those tomorrow. Honza
[Bug testsuite/49375] New: Target libstdc++.so used by host cc1plus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49375 Summary: Target libstdc++.so used by host cc1plus Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com When ppl is used, cc1plus may be linked against libppl.so, which depends on host libstdc++.so. When LD_LIBRARY_PATH is set to target libstdc++.so to run C++ tests, target libstdc++.so, which was just built and may be incompatible with host libstdc++.so. In my case, host libstdc++.so is from GCC 4.6 and target libstdc++.so is from GCC 4.5. As the result, all C++ tests failed.
[Bug middle-end/49373] [4.7 Regression] Many testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49373 --- Comment #4 from H.J. Lu 2011-06-11 17:43:49 UTC --- (In reply to comment #3) > The patch is expected to cause g++.dg/torture/pr43879-1_1.C. > > I do not get the other LTO failures. Perhaps it depends whether or not one use > linker plugin. The final testing was done on gccfarm machines, so w/o plugin. > What kind of error do you get there? I got /tmp/ccdoubbY.lto.o: In function `C::~C()':^M cp_lto_20081118-1_0.o:(.text+0x50): undefined reference to `C::~C()'^M /tmp/ccdoubbY.lto.o: In function `D::~D()':^M cp_lto_20081118-1_0.o:(.text+0xae): undefined reference to `C::~C()'^M /tmp/ccdoubbY.lto.o:(.rodata+0x10): undefined reference to `C::~C()'^M collect2: error: ld returned 1 exit status^M FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link, -O0 -flto -flto-partition=none and FAIL: gcc.c-torture/execute/builtins/strlen-3.c execution, -O2 -flto -flto-partition=none
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 --- Comment #7 from Iain Sandoe 2011-06-11 17:44:13 UTC --- (In reply to comment #6) > If -pie is darwin9 later, shouldn't its passage to the linker be in darwin9.h > instead? yes, this will need sorting out too - darwin 8' s ld will barf on '-pie'. so you could move the spec to darwin9.h -- - or maybe better put something like this (completely untested, not even checked to compile) Index: gcc/config/darwin.h === --- gcc/config/darwin.h(revision 174947) +++ gcc/config/darwin.h(working copy) @@ -226,6 +226,8 @@ extern GTY(()) int darwin_ms_struct; #define LINK_SYSROOT_SPEC "%{isysroot*:-syslibroot %*}" #endif +#define PIE_SPEC "{-fpie|pie|fPIE:}" + /* Please keep the random linker options in alphabetical order (modulo 'Z' and 'no' prefixes). Note that options taking arguments may appear multiple times on a command line with different arguments each time, @@ -290,7 +292,7 @@ extern GTY(()) int darwin_ms_struct; %:version-compare(< 10.5 mmacosx-version-min= -multiply_defined) \ %:version-compare(< 10.5 mmacosx-version-min= suppress)}} \ %{Zmultiplydefinedunused*:-multiply_defined_unused %*} \ - %{fpie:-pie} \ + " PIE_SPEC " \ %{prebind} %{noprebind} %{nofixprebinding} %{prebind_all_twolevel_modules} \ %{read_only_relocs} \ %{sectcreate*} %{sectorder*} %{seg1addr*} %{segprot*} \ Index: gcc/config/darwin9.h === --- gcc/config/darwin9.h(revision 174947) +++ gcc/config/darwin9.h(working copy) @@ -35,6 +35,9 @@ along with GCC; see the file COPYING3. If not see /* Tell collect2 to run dsymutil for us as necessary. */ #define COLLECT_RUN_DSYMUTIL 1 +#undef PIE_SPEC +#define PIE_SPEC "%{fpie|pie|fPIE:-pie}" + #undef ASM_OUTPUT_ALIGNED_COMMON #define ASM_OUTPUT_ALIGNED_COMMON(FILE, NAME, SIZE, ALIGN)\ do {\
[Bug middle-end/49373] [4.7 Regression] Many testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49373 --- Comment #5 from H.J. Lu 2011-06-11 17:51:29 UTC --- Revision 174957 still gave: FAIL: gcc.c-torture/execute/builtins/strlen-3.c execution, -O2 -flto FAIL: gcc.c-torture/execute/builtins/strlen-3.c execution, -O2 -flto -flto-partition=none FAIL: gcc.dg/guality/vla-1.c -O2 -flto -flto-partition=none line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -O2 -flto line 17 sizeof (a) == 6 FAIL: g++.dg/torture/pr43879-1_1.C -O1 execution test FAIL: g++.dg/torture/pr43879-1_1.C -O2 execution test FAIL: g++.dg/torture/pr43879-1_1.C -O3 -fomit-frame-pointer execution test FAIL: g++.dg/torture/pr43879-1_1.C -O3 -g execution test FAIL: g++.dg/torture/pr43879-1_1.C -Os execution test
[Bug middle-end/49373] [4.7 Regression] Many testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49373 --- Comment #6 from Jan Hubicka 2011-06-11 17:51:52 UTC --- The first problem should be solved by: * lto-streamer-out.c (produce_symtab): Stream out the newly represented aliases. The builtins failure is probably yet another manifestation of the fact that we don't stream builtin decls correctly. I will check... Honza
[Bug middle-end/49373] [4.7 Regression] Many testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49373 Laurent GUERBY changed: What|Removed |Added CC||laurent at guerby dot net --- Comment #7 from Laurent GUERBY 2011-06-11 18:10:47 UTC --- (In reply to comment #3) > The patch is expected to cause g++.dg/torture/pr43879-1_1.C. > > I do not get the other LTO failures. Perhaps it depends whether or not one use > linker plugin. The final testing was done on gccfarm machines, so w/o plugin. > What kind of error do you get there? > > I will look into those tomorrow. > Honza Hi Honza, What cfarm machine did you use for testing? gcc20 has binutils 2.20.1 whereas gcc16 has 2.18.1. Thanks! Laurent
[Bug tree-optimization/49343] [4.7 regression] ICE on field with variable offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49343 --- Comment #4 from Martin Jambor 2011-06-11 18:27:49 UTC --- Created attachment 24492 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24492 Proposed fix This is a proposed (fully tested) fix. How do you want me to add a testcase? Should I just add the test-case attached to this bug to gcc/testsuite/gnat.dg?
[Bug target/49094] ARM aligned(1) attribute is sometimes dropped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49094 --- Comment #3 from Martin Jambor 2011-06-11 19:12:16 UTC --- Just for the record, I am aware of this bug, I have managed to reproduce it on the sparc64 in the compile farm and have had a look at it a few times already (albeit so far only briefly). A few mechanisms within SRA come into play as we generate the integer load statement which is wrong: pkt_dst$s_addr_8 = MEM[(struct ip *)ip_3 + 7B].s_addr; I will continue to try to figure out what to do about this but it is not very straightforward.
[Bug c/49376] New: ICE when compiling linux kernel on mipsel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49376 Summary: ICE when compiling linux kernel on mipsel Product: gcc Version: 4.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: aurel...@aurel32.net Host: mipsel-unknown-linux-gnu Target: mipsel-unknown-linux-gnu Build: mipsel-unknown-linux-gnu Created attachment 24493 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24493 Testcase to reproduce the issue Compiling the linux kernel on mipsel with GCC 4.4 ends in an internal compiler error. I have reduced the testcase, so it can be reproduced with the attached testcase and the following options: $ gcc-4.4 -Os -mno-branch-likely -c testcase.i testcase.i: In function 'lpfc_sli4_cq_event_release_all': testcase.i:102: warning: passing argument 3 of 'dev_printk' makes pointer from integer without a cast testcase.i:16: note: expected 'const char *' but argument is of type 'uint32_t' testcase.i:113: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate.
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 --- Comment #8 from Jack Howarth 2011-06-11 19:56:41 UTC --- (In reply to comment #7) This patch bootstraps fine on x86_64-apple-darwin11 and passes -pie as expected... [MacPro:~] howarth% gcc-fsf-4.7 -fpie -v himenoBMTxpa.c ... /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.7.0 -pie -weak_reference_mismatches non-weak -o a.out -lcrt1.10.5.o -L/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.0.0/4.7.0 -L/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.0.0/4.7.0/../../.. /var/folders/1l/n78sywl52lz6kkys6nv7mnphgp/T//ccwqghgh.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 --- Comment #9 from Iain Sandoe 2011-06-11 20:08:35 UTC --- (In reply to comment #8) > (In reply to comment #7) > This patch bootstraps fine on x86_64-apple-darwin11 and passes -pie as > expected... > > > [MacPro:~] howarth% gcc-fsf-4.7 -fpie -v himenoBMTxpa.c > ... > > /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.7.0 -pie > -weak_reference_mismatches non-weak -o a.out -lcrt1.10.5.o > -L/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.0.0/4.7.0 > -L/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.0.0/4.7.0/../../.. > /var/folders/1l/n78sywl52lz6kkys6nv7mnphgp/T//ccwqghgh.o > -no_compact_unwind > -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v it is, however, wrong for darwin8 - there's a typo: +#define PIE_SPEC "{-fpie|pie|fPIE:}" ---^ (should not have a '-'). thus: +#define PIE_SPEC "{fpie|pie|fPIE:}"
[Bug fortran/49324] Deep copy missing for array constructors of DT w/ allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324 --- Comment #8 from Tobias Burnus 2011-06-11 22:08:49 UTC --- Author: burnus Date: Sat Jun 11 22:08:46 2011 New Revision: 174959 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174959 Log: 2011-06-12 Tobias Burnus PR fortran/49324 * trans-expr.c (gfc_trans_assignment_1): Tell gfc_trans_scalar_assign to also deep-copy RHS nonvariables with allocatable components. * trans-array.c (gfc_conv_expr_descriptor): Ditto. 2011-06-12 Tobias Burnus PR fortran/49324 * gfortran.dg/alloc_comp_assign_11.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug target/49094] ARM aligned(1) attribute is sometimes dropped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49094 --- Comment #4 from Martin Jambor 2011-06-11 23:08:59 UTC --- Created attachment 24494 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24494 Fix - a first draft OK, a fix is probably going to look very much like this, at least roughly. Perhaps it would be better to employ this new disqualification of SRA candidates only if the target is strict aligned.
[Bug c++/49377] New: Template specialization attributes cause type mismatches when used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49377 Summary: Template specialization attributes cause type mismatches when used Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmor...@nvidia.com This is similar to PR 45642, but is not fixed by the patch for that bug. I originally ran into this with 4.6.0, but I also see the behavior with a freshly-updated and built svn gcc (revision 174959). The reduced testcase is pretty simple: ---8<--- template class v; template class v { v() { }; } __attribute__((__may_alias__)); typedef v float2; class a { void f(float2 &point); float2 d; }; void a::f(float2 &point) { } ---8<--- No special compile options, the implementation of a::f isn't matched up with the member: $ g++ -c test.cpp test.cpp:14:6: error: prototype for ‘void a::f(float2&)’ does not match any in class ‘a’ test.cpp:10:10: error: candidate is: void a::f(float2&) $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/xbobx/src/gcc/install-174959/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/home/xbobx/src/gcc/install-174959/ --enable-languages=c,c++ --disable-multilib Thread model: posix gcc version 4.7.0 20110611 (experimental) (GCC) If I remove the attribute on the template specialization _or_ the float2 data field 'd', the test compiles fine. The bug also occurs if "float2" is used in other ways between the declaration of class a and the a::f definition (such as in another class).
[Bug c++/49378] New: [4.7 Regression] C++ is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49378 Summary: [4.7 Regression] C++ is broken Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Fedora 15/x86-64, revision 174953 failed most of C++ testcase for 32bit: http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg01336.html (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /export/home/hjl/tmp/bad Program received signal SIGSEGV, Segmentation fault. 0x0018d7b8 in (anonymous namespace)::future_error_category::~future_error_category (this=0x18d7a0, __in_chrg=) at /export/gnu/import/git/gcc/libstdc++-v3/src/future.cc:29 29 struct future_error_category : public std::error_category (gdb) bt #0 0x0018d7b8 in (anonymous namespace)::future_error_category::~future_error_category (this=0x18d7a0, __in_chrg=) at /export/gnu/import/git/gcc/libstdc++-v3/src/future.cc:29 #1 0x00295ec7 in __cxa_finalize () from /lib/libc.so.6 #2 0x001767c4 in __do_global_dtors_aux () from /tmp/libstdc++.so.6 #3 0x001ea860 in _fini () from /tmp/libstdc++.so.6 #4 0x0011f2fd in _dl_fini () from /lib/ld-linux.so.2 #5 0x00295b31 in __run_exit_handlers () from /lib/libc.so.6 #6 0x00295bbd in exit () from /lib/libc.so.6 #7 0x0027d41b in __libc_start_main () from /lib/libc.so.6 #8 0x08048ce1 in _start () (gdb) disass Dump of assembler code for function (anonymous namespace)::future_error_category::~future_error_category(): 0x0018d7a0 <+0>:push %ebx 0x0018d7a1 <+1>:call 0x176847 <__i686.get_pc_thunk.bx> 0x0018d7a6 <+6>:add$0x8784e,%ebx 0x0018d7ac <+12>:sub$0x18,%esp 0x0018d7af <+15>:mov%eax,(%esp) 0x0018d7b2 <+18>:lea-0x2bcc(%ebx),%edx => 0x0018d7b8 <+24>:mov%edx,(%eax) 0x0018d7ba <+26>:call 0x173b4c <_ZNSt14error_categoryD2Ev@plt> 0x0018d7bf <+31>:add$0x18,%esp 0x0018d7c2 <+34>:pop%ebx 0x0018d7c3 <+35>:ret End of assembler dump. (gdb) EAX is never initialized.
[Bug c++/49378] [4.7 Regression] C++ is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49378 H.J. Lu changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from H.J. Lu 2011-06-12 01:15:03 UTC --- Revision 174951 is OK. Revision 174952: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00441.html is the cause.
[Bug middle-end/49378] [4.7 Regression] C++ is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49378 H.J. Lu changed: What|Removed |Added Component|c++ |middle-end Target Milestone|--- |4.7.0
[Bug c/49379] New: warning from Mac OS X linker alignment lost for -ftree-vectorize optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49379 Summary: warning from Mac OS X linker alignment lost for -ftree-vectorize optimization Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ne...@intrepid.com While running some tests on Mac OS X 10.6.7 I ran into the following warning from the linker: ld: warning: alignment lost in merging tentative definition _u_th_arr Test links without the warning if -fno-tree-vectorize option is provided when compiling the source. I didn't have a chance to verify that executable is correct as my test is hanging - there might be multiple reasons for it. Linker is: @(#)PROGRAM:ld PROJECT:ld64-123.2 llvm version 2.9svn, from Apple Clang 2.0 (build 139) I am attaching a small test program that I checked out against the snapshot of the compiler 4.7.0 20110604. Here is the output of the compile/link process: + snapshot/gcc/xgcc -B../bld/packed-opt/gcc/ -v Reading specs from ../bld/packed-opt/gcc/specs COLLECT_GCC=snapshot/gcc/xgcc COLLECT_LTO_WRAPPER=../bld/packed-opt/gcc/lto-wrapper Target: x86_64-apple-darwin10.7.4 Configured with: ../../src/gcc-4.7-20110604/configure --disable-bootstrap Thread model: posix gcc version 4.7.0 20110604 (experimental) (GCC) + snapshot/gcc/xgcc -B../bld/packed-opt/gcc/ -I. -O3 -c a.c + snapshot/gcc/xgcc -B../bld/packed-opt/gcc/ -I. -O3 -c b.c + snapshot/gcc/xgcc -B../bld/packed-opt/gcc/ -o a -O3 a.o b.o ld: warning: alignment lost in merging tentative definition _u_th_arr + snapshot/gcc/xgcc -B../bld/packed-opt/gcc/ -I. -O3 -fno-tree-vectorize -c a.c + snapshot/gcc/xgcc -B../bld/packed-opt/gcc/ -I. -O3 -fno-tree-vectorize -c b.c + snapshot/gcc/xgcc -B../bld/packed-opt/gcc/ -o a -O3 a.o b.o
[Bug c/49379] warning from Mac OS X linker alignment lost for -ftree-vectorize optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49379 --- Comment #1 from Nenad Vukicevic 2011-06-12 02:26:32 UTC --- Created attachment 24495 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24495 Sample code for MAc OS X linker warning