[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
