Hi All,
I'm not sure if this is the right mailing list for asking about
(possible) g++ issues. If not, I'd appreciate it if someone can point
me to the right one.
With that said, here goes...
I have an strange (to me) issue, where trying to compile a header
which has a single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96108
--- Comment #7 from Andrew Pinski ---
My question was rather do you an original code where we are now missing an
optimization and you reduced the code down to this and what happens if you
correct the issue of using an uninit pointer (because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95804
--- Comment #6 from bin cheng ---
(In reply to Martin Liška from comment #5)
> @Bin: Any news about this?
Patch is approved, will apply soon. Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96108
--- Comment #6 from Jolyon <499537630 at qq dot com> ---
I agree that we really can't do this in the test. GCC's inconsistencies with
this behavior are beyond the developers' consideration(the behavior of DSE
pass). I tried to initialize the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87736
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96126
Martin Sebor changed:
What|Removed |Added
Keywords||patch
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78666
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #9 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79815
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90782
--- Comment #5 from Michael Bruck ---
(In reply to Michael Bruck from comment #4)
ugh that was for PR96097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96097
--- Comment #5 from Michael Bruck ---
Further simplified code
template typename>
void func() {}
template
struct Y {};
void test()
{
func();
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90782
Michael Bruck changed:
What|Removed |Added
CC||bruck.michael at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95982
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95968
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95956
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95954
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95945
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P5
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95932
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95930
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93788
--- Comment #2 from Marek Polacek ---
*** Bug 95930 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96125
--- Comment #3 from Peter Bergner ---
Actually, it's more complicated than that. We only initialize the target
builtins once, using the command line option values and not again using the
target attribute/pragma values. That means we basically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96060
Marek Polacek changed:
What|Removed |Added
CC||milasudril at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96064
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96060
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2020-07-08
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96048
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P5
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96126
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96126
Bug ID: 96126
Summary: conflicting attribute section accepted on
redeclaration
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96045
--- Comment #2 from Marek Polacek ---
Regressed with r11-338-g2a0225e47868fbfceaecaa5e2de96c1c5a2251ea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96045
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |11.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95927
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95925
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2020-07-08
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95955
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95955
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96125
--- Comment #2 from Peter Bergner ---
Looks like some missing code in rs6000_option_override_internal() to enable
TARGET_MMA by default when -mcpu=power10 is used, similar to how we handle
-mprefix. I'm testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96122
--- Comment #2 from Andrew Benson ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed. For me it segfaults from GCC7 up to GCC11.
Interesting. This started occurring for me when I updated from GCC10.1 to 11.
But, the code I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96125
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96122
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2020-07-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96125
Bug ID: 96125
Summary: __attribute__((target("cpu=power10,mma"))) does not
set TARGET_MMA
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96070
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96124
Bug ID: 96124
Summary: Template specialization auto
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96120
--- Comment #4 from Jonathan Wakely ---
(In reply to Haoxin Tu from comment #3)
> Apologize for my expression. I mean the meaning of the error message
> "invalid use of type ‘void’ in parameter declaration" is opposite with the
> valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95159
Marek Polacek changed:
What|Removed |Added
CC||lutztonineubert at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96123
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96123
--- Comment #1 from Toni Neubert ---
:23:28: internal compiler error: Segmentation fault
23 | using type = Token;
|^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96123
Bug ID: 96123
Summary: [10, trunk] segment fault with NTTP fixed_string
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96097
Marek Polacek changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96085
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96085
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:1fa08dcac686ca5b6d84e64c9f5813daef59f540
commit r11-1949-g1fa08dcac686ca5b6d84e64c9f5813daef59f540
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95709
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #8)
> Isn't it an aliasing problem?
No. It is not an aliasing problem. It is an invalid
program giving a result that the programmer does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95709
--- Comment #5 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:006fda1b17a4d55b6548a1b3bd7efd0d8e40b6c4
commit r9-8727-g006fda1b17a4d55b6548a1b3bd7efd0d8e40b6c4
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95972
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95709
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:17327d6cc73672ada0c6608f70e0894144b1f54b
commit r10-8439-g17327d6cc73672ada0c6608f70e0894144b1f54b
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96122
Bug ID: 96122
Summary: Segfault when using finalizer
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95497
--- Comment #4 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you for fixing!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95497
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95497
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:9eb7d0d76eb652caa9186766da4fe965f113b1b8
commit r11-1947-g9eb7d0d76eb652caa9186766da4fe965f113b1b8
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95804
--- Comment #5 from Martin Liška ---
@Bin: Any news about this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #35 from Jeffrey A. Law ---
That's a reasonable idea Eric -- the barriers are primarily there for the
benefit of CFG building and manipulation and thus provide marginal, if any,
benefit once we hit the reorg pass.
I recall 81025
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
--- Comment #5 from Marc Glisse ---
Yes, then we are back to the fact that it works for A=int but not for A a class
containing an int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
--- Comment #4 from Antony Polukhin ---
Adding members and usage does not make a difference
https://godbolt.org/z/VommHu
struct A {
A();
int i;
};
struct B {
B(A);
int i;
};
struct composed2 {
B b_;
A a_;
composed2() : b_(a_) {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
--- Comment #3 from Marc Glisse ---
And this translation unit doesn't actually generate any code at all, so the way
the warning is currently implemented has no chance of even looking at it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
--- Comment #2 from Marc Glisse ---
gcc warns for this at the level of actual instructions, not user code. Since A
is empty, nothing uninitialized is getting copied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96120
--- Comment #3 from Haoxin Tu ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Haoxin Tu from comment #0)
> > GCC might emit the ambiguity diagnostic message on it.
>
> What does that mean?
Apologize for my expression. I mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96120
--- Comment #2 from Jonathan Wakely ---
GCC's diagnostic seems fine to me. Using 'void' as the type of a parameter is
invalid. There's a special case for (void) but that isn't relevant to your
declaration, which has two parameters.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96120
--- Comment #1 from Jonathan Wakely ---
(In reply to Haoxin Tu from comment #0)
> GCC might emit the ambiguity diagnostic message on it.
What does that mean?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
Bug ID: 96121
Summary: Uninitialized variable copying not diagnosed
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79815
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96118
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86709
Jonathan Wakely changed:
What|Removed |Added
CC||haoxintu at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81836
Jonathan Wakely changed:
What|Removed |Added
Keywords|diagnostic |
Last reconfirmed|2017-08-21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46206
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19538
Jonathan Wakely changed:
What|Removed |Added
Keywords|accepts-invalid, diagnostic |rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96115
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-07-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96120
Bug ID: 96120
Summary: Ambiguity diagnostic message of "invalid use of type
'void' in parameter declaration"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96117
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-07-08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96119
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96118
--- Comment #1 from Jonathan Wakely ---
This is a duplicate of an existing bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
Jonathan Wakely changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96022
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96022
Maxim Kuvyrkov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96119
Bug ID: 96119
Summary: GCC accepts invalid qualifier in a try-catch block
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96118
Bug ID: 96118
Summary: GCC accepts invalid combination of two type specifiers
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
--- Comment #12 from Jonathan Wakely ---
(In reply to Antal Buss from comment #1)
> Created attachment 48811 [details]
> Preprocessed file
For convenience, that is:
#include
int main() {
auto t = std::jthread([](){});
t.request_stop();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96116
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96117
Bug ID: 96117
Summary: Cannot mix c++11-style and GCC-style attributes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95910
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96116
Bug ID: 96116
Summary: GCC accepts "enum struct/class" in reference to
enumeration
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96110
--- Comment #6 from Jonathan Wakely ---
I've reported https://bugs.llvm.org/show_bug.cgi?id=46637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96115
Bug ID: 96115
Summary: Char literal, decays to a pointer when passed to
function pointer
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95972
--- Comment #4 from Haoxin Tu ---
(In reply to Marek Polacek from comment #3)
> You can still use creduce (I do), but it's good to try adding missing
> parens/braces and similar to make the code more sensible.
Yes, you are right. Thanks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96110
--- Comment #5 from Haoxin Tu ---
(In reply to Jonathan Wakely from comment #2)
> This isn't specific to catch handlers, other compilers accept that nonsense
> function declaration in various contexts, and GCC rejects them all:
Thanks for your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96110
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95105
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95105
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96111
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96110
--- Comment #3 from Jonathan Wakely ---
And this puts Clang into a coma even without debuginfo:
template struct X { T* p; };
X auto> x;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96110
--- Comment #2 from Jonathan Wakely ---
This isn't specific to catch handlers, other compilers accept that nonsense
function declaration in various contexts, and GCC rejects them all:
using F = auto () -> auto;
template struct X { };
X auto> x;
1 - 100 of 166 matches
Mail list logo
