[Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 --- Comment #55 from Dave Murphy 2011-10-29 23:27:02 UTC --- (In reply to comment #54) > I tested with GCC 4.6.2 and the patch provided by Mikael Pettersson. It works > for -march=armv4t and -march=armv5t, but not for -march=armv5te: For what it's worth I've been using Richard Earnshaw's patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282#c8 with my own gcc builds and it's working fine for all -march values. There's also Joern's patch at http://gcc.gnu.org/ml/gcc/2011-07/msg00461.html which I haven't tested but looks like it should work. I still don't understand why there seems to be so much resistance to Richard's suggestion that targets with redzones should explicitly enable this behaviour. How can it be a hack to treat stack moves specially? Isn't the stack generally a special register?
[Bug target/89746] New: powerpc-none-eabi-gcc emits code using stfiwx to misaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746 Bug ID: 89746 Summary: powerpc-none-eabi-gcc emits code using stfiwx to misaligned address Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: davem at devkitpro dot org Target Milestone: --- The following code produces an alignment exception on powerpc 750 and I presume on other powerpc ISAs where unaligned floating point is not allowed. typedef struct { int i; short x, y, z; } foo; void bar(foo *p, float f) { int d = f; p->y = d>>16; p->z = d&0x; } file"stfiwx-test.c" .section".text" .align 2 .globl bar .type bar, @function bar: .LFB0: .cfi_startproc fctiwz %f1,%f1 addi %r3,%r3,6 stfiwx %f1,0,%r3 blr .cfi_endproc .LFE0: .size bar, .-bar compiling with -mstrict-align generates working code .file "stfiwx-test.c" .section".text" .align 2 .globl bar .type bar, @function bar: .LFB0: .cfi_startproc stwu %r1,-16(%r1) .cfi_def_cfa_offset 16 fctiwz %f1,%f1 addi %r9,%r1,8 stfiwx %f1,0,%r9 lwz %r9,8(%r1) srawi %r10,%r9,16 sth %r9,8(%r3) sth %r10,6(%r3) addi %r1,%r1,16 .cfi_def_cfa_offset 0 blr .cfi_endproc .LFE0: .size bar, .-bar
[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #12 from Dave Murphy --- Naive patch based on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017#c7 gets my canadian crosses building. diff --git a/libstdc++-v3/include/c_compatibility/fenv.h b/libstdc++-v3/include/c_compatibility/fenv.h index 0413e3b7c25..56cabaa3635 100644 --- a/libstdc++-v3/include/c_compatibility/fenv.h +++ b/libstdc++-v3/include/c_compatibility/fenv.h @@ -26,6 +26,10 @@ * This is a Standard C++ Library header. */ +#if !defined __cplusplus || defined _GLIBCXX_INCLUDE_NEXT_C_HEADERS +# include_next +#else + #ifndef _GLIBCXX_FENV_H #define _GLIBCXX_FENV_H 1 diff --git a/libstdc++-v3/include/c_global/cfenv b/libstdc++-v3/include/c_global/cfenv index 0b0ec35a837..d24cb1a3c81 100644 --- a/libstdc++-v3/include/c_global/cfenv +++ b/libstdc++-v3/include/c_global/cfenv @@ -37,9 +37,11 @@ #include -#if _GLIBCXX_HAVE_FENV_H -# include -#endif +// Need to ensure this finds the C library's not a libstdc++ +// wrapper that might already be installed later in the include search path. +#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS +#include_next +#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS #ifdef _GLIBCXX_USE_C99_FENV_TR1
[Bug c++/100296] New: [10.x regression] offsetof with non-constant-expression offset no longer accepted in C++ mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100296 Bug ID: 100296 Summary: [10.x regression] offsetof with non-constant-expression offset no longer accepted in C++ mode Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: davem at devkitpro dot org Target Milestone: --- The following code compiles fine as C but produces " error: 'idx' is not a constant expression" with gcc 11.1.0 #include #include struct foo { uint8_t things[12]; }; uintptr_t getThing(const unsigned idx) { return offsetof(struct foo, things[idx]); } The code compiles fine with gcc 6.x through 10.x gcc 5.x says "error: 'idx' cannot appear in a constant-expression"
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #17 from Dave Murphy --- (In reply to Jonathan Wakely from comment #16) > I don't think the patch is sufficient, I think I had a complete one. Shall I leave this or submit the patch I made as a starting point for review?
[Bug driver/109762] New: [AArch64] gcc/config/aarch64/aarch64-builtins.cc: mismatched sizes for flags variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109762 Bug ID: 109762 Summary: [AArch64] gcc/config/aarch64/aarch64-builtins.cc: mismatched sizes for flags variables Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: davem at devkitpro dot org Target Milestone: --- Created attachment 55013 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55013&action=edit preprocessed source that fails On windows and 32 bit hosts int and long are 32bit while aarch64_feature_flags is 64bit. This causes compilation failures on windows & 32bit hosts. The attached source fails with a spurious inlining failed in call to 'always_inline' 'unsigned int GetConstant()': target specific option mismatch.
[Bug driver/109762] [AArch64] gcc/config/aarch64/aarch64-builtins.cc: mismatched sizes for flags variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109762 --- Comment #1 from Dave Murphy --- Created attachment 55014 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55014&action=edit proposed patch