https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #11 from Robin Dapp ---
I figured this particular problem on RISC-V won't be fixed on GCC 14 because we
don't have the zeroing of masked elements there. But you're referring to
backporting just this patch, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118780
--- Comment #4 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:09cc01ca00a140c110c02e4ba297da4718f105e8
commit r14-11341-g09cc01ca00a140c110c02e4ba297da4718f105e8
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
--- Comment #6 from Hongtao Liu ---
(In reply to John Platts from comment #5)
> GCC also fails to optimize (a | b) - ((a ^ b) >> 1) down to a single SSE2
> PAVGB/PAVGW, NEON/SVE2 SRHADD/URHADD, AltiVec
> vavgsb/vavgsh/vavgsw/vavgub/vavguh/vavguw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
Richard Biener changed:
What|Removed |Added
Status|RESOLVED|NEW
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118780
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.4
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118780
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:1283b9f946eea07573be5ba0e0785c9e9279b3be
commit r13-9390-g1283b9f946eea07573be5ba0e0785c9e9279b3be
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119003
--- Comment #1 from Richard Biener ---
The comment is before the respective workers (walk_aliased_vdefs_1 for
example), copy-pasting leads to divergence so I tend to omit the duplication
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119008
--- Comment #3 from terryinzaghi ---
(In reply to Andrew Pinski from comment #1)
> Dup. The problem is GCC thinks > ends the template argument even though it
> is still inside a lambda definition.
>
> *** This bug has been marked as a duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119008
--- Comment #2 from terryinzaghi ---
x86-64 gcc 14.2
-std=c++23 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111008
Andrew Pinski changed:
What|Removed |Added
CC||terryinzaghi at 163 dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119008
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118991
--- Comment #2 from Andreas Schwab ---
There are more occurrences of this problem:
#: config/pru/pru-pragma.cc:61
msgid "% index %"
#: config/pru/pru-pragma.cc:64
msgid "redefinition of %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119008
Bug ID: 119008
Summary: for token(>): compiler can NOT distinguish
close-template-block(>) from operator(>):
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #16 from Maxim Egorushkin ---
(In reply to Maxim Egorushkin from comment #14)
> (In reply to Andrew Pinski from comment #6)
>
> > It happens more often with vector instructions/registers due to the
> > different "modes" of the regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #15 from Maxim Egorushkin ---
(In reply to Maxim Egorushkin from comment #14)
> (In reply to Andrew Pinski from comment #6)
>
> > It happens more often with vector instructions/registers due to the
> > different "modes" of the regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #17 from Gavin Howard ---
> These links are dead. That's why we want references to a standalone testcase
> given (lines in it or functions and so on)...
Fair enough, but in my defense, it's been two years. I was pretty sure this had
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
--- Comment #9 from Jerry DeLisle ---
We can have only one default integer otherwise its not a default. Our default
integer is KIND=4
The RANGE of KIND=4 integer is 9, so we exceed the requirement for at least a
decimal range of 5. RANGE is def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #19 from Gavin Howard ---
Understood.
If I had to guess, and this is a *wild* guess, it's because I'm putting a
pointer to a function in the allocation.
As far as I can tell, this is still allowed, per the docs:
> Attribute `mallo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #18 from Sam James ---
That's exactly where I saw it ;)
I go over bugs marked as needs-reduction/wrong-code/needs-bisection often, but
this bug wasn't marked as those, so I didn't see it. WAITING means we need the
reporter to give u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #16 from Sam James ---
(In reply to Gavin Howard from comment #0)
> [1]:
> https://git.yzena.com/Yzena/Yc/src/commit/
> 6afdc86bd2c17f98b2f9e97e79e37fdf8c6b7708/src/alloc/stackpool.c#L441
>
> [2]:
> https://git.yzena.com/Yzena/Yc/sr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
--- Comment #5 from John Platts ---
GCC also fails to optimize (a | b) - ((a ^ b) >> 1) down to a single SSE2
PAVGB/PAVGW, NEON/SVE2 SRHADD/URHADD, AltiVec
vavgsb/vavgsh/vavgsw/vavgub/vavguh/vavguw instruction where supported on the
target, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #15 from Andrew Pinski ---
void*
y_realloc(void* ptr, y_usize size) __attribute__((malloc));
Yes that should NOT be malloc.
I wonder if removing malloc from y_realloc fixes the issue.
NOTE realloc is not marked as malloc.
See th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99829
Sam James changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
Sam James changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #14 from Sam James ---
Hm, dropping the attribute everywhere doesn't help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #11 from Sam James ---
It still aborts with -O1 -fno-strict-aliasing (just to be sure, though -O1
shouldn't need it). It passes with -O1 -fno-tree-pta.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #13 from Sam James ---
(In reply to Sam James from comment #12)
> I suspect this is abuse of __attribute__((malloc)).
y_stackpool_malloc returns a value derived from input `p`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #12 from Sam James ---
I suspect this is abuse of __attribute__((malloc)).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Sam James changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #14 from Maxim Egorushkin ---
(In reply to Andrew Pinski from comment #6)
> It happens more often with vector instructions/registers due to the
> different "modes" of the registers that it can hold (subregs).
That's right, my empir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119007
Jin Ma changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |majin at gcc dot gnu.org
Ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119007
Bug ID: 119007
Summary: RISC-V: The optimization ignored the side effects of
the rounding mode, resulting in incorrect results for
rvv
Product: gcc
Version: 15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89967
--- Comment #6 from Andrew Pinski ---
So the main thing that needs to be handled is:
```
# .MEM_144 = VDEF <.MEM_143>
g2b = D.23244;
# VUSE <.MEM_144>
_29 = g1b.val[0];
g1v_73 = VIEW_CONVERT_EXPR(_29);
# VUSE <.MEM_144>
_30 = g1b.va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118944
--- Comment #3 from waffl3x ---
(In reply to Patrick Palka from comment #1)
> Confirmed. This bug also affects ordinary static member functions:
>
Nice, good find.
(In reply to Patrick Palka from comment #2)
> > As far as I know, these functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
--- Comment #7 from Sam James ---
Bisecting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.5
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #9 from Hongtao Liu ---
(In reply to H.J. Lu from comment #8)
> (In reply to Richard Biener from comment #7)
>
> >
> > >else if (targetm.small_register_classes_for_mode_p (GET_MODE (x)))
> > > record = false;
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Andrew Pinski changed:
What|Removed |Added
Attachment #60579|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
--- Comment #4 from Andrew Pinski ---
Created attachment 60579
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60579&action=edit
Runtime testcase
Fails with `-O2 -g0 -fwhole-program` but works without -fwhole-program. So no
need for LTO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
--- Comment #3 from Andrew Pinski ---
Your source does not work either:
FixedString(const char* str_) { *this = str_; }
Is an infinite loop.
It should be:
FixedString(const char* str_) { __builtin_strcpy (this->_str, str_); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
--- Comment #2 from Jeff Snyder ---
Further simplified:
template struct FixedString {
bool operator==(const char* rhs_) const { return rhs_ and not
__builtin_strcmp(_str, rhs_); }
bool operator!=(const char* rhs_) const { return !(*this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118991
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Bug ID: 119006
Summary: IPA ICF and LTO cause strcmp condition to be omitted
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #13 from Maxim Egorushkin ---
(In reply to Andrew Pinski from comment #11)
> Let me try again:
>
> So we have:
> __v4di v4 = ymm0
> __v2di tmp = _mm256_extracti128_si256(v4, 1); // vextracti128
> __v2di tmp1 = _mm256_castsi256_si128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19831
--- Comment #24 from Andrew Pinski ---
(In reply to Marc Glisse from comment #16)
> Some more transformations for the list:
>
> p = malloc (n);
> memcpy (p, q, m);
> free (q);
>
> ==>
>
> p = realloc (q, n);
>
> it isn't equivalent, in partic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
--- Comment #8 from Edwin Lu ---
(In reply to Robin Dapp from comment #7)
> Hmm, I don't fully understand. We're actually building with zvl256b right,
> zvl1024b is first and thus gets overridden? But with zvl256b and QEMU
> vlen=256 I'm not s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118595
--- Comment #2 from Robin Dapp ---
Hmm I'm not seeing those locally with -march=rv64gcv_zvl256b at least. Which
exact options were used to run the test suite? Or have those fails disappeared
in the meanwhile?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118947
--- Comment #5 from Andrew Pinski ---
Created attachment 60578
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60578&action=edit
Patch which I am testing for the aliasing improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #4 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005
--- Comment #3 from Alejandro Colomar ---
Hmmm, thinking twice, I guess it is not a false positive. I can rewrite to
something similar, which avoids the overflow, and avoids the diagnostic:
alx@debian:~/tmp$ cat foo.c
#include
int
f(void)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005
Alejandro Colomar changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #2 from Alejandro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119002
--- Comment #3 from Jakub Jelinek ---
Perhaps without looking at the setter, it could:
/* See whether the operands might be unordered. */
if (HONOR_NANS (GET_MODE (XEXP (op0, 0
all = 15;
else if (!flag_finite_math_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005
Bug ID: 119005
Summary: -Wstrict-overflow=3 false positive with static
variable
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
--- Comment #7 from Vineet Gupta ---
I can confirm that it is happening due to following hunk from
r15-5943-gdc0dea98c96e02
bool
ssa_is_replaceable_p (gimple *stmt)
{
if (!is_gimple_assign (stmt))
#if 0
&& (!(call = dyn_cast (stmt))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119004
Bug ID: 119004
Summary: Inconsistent set of flags to trigger -Wstrict-overflow
diagnostics
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119003
Bug ID: 119003
Summary: walk_aliased_vdefs and others are missing a comment in
the front of it descriping what it does
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
Vineet Gupta changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114088
--- Comment #5 from Thiago Macieira ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Xi Ruoyao from comment #2)
> > But __builtin_strlen *does* get optimized when the input is a string
> > literal.
>
> But so does strlen, becaus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #7)
> From the 2023 standard I find:
>
> "The keyword INTEGER with no kind-selector specifies type integer with
> default kind; the kind type parameter val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119002
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
--- Comment #12 from Luke Robison ---
Tamar,
I'm happy to test as many flags as you can think of, just send them my way.
See below for detailed results, but I see that -fdisable-tree-cunroll does not
fix the problem, and I suspect that -march=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119002
--- Comment #1 from Jakub Jelinek ---
During combine it just folds
(set (reg:SI 134)
(ior:SI (ge:SI (reg:CCFP 128)
(const_int 0 [0]))
(lt:SI (reg:CCFP 128)
(const_int 0 [0]
into
(set (reg:SI 134) (const_in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
--- Comment #7 from Jerry DeLisle ---
>From the 2023 standard I find:
"The keyword INTEGER with no kind-selector specifies type integer with default
kind; the kind type parameter value is equal to KIND (0). The decimal exponent
range of default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119002
Bug ID: 119002
Summary: [15 Regression] Comparison miscompilation on ppc64le
and s390x since r15-6777
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119002
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Biener from comment #2)
> Sounds reasonable, note the vectorizer has a pattern for this already. The
> issue with match.pd patterns is when we want to introduce those internal fns
> (la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119001
Marek Polacek changed:
What|Removed |Added
Keywords|needs-bisection |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119001
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Summary|ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119001
Bug ID: 119001
Summary: ICE: in output_constructor_regular_field, at
varasm.cc:5833
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118997
--- Comment #8 from Jakub Jelinek ---
The documentation is fairly clear that it affects that:
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
Although the size of a zero-length array is zero, an array member of this kind
may increase the siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118997
--- Comment #7 from Vincenzo Romano ---
Quoting from "6.18 Arrays of Length Zero"
> Declaring zero-length arrays is allowed in GNU C as an extension.
I would say that under GNU C it is an extension.
Or that the documentation needs some review
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118944
--- Comment #2 from Patrick Palka ---
> As far as I know, these functions shouldn't even be being instantiated yet,
> yet they appear to be.
It's not required by the standard, but GCC checks non-dependent expressions
ahead of time in order to p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119000
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118944
Patrick Palka changed:
What|Removed |Added
Known to work||8.5.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118986
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118876
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #12 from Wilco ---
(In reply to Richard Biener from comment #9)
> I have also always wondered about that glibc guard, esp. it being the
> kitchen-sink fast-math guard rather than sth more specific (yep, we don't
> have anything for -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #11 from Wilco ---
(In reply to Andrew Pinski from comment #8)
> Though accessing the errno from fortran is almost never done anyways so I
> doubt that will matter here.
The issue is that fast-math is the combination of many differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118986
Patrick Palka changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
Robin Dapp changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116773
Bug 116773 depends on bug 114516, which changed state.
Bug 114516 Summary: RISC-V: TSVC2 s315 has spill with dynamic lmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114516
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114516
Robin Dapp changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114516
--- Comment #2 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:6be1b9e94d9a2ead15e3625e833f1e34503ab803
commit r15-7688-g6be1b9e94d9a2ead15e3625e833f1e34503ab803
Author: Robin Dapp
Date: Fri Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #8 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:f3d4208e798afafcba5246334004e9646e390681
commit r15-7687-gf3d4208e798afafcba5246334004e9646e390681
Author: Robin Dapp
Date: Fri Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114516
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2025-02-24
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #26 from Jonathan Wakely ---
I think I should push the partial solution now anyway. It's better than what we
do today, as at least it will work correctly for programs that don't initialize
an atomic in C++11 objects and then use CAS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119000
Bug ID: 119000
Summary: [OpenMP] Function parameter incorrectly reported as
set but not used.
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Keywords: diagno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118997
--- Comment #6 from Jonathan Wakely ---
You don't even need the 'two' member to get the same effect:
typedef struct _test {
_Alignas(long double) void* one;
} _test;
If the structure has to be aligned, then you will get padding after the 'on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118997
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118876
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118999
Bug ID: 118999
Summary: AArch64: Switching off early scheduling causes
regressions in Snappy workload for -mcpu=neoverse-v2
Product: gcc
Version: 15.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118997
--- Comment #4 from Vincenzo Romano ---
I think that an explicit statement in the documentation should be added, then.
After all the zero-sized array field is both an extension (thus not in the
standard manual) and a special case within the exte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118997
--- Comment #3 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> Your expectations are wrong.
> If sizeof(void*) == 8 and alignof(long double) == 16, then padding needs to
> be inserted
> before the two member such that it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118997
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
1 - 100 of 155 matches
Mail list logo
