[Bug middle-end/99696] New: lto looks past aliases to initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99696
Bug ID: 99696
Summary: lto looks past aliases to initializers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rth at gcc dot gnu.org
Target Milestone: ---
The following is a c-ish version of
const int y = init();
which no longer works with gcc 11.
The intended advantage to the program from which this is
extracted is that references to Y may be cse'd across calls.
IMO this should work fine with LTO, so long as it does not
apply the constant initializer optimization to const variables
that are aliased.
Compile: gcc -O2 -flto y?.c
--- y1.c ---
#include
extern const int y;
int main(void)
{
assert(y == 1);
return 0;
}
--- y2.c ---
static int x;
extern const int y __attribute__((alias("x")));
static void __attribute__((constructor)) init(void)
{
x = 1;
}
[Bug middle-end/99696] lto looks past aliases to initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99696 --- Comment #1 from Richard Henderson --- Actually, I can reproduce this with gcc 9.3 as well. My upstream bug report simply uses gcc 11, so I assumed.
[Bug target/97323] [10/11 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323 --- Comment #9 from Richard Henderson --- As a data point, this problem can be seen with any strict-alignment target -- e.g. sparc.
[Bug target/97323] [10/11 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323 --- Comment #10 from Richard Henderson --- Created attachment 49473 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49473&action=edit rfc patch The following fixes the ICE. It seems like a hack, done at the wrong level. Should we have in fact set TYPE_STRUCTURAL_EQUALITY_P all the way back on the unaligned 'a' type, before we even try to create an array of 'a'? If so, that would have properly triggered the test here in build_array_type_1 that would have bypassed the problem.
[Bug ipa/108470] New: Missing documentation for alternate uses of __attribute__((noinline))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470 Bug ID: 108470 Summary: Missing documentation for alternate uses of __attribute__((noinline)) Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: rth at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- The noinline attribute affects decisions made by ipa-split.cc and ipa-icf.cc that are not immediately obvious. At least the ipa-split choice affects code correctness for QEMU (in that we expect __builtin_return_address to be used in very specific contexts, and the transformation done by ipa-split invalidates that). Using noinline on the affected functions prevents the ipa-split optimization and restores functionality. It would be nice to document the effect, so that the workaround is not affected in future gcc versions.
[Bug c/105131] New: Warning for mismatched declaration/definition with enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105131
Bug ID: 105131
Summary: Warning for mismatched declaration/definition with
enum
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rth at gcc dot gnu.org
Target Milestone: ---
For a testcase such as
enum E { l = -1, z = 0, g = 1 };
int foo(void);
enum E foo(void) { return z; }
If the implementation type of 'enum E' is not 'int',
we will correctly emit an error (e.g. -fshort-enums).
It would be desirable to emit a warning in this case,
because it is probably a mistake and definitely a
portability error.
[Bug c/107389] New: Alignment not inferred from type at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107389
Bug ID: 107389
Summary: Alignment not inferred from type at -O0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rth at gcc dot gnu.org
Target Milestone: ---
Consider
typedef __uint128_t aligned_type __attribute__((aligned(16)));
_Static_assert(__alignof(aligned_type) == 16);
__uint128_t foo(aligned_type *p) { return __atomic_load_n(p, 0); }
For s390x, atomic_loadti should expand this to LPQ.
For my purposes, it must also do this at -O0, not just with
optimization. But the alignment seen by gen_atomic_loadti
is only 8, so it FAILs the expansion and falls back to libatomic.
The following appears to solve the problem:
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -468,8 +468,11 @@ get_pointer_alignment_1
}
else
{
+ /* Assume alignment from the type. */
+ tree ptr_type = TREE_TYPE (exp);
+ tree obj_type = TREE_TYPE (ptr_type);
+ *alignp = TYPE_ALIGN (obj_type);
*bitposp = 0;
- *alignp = BITS_PER_UNIT;
return false;
}
}
but I have an inkling that would have undesired effects
for other usages. If so, perhaps a special case could be
made for the usage in get_builtin_sync_mem.
[Bug c/107389] Alignment not inferred from type at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107389 --- Comment #3 from Richard Henderson --- If __builtin_assume_aligned were to work at -O0, that would also work for me. Better, probably, than fiddling with __attribute__((aligned)).
[Bug middle-end/107389] Always propagate __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107389 Richard Henderson changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|Alignment not inferred from |Always propagate |type at -O0 |__builtin_assume_aligned Version|unknown |12.2.1 Ever confirmed|0 |1 Last reconfirmed||2022-10-26 Severity|normal |enhancement --- Comment #4 from Richard Henderson --- Rename and re-categorise as enhancement. As mentioned, in comments above, need to be able to rely on __builtin_assume_aligned even with -O0 to avoid link errors when not including libatomic.
[Bug tree-optimization/112296] __builtin_constant_p doesn't propagate through member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112296
--- Comment #7 from Richard Henderson ---
(In reply to Richard Biener from comment #5)
> int bad1(void) { return __builtin_constant_p(global++); }
...
> Joseph, Richard, do you have anything to add or remember discussions about
> this semantic detail of __builtin_constant_p?
Since it has been 25 years, I don't recall any specific discussions.
The intended use-case at the time was more like
#define macro(x) \
(__builtin_constant_p(x) \
? inline_expression(x) \
: out_of_line_function(x))
So I would have expected side effects to have been ignored for
the builtin and expanded via one of the two arms.
[Bug tree-optimization/112296] __builtin_constant_p doesn't propagate through member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112296
--- Comment #9 from Richard Henderson ---
> Thanks. So yes,
>
> macro(x++);
>
> incrementing x twice would have been odd - but that's the usual bug
> in this kind of macro definition. Fixing it by throwing away
> side-effects (and always going the out_of_line_function (x) path!)
> for the __builtin_constant_p argument is an odd choice.
In the beginning __builtin_constant_p was resolved immediately,
so formulating this as
#define macro(x) \
({ __typeof(x) _x = (x); \
__builtin_constant_p(_x) })
would always return false, defeating the purpose.
> The execute.exp testcase suggests the intention but the testcases
> verification is somewhat incomplete (it lacks verifying the side-effects
> are gone).
That's probably my omission. ;-)
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #36 from Richard Henderson --- (In reply to Mayshao-oc from comment #34) > (In reply to Jakub Jelinek from comment #17) > > Fixed for AMD on the library side too. > > We need a statement from Zhaoxin and VIA for their CPUs. > > Sorry for the late reply. > We guarantee that VMOVDQA will be an atomic load or store provided 128 bit > aligned address in Zhaoxin processors, provided that the memory type is WB. > Can we extend this patch to Zhaoxin processors as well? Is VMOVDQU atomic, provided the address is aligned in Zhaoxin processors? In QEMU, we make use of this additional guarantee from AMD. We also reference this gcc bugzilla entry for documentation. :-)
