[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 --- Comment #4 from Gaetano Mendola --- At this point I'm very puzzled. The fact I have to use memcpy instead of an assignment for sake of portability is plain wrong. Consider that only looking at: struct in_addr myInAddr; myInAddr.s_addr = theIpHeader->daddr; I have no idea if the theIpHeader pointer was the result of a malloc or the result of an assignment with a not aligned offset. Unless of course I inspect the pointer value. The entire application (my application) suppose, as I think it should, that an assignment of a value retrieved from a structure member is correctly done, note that I'm not relying if this is done with 1 bus access, 2 or whatever. I'm going to put 2 in /proc/cpu/alignment and considering it as a kernel configuration problem. btw clang behaves correctly even with a "kernel not well configured".
[Bug target/57841] Assembler error on gcc for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57841 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Earnshaw --- Your version of GAS/binutils is too old. It had a bug in the handling of alignment specifiers. This is not a GCC bug anyway.
[Bug target/57865] Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 Sebastian Huber changed: What|Removed |Added CC||amodra at gmail dot com Known to work||4.8.0 --- Comment #1 from Sebastian Huber --- I performed a git bisect. This problem was introduced with this commit: cef20746448f8897180eed3a49a3f8c68b0147f2 is the first bad commit commit cef20746448f8897180eed3a49a3f8c68b0147f2 Author: amodra Date: Wed Apr 25 02:32:56 2012 + gcc/ * config/rs6000/rs6000 (SAVE_INLINE_VRS, REST_INLINE_VRS, V_SAVE_INLINE, SAVRES_LR, SAVRES_SAVE, SAVRES_REG, SAVRES_GPR, SAVRES_FPR, SAVRES_VR): Define. (no_global_regs_above): Delete. (no_global_regs): New function. (rs6000_savres_strategy): Handle vector regs. Use proper lr_save_p value for load multiple test. (savres_routine_syms): Increase size. (rs6000_savres_routine_name, rs6000_savres_routine_sym, ptr_regno_for_savres, rs6000_emit_savres_rtx): Pass in int selector rather than a number of boolean flags. Update all callers. (rs6000_savres_routine_name): Generate vector save/restore names. (rs6000_savres_routine_sym): Handle vector regs. Delete forward decl. (ptr_regno_for_savres, rs6000_emit_savres_rtx): Likewise. (rs6000_emit_prologue): Delete saving_FPRs_inline, saving_GPRs_inline and using_store_multiple. Expand uses. Don't always use r11 as frame reg when needed for out-of-line saves. Set up initial offset for out-of-line vector saves when buying stack frame. Handle pointer reg setup for out-of-line fp save. Emit call to out-of-line vector save function. Choose r11 or r12 for vrsave reg when available for better scheduling. (rs6000_output_function_prologue): Don't emit .extern for ELF. (rs6000_emit_epilogue): Choose a better frame reg when restoring from back-chain to suit out-of-line vector restore functions. Emit call to out-of-line vector restore function. Adjust register used for cr restore. Tweak pointer register setup for gpr restore. * config/rs6000/rs6000.h (FIRST_SAVED_GP_REGNO): Take into account FIXED_R13. * config/rs6000/sysv4.h (FP_SAVE_INLINE, GP_SAVE_INLINE): Simplify. (V_SAVE_INLINE): Define. * config/rs6000/altivec.md (save_vregs_*, restore_vregs_*): New insns. libgcc/ * config/rs6000/crtsavevr.S: New file. * config/rs6000/crtrestvr.S: New file. * config/rs6000/t-savresfgpr: Build the above. * config/rs6000/t-netbsd: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186800 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 f8dd5a05848aed385c5d1a8ec6d6a6979ea3777c c644e474189368b21c2c950e54c75ad2cada389c M gcc :04 04 4b65af83bd972aa70908f8d3f5efad7b22ac2ce2 51b8b2f6236f0261d920ff6b5823cfdb17d8871e M libgcc
[Bug tree-optimization/57858] AVX2: ymm used for div, not for sqrt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57858 --- Comment #5 from vincenzo Innocente --- I remember something similar in the past --param max-completely-peel-times=1 sort of fix it… (why pre does not recognize that 1/(1+0) == 1 btw?? of course it is just a benchmark (and I can modify it to avoid the loop peeling), still
[Bug target/45208] powerpc-gcc -msdata breakdown on incomplete initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45208 Sebastian Huber changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #1 from Sebastian Huber --- I can no longer reproduce this problem with GCC 4.7 and 4.8.
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862
--- Comment #5 from Mikael Pettersson ---
Your test case contains this:
===snip===
struct iphdr
{
...
};
...
int main()
{
char thePacket[1518];
memset(thePacket, 0, 1518);
thePacket[30] = 1;
thePacket[31] = 2;
thePacket[32] = 3;
thePacket[33] = 4;
struct ether_header* theEthHeader = (struct ether_header*)(thePacket);
struct iphdr* theIpHeader = (struct iphdr*)((const unsigned
char*)(theEthHeader) + 14);
struct in_addr myInAddr;
myInAddr.s_addr = theIpHeader->daddr;
===snip===
The alignment of thePacket is arbitrary, so the alignment of theIpHeader is
unknown, and struct iphdr is not declared with attribute packed. The final
load may therefore be misaligned.
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 --- Comment #6 from Gaetano Mendola --- That's clear to me. I'm writing in C not in assembler, what I'm trying to understand is if I have to threat the following code: struct in_addr myInAddr; myInAddr.s_addr = theIpHeader->daddr; as not portable, where myInAddr.s_addr and theIpHeader->daddr are of the same type. I'm not a c-standard lawyer but I'm hard believing that in the standard that assignment is marked as: "undefined behaviour" unless you use memcpy. And again printf-ing the two values, both are reported on screen as the same number but the bytes behind that area of memory do not contain the same values.
[Bug target/47540] ARM THUMB crash with complex numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540 Sebastian Huber changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #9 from Sebastian Huber --- I cannot reproduce this problem with GCC 4.6.4 and 4.8.1.
[Bug target/57865] Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-07-10 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1 --- Comment #2 from Alan Modra --- My guess is that it's this change -#define FIRST_SAVED_GP_REGNO 13 +#define FIRST_SAVED_GP_REGNO (FIXED_R13 ? 14 : 13) messing with ool_adjust.
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 --- Comment #7 from Mikael Pettersson --- (In reply to Gaetano Mendola from comment #6) > struct in_addr myInAddr; > myInAddr.s_addr = theIpHeader->daddr; > > as not portable, where myInAddr.s_addr and theIpHeader->daddr are of the > same type. I'm not a c-standard lawyer but I'm hard believing that in the > standard > that assignment is marked as: "undefined behaviour" unless you use memcpy. The assignment is immaterial, it's the load (theIpHeader->daddr) that's problematic because the base pointer (theIpHeader) is not correctly aligned for its declared type (struct iphdr).
[Bug driver/42485] [4.4/4.5/4.6 Regression] -V switch broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org Known to fail|| --- Comment #9 from Michael Matz --- Heh. I just had an actual user who wanted to make use of -V; because in the build system he was working in, the compiler name 'gcc' was hardcoded everywhere, but he could add options via environment variables, so 'gcc-VERSION' was no option, but '-V VERSION' would have been possible, except of course, that it isn't anymore ;-) Well, too bad, I guess.
[Bug target/57865] Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 --- Comment #3 from Sebastian Huber --- (In reply to Alan Modra from comment #2) > My guess is that it's this change > > -#define FIRST_SAVED_GP_REGNO 13 > +#define FIRST_SAVED_GP_REGNO (FIXED_R13 ? 14 : 13) > > messing with ool_adjust. I used this on the current 4.8 head: diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h index 8a36084..d075915 100644 --- a/gcc/config/rs6000/rs6000.h +++ b/gcc/config/rs6000/rs6000.h @@ -952,7 +952,7 @@ extern unsigned rs6000_pointer_size; #define FIRST_SAVED_ALTIVEC_REGNO (FIRST_ALTIVEC_REGNO+20) #define FIRST_SAVED_FP_REGNO (14+32) -#define FIRST_SAVED_GP_REGNO (FIXED_R13 ? 14 : 13) +#define FIRST_SAVED_GP_REGNO 13 /* List the order in which to allocate registers. Each register must be listed once, even those in FIXED_REGISTERS. This solves the problem above. I don't know the other impact of the change.
[Bug target/57865] Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 --- Comment #4 from Alan Modra --- Created attachment 30489 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30489&action=edit Fix ool_adjust Please verify that this fixes the problem
[Bug target/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 --- Comment #19 from Charles L. Wilcox --- (In reply to Uroš Bizjak from comment #11) > On an x86 target using the legacy x87 instructions and the 80-bit registers, > a load of a 64-bit or 32-bit value in memory into the 80-bit registers > counts as a format conversion and an signaling NaN input will turn into a > quiet NaN in the register format. Does this mean if a 80-bit sNaN was generated and loaded into a register it was still have the signaling bit set correctly? And if so, could this value then be down-converted to a 32 or 64-bit float? In C++: float float32_snan const = static_cast< float >( std::numeric_limits< long double >::signaling_NaN() ); double float64_snan const = static_cast< double >( std::numeric_limits< long double >::signaling_NaN() ); Or, is the "cast" here a format conversion, causing the signaling NaN to convert to a quiet NAN?
[Bug target/57865] Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 --- Comment #5 from Sebastian Huber --- (In reply to Alan Modra from comment #4) > Created attachment 30489 [details] > Fix ool_adjust > > Please verify that this fixes the problem Yes, your patch fixes also the problem if applied to the 4.8 head. Thanks a lot for the quick response.
[Bug target/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 --- Comment #20 from Uroš Bizjak --- (In reply to Charles L. Wilcox from comment #19) > (In reply to Uroš Bizjak from comment #11) > > On an x86 target using the legacy x87 instructions and the 80-bit registers, > > a load of a 64-bit or 32-bit value in memory into the 80-bit registers > > counts as a format conversion and an signaling NaN input will turn into a > > quiet NaN in the register format. > > Does this mean if a 80-bit sNaN was generated and loaded into a register it > was still have the signaling bit set correctly? And if so, could this value 80-bit load is not considered as a format conversion, so signalling bit will be set correctly. > then be down-converted to a 32 or 64-bit float? In C++: > float float32_snan const > = static_cast< float >( std::numeric_limits< long double > >::signaling_NaN() ); > double float64_snan const > = static_cast< double >( std::numeric_limits< long double > >::signaling_NaN() ); > Or, is the "cast" here a format conversion, causing the signaling NaN to > convert to a quiet NAN? I don't know the c++ details, but compiler can spill the value out from the register stack using 32- or 64-bit float moves. In any case, signalling bit in x87 is unreliable and should not be used.
[Bug driver/42485] [4.4/4.5/4.6 Regression] -V switch broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485 --- Comment #10 from Manuel López-Ibáñez --- (In reply to Michael Matz from comment #9)that it isn't anymore ;-) > > Well, too bad, I guess. I am not sure of the exact details but unless the path itself is hard-coded, you could always put a fake gcc, to be found in the path before the real gcc, that parses -V VERSION and calls the correct gcc. It should be a few lines of shell (or another scripting language). Another alternative is to make gcc a symlink to the actual gcc-VERSION. Yet another may be shell aliases, but I am not sure if that works for Makefiles. The -V switch was not working so it wouldn't have helped your user anyway.
[Bug tree-optimization/57861] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57861 Mikael Pettersson changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #1 from Mikael Pettersson --- It's a recent regression, caused by the LRA change in r200723. Author CCd.
[Bug libitm/56801] Internal Compiler Error when compiling relaxed transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56801 --- Comment #4 from Patrick Marlier --- Created attachment 30490 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30490&action=edit reduced testcase. I am now able to reproduce the ICE even with FSF 4.7.3 (it was due to different included headers). Attached the preprocessed testcase. $ gcc-4.7 -O1 -fgnu-tm -pthread -S -Wall -Wfatal-errors testcase2.i testcase2.i: In function ‘foo’: testcase2.i:5:6: internal compiler error: in expand_call_tm, at trans-mem.c:2280
[Bug tree-optimization/57861] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57861 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-10 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- This revision also causes FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -Og -g FAIL: gfortran.dg/pointer_remapping_5.f08 -Os execution test FAIL: libgomp.fortran/vla3.f90 -Os execution test on x86_64-apple-darwin10 with -m32 and FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -O2 FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -O3 -g FAIL: gfortran.fortran-torture/execute/where_7.f90 execution, -Os FAIL: libgomp.fortran/vla3.f90 -Os execution test on x86_64-unknown-linux-gnu with -m32.
[Bug tree-optimization/57860] wrong code for bitwise ops with long long literal on x86_64-linux (32-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57860 Mikael Pettersson changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #1 from Mikael Pettersson --- Caused by the LRA changes in r200723. Author CCd.
[Bug fortran/57871] gfortran -freal-4-real-16 gives wrong result for selected_real_kind(1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Dominique d'Humieres --- > gfortran 4.8.1 -freal-4-real-16 gives real(16) kind with > selected_real_kind(1) but it ought to give real(8) because that is > the smallest decimal precision available with that compiler option. > Same problem with -freal-4-real-10 giving real(10) instead of real(8). ... Why are you expecting that? The manual says: -freal-4-real-8 -freal-4-real-10 -freal-8-real-4 -freal-8-real-10 -freal-8-real-16 Promote all REAL(KIND=M) entities to REAL(KIND=N) entities. If REAL(KIND=N) is unavailable, then an error will be issued. All other real kind types are unaffected by this option. These options should be used with care and may not be suitable for your codes. Areas of possible concern include calls to external procedures, alignment in EQUIVALENCE and/or COMMON, generic interfaces, BOZ literal constant conversion, and I/O. Inspection of the intermediate representation of the translated Fortran code, produced by -fdump-tree-original, is suggested. and your example does exactly that: Closing as INVALID.
[Bug target/56771] Integer Overflow? Building arm-rtems libgcc2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56771 Joel Sherrill changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Joel Sherrill --- Fixed per email from Sebastian Huber. Closing.
[Bug middle-end/57859] -ftrapv does not trap on signed overflows for struct fields (32-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57859 --- Comment #1 from Mikael Pettersson --- With -m64: both test cases work with gcc-3.2.3, and fail with every release from 3.3.6 up to current trunk. With -m32: the first test case doesn't trap with any release since 3.2.3, the second test case traps with current trunk and 4.8, but not with any release from 3.2.3 to 4.7.3.
[Bug target/56987] gcc/config/avr/avr.opt:80: "change" -> "changed"?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56987 Georg-Johann Lay changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Georg-Johann Lay --- Fixed in r200869 (trunk), r200868 (4.8.2)
[Bug target/57506] [avr] Some devices are present twice in avr-mcus.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57506 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Georg-Johann Lay --- Fixed by 200870 (trunk), 200871 (4.8.2).
[Bug target/57506] [avr] Some devices are present twice in avr-mcus.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57506 --- Comment #3 from Georg-Johann Lay --- Fixed by r200870 (trunk), r200871 (4.8.2).
[Bug target/57844] ICE: unrecognizable addqi3 insn with -msp8 and frame size of 128 bytes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57844 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.7.4 Resolution|--- |FIXED Known to fail|4.7.2 |4.7.3 --- Comment #2 from Georg-Johann Lay --- Fixed by r200872 (trunk), r200873 (4.8.2), r200874 (4.7.4).
[Bug c/57873] New: [avr-gcc] Local variable on stack overwritten by call instruction on target AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57873
Bug ID: 57873
Summary: [avr-gcc] Local variable on stack overwritten by call
instruction on target AVR
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: schlimmchen at yahoo dot de
Created attachment 30491
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30491&action=edit
Sample code to reproduce the bug
Have a look at this (real) non-working code snippet:
1 char helper ( char *param )
2 {
3 return param[0];
4 }
5
6 int main () {
7 char localNonStaticVar = 0x80;
8
9 helper ( &localNonStaticVar );
10
11 while ( 1 ) { }
12
13 return 0;
14 }
The function "helper" will return the low or high byte (I don't really know
which) of the return address in the call of "helper" in "main". Have a look at
how "main" is compiled to assembler:
avr-gcc -Wall -Wextra -S -mmcu=atmega1284p -O0 main.c -o main.s
35 .type main, @function
36 main:
37 push r28
38 push r29
39 push __zero_reg__
40 in r28,__SP_L__
41 in r29,__SP_H__
42 /* prologue: function */
43 /* frame size = 1 */
44 /* stack size = 3 */
45 .L__stack_usage = 3
46 ldi r24,lo8(-128)
47 std Y+1,r24
48 movw r24,r28
49 adiw r24,1
50 call helper
51 .L4:
52 rjmp .L4
53 .size main, .-main
Three registers are pushed onto the stack. Then r28,r29 (special register Y)
are assigned the stack pointer address. The value 0x80 is loaded into r24, then
stored on top of the stack BUT the stack pointer is NOT changed. In preparation
for the call of "helper", the address of this local variable is placed into r24
and r25.
Now, the instruction "call" places two bytes (the function return address) on
top of the stack, but the stack pointer still points to "__zero_reg__" and the
local variable on the stack is overwritten.
I guess my explanation is understandable?!
See the attached documents for more.
[Bug c/57873] [avr-gcc] Local variable on stack overwritten by call instruction on target AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57873 --- Comment #1 from Bernhard --- Created attachment 30492 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30492&action=edit Compiled assembly code
[Bug c++/57874] New: No SFINAE on ADL lookup failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57874
Bug ID: 57874
Summary: No SFINAE on ADL lookup failure
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gpderetta at gmail dot com
It seems that at least GCC 4.7 fails with an hard error on failure to lookup a
function via ADL in a sfinae context, if a function of that name is not visible
in scope. The following test fails to compile unless WORKAROUND is defined:
#ifdef WORKAROUND
struct unusable{};
void foo(unusable);
#endif
namespace NX
{
struct X {};
void foo(X){}
}
namespace NY
{
struct Y {};
}
template
auto ADLfoo(T&&x) -> decltype((foo(T{}), short())); //decltype(foo(x));
char ADLfoo(...);
static_assert(sizeof(ADLfoo(NY::Y{})) == 1, "");
static_assert(sizeof(ADLfoo(NX::X{})) == 2, "");
int main(){}
# g++ --std=c++11 -C adl.cc
adl.cc: In substitution of ‘template decltype ((foo(T{}), short
int())) ADLfoo(T&&) [with T = NY::Y]’:
adl.cc:24:36: required from here
adl.cc:19:6: error: ‘foo’ was not declared in this scope
adl.cc:19:6: note: suggested alternative:
adl.cc:9:6: note: ‘NX::foo’
Clang 3.2 compiles this fine.
[Bug c++/57869] [C++11] Casting a object pointer to a function pointer should not warn about a forbidden conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57869 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Paolo Carlini --- Fixed for 4.9.0.
[Bug c++/57874] No SFINAE on ADL lookup failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57874 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.0, 4.9.0 Resolution|--- |FIXED Known to fail||4.7.3 --- Comment #1 from Paolo Carlini --- Works fine in 4_8-branch and mainline. To be safe I'm adding the testcase.
[Bug fortran/57871] gfortran -freal-4-real-16 gives wrong result for selected_real_kind(1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2013-07-10
CC||kargl at gcc dot gnu.org
Resolution|INVALID |---
Ever confirmed|0 |1
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> > gfortran 4.8.1 -freal-4-real-16 gives real(16) kind with
> > selected_real_kind(1) but it ought to give real(8) because that is
> > the smallest decimal precision available with that compiler option.
>
> and your example does exactly that: Closing as INVALID.
I think that you may have been a little too hasty in closing
this PR. The issue lies in the code for selected_real_kind.
implicit none
integer,parameter:: p1 = selected_real_kind(1)
This initialization expression is requesting the type with
smallest precision that exceeds 1. With -freal-4-real-16,
that type is double precision (ie kind=8). The problem
lies in gfc_simplify_selected_real_kind. It has no knowledge
of the -freal-*-real-* options. The loop (lines 5447-5457)
for (i = 0; gfc_real_kinds[i].kind != 0; i++)
{
if (gfc_real_kinds[i].precision >= precision)
found_precision = 1;
if (gfc_real_kinds[i].range >= range)
found_range = 1;
if (gfc_real_kinds[i].radix >= radix)
found_radix = 1;
if (gfc_real_kinds[i].precision >= precision
&& gfc_real_kinds[i].range >= range
&& gfc_real_kinds[i].radix >= radix && gfc_real_kinds[i].kind < kind)
kind = gfc_real_kinds[i].kind;
}
searchs the ordered set [24, 53, 53, 113] (on FreeBSD-i386) or
[24, 53, 64, 113] (on FreeBSD-amd64). In either case, the
initialization expression returns REAL(4). However, with
-freal-4-real-16, one might expect the ordered set to be
searched is [113, 53, 64, 113] as REAL(4) has been promoted
to REAL(16).
[Bug preprocessor/57757] CPP extra inserted whitespace needs to be reviewed for C++11 user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57757
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Wed Jul 10 16:40:49 2013
New Revision: 200875
URL: http://gcc.gnu.org/viewcvs?rev=200875&root=gcc&view=rev
Log:
PR preprocessor/57757
* lex.c (cpp_avoid_paste): Avoid pasting CPP_{,W,UTF8}STRING
or CPP_STRING{16,32} with CPP_NAME or SPELL_LITERAL token that
starts if a-zA-Z_.
* g++.dg/cpp/paste1.C: New test.
* g++.dg/cpp/paste2.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/cpp/paste1.C
trunk/gcc/testsuite/g++.dg/cpp/paste2.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c
Fixed for 4.9+.
[Bug preprocessor/57824] Raw string literals not handled correctly in macro arguments or deferred pragmas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57824 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Jul 10 16:52:19 2013 New Revision: 200879 URL: http://gcc.gnu.org/viewcvs?rev=200879&root=gcc&view=rev Log: PR preprocessor/57824 * lex.c (lex_raw_string): Allow reading new-lines if in_deferred_pragma or if parsing_args and there is still data in the current buffer. * c-c++-common/raw-string-17.c: New test. * c-c++-common/gomp/pr57824.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr57824.c trunk/gcc/testsuite/c-c++-common/raw-string-17.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/lex.c Fixed for 4.9+.
[Bug tree-optimization/57875] New: wrong code at -O2 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57875
Bug ID: 57875
Summary: wrong code at -O2 on x86_64-linux-gnu in 32-bit mode
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -O2 in
32-bit mode. This is a regression from 4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130710 (experimental) [trunk revision 200864] (GCC)
$
$ gcc-trunk -m32 -O2 small.c
$ a.out
1
$ gcc-trunk -m32 -O1 small.c
$ a.out
0
$ gcc-trunk -m32 -O3 small.c
$ a.out
0
$ gcc-4.8 -m32 -O2 small.c
$ a.out
0
$
int printf (const char *, ...);
int a[1], b, c, d, f, i;
char e[1];
int
main ()
{
for (; i < 1; i++)
if (!d) {
if (!c)
f = 2;
e[0] &= f ^= 0;
}
b = a[e[0] >> 1 & 1];
printf ("%d\n", b);
return 0;
}
[Bug tree-optimization/57876] New: wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57876
Bug ID: 57876
Summary: wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -O3 in
32-bit mode. This is a regression from 4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130710 (experimental) [trunk revision 200864] (GCC)
$
$ gcc-trunk -m32 -O3 small.c
$ a.out
0
$ gcc-trunk -m32 -O2 small.c
$ a.out
1
$ gcc-4.8 -m32 -O3 small.c
$ a.out
1
$
int printf (const char *, ...);
int a, b = 1, c, *d = &c, f, *g, h, j;
static int e;
int
main ()
{
int i;
for (i = 0; i < 2; i++)
{
long long k = b;
int l;
for (f = 0; f < 8; f++)
{
int *m = &e;
j = *d;
h = a * j - 1;
*m = (h == 0) < k;
g = &l;
}
}
printf ("%d\n", e);
return 0;
}
[Bug tree-optimization/57877] New: wrong code at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57877
Bug ID: 57877
Summary: wrong code at -Os on x86_64-linux-gnu in 32-bit mode
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -Os in
32-bit mode. This is a regression from 4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130710 (experimental) [trunk revision 200864] (GCC)
$
$ gcc-trunk -m32 -Os small.c
$ a.out
0
$ gcc-trunk -m32 -O3 small.c
$ a.out
1
$ gcc-4.8 -m32 -Os small.c
$ a.out
1
$
-
int printf (const char *, ...);
int a, b, *c = &b, e, f = 6, g, h;
short d;
static unsigned char
foo (unsigned long long p1, int *p2)
{
for (; g <= 0; g++)
{
short *i = &d;
int *j = &e;
h = *c;
*i = h;
*j = (*i == *p2) < p1;
}
return 0;
}
int
main ()
{
foo (f, &a);
printf ("%d\n", e);
return 0;
}
[Bug rtl-optimization/57878] New: Incorrect code: live register clobbered in split2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57878
Bug ID: 57878
Summary: Incorrect code: live register clobbered in split2
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: eraman at google dot com
Created attachment 30493
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30493&action=edit
Preprocessed source of the test case
$ ./g++_4_8 --version
g++_4_8 (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
(Compiling the attached preprocessed source)
$ ./g++_4_8 -m32 -O2 -fno-omit-frame-pointer -fPIC -std=gnu++11 -c r.ii
$ objdump -d --no-show-raw-insn r.o > r.s
In the attached r.s, in function
_ZNSt6vectorIN3FDB9ChunkDataESaIS1_EE19_M_emplace_back_auxIIRKS1_EEEvDpOT_, the
sub instruction at address 0xfd writes to edx, which is subsequently stored at
[rbp-0x24]. edx is immediately clobbered. At 0x119, rbp-0x24 is clobbered and
hence the load at 0x168 loads an incorrect value into ecx.
After reload, we see the following:
(insn 117 241 196 7 (parallel [
(set (reg/f:SI 1 dx [orig:138 D.3282 ] [138])
(minus:SI (reg/f:SI 1 dx [orig:138 D.3282 ] [138])
(reg/v/f:SI 5 di [orig:103 __cur ] [103])))
(clobber (reg:CC 17 flags))
]) 309 {*subsi_1}
(nil))
(insn 196 117 268 7 (set (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -36 [0xffdc])) [21 %sfp+-36 S4 A32])
(reg/f:SI 1 dx [orig:138 D.3282 ] [138])) 89 {*movsi_internal}
(expr_list:REG_DEAD (reg/f:SI 1 dx [orig:138 D.3282 ] [138])
(nil)))
...
(insn 119 274 237 7 (set (reg:DI 0 ax [193])
(mem:DI (plus:SI (reg/v/f:SI 0 ax [orig:109 __first ] [109])
(const_int 4 [0x4])) [10 MEM[base: _1, index: _28, offset: 0]+0
S8 A64])) r.ii:197 88 {*movdi_internal}
(expr_list:REG_DEAD (reg/v/f:SI 0 ax [orig:109 __first ] [109])
(nil)))
...
(insn 234 120 200 7 (set (reg/f:SI 1 dx [orig:138 D.3282 ] [138])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -36 [0xffdc])) [21 %sfp+-36 S4 A32]))
r.ii:197 89 {*movsi_internal}
(expr_list:REG_DEAD (reg/f:SI 138 [ D.3282 ])
(nil)))
...
(insn 232 122 265 7 (set (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -36 [0xffdc])) [21 %sfp+-36 S4 A32])
(reg/f:SI 1 dx [orig:138 D.3282 ] [138])) r.ii:197 89 {*movsi_internal}
(nil))
The fill in 234 and the second spill in 232 are redundant. Insn 234 gets
removed by ce3 later, but 234 remains till the end. Meanwhile, 119 writes to a
DI mode register and gets split by split2 into eax and edx and hence the store
in 232 ends up clobbering the right value.
When compiled with a trunk built 2 weeks ago, the compiler ICEs with the
following stacck trace:
r.ii: In member function ‘void std::vector<_Tp,
_Alloc>::_M_emplace_back_aux(_Args&& ...) [with _Args = {const
FDB::ChunkData&}; _Tp = FDB::ChunkData; _Alloc =
std::allocator]’:
r.ii:192:3: internal compiler error: in assign_by_spills, at lra-assigns.c:1266
}
^
0x9ba360 assign_by_spills
/usr/local/google/home/eraman/gcc/trunk/gcc/lra-assigns.c:1266
0x9bb013 lra_assign()
/usr/local/google/home/eraman/gcc/trunk/gcc/lra-assigns.c:1423
0x9b71b9 lra(_IO_FILE*)
/usr/local/google/home/eraman/gcc/trunk/gcc/lra.c:2342
0x97d7b8 do_reload
/usr/local/google/home/eraman/gcc/trunk/gcc/ira.c:4689
0x97d7b8 rest_of_handle_reload
/usr/local/google/home/eraman/gcc/trunk/gcc/ira.c:4801
[Bug rtl-optimization/57878] Incorrect code: live register clobbered in split2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57878 --- Comment #1 from Easwaran Raman --- Created attachment 30494 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30494&action=edit Disassembly of the compiled r.ii
[Bug fortran/57871] gfortran -freal-4-real-16 gives wrong result for selected_real_kind(1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871 --- Comment #3 from Steve Kargl --- On Wed, Jul 10, 2013 at 05:42:03PM +, kargl at gcc dot gnu.org wrote: > implicit none > integer,parameter:: p1 = selected_real_kind(1) > > This initialization expression is requesting the type with > smallest precision that exceeds 1. With -freal-4-real-16, > that type is double precision (ie kind=8). The problem > lies in gfc_simplify_selected_real_kind. It has no knowledge > of the -freal-*-real-* options. The loop (lines 5447-5457) (remove loop code) > searchs the ordered set [24, 53, 53, 113] (on FreeBSD-i386) or > [24, 53, 64, 113] (on FreeBSD-amd64). In either case, the > initialization expression returns REAL(4). However, with > -freal-4-real-16, one might expect the ordered set to be > searched is [113, 53, 64, 113] as REAL(4) has been promoted > to REAL(16). The results of running John's code are odder than what one might expect. The normal results: % gfc4x -o foo foo.f90 && ./foo kind(1.0_p1) 4 precision(1.0_p1) 6 kind(1.0_dp) 8 precision(1.0_dp) 15 One might expect the first line to be 8 and 15, respectively. % gfc4x -o foo foo.f90 -freal-4-real-16 && ./foo kind(1.0_p1) 16 precision(1.0_p1) 33 kind(1.0_dp) 8 precision(1.0_dp) 15 Here the default real kind is promoted to REAL(8), but literal constants declared with a kind type suffix are not promoted. The first line is the correct output, although one might anticipate 8 and 15. But, what may be surprising is that the double precision kind has been bumped to quad precision. troutmask:sgk[207] gfc4x -o foo foo.f90 -fdefault-real-8 && ./foo kind(1.0_p1) 4 precision(1.0_p1) 6 kind(1.0_dp) 16 precision(1.0_dp) 33 I've always hated these type options as a lzy programmer's crutch who refuses to properly port an algorithm from one precision to another.
[Bug lto/57879] New: GCC with -flto generates invalid code for genmddeps program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57879 Bug ID: 57879 Summary: GCC with -flto generates invalid code for genmddeps program Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: d.g.gorbachev at gmail dot com Host: i686-pc-linux-gnu Target: i686-pc-linux-gnu Build: i686-pc-linux-gnu Created attachment 30495 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30495&action=edit Self-contained (though not yet minimized) testcase A function htab_create_typed_alloc.constprop.9 expects arguments in registers, but called from main() with arguments on the stack.
[Bug lto/57879] GCC with -flto generates invalid code for genmddeps program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57879 --- Comment #1 from Dmitry Gorbachev --- GCC 20130526 (r199345) - works: 08048a10 : main(): [...] 8048a62: mov$0x8048f60,%ecx 8048a67: mov$0x8048f80,%edx 8048a6c: mov$0xa1,%eax 8048a71: call 8049790 [...] 08049790 : htab_create_typed_alloc.constprop.9(): 8049790: push %ebp 8049791: mov%edx,%ebp [...] 80497e8: mov%ebp,(%edi) [...] GCC 20130609 (r199874) - fails: 08048a10 : main(): [...] 8048a62: movl $0x8048f80,0x8(%esp) 8048a6a: movl $0x8048fa0,0x4(%esp) 8048a72: movl $0xa1,(%esp) 8048a79: call 80497b0 [...] 080497b0 : htab_create_typed_alloc.constprop.9(): 80497b0: push %ebp 80497b1: mov%edx,%ebp [...] 8049808: mov%ebp,(%edi) [...] GCC 4.9.0 20130707 (experimental) - still fails.
[Bug lto/57879] GCC with -flto generates invalid code for genmddeps program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57879 Igor Zamyatin changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #2 from Igor Zamyatin --- Dup of PR57602, I suppose
[Bug fortran/57871] gfortran -freal-4-real-16 gives wrong result for selected_real_kind(1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871 --- Comment #4 from harper at msor dot vuw.ac.nz --- The reason I sent that bug report is that I had read the manual and found that -freal-4-real-16 makes the available real kinds 8, 10, 16. The Fortran standard says selected_real_kind(1) must give the kind with the smallest available decimal precision that has precison at least 1. In the circumstances that is kind 8. The manual refers to promotion of REAL(KIND=M) entities. Selected_real_kind is an integer entity not a real one. On Wed, 10 Jul 2013, dominiq at lps dot ens.fr wrote: > Date: Wed, 10 Jul 2013 13:07:40 + > From: dominiq at lps dot ens.fr > To: john.har...@vuw.ac.nz > Subject: [Bug fortran/57871] gfortran -freal-4-real-16 gives wrong result for > selected_real_kind(1) > Resent-Date: Wed, 10 Jul 2013 13:08:02 + > Resent-From: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871 > > Dominique d'Humieres changed: > > What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution|--- |INVALID > > --- Comment #1 from Dominique d'Humieres --- >> gfortran 4.8.1 -freal-4-real-16 gives real(16) kind with >> selected_real_kind(1) but it ought to give real(8) because that is >> the smallest decimal precision available with that compiler option. >> Same problem with -freal-4-real-10 giving real(10) instead of real(8). ... > > Why are you expecting that? The manual says: > > -freal-4-real-8 > -freal-4-real-10 > -freal-8-real-4 > -freal-8-real-10 > -freal-8-real-16 > Promote all REAL(KIND=M) entities to REAL(KIND=N) entities. If REAL(KIND=N) is > unavailable, then an error will be issued. All other real kind types are > unaffected by this option. These options should be used with care and may not > be suitable for your codes. Areas of possible concern include calls to > external > procedures, alignment in EQUIVALENCE and/or COMMON, generic interfaces, BOZ > literal constant conversion, and I/O. Inspection of the intermediate > representation of the translated Fortran code, produced by > -fdump-tree-original, is suggested. > > and your example does exactly that: Closing as INVALID. > > -- > You are receiving this mail because: > You reported the bug. > > > -- John Harper, School of Mathematics Statistics and Operations Research Victoria University, PO Box 600, Wellington 6140, New Zealand e-mail john.har...@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045
[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 mrs at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|unknown |4.8.0 Resolution|--- |FIXED --- Comment #8 from mrs at gcc dot gnu.org --- Fixed.
[Bug rtl-optimization/57462] ira-costs considers only a single register at a time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57462 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #3 from Ramana Radhakrishnan --- This is part of the reason why on trunk we currently disable 64 bit arithmetic in neon in a large number of cases. It's sometimes just not worth it - Additionally neon doesn't have comparison operations so many times one has noticed that we keep doing a lot of operations on the neon side and then you just have to move back to the integer side to the comparisons. So there are times when this doesn't happen properly. Ramana
[Bug target/57731] [4.9 Regression] ICE in extract_insn, at recog.c:2158 (arm-linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57731 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-07-10 CC||ramana at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan --- confirmed. mine.
[Bug target/57731] [4.9 Regression] ICE in extract_insn, at recog.c:2158 (arm-linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57731 Ramana Radhakrishnan changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/57329] ICE with -O2 and -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57329 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.8.2 --- Comment #5 from Ramana Radhakrishnan --- fixed.
[Bug target/57837] ARM function pointer tailcall miscompilation regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57837 Ramana Radhakrishnan changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-10 CC||ramana at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ramana at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan --- mine.
[Bug c++/57827] compiler segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57827 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.0 Resolution|--- |FIXED Known to fail||4.8.1 --- Comment #3 from Paolo Carlini --- I'm adding the testcase and closing the bug as fixed for 4.9.0.
[Bug c++/55004] [meta-bug] constexpr issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 57827, which changed state. Bug 57827 Summary: compiler segmentation fault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57827 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/57109] ice tsubst_copy, at cp/pt.c:12171
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57109 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|2013-04-29 00:00:00 |2013-07-10 Ever confirmed|0 |1 --- Comment #3 from Paolo Carlini --- Can you please try to reduce your testcase to a manageable size? Normally, for proper C++ front-end issues less 50 lines are enough and no special command line options are needed, but your *.i has a lot of target-specific code. We have a wiki entry: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction Thanks!
[Bug c++/56973] crash when capturing variables in nested lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56973 Paolo Carlini changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2
[Bug c++/56892] dllexport prevents inline inside dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56892 Paolo Carlini changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Paolo Carlini --- Kai, can you have a look?
[Bug tree-optimization/55334] [4.8/4.9 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 Chris Jones changed: What|Removed |Added CC||chris_s_jones at yahoo dot com --- Comment #32 from Chris Jones --- I'm curious if the original 172.mgrid regression is believed to still exist in GCC 4.8.1. I notice that ipa-cp.c has Martin's special case for RESTRICT pointers, yet building 172.mgrid for AArch64 seems to result in an inlined version of resid_() which does not get vectorized. Using -fno-inline-functions (or alternatively --param inline-min-speedup=17) produces code which runs significantly faster. It's remotely possible that I have some local edits which are causing the regression, but I suspect that the issue is still present for the mgrid case and wanted to verify that before attempting another work-around.
