https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #5 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
--- Comment #4 from David Binderman ---
Only one pass at reduction, leaving 14 revisions, but
this commit looks to be a hot candidate:
commit e8109bd87766be88e83fe88a44433dae16358a02
Author: Martin Jambor
Date: Fri Feb 3 13:28:24 2023 +01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #17 from Jakub Jelinek ---
(In reply to jbeulich from comment #16)
> I can only repeat: Unless the anomaly is properly called out in non-internal
> documentation, I continue to think there's a bug here. And the reference to
For inli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
David Binderman changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Gaius Mulley ---
> The hand built modules were not changed to include the libname. (UnixArgs,
> ldtoa, dtoa for the tool pge). The patch corrects the hand built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
--- Comment #6 from David Binderman ---
As expected:
$ git bisect bad e8109bd87766be88
e8109bd87766be88e83fe88a44433dae16358a02 is the first bad commit
commit e8109bd87766be88e83fe88a44433dae16358a02
Author: Martin Jambor
Date: Fri Feb 3 13:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108963
Bug ID: 108963
Summary: ASAN produces wrong line number in the report
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108964
Bug ID: 108964
Summary: Attribute target should be implemented for C backend
(not only c++)
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #19 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:822a11a1e642e0abe92a996e7033a5066905a447
commit r13-6372-g822a11a1e642e0abe92a996e7033a5066905a447
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:8e342c04550466ab088c33746091ce7f3498ee44
commit r13-6373-g8e342c04550466ab088c33746091ce7f3498ee44
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952
Jonathan Wakely changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
Bug ID: 108965
Summary: g++: unable to parse c11 _Generics
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
--- Comment #1 from Jonathan Wakely ---
(In reply to Christopher Friedt from comment #0)
> It's not clear to me if any part of the ISO C++ standard requires a C++
> compiler to parse C11 _Generic,
It's very clear that it doesn't, _Generic is ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108966
Bug ID: 108966
Summary: Inheriting consteval constructor makes it constexpr in
the derived class
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108942
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108942
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:41c02eeb309b3be58683be8f9961f3894b6fb4c7
commit r13-6374-g41c02eeb309b3be58683be8f9961f3894b6fb4c7
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108942
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108947
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108949
--- Comment #1 from Richard Biener ---
There's still the goal to get rid of SHIFT_COUNT_TRUNCATED, that is, make the
semantics of RTL (and most definitely GIMPLE) independent of target
macros/hooks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c7728805a7107444683290cd629d13f089130a0d
commit r13-6375-gc7728805a7107444683290cd629d13f089130a0d
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108950
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.5
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108953
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-02-28
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108954
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-02-28
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
--- Comment #3 from Christopher Friedt ---
All you need to do is look at the example above pulled directly from
cppreference.com, but please simply gaslight the user if that's an easier path
to resolution for you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
--- Comment #4 from Andrew Pinski ---
(In reply to Christopher Friedt from comment #3)
> All you need to do is look at the example above pulled directly from
> cppreference.com, but please simply gaslight the user if that's an easier
> path to r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545
Tobias Burnus changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
--- Comment #5 from Jonathan Wakely ---
(In reply to Christopher Friedt from comment #3)
> All you need to do is look at the example above pulled directly from
> cppreference.com, but please simply gaslight the user if that's an easier
> path to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
Bug ID: 108967
Summary: internal compiler error: in expand_debug_expr, at
cfgexpand.cc:5450
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
--- Comment #6 from Christopher Friedt ---
It's supported OOTB in `clang++` but fails in `g++`.
The example above is the simplest example that illustrates the issue.
I am not being abusive, but it certainly did feel like gaslighting to read
"y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
--- Comment #7 from Jonathan Wakely ---
(In reply to Christopher Friedt from comment #6)
> It's supported OOTB in `clang++` but fails in `g++`.
Nobody is disputing that, but Clang supports lots of things that aren't valid
in C++ and aren't supp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
--- Comment #8 from Christopher Friedt ---
My code is clearly valid C++ according to g++ :-)
Thanks for your help in any case.
On Tue, Feb 28, 2023, 7:38 AM redi at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
Bug ID: 108968
Summary: fanalyzer false positive with the uninitalised-ness of
the stack pointer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
--- Comment #9 from Jonathan Wakely ---
(In reply to Christopher Friedt from comment #8)
> My code is clearly valid C++ according to g++ :-)
Maybe you mean clang++ but even then, no it's not:
$ clang++ -pedantic gen.cc
gen.cc:15:32: warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
--- Comment #10 from Christopher Friedt ---
Thanks - I wasn't using -pedantic, but you have certainly proven stuff.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
--- Comment #7 from Vincent Lefèvre ---
On https://godbolt.org/z/Yx7b1d this still fails with "x86-64 gcc (trunk)".
Moreover, several releases are affected: 11.1, 11.2, 11.3, 12.1, 12.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956
Gaius Mulley changed:
What|Removed |Added
Attachment #54553|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Bug ID: 108969
Summary: [13 Regression] Initializing iostreams in the library
needs a GLIBCXX_3.4.31 versioned symbol
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #1 from Andreas Schwab ---
Can you use __builtin_frame_address instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #2 from Jonathan Wakely ---
--- a/libstdc++-v3/src/c++98/globals_io.cc
+++ b/libstdc++-v3/src/c++98/globals_io.cc
@@ -43,6 +43,12 @@
// In macro form:
// _GLIBCXX_ASM_SYMVER(currentname, oldname, GLIBCXX_3.2)
+#if __has_attribute(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #3 from Jakub Jelinek ---
You're right, it can be done just on the library side.
Though, only for GNU symbol versioning, I think the Solaris one doesn't allow
having one symbol with multiple symbol versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #4 from Jonathan Wakely ---
The patch above means that a program using cout (or any of the standard
streams) gets:
00404040 B _ZSt4cout@GLIBCXX_3.4.31
instead of:
00404040 B _ZSt4cout@GLIBCXX_3.4
And then it fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #5 from Jakub Jelinek ---
Even for the partial Linux solution, you need to make sure that those variables
are exported as both _ZSt5wcout@GLIBCXX_3.4 and _ZSt5wcout@@GLIBCXX_3.4.31
(same address i.e. aliases).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
--- Comment #11 from Christopher Friedt ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Christopher Friedt from comment #8)
> > My code is clearly valid C++ according to g++ :-)
>
> Maybe you mean clang++ but even then, no it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #6 from Florian Weimer ---
(In reply to Jonathan Wakely from comment #2)
> --- a/libstdc++-v3/src/c++98/globals_io.cc
> +++ b/libstdc++-v3/src/c++98/globals_io.cc
> @@ -43,6 +43,12 @@
> // In macro form:
> // _GLIBCXX_ASM_SYMVER(cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #7 from Jonathan Wakely ---
I think they're exported correctly with both versions:
$ nm -D --defined-only src/.libs/libstdc++.so.6.0.31 | grep '_ZSt[345]c'
0025d7a0 B _ZSt3cin@@GLIBCXX_3.4
0025d7a0 B _ZSt3cin@@GLIB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #2 from Andrew Cooper ---
__builtin_frame_address() does appear to resolve the warning, but the knock-on
effect for code generation is even worse than the asm() block.
It forces a frame-pointer setup in all functions that use it (wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #8 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #7)
> I think they're exported correctly with both versions:
>
> $ nm -D --defined-only src/.libs/libstdc++.so.6.0.31 | grep '_ZSt[345]c'
> 0025d7a0 B _ZS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target||aarch64
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #9 from Richard Biener ---
(In reply to Florian Weimer from comment #6)
> (In reply to Jonathan Wakely from comment #2)
> > --- a/libstdc++-v3/src/c++98/globals_io.cc
> > +++ b/libstdc++-v3/src/c++98/globals_io.cc
> > @@ -43,6 +43,12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #3 from Andreas Schwab ---
Perhaps it works if you declare the register variable in file scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #10 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #8)
> Unfortunately we build libstdc++ objects just once because even libstdc++.a
> contains -fPIC code. So not sure how to arrange it to be libstdc++.so only.
We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108950
--- Comment #3 from Richard Biener ---
It's because we do
if (slp_node
&& !(!single_defuse_cycle
&& !lane_reduc_code_p
&& reduction_type != FOLD_LEFT_REDUCTION))
for (i = 0; i < (int) op.num_ops; i++)
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
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=108165
--- Comment #11 from Marek Polacek ---
No, because as Comment 9 says, there's no good way to suppress the warning.
I'm currently leaning towards closing the BZ and suggesting adding a #pragma to
disable the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107938
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:ea718febab2a1f6e58806738abf70f1c73c6a308
commit r13-6376-gea718febab2a1f6e58806738abf70f1c73c6a308
Author: Marek Polacek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108550
--- Comment #9 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:d918c3a221434521f90cc9b63d5d87f5129e9231
commit r13-6377-gd918c3a221434521f90cc9b63d5d87f5129e9231
Author: Marek Polacek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108550
Marek Polacek changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Martin Liška changed:
What|Removed |Added
CC||rui314 at gmail dot com
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956
--- Comment #5 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:62ed1066196c81ab1fad13b2cc5ebbfe887138f9
commit r13-6378-g62ed1066196c81ab1fad13b2cc5ebbfe887138f9
Author: Gaius Mulley
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
--- Comment #4 from Jakub Jelinek ---
Somewhat reduced for -O2 -g:
template
struct A {
using T = unsigned short;
static constexpr int a = N;
};
template
struct B { using type = A; };
struct C {
static constexpr int N = 16 / sizeof (shor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
Andrew Cooper changed:
What|Removed |Added
Component|analyzer|c
--- Comment #4 from Andrew Cooper --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #8 from Segher Boessenkool ---
To expand a bit: st_other with value 1 was reserved before, and now it
isn't anymore. Any tool that silently ignores the "special case" of
reserved values will not work correctly (it might sometimes do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108970
Bug ID: 108970
Summary: [13 Regression] ICE in vect_do_peeling, at
tree-vect-loop-manip.cc:2971, or ICE in
dump_printf_loc, at dumpfile.cc:1359
Product: gcc
Vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
Christophe Lyon changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108970
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #33 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #20)
> (In reply to Jakub Jelinek from comment #16)
>
> > More questionable is the #Z case, where Table 8-11 just talks about
> > Divide or reverse divide operation Returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
--- Comment #5 from Jakub Jelinek ---
Created attachment 54557
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54557&action=edit
gcc13-pr108967.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108964
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target|powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108971
Bug ID: 108971
Summary: [13 Regression] ICE in tree_profiling, at
tree-profile.cc:724
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97956
--- Comment #5 from Jonathan Wakely ---
(In reply to G. Steinmetz from comment #0)
> typedef __INT8_TYPE__ int8_t;
> typedef __INT32_TYPE__ int32_t;
> extern void* memchr (const void*, int, long);
For the record, the signature above is wrong (th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108972
Bug ID: 108972
Summary: ICE: tree check: expected tree that contains 'decl
common' structure, have 'error_mark' in
compare_lambda_template_head, at cp/lambda.cc:1551
Produc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108966
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104490
Patrick Palka changed:
What|Removed |Added
CC||g...@arne-mertz.de
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
--- Comment #14 from CVS Commits ---
The master branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:afe6cea4489846aa8585f3c045d16cdaa08cc6cd
commit r13-6379-gafe6cea4489846aa8585f3c045d16cdaa08cc6cd
Author: Qing Zhao
Date: Tue Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973
Bug ID: 108973
Summary: Sufficiently narrow terminal window causes selftest
failure
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 107411, which changed state.
Bug 107411 Summary: trivial-auto-var-init=zero invalid uninitialized variable
warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #5 from David Malcolm ---
Minimal reproducer: https://godbolt.org/z/E6EEY1WT6
Am I right in understanding that:
register unsigned long sp asm("rsp");
is intended as a way to read the %rsp register?
If so, I think the analyzer m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #6 from Andrew Cooper ---
(In reply to David Malcolm from comment #5)
> Minimal reproducer: https://godbolt.org/z/E6EEY1WT6
>
> Am I right in understanding that:
> register unsigned long sp asm("rsp");
> is intended as a way to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
Bug ID: 108974
Summary: std::barrier except completion function which is not
manifestly noexcept
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
--- Comment #1 from Andrew Pinski ---
Created attachment 54558
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54558&action=edit
Full testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108848
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:d3d205ab440886164b6de2be2a2efa10cac95b66
commit r13-6380-gd3d205ab440886164b6de2be2a2efa10cac95b66
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108848
Patrick Palka changed:
What|Removed |Added
Known to work||13.0
Known to fail|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106946
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
--- Comment #3 from Marek Polacek ---
// PR c++/106259
// { dg-do compile { target c++11 } }
template struct A {
template
struct W { };
};
template<>
struct A {
template
class W { };
};
void
g ()
{
struct A::W w1; // warn
struct A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Bug ID: 108975
Summary: Internal compiler error on constexpr variable used as
nontype template
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #1 from Andrew Pinski ---
>but it is too large to attach here,
You can use bzip2 or zip to compress it and attach that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #6 from Costas Argyris ---
Created attachment 54559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54559&action=edit
Integrate UTF-8 manifest into gcc's build process for mingw host
This builds fine and the resource object doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108452
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-02-28
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #2 from Sam Mish ---
Does the dropbox link to the .ii file not work for you, Andrew?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #3 from Andrew Pinski ---
(In reply to Sam Mish from comment #2)
> Does the dropbox link to the .ii file not work for you, Andrew?
It does but I was just explaining how we are ok with compressed files in many
cases.
1 - 100 of 149 matches
Mail list logo
