https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
Richard Biener changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108977
Richard Biener changed:
What|Removed |Added
Keywords||testsuite-fail
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108972
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
--- Comment #3 from vinay kumar ---
Hi Andrew Pinski
Currently we upgraded from 4.2 to 4.8.3.
we used rpm to upgrade GCC to 4.8.3 with below command.
rpm -ivh gcc-cpp-8-1.aix7.1.ppc.rpm
Validation
gcc --version(4.8.3)
we are trying to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108971
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108970
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108950
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:e3837b6f6c28a1d2cea3a69efbda795ea3fb8816
commit r13-6384-ge3837b6f6c28a1d2cea3a69efbda795ea3fb8816
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
--- Comment #2 from Andrew Pinski ---
Third you might need to run fix includes again after doing the install.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
--- Comment #1 from Andrew Pinski ---
First off 4.8.x has not been supported for around 5 years now so there is not
much we can do plus since this is also from a binary build of gcc you should
ask where you got gcc from for support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
Bug ID: 108982
Summary: While recompiling when even we modify any line in got
its giving error
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108729
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108727
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415
Bug 108415 depends on bug 108240, which changed state.
Bug 108240 Summary: [13 Regression] Error message missing since
r13-4894-gacc727cf02a144 (then make concealed ICE exposed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108981
Kewen Lin changed:
What|Removed |Added
Keywords|ice-on-valid-code |diagnostic
Depends on|108240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108981
Bug ID: 108981
Summary: Raise errors for cpu type without powerpc64 support.
Product: gcc
Version: 13.0
URL: https://gcc.gnu.org/pipermail/gcc-patches/2023-January
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #14 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:392f399ae0595e6b4433c18900cc67991fb140f4
commit r13-6383-g392f399ae0595e6b4433c18900cc67991fb140f4
Author: Kewen Lin
Date: Tue Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #4 from Andrew Pinski ---
Created attachment 54562
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54562=edit
Patch which I think is correct but not 100% sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
Andrew Pinski changed:
What|Removed |Added
Summary|Warning text missing the|[13 Regression] Warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #2 from Andrew Pinski ---
The problem is obviously in array_bounds_checker::check_array_ref .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #1 from Thiago Macieira ---
GCC 13 (trunk) built today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
Bug ID: 108980
Summary: Warning text missing the warning itself (GCC 13)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #9 from Surya Kumari Jangala ---
The same issue of unnecessary rldicl instruction is there if we change return
value from bool to int.
int foo (int a, int b)
{
if (a > 2)
return 0;
if (b < 10)
return 1;
return 0;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108977
--- Comment #2 from Kewen Lin ---
(In reply to Kewen Lin from comment #1)
> The newly added test case requires Richard's commit r13-5979 to pass. This
> should be fixed once that commit gets fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108977
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979
Bug ID: 108979
Summary: [13 Regression] ICE in compute_live_loop_exits, at
tree-ssa-loop-manip.cc:248
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108978
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108978
--- Comment #2 from Andrew Pinski ---
Created attachment 54561
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54561=edit
quick patch
This is a quick hacked patch which adds this. I didn't even test it or add
testcases. It might not even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93680
Xionghu Luo (luoxhu at gcc dot gnu.org) changed:
What|Removed |Added
CC||yinyuefengyi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108978
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108978
Bug ID: 108978
Summary: Add __builtin_FILE_NAME() which behaves like the
__FILE_NAME__ macro
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97923
--- Comment #6 from Xionghu Luo (luoxhu at gcc dot gnu.org) ---
below changes could fix the incorrect location
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 96845154a92..2dc8608dedf 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97923
Xionghu Luo (luoxhu at gcc dot gnu.org) changed:
What|Removed |Added
CC||yinyuefengyi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #9 from Rui Ueyama ---
I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI
because I didn't have an access to a POWER10 machine and therefore couldn't
verify the correctness of my implementation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108977
Bug ID: 108977
Summary: [11 regression] gcc.target/powerpc/pr96373.c fails
after r11-10549-gcf3d95cce379f3 on power 10
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976
Bug ID: 108976
Summary: codecvt for Unicode allows surrogate code points
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
Sam James changed:
What|Removed |Added
CC||sam at gentoo dot org
--- Comment #16 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #10 from Costas Argyris ---
The only interesting bit I found there was the shell script that gets called
before actually running windres:
https://github.com/jbruchon/jdupes/blob/master/Makefile#L201
which is doing some setup:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #5 from Andrew Pinski ---
Trying to reduce this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #9 from Andrew Pinski ---
https://github.com/jbruchon/jdupes
Suggest this is definitely possible. That program includes a manifest that say
that the program supports long file names.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
--- Comment #2 from Jonathan Wakely ---
"is_nothrow_invocable_v shall be true."
Failing to meet that requirement is undefined, so we're not required to reject
it as ill-formed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #8 from Andrew Pinski ---
(In reply to Costas Argyris from comment #7)
> I couldn't find examples online for doing this.There are examples of
> compiling and linking resource files in general using GNU tools, but not a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #4 from Andrew Pinski ---
Created attachment 54560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54560=edit
Original unreduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #7 from Costas Argyris ---
I think the problem is that the embedding of the manifest into the executable
is a very low-level process that depends on ms specifics that mt.exe (or VS)
knows about and windres + link doesn't.
For
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.
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=108452
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-02-28
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=edit
Integrate UTF-8 manifest into gcc's build process for mingw host
This builds fine and the resource object does get
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=108975
Bug ID: 108975
Summary: Internal compiler error on constexpr variable used as
nontype template
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity:
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
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=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=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:
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=edit
Full testcase
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:
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=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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
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
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=104490
Patrick Palka changed:
What|Removed |Added
CC||g...@arne-mertz.de
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108966
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
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
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
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:
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=108964
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
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=edit
gcc13-pr108967.patch
Full untested patch.
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
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=108910
Christophe Lyon changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |INVALID
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=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
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:
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
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=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:
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:
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=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=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=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.
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 #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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target||aarch64
Last
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
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
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
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:
> //
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
1 - 100 of 149 matches
Mail list logo
