https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103927
Bug ID: 103927
Summary: ICE in a recursive class template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103811
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103927
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103908
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:80ad67e2af0620d58d57d0406dc22693cf5b8ca9
commit r12-6278-g80ad67e2af0620d58d57d0406dc22693cf5b8ca9
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103908
--- Comment #7 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
Bug ID: 103928
Summary: [12] ICE in get_insn_template, at final.c:2050
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82125
--- Comment #3 from Jonathan Wakely ---
>From PR 103583:
Compiling the following with gcc -c:
struct A {
int *begin();
// int *end();
};
void foo(A a) {
for (auto it : a) { }
}
shows two error messages:
error: ‘begin’ was not decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103583
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82125
Jonathan Wakely changed:
What|Removed |Added
CC||shlomo at fastmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103922
--- Comment #3 from Jonathan Wakely ---
Yes, this was fixed by r276764 which is the big rewrite:
"Update the concepts implementation to conform to C++20."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923
--- Comment #2 from Jonathan Wakely ---
The instantiation of unordered_map instantiates this alias:
template
using __cache_default
= __not_<__and_,
// Mandatory to have erase not throwing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923
--- Comment #3 from Jonathan Wakely ---
If I change the __cache_default trait to be:
template
using __cache_default
= __bool_constant::value // Do not cache for fast
hasher.
// Mandatory to have erase not throwing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-01-06
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923
--- Comment #5 from Jonathan Wakely ---
Here's a minimal program showing the underlying problem:
template
struct C
{
};
struct T {
struct H {
auto operator()() const { return 0; }
};
C c;
};
T t;
103923.C:1:43: error: use of 'auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923
--- Comment #6 from Jonathan Wakely ---
This is another case of https://wg21.link/cwg2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45272
--- Comment #3 from Martin Liška ---
Do you suggest using sreal, or something else?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #19 from Martin Liška ---
(In reply to Eric Botcazou from comment #18)
> The fix does more harm than good though since it disables
> -freorder-blocks-and-partition entirely for 64-bit Windows.
Can you be more concrete about what's w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
--- Comment #30 from Andrew Cooper ---
(In reply to CVS Commits from comment #27)
>
> x86: Add -mharden-sls=[none|all|return|indirect-branch]
>
It occurs to me that `indirect-branch` needs renaming to be `indirect-jmp` as
the logic specifi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103927
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
--- Comment #3 from Manuel Lauss ---
You're right, I too can only reproduce it on the bdver4 machine itself, not on
e.g. a Zen or Haswell host. I'll rebuild gcc-12 on the bdver4 host again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
--- Comment #4 from Martin Liška ---
(In reply to Manuel Lauss from comment #3)
> You're right, I too can only reproduce it on the bdver4 machine itself, not
> on e.g. a Zen or Haswell host. I'll rebuild gcc-12 on the bdver4 host again.
How do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
--- Comment #5 from Manuel Lauss ---
(In reply to Martin Liška from comment #4)
> (In reply to Manuel Lauss from comment #3)
> > You're right, I too can only reproduce it on the bdver4 machine itself, not
> > on e.g. a Zen or Haswell host. I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #21 from Jiu Fu Guo ---
Also had a test on powerpc, -m32. As testing, it seems no significant benefit
loading from 'rodata' vs. building constants by instructions.
lis %r7,0x410
ori %r7,%r7,0x103c
lis %r6,0x7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
--- Comment #6 from Martin Liška ---
Then you may be affected by PR103905 which is fixed on the current master.
Please pull to tip of master branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
--- Comment #7 from Uroš Bizjak ---
(In reply to Martin Liška from comment #6)
> Then you may be affected by PR103905 which is fixed on the current master.
> Please pull to tip of master branch.
No, bdver4 does not include XOP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
--- Comment #8 from Martin Liška ---
> No, bdver4 does not include XOP.
Ohh, didn't know that...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103853
Pavel I. Kryukov changed:
What|Removed |Added
Attachment #52080|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
--- Comment #9 from Manuel Lauss ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to Martin Liška from comment #6)
> > Then you may be affected by PR103905 which is fixed on the current master.
> > Please pull to tip of master branch.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
Andrew Pinski changed:
What|Removed |Added
Summary|Label with address taken|asm goto interacting with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45272
--- Comment #4 from Andrew Pinski ---
(In reply to Martin Liška from comment #3)
> Do you suggest using sreal, or something else?
MPFR? See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45273#c6 for the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103929
Bug ID: 103929
Summary: False warning: no return statement in function
returning non-void
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61755
--- Comment #1 from Andrew Pinski ---
Looks fine on the trunk and in GCC 7.5.0.
<2><50>: Abbrev Number: 3 (DW_TAG_variable)
<51> DW_AT_name: g
<53> DW_AT_decl_file : 1
<54> DW_AT_decl_line : 7
<55> DW_AT_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #20 from Eric Botcazou ---
> Can you be more concrete about what's wrong with that? I haven't changed the
> conditions that drop the flag, but only make it respect pragmas.
Previously the opts.c logic would trigger only with the pra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61755
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45273
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
Manuel Lauss changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103929
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-01-06
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103929
--- Comment #2 from Andrew Pinski ---
(gdb) p debug_tree(0x773b22a0)
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x772625e8 precision:32 min max
pointer_to_this >
QI
si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103929
--- Comment #3 from Andrew Pinski ---
With just:
template
struct B { using X = B<>; };
B<> x;
We get an ICE :).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #21 from Martin Liška ---
> Previously the opts.c logic would trigger only with the pragma, now it
> triggers even without it, disabling flag_reorder_blocks_and_partition in all
> cases:
I don't see why should it behave differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
--- Comment #31 from H.J. Lu ---
Created attachment 52134
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52134&action=edit
A patch to rename -harden-sls=indirect-branch to -harden-sls=indirect-jmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #22 from Eric Botcazou ---
> I don't see why should it behave differently for command-line options and
> options that are passed via #pragma GCC optimize (or optimize attribute).
> That should behave the same.
Absolutely, but it sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #23 from Martin Liška ---
> Absolutely, but it should let -freorder-blocks-and-partition go through in
> both cases, instead of disabling it in both cases as it does now.
That's something I'm complete fine with ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #24 from Tomas Kalibera ---
FWIW, predict-22.c from GCC test suite is an example for which
reorder-blocks-and-partition has an effect (creates foo.cold) in GCC trunk, up
to but excluding
https://gcc.gnu.org/g:a187edd2b437fc9571d57f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103930
Bug ID: 103930
Summary: asan intercepts fail if target library is only loaded
(indirectly) through dlopen (e.g. plugin)
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923
Jonathan Wakely changed:
What|Removed |Added
CC||fdumont at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101961
Jason Merrill changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
Jason Merrill changed:
What|Removed |Added
CC||mbtrash at yandex dot ru
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103899
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:db33b1059bcee3eeb36d174d59abf19f2bef5d66
commit r12-6280-gdb33b1059bcee3eeb36d174d59abf19f2bef5d66
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61611
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103899
--- Comment #10 from Jakub Jelinek ---
Workaround applied, tree-ssa-uninit.c should be improved if possible though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102551
Patrick Palka changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103600
Patrick Palka changed:
What|Removed |Added
Blocks|102551 |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 102551, which changed state.
Bug 102551 Summary: Failing compile-time comparison of std::type_info addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102551
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923
--- Comment #8 from Jonathan Wakely ---
I think libc++ just always caches the hash code, which keeps things much
simpler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103911
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:c83ecfbe74a5cf107642b9c5e1680b548ff1a0e1
commit r12-6281-gc83ecfbe74a5cf107642b9c5e1680b548ff1a0e1
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
--- Comment #91 from David Binderman ---
I confirm that the problem seems fixed to me in today's trunk.
Thanks to everyone for what has been an unusually difficult bug to find.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103853
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:52ebc2be0990d6d3a46bb716164f9cef6f661021
commit r12-6284-g52ebc2be0990d6d3a46bb716164f9cef6f661021
Author: Pavel I. Kryukov
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931
Bug ID: 103931
Summary: Type name "c_ptr" is ambiguous when iso_c_binding is
imported both directly and indirectly
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103853
--- Comment #9 from Jonathan Wakely ---
Thanks! This is fixed on trunk now, and will be backported to the release
branches soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
--- Comment #12 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:2793af17db239429ea3a2e26834e74daa6cff2c0
commit r12-6285-g2793af17db239429ea3a2e26834e74daa6cff2c0
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
Patrick Palka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 69681, which changed state.
Bug 69681 Summary: C/C++ FEs do not consider comparisons of distinct function
pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77911
Bug 77911 depends on bug 69681, which changed state.
Bug 69681 Summary: C/C++ FEs do not consider comparisons of distinct function
pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77911
Patrick Palka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 77911, which changed state.
Bug 77911 Summary: Comparing function pointers in a constexpr function can
produce an error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77911
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #52 from Jonathan Wakely ---
(In reply to Andrew Aladjev from comment #35)
> Hello cqwrteur, do you have an influence on core gcc developers?
He has negative influence. The more he comments on a bug, the less likely I am
to even rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #53 from cqwrteur ---
(In reply to Jonathan Wakely from comment #52)
> (In reply to Andrew Aladjev from comment #35)
> > Hello cqwrteur, do you have an influence on core gcc developers?
>
> He has negative influence. The more he com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #54 from Jonathan Wakely ---
(In reply to Andrew Aladjev from comment #38)
> Sure, patches works perfect. But we need somehow decrease the chance of
> similar regressions in future. It is possible by adding any basic "canadian"
> bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85428
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |12.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 85428, which changed state.
Bug 85428 Summary: constexpr pointer equality comparison not considered
constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85428
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #55 from cqwrteur ---
(In reply to Jonathan Wakely from comment #54)
> (In reply to Andrew Aladjev from comment #38)
> > Sure, patches works perfect. But we need somehow decrease the chance of
> > similar regressions in future. It is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923
--- Comment #9 from Jonathan Wakely ---
Maybe we don't actually need to do anything here. As the original testcase
shows, trying to actually use the map is still ill-formed:
//T().m[T::K()]; // for extra fun
I'm not going to work on th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 89367, which changed state.
Bug 89367 Summary: Constexpr expression is not constexpr in template, but is
constexpr in non-template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86354
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94716
Patrick Palka changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 86354, which changed state.
Bug 86354 Summary: Address comparison not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86354
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #56 from Alexander von Gluck ---
Canadian builds are pretty important in GCC.
clang doesn't really need Canadian builds since they support all targets out of
the box on every platform, but we don't have that luxury with gcc.
With t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
--- Comment #11 from Uroš Bizjak ---
(In reply to Martin Liška from comment #8)
> > No, bdver4 does not include XOP.
>
> Ohh, didn't know that...
Sorry, I was wrong:
{"bdver4", PROCESSOR_BDVER4, CPU_BDVER4,
PTA_64BIT | PTA_MMX | PTA_SSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #57 from Jakub Jelinek ---
I don't see how the patch could be correct.
Looking at RAW_CXX_FOR_TARGET in configure, I see:
(starting with the line you're proposing to change):
RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET"
...
{ $as_echo "$as_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103928
--- Comment #12 from Uroš Bizjak ---
(In reply to Manuel Lauss from comment #10)
> So it was either fixed in trunk in the last 20 hours, or pgo build broke
> gcc, or "-mno-xop" fixed it.
The fix for PR103905 was pushed to the master in the last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #25 from Eric Botcazou ---
> That's something I'm complete fine with ;)
Time for a promotion of UI_SEH :-)
diff --git a/gcc/coretypes.h b/gcc/coretypes.h
index 5d0fc1d915d..f6206154e1a 100644
--- a/gcc/coretypes.h
+++ b/gcc/coretyp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #58 from cqwrteur ---
(In reply to Alexander von Gluck from comment #56)
> Canadian builds are pretty important in GCC.
>
> clang doesn't really need Canadian builds since they support all targets out
> of the box on every platform,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #59 from cqwrteur ---
(In reply to Jakub Jelinek from comment #57)
> I don't see how the patch could be correct.
> Looking at RAW_CXX_FOR_TARGET in configure, I see:
> (starting with the line you're proposing to change):
> RAW_CXX_FO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #60 from cqwrteur ---
(In reply to Alexander von Gluck from comment #56)
> Canadian builds are pretty important in GCC.
>
> clang doesn't really need Canadian builds since they support all targets out
> of the box on every platform,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #61 from cqwrteur ---
(In reply to Alexander von Gluck from comment #56)
> Canadian builds are pretty important in GCC.
>
> clang doesn't really need Canadian builds since they support all targets out
> of the box on every platform,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #62 from Jonathan Wakely ---
But that's off topic for GCC's bugzilla, please try to focus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #63 from cqwrteur ---
(In reply to Jonathan Wakely from comment #62)
> But that's off topic for GCC's bugzilla, please try to focus.
so what's your solution to fix this problem? Are we going to fix it after
GCC13?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #64 from Alexander von Gluck ---
(In reply to cqwrteur from comment #61)
> TBH, I failed to see how cross-compile in llvm is simple compared to GCC.
I mean... bootstrap. Compiling Canadian toolchains to compile non-Canadian
toolcha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #65 from cqwrteur ---
(In reply to Jonathan Wakely from comment #62)
> But that's off topic for GCC's bugzilla, please try to focus.
Is that because
#if _GLIBCXX_HAVE_FENV_H
# include
#endif
here _GLIBCXX_HAVE_FENV_H in the libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
--- Comment #33 from Andrew Cooper ---
Looks good to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #66 from Jonathan Wakely ---
(In reply to cqwrteur from comment #63)
> so what's your solution to fix this problem? Are we going to fix it after
> GCC13?
I'm working on it right now, but it would help if you would just shut the hell
1 - 100 of 242 matches
Mail list logo
