https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107024
Bug ID: 107024
Summary: ICE in finish_expr_stmt, at cp/semantics.cc:872
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106939
--- Comment #8 from Arseny Vakhrushev ---
Thank you, Jakub! I have read that section and can see that the Standard is
just very cautious about the cases it doesn't cover labeling them as "undefined
behaviour". The most likely reason is memory se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91456
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:71c828f84572d933979468baf2cf744180258ee4
commit r13-2825-g71c828f84572d933979468baf2cf744180258ee4
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107023
Bug ID: 107023
Summary: [[gnu::stdcall]] Crashes the compiler, but
__attribute__((stdcall)) and __stdcall worrks
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107022
--- Comment #6 from Andrew Pinski ---
(In reply to piersh from comment #4)
> struct my_hash
> {
> my_hash() {}
> my_hash(int i = 42) {} // <<-- uncomment for bug
> std::size_t operator()(const key &ep) const { return 0; }
> };
That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107022
--- Comment #5 from piersh at hotmail dot com ---
oh, no. scratch that last comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107022
--- Comment #4 from piersh at hotmail dot com ---
is it related to nested classes? this reproduces the issue: uncomment line 9 to
repro:
#include
#include
struct key {};
struct my_hash
{
my_hash() {}
//my_hash(int i = 42) {} // <<-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107022
--- Comment #3 from Jonathan Wakely ---
Yes, and the standard says that instantiating std::unordered_map with
incomplete types is undefined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107022
--- Comment #2 from Andrew Pinski ---
Mainly read bug 102199 comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107022
--- Comment #1 from Andrew Pinski ---
This is another when is the inner type complete and the constructor can be used
issues really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107022
Bug ID: 107022
Summary: error: use of deleted function 'std::unordered_map
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021
--- Comment #2 from Andrew Pinski ---
You need -fno-finite-math-only now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437
--- Comment #18 from Pavel M ---
(In reply to Jonathan Wakely from comment #17)
> (In reply to Josh Triplett from comment #5)
> > I'd like to see this as well. While issuing such a warning by default would
> > cause numerous warnings with existi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021
--- Comment #1 from Martin Liška ---
Btw. since the same revision fails TSVC's s1281 w/ -march=znver2 -Ofast. Maybe
it will be smaller reproducer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021
Bug ID: 107021
Summary: [13 Regression] 511.povray_r error with -Ofast
-march=znver2 -flto since r13-2810-gb7fd7fb5011106
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106945
--- Comment #3 from anlauf at gcc dot gnu.org ---
It is -fcheck=bounds that is required to trigger the failure.
Replacing -ftrapv by -fsanitize=undefined produces the same error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #16 from Martin Liška ---
(In reply to andi from comment #15)
> > Provided I cannot reproduce on the current kernel, where exactly does this
> > come
> > from?
>
> Usually I had to do a longer loop of randconfig builds to find it. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107020
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101978
--- Comment #10 from Jonathan Wakely ---
We even have tests for the bogus tsan errors:
g++.dg/tsan/pthread_cond_clockwait.C
(which fails on machines with an old glibc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106982
--- Comment #1 from Tobias Burnus ---
Submitted patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602138.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #15 from andi at firstfloor dot org ---
> Provided I cannot reproduce on the current kernel, where exactly does this
> come
> from?
Usually I had to do a longer loop of randconfig builds to find it. It only
happens in some specific c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
--- Comment #7 from Aldy Hernandez ---
Created attachment 53622
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53622&action=edit
DOM patch in testing to calculate ranges for all ranges involving unreachable
edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
--- Comment #6 from Aldy Hernandez ---
Created attachment 53621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53621&action=edit
bitwise and op1_range patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
--- Comment #5 from Aldy Hernandez ---
There are two things needed to fix this regression.
First, we need an op1_range entry for bitwise-and, so that the 2->4 edge range
has the correct nonzero bits for n_12.
[local count: 118111600]:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101978
--- Comment #9 from Jonathan Wakely ---
The new interceptor was merged as g:d0fee87e0ce24f066cde3dbf9605abce24dd75e1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101978
--- Comment #8 from Jakob Weisblat ---
@Andrew: (In reply to Andrew Pinski from comment #7)
Thanks! I'll try upgrading to GCC 12 to see if my issues go away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101978
--- Comment #7 from Andrew Pinski ---
(In reply to Jakob Weisblat from comment #6)
> I think this is the same issue as
> https://github.com/google/sanitizers/issues/1259.
>
> It was fixed in clang at
> https://github.com/llvm/llvm-project/comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107020
--- Comment #1 from Tobias Burnus ---
Fails with GCC 11 to compile with:
input1.ii:10:18: error: ‘main_devPtr’ referenced in target region does not
have a mappable type
Gives an ICE with GCC 12 (+ mainline). Thus, it is a p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107020
Bug ID: 107020
Summary: [OpenMP][UBSAN] ICE during GIMPLE pass: sanopt via
ubsan_expand_vptr_ifn: "output_operand: invalid
expression as operand"
Product: gcc
Ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88804
Andrew Pinski changed:
What|Removed |Added
CC||gccbugbjorn at fahller dot se
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96400
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88804
Andrew Pinski changed:
What|Removed |Added
CC||cuzdav at gmail dot com
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105571
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88804
Andrew Pinski changed:
What|Removed |Added
Summary|Inconsistently diagnosed|incorrect unused but set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88804
Andrew Pinski changed:
What|Removed |Added
CC||mario at klebsch dot de
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107019
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106784
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106784
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:8a7bcf95a82c3dd68bd4bcfbd8432eb970575bc2
commit r13-2822-g8a7bcf95a82c3dd68bd4bcfbd8432eb970575bc2
Author: Marek Polacek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96400
Andrew Pinski changed:
What|Removed |Added
CC||johelegp at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105743
--- Comment #2 from Andrew Pinski ---
Actually this is a dup of bug 96400.
*** This bug has been marked as a duplicate of bug 96400 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102310
--- Comment #8 from Thomas Schwinge ---
I found that the '-O2' ICE 'during IPA pass: cp' originally reported here as
well as the '-O0' ICE 'during RTL pass: expand' do disappear with Julian's
recent r13-2665-g23baa717c991d77f206a9358ce2c04960ccf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107019
Mario Klebsch changed:
What|Removed |Added
CC||mario at klebsch dot de
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107019
Bug ID: 107019
Summary: -Wunused-but-set-variable false positive for static
variable in lambda with boost
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101978
Jakob Weisblat changed:
What|Removed |Added
CC||jakob.weisblat at zoom dot us
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #22 from Jan Žižka ---
Great, our production code builds just fine with
af611afe5fcc908a6678b5b205fb5af7d64fbcb2 :-) thanks a lot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> # RANGE [irange] size_t [1, +INF]
> size_t n_12(D) = n;
>
> the nonzero bits info on 'n' is gone. DOM2 used to produce that and
> CCP3 elides the __built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107018
Bug ID: 107018
Summary: [13 Regression] libgcc unwind-dw2-fde references
undeclared variable
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501
--- Comment #9 from Roy Jacobson ---
Thanks for the patch! I wonder if it would handle coroutines correctly. Clang
has this open bug https://github.com/llvm/llvm-project/issues/47179 that is
related to this optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839
--- Comment #11 from Jonathan Wakely ---
(In reply to Paolo Carlini from comment #8)
> about the other compilers? For sure some are following the current gcc
> behaviour, for compatibility, I suspect ICC for example. Should we also have
> a comma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #21 from Richard Biener ---
try again!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #20 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:af611afe5fcc908a6678b5b205fb5af7d64fbcb2
commit r13-2817-gaf611afe5fcc908a6678b5b205fb5af7d64fbcb2
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107017
Bug ID: 107017
Summary: RFE: support printf-style formatted functions in
-fanalyzer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107012
--- Comment #2 from Jakub Jelinek ---
I don't see anything wrong on what GCC emits.
If I compile with -O3 -g3 -gdwarf-4 -dA -nostdinc so that stdc-predef.h isn't
included vs. -O3 -g3 -gdwarf-5 -dA -nostdinc, in .debug_macro I see for DWARF
4:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107016
Bug ID: 107016
Summary: [meta-bug] tracker bug for supporting "sparse"
attributes in GCC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: meta-bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107001
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=106922
--- Comment #19 from Richard Biener ---
(In reply to Jan Žižka from comment #18)
> Created attachment 53617 [details]
> Third reproducer failing with 9baee6181b4e427e0b5ba417e51424c15858dce7
>
> I did cherry-pick 9baee6181b4e427e0b5ba417e51424c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107015
--- Comment #2 from Jonathan Wakely ---
And we don't even do that check for the const overload, even in debug mode!
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 11. Bitset minor problems
_GLIBCXX_CONSTEXPR bool
operator[](size_t _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107015
--- Comment #1 from Jonathan Wakely ---
In C++11 and later (when bitset::reference doesn't use the debug mode
iterator validity checks) the only benefit to __debug::bitset is that we check
the argument to operator[] is in range, using __glibcxx_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #18 from Jan Žižka ---
Created attachment 53617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53617&action=edit
Third reproducer failing with 9baee6181b4e427e0b5ba417e51424c15858dce7
I did cherry-pick 9baee6181b4e427e0b5ba417
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107015
Bug ID: 107015
Summary: __debug::bitset has different ABI for -std=c++98
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Keywords: ABI
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #7 from Alexander Monakov ---
I wanted to understand what gets exposed in LTO mode that causes a blowup.
I'd say flatten is not appropriate for this function (I don't think you want to
force inlining of memset or _find_next_bit?), s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #6 from Jiri Slaby ---
(In reply to Alexander Monakov from comment #5)
> I mean now, about compile time blowup with LTO.
No, LTO is not supported by upstream (yet) ;).
The point is what should I do when submitting the LTO support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981
--- Comment #7 from Jakub Jelinek ---
(In reply to Tobias Burnus from comment #6)
> (In reply to Jakub Jelinek from comment #5)
>
> > The fix could be either partially backport what C++ FE did in
> > --- gcc/c/c-typeck.cc.jj2022-09-23 09:02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981
--- Comment #6 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #5)
> The fix could be either partially backport what C++ FE did in
> --- gcc/c/c-typeck.cc.jj 2022-09-23 09:02:56.525318361 +0200
> +++ gcc/c/c-typeck.cc 2022-0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981
--- Comment #5 from Jakub Jelinek ---
Slightly more reduced:
void
foo (int a, double *b, double *c, double *d, long long e)
{
#pragma omp atomic capture
c[a] = d[((int) (e / 10 + 1))] = b[a] + d[((int) e / 10 + 1)];
}
The fix could be either p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919
--- Comment #8 from rdapp at gcc dot gnu.org ---
Yes, one of dst and dest is superflous. Looks good like that. I bootstrapped
the same patch locally already, no regressions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #5 from Alexander Monakov ---
(In reply to Jiri Slaby from comment #4)
> > I am surprised that "flatten" blows up on this function. Is that with any
> > config, or again some specific settings like gcov? Is there an existing lkml
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #4 from Jiri Slaby ---
(In reply to Alexander Monakov from comment #3)
> It was added to force inlining of small helpers that outgrow limits when
> building with gcov profiling:
(with clang)
> I am surprised that "flatten" blows up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #2 from Richard Biener ---
The whole point of "flatten" is that there's _no_ limit. Looking at the
function I don't see why you'd ever use that?
If the desire is to force inlining a specific call then I think there's
currently
no g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-09-23
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #17 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a0de11d0d22054b6fd76a0730a3ec807542379d0
commit r13-2806-ga0de11d0d22054b6fd76a0730a3ec807542379d0
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Bug ID: 107014
Summary: flatten+lto
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned
78 matches
Mail list logo
