[Bug tree-optimization/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55619 --- Comment #2 from Andrew Pinski 2012-12-08 08:05:54 UTC --- I think it would be better to rewrite this using intrinsics than depending on the register allocator. You have 3 register inputs, 4 register outputs and 5 memory inputs. I also don't think you have the input/outputs correct either. %2 you only read and never write to so why have it as +? \
[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55619 Markus Trippelsdorf changed: What|Removed |Added CC||glisse at gcc dot gnu.org Component|tree-optimization |c++ --- Comment #3 from Markus Trippelsdorf 2012-12-08 08:19:09 UTC --- Andrew, you may be right, but I didn't wrote this code; I'm just reporting the issue... Anyway this started with revision193938: 31631c5351145bb3a9a1152b2e10ad52c6b42a65 is the first bad commit commit 31631c5351145bb3a9a1152b2e10ad52c6b42a65 Author: glisse Date: Thu Nov 29 15:40:16 2012 + 2012-11-29 Marc Glisse PR c++/53094 gcc/ * fold-const.c (fold): Replace a CONSTRUCTOR with a VECTOR_CST. gcc/cp/ * cvt.c (ocp_convert): Call convert_to_vector. gcc/testsuite/ * g++.dg/ext/vector20.C: New testcase. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@193938 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55619 --- Comment #4 from Andrew Pinski 2012-12-08 08:29:53 UTC --- I think it is obvious what is happening. The c++ front-end is propagating the const vector. Does a const int cause a similar issue if so the inline-asm is buggy i think.
[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55619
--- Comment #5 from Marc Glisse 2012-12-08 08:49:35
UTC ---
Indeed I got it down to this code, which fails just the same with an int
instead of a vector. I didn't know it was forbidden to pass constants with the
"m" constraint, I thought gcc would manage that somehow. What is the
appropriate x86 constraint for a vector constant? "C" doesn't seem to work.
typedef unsigned __attribute__((vector_size(16))) uvec32;
static const uvec32 C = { 0x92d9e201, 0, 0, 0 };
//static const unsigned C = 0x92d9e201;
void f() {
asm volatile ( "" : : "m"(C));
}
[Bug other/54814] [4.8 Regression] ICE: unable to find a register to spill in class 'R0_REG'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54814 --- Comment #7 from Georg-Johann Lay 2012-12-08 10:28:07 UTC --- Many thanks for your help! Mike Stein stopped posting test results quite some time ago. Dunno why, he does not respond to email. avr.h defines R0_REG as register class with 1 fixed register, r0. This regclass is subset of NO_LD_REGS and GENERAL_REGS, which is odd. R0_REG does not make much sense to me, thus remove it from NO_LD_REGS and GENERAL_REGS or delete that regclass and constraint "t" completely. I'll try next week and report back.
[Bug c++/35688] template visibility not overridden by template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688 André Wöbbeking changed: What|Removed |Added CC||Woebbeking at web dot de --- Comment #13 from André Wöbbeking 2012-12-08 12:09:37 UTC --- HI, I've the following problem with this: 3rd party libs don't "export" their templates, e. g. Boost doesn't export shared_ptr. So if I use a shared_ptr as template parameter the template itself isn't exported. I don't understand why fully declared templates like Boost's shared_ptr have a visibility at all. I know that C++11's shared_ptr is exported but that doesn't help me now. Do I've to change my code or is this a regression or is it Boost's fault? Cheers, André
[Bug rtl-optimization/55158] [4.8 Regression] segfault in schedule_region at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158 --- Comment #23 from Steven Bosscher 2012-12-08 12:12:59 UTC --- Author: steven Date: Sat Dec 8 12:12:50 2012 New Revision: 194322 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194322 Log: PR rtl-optimization/55158 * sched-rgn.c (bb_state_array, bb_state): Add some explaining comment, and initialize to NULL explicitly. (realloc_bb_state_array): New function. (free_bb_state_array): New function. (schedule_region): Call realloc_bb_state_array after schedule_block. (sched_rgn_init): Use realloc_bb_state_array to initialize bb_state. (sched_rgn_finish): Use free_bb_state_array to free it. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-rgn.c
[Bug other/54814] [4.8 Regression] ICE: unable to find a register to spill in class 'R0_REG'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54814 Steven Bosscher changed: What|Removed |Added CC|steven at gcc dot gnu.org |bernds at gcc dot gnu.org --- Comment #8 from Steven Bosscher 2012-12-08 13:16:23 UTC --- Trying to bisect down to the revision where this problem appeared: Fail: 193053 (1 Nov 2012) Fail: 191882 (1 Oct 2012) Pass: 188094 (1 Jun 2012) Pass: 190028 (1 Aug 2012) Fail: 190845 (1 Sep 2012) Fail: 190426 (16 Aug 2012) -- does not build, double_int issues Fail: 190521 (20 Aug 2012) Pass: 190219 (8 Aug 2012) Fail: 190324 (12 Aug 2012) Fail: 190277 (10 Aug 2012) Pass: 190246 (9 Aug 2012) Fail: 190257 (9 Aug 2012) Fail: 190252 (9 Aug 2012) Pass: 190251 (9 Aug 2012) Thus, caused by: http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00229.html
[Bug other/54814] [4.8 Regression] ICE: unable to find a register to spill in class 'R0_REG'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54814 --- Comment #9 from Bernd Schmidt 2012-12-08 14:08:52 UTC --- Created attachment 28900 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28900 Candidate patch Try this.
[Bug sanitizer/55374] [asan] Wrong linking order of libasan and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374
--- Comment #3 from H.J. Lu 2012-12-08 17:05:51
UTC ---
[hjl@gnu-6 gcc]$ cat /tmp/bad.cc
#include
int
main ()
{
int *buf = new int(30);
buf[30]=1;
return 0;
}
[hjl@gnu-6 gcc]$ ./release/usr/gcc-4.8.0/bin/g++ -fsanitize=address /tmp/bad.cc
-static-libasan -static-libstdc++
/export/build/gnu/gcc/release/usr/gcc-4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libasan.a(asan_new_delete.o):
In function `operator new(unsigned long)':
/export/gnu/import/git/gcc/libsanitizer/asan/asan_new_delete.cc:41: multiple
definition of `operator new(unsigned long)'
/export/build/gnu/gcc/release/usr/gcc-4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libstdc++.a(new_op.o):/export/gnu/import/git/gcc/libstdc++-v3/libsupc++/new_op.cc:45:
first defined here
/export/build/gnu/gcc/release/usr/gcc-4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libasan.a(asan_new_delete.o):
In function `operator delete(void*)':
/export/gnu/import/git/gcc/libsanitizer/asan/asan_new_delete.cc:54: multiple
definition of `operator delete(void*)'
/export/build/gnu/gcc/release/usr/gcc-4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libstdc++.a(del_op.o):/export/gnu/import/git/gcc/libstdc++-v3/libsupc++/del_op.cc:46:
first defined here
collect2: error: ld returned 1 exit status
[hjl@gnu-6 gcc]$
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 H.J. Lu changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|[asan] Wrong linking order |[asan] -static-libasan |of libasan and libstdc++|-static-libstdc++ doesn't ||work
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-11/msg01872.htm ||l Last reconfirmed||2012-12-08 Ever Confirmed|0 |1 --- Comment #4 from H.J. Lu 2012-12-08 17:11:16 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01872.html
[Bug other/53313] Add warning levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 --- Comment #5 from Marc Glisse 2012-12-08 17:59:31 UTC --- Created attachment 28901 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28901 -Weverything A very basic implementation of -Weverything (I don't really understand that code, but it compiles and shows many warnings :-)
[Bug rtl-optimization/52573] [4.6/4.7/4.8 regression] regrename creates overlapping register allocations for output operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52573 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #9 from Mikael Pettersson 2012-12-08 19:05:47 UTC --- (In reply to comment #8) > The failure disappeared somewhere between r190830 and r191055. Are you sure about that revision range? I still see the bug with 4.8-20120909, i.e., r191120. The bug appears to be gone on current trunk however; a bisection tells me it disappeared with Richard Sandiford's "Replace mode_for_extraction with new interface" patch in r193605: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00260.html http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00552.html
[Bug sanitizer/55599] switch from mach_override to mac interpose function support in libasan broke -static-libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55599 Jack Howarth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Jack Howarth 2012-12-08 19:06:24 UTC --- "Fixed' with... r194257 | kcc | 2012-12-06 09:49:44 -0500 (Thu, 06 Dec 2012) | 1 line Fix PR55599/sanitizer by disabling static libasan on darwin
[Bug rtl-optimization/52573] [4.6/4.7/4.8 regression] regrename creates overlapping register allocations for output operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52573 --- Comment #10 from Andreas Schwab 2012-12-08 19:31:46 UTC --- http://gcc.gnu.org/ml/gcc-testresults/2012-12/msg00595.html is based on r191055.
[Bug tree-optimization/55104] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:269
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55104 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #6 from Andrew Pinski 2012-12-09 00:21:17 UTC --- Yes this is a dup of bug 55078 after all. *** This bug has been marked as a duplicate of bug 55078 ***
[Bug middle-end/55078] [4.8 Regression] FAIL: g++.dg/torture/pr46154.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55078 Andrew Pinski changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #10 from Andrew Pinski 2012-12-09 00:21:17 UTC --- *** Bug 55104 has been marked as a duplicate of this bug. ***
[Bug lto/55596] [google] r191813 broke bootstrap-lto on google/gcc-4_7 branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55596 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski 2012-12-09 00:25:55 UTC --- This bug system is not for filing bugs against distro (google in this case) support branches. ask them where you should where you should file the bug reports.
[Bug middle-end/55595] [google] r172952 (LIPO) broke profiledbootstrap on google/main, and later in google/gcc-4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55595 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski 2012-12-09 00:26:09 UTC --- This bug system is not for filing bugs against distro (google in this case) support branches. ask them where you should where you should file the bug reports.
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-09 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski 2012-12-09 00:31:40 UTC --- Confirmed. It only happens with the C++ front-end though. The exact same code does not warn with the C front-end. I think this might be the pre-ahead of time tokenizer that happens for the C++ front-end but does not happen for C.
[Bug sanitizer/55480] many test cases fail using -fsanitize=address with internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55480
Jack Howarth changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
--- Comment #7 from Jack Howarth 2012-12-09
00:32:19 UTC ---
Comfirmed with...
make -k check-gfortran RUNTESTFLAGS="--target_board=unix'{-fsanitize=address}'"
that these failures are all eliminated in current gcc trunk.
[Bug c++/55606] sorry, unimplemented: non-trivial designated initializers not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55606 Andrew Pinski changed: What|Removed |Added Keywords||FIXME, rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-09 Ever Confirmed|0 |1 Known to fail||4.2.3, 4.3.4, 4.4.5, 4.8.0 --- Comment #7 from Andrew Pinski 2012-12-09 00:33:13 UTC --- Confirmed.
[Bug c/55613] Add suggestion of adding struct if the name exists in the struct tag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55613 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||diagnostic Last reconfirmed||2012-12-09 Ever Confirmed|0 |1 Summary|Better warning for |Add suggestion of adding |reference to struct type|struct if the name exists ||in the struct tag Severity|normal |enhancement
[Bug libfortran/55601] libgfortran build fails with --disable-libquadmath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55601 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-09 Ever Confirmed|0 |1
[Bug c++/55582] [C++11] Unable to define string user-defined literal without leading underscore.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55582 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-09 Ever Confirmed|0 |1 --- Comment #5 from Andrew Pinski 2012-12-09 00:37:26 UTC --- .
[Bug other/55560] fesetround(FE_DOWNWARD) causes cos() to return values outside the range of -1 to +1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55560 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||MOVED --- Comment #4 from Andrew Pinski 2012-12-09 00:40:04 UTC --- So closing as moved (as in moved to glibc bug).
[Bug libgcc/55589] Failure compiling "generic-morestack-thread.c", without threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55589 --- Comment #3 from Andrew Pinski 2012-12-09 00:48:37 UTC --- Created attachment 28902 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28902 Patch which might work Can you try this patch?
[Bug c/39900] ICE on nested function returning pointer to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39900 Andrew Pinski changed: What|Removed |Added CC||cookevillain at yahoo dot ||com --- Comment #2 from Andrew Pinski 2012-12-09 00:55:19 UTC --- *** Bug 55420 has been marked as a duplicate of this bug. ***
[Bug c/55420] Gcc produces an internal compiler error (nested function with variably modified return)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55420 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Andrew Pinski 2012-12-09 00:55:19 UTC --- Exact dup of bug 39900. *** This bug has been marked as a duplicate of bug 39900 ***
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 --- Comment #1 from Andrew Pinski 2012-12-09 00:59:40 UTC --- There seems like there are two different issues here. The first issue if musl libc not following the same ABI as glibc. The second issues looks like maybe a real one.
[Bug target/55344] Cross compiling for alpha-linux fails because doesn't exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55344 Andrew Pinski changed: What|Removed |Added Keywords||build Target||alpha*-*-linux-gnu --- Comment #1 from Andrew Pinski 2012-12-09 01:08:43 UTC --- Simple wrap the whole file linux-unwind.h with #ifndef inhibit_libc like most other target's linux-unwind.h.
[Bug target/55246] Define a macro for 16*1024*1024 in i386.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55246 Andrew Pinski changed: What|Removed |Added Target||i?86-*-* x86_64-linux-gnu Summary|Define a macro for |Define a macro for |16*1024*1024|16*1024*1024 in i386.c Severity|normal |enhancement --- Comment #2 from Andrew Pinski 2012-12-09 01:10:28 UTC --- I don't understand why you just did not post a patch for this.
[Bug c++/54416] [4.7/4.8 Regression] ICE (segv) in codegen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54416 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|4.7.3 |4.8.0
[Bug middle-end/55279] New pseudo registers aren't supported in CSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55279 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #3 from Andrew Pinski 2012-12-09 01:23:00 UTC --- I think combine was changed for the similar reason to support psedudos but I cannot find the patch right now.
[Bug c++/55254] Warn for implicit conversion from int to char
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55254 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c/55422] gcc does not diagnose change of linkage for a function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55422 --- Comment #5 from Andrew Pinski 2012-12-09 01:29:44 UTC --- The first example is invalid C90 anyways: t4.c:10:3: error: ISO C90 forbids mixed declarations and code [-Wpedantic]
[Bug testsuite/55440] Plugin tests is compiled with wrong CFLAGS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55440 --- Comment #1 from Andrew Pinski 2012-12-09 01:34:15 UTC --- > 1. plugin DSO is dlopened by linker, not GCC. Compiling it with asan may > not work correctly. linker may not find asan DSO at run-time. No this is testing the plugin to GCC and not the linker so you are wrong there. POSTSTAGE1_LDFLAGS should be used also I think or rather if you do a botostrap with a weird option you should be testing an already installed compiler instead.
[Bug c/55457] Having some predefined macros to get more information about gcc vector extensions capabilities would be nice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55457 --- Comment #1 from Andrew Pinski 2012-12-09 01:39:39 UTC --- The whole point of the gcc vector extensions is that you don't need to depend on what the hardware can do under neath as it should produce good code in either case.
[Bug target/55516] strict volatile bitfields are done by what the ARM EABI says
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55516 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Component|regression |target Summary|strict volatile bitfields |strict volatile bitfields |are broken on ARM. |are done by what the ARM ||EABI says --- Comment #1 from Andrew Pinski 2012-12-09 01:43:01 UTC --- I think the ARM EABI is broken anyways. Volatile bitfields in general are broken for more than one reason. I wish people would stop using them.
[Bug other/55530] Visibility warning not always shown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55530 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-09 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski 2012-12-09 01:54:20 UTC --- The warning happens when the struct at definition time rather than at the end of compilation. Maybe we should warn about the case where the forward declaration and definitions are two different visibility.
[Bug middle-end/55266] vector expansion: 24 movs for 4 adds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55266 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-09 Ever Confirmed|0 |1 --- Comment #3 from Andrew Pinski 2012-12-09 02:07:58 UTC --- The other issue is there is no DCE that happens after forwprop4.
[Bug target/54951] Incorrect pointer handling on 32K boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54951 Andrew Pinski changed: What|Removed |Added Severity|critical|normal
[Bug bootstrap/55083] failure while configuring libatomic is not cleaned up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55083 --- Comment #3 from Andrew Pinski 2012-12-09 02:23:48 UTC --- It does not test if the directory exists but rather if the Makefile in the directory exists. test ! -f $(TARGET_SUBDIR)/libatomic/Makefile || exit 0; \ So I think this is invalid.
[Bug tree-optimization/54982] false unitialized warning about store_flag in tree-ssa-loop-im.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54982 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |WAITING Last reconfirmed||2012-12-09 Summary|Uninitialised variable |false unitialized warning |store_flag in |about store_flag in |tree-ssa-loop-im.c |tree-ssa-loop-im.c Ever Confirmed|0 |1 Severity|trivial |normal --- Comment #2 from Andrew Pinski 2012-12-09 02:31:26 UTC --- How did you configure GCC? What version of GCC are you using to start wtih? All sets/uses of store_flag are predicated by multi_threaded_model_p so the warning is false.
[Bug c/55457] Having some predefined macros to get more information about gcc vector extensions capabilities would be nice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55457 --- Comment #2 from Siarhei Siamashka 2012-12-09 02:33:24 UTC --- (In reply to comment #1) > The whole point of the gcc vector extensions is that you don't need to depend > on what the hardware can do under neath as it should produce good code in > either case. I think that you are a bit too idealistic and overlooking some practical implications: 1. GCC just does not generate really good code with vector extensions when there is no real SIMD backend. 2. There may be some high level algorithmic optimizations possible. For example, branches to skip calculations for some special cases. We really want to have these branches in scalar code, while SIMD can sacrifice the branches and gain a lot more performance from parallel processing. So right now GCC is forcing me and the other users to infest the code with ifdefs checking for __x86__, __amd64__, __arm__, __powerpc__, __SSE2__, __ALTIVEC__, __ARM_NEON__, etc. to disable the use of vector extensions when there is actually no real SIMD. It kinda defeats the purpose, because turns out that I need to know about the existence of all the CPU architectures supported by GCC and their SIMD implementations before I can expect that the code will work reasonably fast everywhere. Relying just on GCC vector extensions means non-portable code, which will not work with the other compilers. So in any case, everyone is likely to already have an alternative implementation written in standard C. Having two alternative implementations to select from, we want to be able to make a reasonably good guess about which implementation is going to be preferable for this particular build.
[Bug debug/55059] [4.8 Regression] DWARF missing concrete class definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55059 Andrew Pinski changed: What|Removed |Added Keywords||wrong-debug Version|unknown |4.8.0 See Also||http://sourceware.org/bugzi ||lla/show_bug.cgi?id=14760 Target Milestone|--- |4.8.0 Summary|DWARF missing concrete |[4.8 Regression] DWARF |class definition|missing concrete class ||definition
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 --- Comment #2 from Rich Felker 2012-12-09 02:37:19 UTC --- The ABI issue is a dependency on an undocumented part of glibc's ABI behavior -- I don't see anywhere it's documented that __libc_stack_end points at "argc" (i.e. the original place the stack pointer points to on program entry), just some point past the end of the stack, and thus it's conceivable that even in glibc it could change to point somewhere else. In any case, it's a gratuitous dependency on glibc internals. The logic error issue (assuming the initial environ array is still intact) is of course an outright observable bug even without any incompatible changes at the libc level. Do you have any idea why this code was added to begin with? It seems completely unnecessary.
[Bug target/55089] ICE in varasm.c during bootstrap-lean on x86_64-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55089 Andrew Pinski changed: What|Removed |Added Keywords||build, ice-on-valid-code Component|bootstrap |target Host||x86_64-sun-solaris2.10 Build||x86_64-sun-solaris2.10 Severity|blocker |normal --- Comment #3 from Andrew Pinski 2012-12-09 02:42:36 UTC --- CC=cc -m64 CFLAGS=-m64 + export CC CPPFLAGS= -I/local/gnu/include -I/local/include CFLAGS=-m64 -I/local/gnu/include -I/local/include LDFLAGS= -m64 -L/local/gnu/lib/64 -L/local/lib/64 + export CPPFLAGS CFLAGS LDFLAGS + ../gcc-4.7.2/configure --prefix=/local/gnu --exec-prefix=/local/gnu Your stage1 compiler is producing an internal compiler error. Either the compiler you are starting with is miscompiling the stage1 compiler (most likely because I have seen other people compile on x86_64-pc-solaris2.10) or your stage1 compiler has a bug in it. > I'm using the Oracle Studio 12.3 compiler suite to build the initial xgcc. Have you tried building it with a prebuilt GCC? Maybe even trying to do i386-pc-solaris2.10 compiler to begin with and then doing a x86_64-pc-solaris2.10 compiler with that newly build gcc? I am thinking Oracle's compiler has bugs in it with respect of 64bit mode.
[Bug target/55089] ICE in varasm.c during bootstrap-lean on x86_64-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55089 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-12-09 Ever Confirmed|0 |1
[Bug c++/54883] [4.6/4.7/4.8 Regression] Name mangling of types in an unnamed namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54883
Andrew Pinski changed:
What|Removed |Added
Keywords||ABI
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-12-09
Known to work||4.2.4
Target Milestone|--- |4.6.4
Summary|Name mangling of types in |[4.6/4.7/4.8 Regression]
|an unnamed namespace|Name mangling of types in
||an unnamed namespace
Ever Confirmed|0 |1
--- Comment #3 from Andrew Pinski 2012-12-09
02:50:00 UTC ---
Confirmed.
Simple linktime testcase:
echo "namespace { enum E { E1 }; } void f(E e) { }" | tee a.c b.c > /dev/null
echo "int main(void){}"> c.c
g++ a.c b.c c.c
[Bug tree-optimization/55107] [4.7/4.8 Regression] GCC in an infinite loop in PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55107 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.4.5 Keywords||compile-time-hog Last reconfirmed||2012-12-09 Ever Confirmed|0 |1 Summary|GCC in an infinite loop at |[4.7/4.8 Regression] GCC in |-O2 |an infinite loop in PRE Target Milestone|--- |4.7.3 Known to fail||4.7.0, 4.8.0 --- Comment #1 from Andrew Pinski 2012-12-09 02:55:54 UTC --- #0 0x00bd02db in bmp_iter_set (bi=0x7fffda90, bit_no=0x7fffdab4) at /home/apinski/src/gcc-fsf/local//gcc/gcc/bitmap.h:532 #1 0x00bd305f in bitmap_set_replace_value (set=0x1970858, lookfor=29, expr=0x197d9a8) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-pre.c:862 #2 0x00bd30e6 in bitmap_value_replace_in_set (set=0x1970858, expr=0x197d9a8) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-pre.c:889 #3 0x00bda1dd in insert_aux (block=0x770223a8) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-pre.c:3639 #4 0x00bda294 in insert_aux (block=0x76fe6d00) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-pre.c:3654 #5 0x00bda294 in insert_aux (block=0x76fe6bc8) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-pre.c:3654 #6 0x00bda294 in insert_aux (block=0x76fe6820) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-pre.c:3654 #7 0x00bda294 in insert_aux (block=0x76fe62d8) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-pre.c:3654 #8 0x00bda294 in insert_aux (block=0x76fe6270) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-pre.c:3654 #9 0x00bda294 in insert_aux (block=0x76fe61a0) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-pre.c:3654 #10 0x00bda372 in insert () at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-pre.c:3677 #11 0x00bdd70f in do_pre () at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-pre.c:4729 >Note that the stack trace looks the same as in PR55011. That stack trace is just where xgcc is saying the cc1 was executed from.
[Bug target/55146] jumptables with byte entries produce wrong code with -Os/-O2 for SH-1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55146 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target||sh-elf Severity|critical|normal
[Bug middle-end/55152] MAX_EXPR(a,-a) is really ABS_EXPR(a)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55152 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug fortran/55205] build gcc-4.7.2 failed on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55205 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Andrew Pinski 2012-12-09 03:04:49 UTC --- . *** This bug has been marked as a duplicate of bug 51343 ***
[Bug fortran/51343] compile GCC4.6.2 in apple OS X 10.6.8, error found. and also in 4.6.1 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51343 Andrew Pinski changed: What|Removed |Added CC||shankerwangmiao at 163 dot ||com --- Comment #3 from Andrew Pinski 2012-12-09 03:04:49 UTC --- *** Bug 55205 has been marked as a duplicate of this bug. ***
[Bug bootstrap/55196] GCC 4.8 build error : link error on OS X 10.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55196 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-12-09 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski 2012-12-09 03:07:08 UTC --- >./configure First don't build in the source directory. Second Don't use --prefix=/usr unless you are the distro builder. Third is your gcc and g++ programs two different versions of GCC which are configured differently?
[Bug tree-optimization/55222] [4.8 Regression] weird unstable "array subscript is above array bounds" warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55222 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED Component|c |tree-optimization Resolution||DUPLICATE Summary|weird unstable "array |[4.8 Regression] weird |subscript is above array|unstable "array subscript |bounds" warning |is above array bounds" ||warning --- Comment #1 from Andrew Pinski 2012-12-09 03:14:52 UTC --- It was a bug in 4.8.0 which has since been fixed. *** This bug has been marked as a duplicate of bug 55085 ***
[Bug tree-optimization/55085] [4.8 regression] false positive -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55085 Andrew Pinski changed: What|Removed |Added CC||akim.demaille at gmail dot ||com --- Comment #5 from Andrew Pinski 2012-12-09 03:14:52 UTC --- *** Bug 55222 has been marked as a duplicate of this bug. ***
[Bug bootstrap/55083] failure while configuring libatomic is not cleaned up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55083 --- Comment #4 from Perry Smith 2012-12-09 04:45:47 UTC --- I can't remember much about this. Things may have changed since I reported it. Is the Makefile created as the last step? If not, then if something fails after the Makefile is created, then the next build will assume everything in that section completed successfully (which will be incorrect).
[Bug bootstrap/55083] failure while configuring libatomic is not cleaned up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55083 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Andrew Pinski 2012-12-09 05:06:54 UTC --- (In reply to comment #4) > I can't remember much about this. Things may have changed since I reported > it. Not in the toplevel Makefile or libatomic's configure. > > Is the Makefile created as the last step? yes it is created after all of configure has finished. > If not, then if something fails after the Makefile is created, then the next > build will assume everything in that section completed successfully (which > will > be incorrect).
[Bug bootstrap/55083] failure while configuring libatomic is not cleaned up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55083 --- Comment #6 from Perry Smith 2012-12-09 05:40:28 UTC --- If it helps, here are the last messages from the make log: checking for powerpc-ibm-aix6.1.0.0-gcc... /usr/work/build/gcc.git/./gcc/xgcc -B/usr/work/build/gcc.git/./gcc/ -B /gsa/ausgsa/projects/r/ruby/powerpc-ibm-aix6.1.0.0/bin/ -B/gsa/ausgsa/projects/r/ruby/powerpc-ibm-aix6.1.0.0/lib/ -isystem /gsa/ausgsa/projects/r/ruby/powerpc-ibm-aix6.1.0.0/include -isystem /gsa/ausgsa/projects/r/ruby/powerpc -ibm-aix6.1.0.0/sys-include -maix64 checking for C compiler default output file name... configure: error: in `/usr/work/build/gcc.git/powerpc-ibm-aix6.1.0.0/ppc64/libatomic': configure: error: C compiler cannot create executables See `config.log' for more details. make[1]: *** [configure-target-libatomic] Error 1 make[1]: Leaving directory `/usr/work/build/gcc.git' make: *** [all] Error 2 All's I know is after the error, a "make" would not finish the config processing and go down a different path.
[Bug testsuite/55621] New: no gcc or g++ tests run for solaris2.11 target : missing $OBJDIR/gcc/testsuite/config/unix_{gcc,g++}.exp files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55621
Bug #: 55621
Summary: no gcc or g++ tests run for solaris2.11 target :
missing
$OBJDIR/gcc/testsuite/config/unix_{gcc,g++}.exp files
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jason.vas.d...@gmail.com
