https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120889
Andre Vehreschild changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120495
LIU Hao changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120495
--- Comment #5 from Iain Sandoe ---
this was reported against GCC-15.1 - I was expecting to back-port for 15.2, so
perhaps re-open so that it does not get forgotten?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88853
--- Comment #6 from David Binderman ---
For this C++ code:
cvise $ more bug1108.cc
template
constexpr bool is_trivially_destructible_v = __is_trivially_destructible(_Tp);
template struct _Traits {
static constexpr bool _S_trivial_dtor =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120495
LIU Hao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
--- Comment #8 from Florian Weimer ---
There's this big comment in typeinfo:
// Determine whether typeinfo names for the same type are merged (in which
// case comparison can just compare pointers) or not (in which case strings
// must be compar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120709
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:be07dd9a96a7a6f8fb59c939eda84d74b54f8182
commit r16-2044-gbe07dd9a96a7a6f8fb59c939eda84d74b54f8182
Author: Andrew Pinski
Date: Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120709
Andrew Pinski changed:
What|Removed |Added
Summary|[15/16 Regression] ICE in |[15 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
--- Comment #3 from Tomasz Kamiński ---
I have posted this patch in May, that will fix the issue:
https://gcc.gnu.org/pipermail/libstdc++/2025-May/061450.html
I think we should merge it.
The only architecture where __float128 exists and is diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980
--- Comment #1 from Tamar Christina ---
I'm not sure that I'd draw the same conclusion. I view it as the vectorizer has
put a 32-byte alignment requirement on the object and so I'd consider the
object itself to be 32-bytes sized.
So to the not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 118241, which changed state.
Bug 118241 Summary: RISC-V ICE: internal compiler error: in int_mode_for_mode,
at stor-layout.cc:407 caused by prefetch instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118241
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #26 from Segher Boessenkool ---
(In reply to chenglulu from comment #25)
> > And if the input is non-sensical, the compiler output will be as well, or
> > the
> > compiler can give up in some cases.
> >
> I also don't quite agree t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #25 from chenglulu ---
(In reply to Segher Boessenkool from comment #24)
> (In reply to Xi Ruoyao from comment #21)
> > (In reply to Segher Boessenkool from comment #20)
> > > (In reply to Peter Bergner from comment #17)
> > > > The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120983
--- Comment #6 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #4)
> Oh look:
> /* Both the earlyclobber operand and conflicting operand
>cannot both be user defined hard registers. */
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120983
--- Comment #5 from Andrew Pinski ---
gcc.target/loongarch/bitwise-shift-reassoc-clobber.c:
```
/* { dg-do run } */
/* { dg-options "-O2" } */
register long x asm ("s0");
#define TEST(x) (int)(((x & 0x114) << 3) + x)
[[gnu::noipa]] void
test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120983
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120983
--- Comment #3 from Segher Boessenkool ---
Please attach a testcase, and how to compile the code (-O2 etc.). Oh, and fill
in
the target field :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120983
Andrew Pinski changed:
What|Removed |Added
Keywords||ra
--- Comment #2 from Andrew Pinski -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120983
--- Comment #1 from Andrew Pinski ---
So the problem is before reload only the predicates are used and not the
constraints. The early clobbered is never looked at.
I wonder why IRA could not generate a reload here though since it could push
(re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #24 from Segher Boessenkool ---
(In reply to Xi Ruoyao from comment #21)
> (In reply to Segher Boessenkool from comment #20)
> > (In reply to Peter Bergner from comment #17)
> > > The reason operands 0, 1 and 4 all use the register r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #23 from Segher Boessenkool ---
It is a different target. Your issue has nothing at all to do with the
problem we used to have. The root cause is very likely completely unrelated.
Etc. etc. etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
Xi Ruoyao changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120983
Bug ID: 120983
Summary: recog violates earlyclobber with user-defined hard
register before reload (causing ICE on
gcc.target/loongarch/bitwise-shift-reassoc-clobber.c)
Prod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #21 from Xi Ruoyao ---
(In reply to Segher Boessenkool from comment #20)
> (In reply to Peter Bergner from comment #17)
> > The reason operands 0, 1 and 4 all use the register r23, is that each
> > operand is using the same pseudo, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120982
Bug ID: 120982
Summary: Incorrect alignment after vectorization
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120981
Bug ID: 120981
Summary: Vectorizer introduces UB address calculation
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #20 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #17)
> The reason operands 0, 1 and 4 all use the register r23, is that each
> operand is using the same pseudo, coming from variable "x", which is a user
> defi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #19 from Segher Boessenkool ---
Hi Peter!
(In reply to Peter Bergner from comment #18)
> So the error message is coming from this hunk in my patch:
>
> + /* Both the earlyclobber operand and conflicting operand
> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #18 from Peter Bergner ---
(In reply to Xi Ruoyao from comment #13)
> I'm almost sure this is causing
> gcc.target/loongarch/bitwise-shift-reassoc-clobber.c ICE in GCC 16:
>
> bitwise-shift-reassoc-clobber.c:12:1: error: unable to g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980
Bug ID: 120980
Summary: Vectorizer introduces out-of-bounds memory access
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
--- Comment #8 from Halalaluyafail3 ---
(In reply to Andrew Pinski from comment #6)
> Because otherwise it would mean:
> ```
> [[ignored(
> #)]]int main(){}
> ```
>
> Would be invalid C while:
> ```
> [[ignored(#)]]int main(){}
> ```
>
> Would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #17 from Peter Bergner ---
(In reply to Xi Ruoyao from comment #15)
> The problem is operand 4 does not have "0", and it's also assigned the hard
> register r23. It's fine for operand 0 and 1 to be the same, also for
> operand 1 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120979
--- Comment #3 from Andrew Pinski ---
Also as I mentioned xstrdup is not linked at all to the normal strdup (it is a
wrapper around strdup which will error out [and exit] if strdup returns NULL).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120979
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Note xstrdup is not the same as strdup ...
>
> ```
> char *a()
> {
> return __builtin_strdump ("");
Sorry typo, __builtin_strdup.
> }
> ```
>
> Would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120979
--- Comment #1 from Andrew Pinski ---
Note xstrdup is not the same as strdup ...
```
char *a()
{
return __builtin_strdump ("");
}
```
Would need to be changed into:
```
char *a()
{
const char tt[] = "";
char *t = __builtin_mallo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120979
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120979
Bug ID: 120979
Summary: Missed strdup to malloc + memcpy for known strings
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
--- Comment #6 from Andrew Pinski ---
The way I read the standard is the following:
during phase 4:
Preprocessing directives are executed,
And it is invalid for `#` or the `##` operator to be outside of `the
replacement list of a function-like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
--- Comment #5 from Andrew Pinski ---
(In reply to Halalaluyafail3 from comment #4)
> They are only considered operators during macro expansion. The standard
> provides the following example:
>
> > #define hash_hash # ## #
> > #define mkstr(a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
--- Comment #4 from Halalaluyafail3 ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > The C23 spec says:
> > any token other than a parenthesis, a bracket, or a brace
> >
> > But # is not a token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> The C23 spec says:
> any token other than a parenthesis, a bracket, or a brace
>
> But # is not a token in C; it is only a preprocessor token ...
I was wrong t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
--- Comment #2 from Andrew Pinski ---
The C23 spec says:
any token other than a parenthesis, a bracket, or a brace
But # is not a token in C; it is only a preprocessor token ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
--- Comment #1 from Andrew Pinski ---
MSVC also rejects this:
(1): error C2014: preprocessor command must start as first nonwhite
space
(1): error C2958: the left '[[' found at '(1)' was not matched
correctly
EDG also rejects this:
"", line 1:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
Bug ID: 120978
Summary: Punctuators that contain # or %: are incorrectly
rejected within attributes
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109934
--- Comment #9 from Sam James ---
(In reply to Fangrui Song from comment #8)
> I am curious when the regression started to happen.
I think it's probably the same as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117100#c1 (it got broken by a
back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109934
Fangrui Song changed:
What|Removed |Added
CC||maskray at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
--- Comment #1 from John David Anglin ---
I would have thought __float128 and long double should have been the same
on this target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120977
Andrew Pinski changed:
What|Removed |Added
Target||arm
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120977
Bug ID: 120977
Summary: [16 Regression] ICE on Cortex-M23/M33/M55/M85 with
-mcmse
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119920
--- Comment #5 from Andrew Pinski ---
(In reply to Alfie Richards from comment #4)
> Ah okay great, I'll shelve this for now and check back later.
I am going to start working on this today. I should have a prototype by the end
of this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #6 from fiesh at zefix dot tv ---
Alas, running `avr-size` on the individual modules doesn't produce anything of
significant data size. They also don't add up even remotely to the final
linked file. Am I doing something wrong?
I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120709
--- Comment #5 from Andrew Pinski ---
Created attachment 61809
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61809&action=edit
Patch which I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
Bug ID: 120976
Summary: error: static_assert( !is_same_v<__float128, long
double> failed
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #12 from Tamar Christina ---
Looks like the problem is that during ao_ref_init_from_ptr_and_range when
initializing vectp_target.14_54 = &targetD.4595 + _55;
we don't enter the block splitting apart POINTER_PLUS_EXPR.
So it ends up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430
--- Comment #13 from Alexandre Oliva ---
I'm not sure how to tell, but the fact that it has an lto-related symbolic name
suggested to me it was generated by the compiler rather than by the linker:
__sinput__get_source_file_index__assertions.0.lt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120975
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105699
Andrew Pinski changed:
What|Removed |Added
CC||ykakeyama3014 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120975
Bug ID: 120975
Summary: GCC incorrectly accepts requires-clause for virtual
functions
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #11 from Tamar Christina ---
(In reply to Richard Biener from comment #10)
> (In reply to Tamar Christina from comment #8)
> > C testcase
> >
> > typedef struct {
> > int _M_current;
> > } __normal_iterator;
> >
> > typedef str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120973
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|middle-end
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120973
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120951
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120951
--- Comment #11 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:e17e3de4bbb1848ce1ce7d69d7786b92f1969b11
commit r16-2039-ge17e3de4bbb1848ce1ce7d69d7786b92f1969b11
Author: Andrew Pinski
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057
Bug 101057 depends on bug 120921, which changed state.
Bug 120921 Summary: gimple verifier (and gimple FE) accepts CST on LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120921
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120921
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |16.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120921
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:5c2dc85c1923af118a9ec9657dc969fd3d95498a
commit r16-2038-g5c2dc85c1923af118a9ec9657dc969fd3d95498a
Author: Andrew Pinski
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #3 from Tamar Christina ---
before the bounds variable didn't have any range attached to it.
e.g.
bnd.704_180 = _181 - _132;
but now it shows
# RANGE [irange] unsigned int [1, 2147483647]
bnd.704_180 = _181 - _132;
For some reas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120959
Tamar Christina changed:
What|Removed |Added
Assignee|tnfchris at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120973
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120974
Bug ID: 120974
Summary: Default -fdeps-file and -fdeps-target arguments don't
support output directories with spaces
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120973
Bug ID: 120973
Summary: ICE on x86_64-linux-gnu: verify_flow_info failed with
naked attribute: wrong insn in the fallthru edge
Product: gcc
Version: 16.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #5 from fiesh at zefix dot tv ---
Ah of course, sizing individual object files might make it much easier. Thank
you, I think I'll be able to create a proper testcase this way. I'll get back
to here when I've reduced it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120972
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120972
Bug ID: 120972
Summary: restrict does not work for not-parameter pointer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #12 from Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569
--- Comment #12 from Jonathan Wakely ---
That's why the bug is still open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120971
Bug ID: 120971
Summary: ICE on x86_64-linux-gnu: in omp_extract_for_data, at
omp-general.cc:423
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120970
Bug ID: 120970
Summary: -static-pie together with -fsanitize=address should be
disallowed
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
82 matches
Mail list logo
