https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #20 from Gabriel Ravier ---
> In general, why avoiding std::sort crashes is considered a good thing?
> Wouldn't we just hide the error and produce invalid results causing harder to
> debug errors later in user's program?
The issue
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int main(){
unsigned __int128_t x = 0;
}
Compiled with -pedantic, results in the following warning:
: In function &#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96290
--- Comment #3 from Gabriel Ravier ---
Well, nonsensical from the point of view of the user - it didn't seem to be
particularly different to me for the error to evoke an object as " + 1"
when it just means a VLA and "" when it just means an empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116465
--- Comment #2 from Gabriel Ravier ---
Looked into it a bit more and the root cause seems to be that
gcc/tree-eh.cc:lower_eh_constructs_2, when attempting to handle the case where
the user partakes in a little tomfoolery with its builtins (i.e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116465
--- Comment #1 from Gabriel Ravier ---
(PS: I have no idea what this is caused by, somehow an assignment statement
with no left hand side appears to be generated ?)
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void canada(){
__builtin_eh_pointer(0);
}
This crashes GCC with the following error:
during GIMPLE pass: eh
: In function 'c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96290
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int32_t mulx32(int32_t x, int32_t y)
{
uint64_t r1 = (uint64_t)(x + x) * (uint64_t)(y + y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115896
--- Comment #4 from Gabriel Ravier ---
I'll add that the case of `(a << cst0) == cst1` (which LLVM handles but not
GCC) seems relatively frequent in real code, e.g. after a few minutes I've
found it in:
-
https://github.com/TASEmulators/BizHawk/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115896
--- Comment #3 from Gabriel Ravier ---
(PS: LLVM seems to do the `(cst0 << a) == cst1` transformation including when
`cst1 == 0` since 59939acd2684708a1c617f9e42b2206956804bb6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115896
--- Comment #2 from Gabriel Ravier ---
Also somewhat of an opposite to `(a << cst0) == cst1` is `(cst0 << a) == cst1`,
which seems to be optimized by GCC in certain cases but not for `cst1 == 0`,
which LLVM does for e.g.:
#include
bool f3(int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115896
--- Comment #1 from Gabriel Ravier ---
A generalization of this is that `(a << cst0) == cst1` should be foldable to `a
== cst0 >> cst1`, leading to the much more obvious case of:
bool f1(int8_t a)
{
int32_t b = a << 4;
return b == -128;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95817
--- Comment #3 from Gabriel Ravier ---
A place where this does seem to give faster results in real code is code where
multiple conditions like this are placed in a row, in e.g. the code at
https://github.com/openbsd/xenocara/blob/0c50e27b4c04e035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102392
Gabriel Ravier changed:
What|Removed |Added
Target|X86_64-linux-gnu|x86_64-linux-gnu
Version|12
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
int32_t f(int32_t i2, int32_t aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102623
--- Comment #3 from Gabriel Ravier ---
Seems fixed on trunk ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580
--- Comment #8 from Gabriel Ravier ---
Seems to be fixed on trunk ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95762
--- Comment #6 from Gabriel Ravier ---
Seems fixed on trunk ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95230
--- Comment #6 from Gabriel Ravier ---
Oh oops, I was looking at -O3 output instead of -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95230
--- Comment #4 from Gabriel Ravier ---
Seems to be fixed on trunk ?
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
bool f1(int8_t a)
{
int8_t b = a << 4;
return b == -128;
}
bool f2(int8_t a)
{
return (
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int main(){}
int HMAP_unset_copy(const char *key) {
return __builtin_strcmp("a", key) + __builtin
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
struct Vec3
{
union {
float v[3];
float x, y, z;
};
};
float Vec3Dot(struct Vec3 vec1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113812
--- Comment #2 from Gabriel Ravier ---
Also I guess this is a simpler minimal example:
void f(int x)
{
int(x), 0;
}
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f()
{
int(x), a, b, c, d, e, f, g, h, etc;
int(x), a, b, c, d, e, f, g, h, etc, (new int);
}
Clang parses
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f() {
__builtin_nonlocal_goto(0, 0);
}
This crashes GCC with the following error:
during RTL pass: expand
: In function 'f&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107845
--- Comment #2 from Gabriel Ravier ---
I'll add that the new `__builtin_init_heap_trampoline` builtin also ICEs when
given the same arguments, presumably for the same reasons (thus, an extra bug
report doesn't seem very useful)
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f()
{
return __builtin_eh_return_data_regno(-1);
}
This crashes GCC with the following error:
during RTL pass: expand
: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111378
--- Comment #5 from Gabriel Ravier ---
It does seem as though this transformation is not particularly favorable on
most platforms. In fact, it seems as though the opposite transformation (which
Clang does on many targets, along with MSVC) would
mponent: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int[[gnu::copy("")]]a;
This crashes trunk GCC with the following error:
:1:1: internal compiler error: tree check: expected tree that contains
'decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109986
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911
--- Comment #5 from Gabriel Ravier ---
Also, as an extra note, w.r.t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911#c3, I've just noticed that I
had indeed made a separate bug report at https://gcc.gnu.org/PR94912 (which
ended up being close
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104375
--- Comment #4 from Gabriel Ravier ---
So should the bug be marked as fixed or... ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98966
--- Comment #3 from Gabriel Ravier ---
Appears to be fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96930
--- Comment #11 from Gabriel Ravier ---
It appears like this is fixed on trunk, I think ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96692
--- Comment #3 from Gabriel Ravier ---
This seems to be fixed on trunk now, I think ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95427
--- Comment #2 from Gabriel Ravier ---
Still appears to be fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908
--- Comment #3 from Gabriel Ravier ---
Looks like this gives much better output now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94899
--- Comment #7 from Gabriel Ravier ---
I don't know if I've missed something obvious but this still appears to be
fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94782
--- Comment #2 from Gabriel Ravier ---
Appears to be fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #19 from Gabriel Ravier ---
(In reply to Jakub Jelinek from comment #14)
> The patch does:
> + bool zero_ok = CTZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (type), ctzval)
> == 2;
> +
> + /* Skip if there is no value defined at zero,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
--- Comment #29 from Gabriel Ravier ---
Looks like the patch fixes this bug, unless I'm missing something.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
--- Comment #14 from Gabriel Ravier ---
Actually I think there's some aliasing violations in the C++ code w.r.t. the
re-usage of `p4` after another object has been created in its place so I think
this code would be more correct:
void test1(long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f()
{
__builtin_init_trampoline(0, 0, 0);
}
This crashes GCC with the following error:
during RTL pass: expand
: In function 'f':
:3:5: internal comp
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
typedef __UINT16_TYPE__ uint16_t;
typedef __UINT32_TYPE__ uint32_t;
typedef __INTPTR_TYPE__ intptr_t;
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535
--- Comment #3 from Gabriel Ravier ---
Considering the comment appears to be from 1993 (see commit
d9fc6069c69564ce7fecd9ca0ce1bbe0b3c130ef), it having become wrong since then
doesn't seem particularly surprising :p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535
Gabriel Ravier changed:
What|Removed |Added
Keywords||accepts-invalid,
|
13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f = (0, 0);
Compiled without any options:
:1:9: error: initia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94920
--- Comment #4 from Gabriel Ravier ---
So, is this fully fixed, or did I miss something ?
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
int8_t f(int8_t a)
{
return (uint8_t)(a << 7) >> 7;
}
This can be optimized to `return a & 1;`. This tra
NCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
int8_t f(int8_t x)
{
int8_t sh = 1 << x;
return sh & 1;
}
This
nent: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
typedef int64_t v2i64 __attribute__((vector_size(16)));
v2i64 f(v2i64 x)
{
return (0 - x) & 1;
}
This can be optimized to `return x &am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94899
--- Comment #6 from Gabriel Ravier ---
Can confirm that this appears to be fixed.
UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool f(unsigned a, unsigned b)
{
return (b != 0) && (a >= b);
}
This can b
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f17(unsigned x)
{
int z;
return __builtin_mul_overflow((int)x, 35, &z);
}
This ca
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f4(unsigned x, unsigned y)
{
if (x == 0)
return 1;
return ((int)(x * y) / (int)x) == y;
}
can be optimized to
int f4(unsigned x
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int
baz (unsigned long x, unsigned long y)
{
return (int) (x & y) > 0;
}
With -O3, AArch64 GCC outputs this:
baz(unsigned long, unsigned long):
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102583
--- Comment #7 from Gabriel Ravier ---
Can confirm it is indeed fixed
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f1();
void f2();
void f3();
void g(int b, int c)
{
int a = b + c;
if (a > 0)
f1();
else if
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
typedef int64_t v2i64 __attribute__((vector_size(16)));
v2i64 _mm_set_epi64x(int64_t i1, int64_t i2)
{
union
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
Created attachment 52361
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52361&action=edit
Prepr
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
__m128i min32(__m128i value, __m128i input)
{
return _mm_blendv_epi8(input, value, _mm_cmplt_epi32(value, input));
}
With
ent: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
typedef int32_t v4i32 __attribute__((vector_size(16)));
v4i32 get_cmpmask(v4i32 mask)
{
v4i32 signmask{(int32_t)0x8000, (int32_t)0x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371
--- Comment #2 from Gabriel Ravier ---
Although I agree the pattern doesn't seem that useful at first, I've seen it
crop up in several places, such as:
- in pixman: https://github.com/servo/pixman/blob/master/pixman/pixman-sse2.c
on line 181
-
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
uint32_t countLeadingZeros32(uint32_t x)
{
if (x == 0)
return 32;
return (31 - __builtin_clz(x)) ^ 31;
}
On x86, with `-mlzcnt`, GCC
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
uint64_t bextr_u64(uint64_t w, unsigned off, unsigned int len)
{
return (w >> off) & ((1U << len) - 1U)
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool is_zero(__m128i x)
{
return _mm_movemask_epi8(_mm_cmpeq_epi8(x, _mm_setzero_si128())) == 0x;
}
This can
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
typedef int16_t v8i16 __attribute__((vector_size(16)));
v8i16 abs_i16(v8i16 x)
{
auto isN = x < v8i16{};
x ^= isN;
return x -
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
unsigned char stbi__clamp(int x)
{
if ((unsigned)x > 255) {
if (x < 0) return 0;
if (x > 255) r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104315
--- Comment #1 from Gabriel Ravier ---
PS: I've just stumbled upon the more generic case, which would be this code:
unsigned int stb_bitreverse(unsigned int n)
{
n = ((n & 0x) >> 1) | ((n & 0x) << 1);
n = ((n & 0x)
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
unsigned int stb_bitreverse8(unsigned char n)
{
n = ((n & 0xAA) >> 1) + ((n & 0x55) << 1);
n = ((n & 0xCC) >> 2) + ((n &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103343
--- Comment #3 from Gabriel Ravier ---
Well the code does not invoke undefined behavior here, it just so happens that
`p == (x + 1)` because `y` happens to be laid out in memory after `x` (note:
this isn't a guarantee, of course, but GCC can't p
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
extern int x[1], y;
int f(int *p, int *q) {
*q = y;
if (p == (x + 1)) {
*p = 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939
--- Comment #4 from Gabriel Ravier ---
(In reply to Hans-Peter Nilsson from comment #3)
> (In reply to Gabriel Ravier from comment #0)
> ...
> > #define PTR4 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3
> > #define PTR5 PTR4 PTR4 PTR4 PTR4
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#define PTR1 * * * * * * * * * *
#define PTR2 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1
#define PTR3 PTR2 PTR2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
--- Comment #5 from Gabriel Ravier ---
Um, what ? How is this invalid, exactly ? Are you saying foo is faster than baz
(in which case it seems the opposite optimization should be implemented for baz
and bar), or that this optimization just won't
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int foo(int i) {
if (i == 0)
return 52;
else if (i == 1)
return 77;
else if (i == 2)
return 91;
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573
--- Comment #11 from Gabriel Ravier ---
Well, that does help, although it is still a significant annoyance that would
take more than its fair share of time to handle.
(Also, is it still really that much of a concern anymore that users would thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
++
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f()
{
void{};
}
This has been considered valid since
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2351 was accepted
as a DR in 2018, but GCC fails to compile it, with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15792
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
typedef int64_t v2i64 __attribute__((vector_size(16)));
typedef uint16_t v8u16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95740
--- Comment #3 from Gabriel Ravier ---
I've also encountered what looks like a duplicate of this bug, although I'm not
sure but it seems likely:
int foo(float f)
{
union
{
float f;
int i;
} z = { .f = f };
return z.i - 1;
}
Whi
IRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int a(__int128 f, int g)
{
return (f >> 127) >> g;
}
This can be optimized to
MED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
double foo(int s, double a)
{
return s + a;
}
With -O3, GCC outputs this on AMD64:
foo(int, dou
converted to 32-bit
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102676
--- Comment #2 from Gabriel Ravier ---
Well, I think the assumption LLVM is making is that the allocation, being
unused, can just be eliminated and considered to have always succeeded. I don't
see how that would contradict the standard, although
IRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
#include
bool f()
{
return new(std::nothrow) int;
}
bool g()
{
return mal
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
struct X {
int i;
void *p;
};
void foo(struct X *q, void *p)
{
struct X b{};
b.p = p;
*q = b;
}
With
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
using T = int;
consteval bool f()
{
T t = 42;
t.~T();
return (t == 42);
}
bool x = f();
This code should not compile, as `f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102591
--- Comment #2 from Gabriel Ravier ---
memcpy can fail on unaligned memory ??? I used it specifically to avoid this
problem !
(also, LLVM's code, I am pretty sure, does not have any issue with alignment,
as it uses either AVX instructions which
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool match8(char *tpl)
{
int found = 0;
for (int at = 0; at < 16; at++)
if (tpl[at] == 0)
found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730
--- Comment #4 from Gabriel Ravier ---
That's a bit odd, really - I'm just using the latest released sub-versions of
each of these (except for GCC 6 since I only have access to it through Godbolt
which doesn't have GCC 6.5), i.e. GCC 6.4, 7.5, 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
typedef int v8si __attribute__((vector_size(32
IRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x) {
if (x < 0)
__builtin_abort();
return x/3;
}
The `return` statemen
1 - 100 of 467 matches
Mail list logo
