https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109534
Bug ID: 109534
Summary: -fdirectives-only does not work with
assembler-with-cpp
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622
--- Comment #12 from Wilhelm M ---
(In reply to Wilhelm M from comment #11)
> Without an underlying type but with -fshort-enums the underlying type should
> be as small as possible. In this case this should be a uint8_t. But in this
> case we ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #15 from Richard Biener ---
(In reply to Richard Smith from comment #14)
> If I understand correctly, you're looking for documentation that
>
> __builtin_operator_new(size)
>
> has the exact same semantics and permits the same op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109531
--- Comment #5 from Andrew Pinski ---
>'g++-13 -O2 -Wall -c ArithmeticSubtermGeneralization.ii' is enough to
>reproduce.
Interesting because it was not for me, but I noticed that removing all of the
lines that begin with "#" is able to reprodu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109504
--- Comment #6 from Hongtao.liu ---
(In reply to Jakub Jelinek from comment #4)
> Yeah. Enable all the time and have say the
> targetm.invalid_conversion, targetm.invalid_unary_op,
> targetm.invalid_binary_op
> and something in argument/return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109533
Bug ID: 109533
Summary: Build failure with upcoming musl release
(sanitizer_platform_limits_posix.cpp:182:31: error:
invalid application of 'sizeof' to incomplete type
Hi @Andrew Pinski
>Note libstdc++ does ABI changes too which is NOT part of that ABI design.
>This is where the symbol
>__gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So any
>changes you might do to fix __gthrw_pthread_cond_timedwait is not really going
>to work >without wider
On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via
Gcc-bugs wrote:
>
>
> ++
> From: Puneet Kumar Yatnal (QUIC)
> Sent: Monday, April 17, 2023 9:26 AM
> To: gcc-h...@gcc.gnu.org
> Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has impact
> on time values
First gcc-b
++
From: Puneet Kumar Yatnal (QUIC)
Sent: Monday, April 17, 2023 9:26 AM
To: gcc-h...@gcc.gnu.org
Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has impact on
time values
All
if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for Y2038
fix(where all timer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532
--- Comment #5 from Wilhelm M ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Wilhelm M from comment #3)
> > Isn't this a case where the as-if rule kicks in?
>
> What rule is that? Scopped enums are different from unscopped ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532
--- Comment #4 from Andrew Pinski ---
(In reply to Wilhelm M from comment #3)
> Isn't this a case where the as-if rule kicks in?
What rule is that? Scopped enums are different from unscopped ones here
specifically as defined in the C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109531
--- Comment #4 from Andrew Pinski ---
Anyways I am trying to reduce this using delta with a script which tests if it
passes no options (except -Wfatal-errors to speed up the testing); that should
reduce it to a valid testcase I hope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532
--- Comment #3 from Wilhelm M ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > That is because a scopped enum has an underlying type of int if not
> > supplied.
> >
> > From [dcl.enum]/5:
> > Fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109531
--- Comment #3 from Andrew Pinski ---
I almost want to say there is some GC issue going on with the original
testcase.
When I tried to use topformflat with the source (with all the "^# " lines
removed), it no longer ICEs. But then again I did ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> That is because a scopped enum has an underlying type of int if not supplied.
>
> From [dcl.enum]/5:
> For a scoped enumeration type, the underlying type is int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532
Bug ID: 109532
Summary: -fshort-enums does not pick smallest underlying type
for scoped enum
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109531
--- Comment #2 from Andrew Pinski ---
command line that in the end needed to reproduce with the original non-reduced
testcase:
-std=c++14 -march=znver3 -O2 -fno-strict-aliasing -Wall
Note you need all of those options to get the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109489
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91440
David Fong changed:
What|Removed |Added
CC||davidfong19 at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109489
Fangrui Song changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109531
--- Comment #1 from Sam James ---
Created attachment 54873
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54873&action=edit
invalid_reduction.ii
meh, the reduction cvise just finished with is invalid, but it does trigger the
ICE still. I'
vampire-2d02e4655e1b08d1ca9ee7c0aade40f59f046460/Lib/Metaiterators.hpp:1787:19:
internal compiler error: in hashtab_chk_error, at hash-table.cc:137
1787 | Container collect()
| ^~~
0x18f8915 hashtab_chk_error()
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108809
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jiu Fu Guo :
https://gcc.gnu.org/g:a1f25e04b8d10bbe5dcaf98bb7e17cdaec9f169d
commit r13-7202-ga1f25e04b8d10bbe5dcaf98bb7e17cdaec9f169d
Author: Jiufu Guo
Date: Fri Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81745
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81745
--- Comment #12 from Sam James ---
(In reply to Sam James from comment #11)
> C99 seems to explicitly say, within Clause J.2, in the second bullet point:
This seems to be in C23 still.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81745
--- Comment #11 from Sam James ---
C99 seems to explicitly say, within Clause J.2, in the second bullet point:
>
>1 The behavior is undefined in the following circumstances:
>
>[...]
>A nonempty source file does not end in a new-line char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100297
--- Comment #3 from Andreas Schwab ---
"\.data" is the same as ".data", you want either "\\.data" or {\.data}. But it
still doesn't lower the probability to match a filename by much.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622
--- Comment #11 from Wilhelm M ---
Without an underlying type but with -fshort-enums the underlying type should be
as small as possible. In this case this should be a uint8_t. But in this case
we get a 16-bit value for mState. This is a clear vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100297
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83904
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109280
--- Comment #3 from Georg-Johann Lay ---
Could you check against avr-gcc v12.3 just to make sure you didn't hit PR90706
(which affects all versiond from v9 to v12.2).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #9 from anlauf at gcc dot gnu.org ---
The following patch rejects the code in comment#0 and regtests ok:
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index e9843e9549c..64a54c06800 100644
--- a/gcc/fortran/interfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
--- Comment #9 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:dd2cd1e70509aaeb3db3e7b322d8357bac817632
commit r10-11289-gdd2cd1e70509aaeb3db3e7b322d8357bac817632
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:dfcdb457c462b9e35eb54d3b758221a119067e24
commit r11-10625-gdfcdb457c462b9e35eb54d3b758221a119067e24
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #14 from Richard Smith
---
If I understand correctly, you're looking for documentation that
__builtin_operator_new(size)
has the exact same semantics and permits the same optimizations as `::new T`
for a trivially-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109424
Andrew Pinski changed:
What|Removed |Added
Depends on||59424
--- Comment #4 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105804
Alfred Agrell changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66511
Wilhelm M changed:
What|Removed |Added
CC||klaus.doldinger64@googlemai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109525
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109508
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109508
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:a647198fcf7463a42c8e035a429200e7998735dc
commit r13-7198-ga647198fcf7463a42c8e035a429200e7998735dc
Author: Jeff Law
Date: Sun Apr 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66511
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816
Roger Sayle changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816
--- Comment #4 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:f006d1a5a1e136be29c78b96c8742ebd3710f4d0
commit r13-7197-gf006d1a5a1e136be29c78b96c8742ebd3710f4d0
Author: Roger Sayle
Date: Sun Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529
--- Comment #7 from Lisp2D ---
.. or
int volatile && rx = static_cast < int volatile && > ( x ) ;
fun(rx);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557
--- Comment #5 from Federico Kircheis ---
Today I just found a possible workaround that involves macros and lambdas...
struct node {
const char* d;
const node& left;
};
#define LEAF(a) []()-> const node&{ constexpr static auto a =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529
--- Comment #6 from Lisp2D ---
(In reply to Andrew Pinski from comment #4)
> https://stackoverflow.com/questions/40193008/why-a-const-volatile-reference-
stackoverflow offers to link an rvalue reference to a variable for this. But I
think this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529
--- Comment #5 from Andrew Pinski ---
Basically [dcl.init.ref]/5 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #5 from Bálint Aradi ---
I also think that by allowing for explicit EORs caused by achar(10) characters
in the variable being written or by explicit new_line() calls, the standard
made the formatted stream output probably more compli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529
--- Comment #4 from Andrew Pinski ---
https://stackoverflow.com/questions/40193008/why-a-const-volatile-reference-cannot-be-bound-to-an-rvalue-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529
--- Comment #3 from Lisp2D ---
(In reply to Andrew Pinski from comment #2)
> Since `static_cast(x)` is considered rvalue and `int
I can't find a reason anywhere in the standard why the volatile property
prevents conversion from `&&` to `const &`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109530
--- Comment #2 from Andreas Schwab ---
It also doesn't see that setjmp()==0 means that the block is not reached a
second time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494
--- Comment #12 from Oliver Rosten ---
Yes, I am aware that I homebrewed gcc. What I don't understand is the
extent to which this a homebrew problem and not a gcc problem. Forgive my
ignorance but I would like to understand what submitting this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109530
--- Comment #1 from Andrew Pinski ---
The warning is confusing but it is partly correct.
Across a setjmp, you might need volatile variables.
Gcc does not know that fprintf nor fclose will call longjmp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109521
--- Comment #4 from Sam James ---
Note that it's also missing the 'internal compiler error' message in the
output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109530
Bug ID: 109530
Summary: Warning "is used uninitialized" raised for an
initialized variable.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
58 matches
Mail list logo
