https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98878
--- Comment #1 from Sebastian Huber ---
It may have something to do with TARGET_RISCV_DEFAULT_ABI == ilp32d. The
gcc/tm.h in the build tree contains this:
gcc/tm.h:#ifndef TARGET_RISCV_DEFAULT_ARCH
gcc/tm.h:# define TARGET_RISCV_DEFAULT_ARCH rv3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875
--- Comment #1 from Richard Biener ---
With perf you'll have to use -gdwarf-4 anyway since otherwise it cannot parse
debug in my experience. Quite some tools need to be brought up-to-date with
DWARF5 yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
Richard Biener changed:
What|Removed |Added
Target Milestone|11.0|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98866
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98878
Bug ID: 98878
Summary: Incorrect multilib list for riscv*-rtems
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98868
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
Andrew Pinski changed:
What|Removed |Added
Depends on||91753
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
--- Comment #1 from Andrew Pinski ---
I am 90% sure this is just a register allocation issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209
--- Comment #10 from rguenther at suse dot de ---
On Thu, 28 Jan 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98848
--- Comment #5 from rguenther at suse dot de ---
On Thu, 28 Jan 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98848
>
> --- Comment #4 from Jakub Jelinek ---
> Alternatively, couldn't we support truncatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
Bug ID: 98877
Summary: [AArch64] Inefficient code generated for tbl NEON
intrinsics
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98876
Bug ID: 98876
Summary: demangler-warning: unable to demangle
Product: gcc
Version: 7.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98355
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96137
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96137
--- Comment #6 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:f8f5388c9e94d4324c31d82b335fa138518e3171
commit r11-6967-gf8f5388c9e94d4324c31d82b335fa138518e3171
Author: Marek Polacek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
Liu Hao changed:
What|Removed |Added
CC|lh_mouse at 126 dot com|
--- Comment #20 from Liu Hao ---
0. Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875
Bug ID: 98875
Summary: DWARF5 as default causes perf probe to hang
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98065
Bug 98065 depends on bug 98799, which changed state.
Bug 98799 Summary: [11 Regression] vector_set_var ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871
Martin Sebor changed:
What|Removed |Added
Component|c |middle-end
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81930
Bug 81930 depends on bug 98841, which changed state.
Bug 98841 Summary: wrong ‘operator=’ should return a reference to ‘*this’
[-Weffc++]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:850a8ec54c4310d779004299bf9a0dec52324e9e
commit r11-6964-g850a8ec54c4310d779004299bf9a0dec52324e9e
Author: Jakub Jelinek
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98874
Bug ID: 98874
Summary: PowerPC test
gcc.target/powerpc/ppc-fortran/pr80108-1.f90 uses
wrong dg-options
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870
--- Comment #2 from Peter Bergner ---
*** Bug 98873 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98873
Peter Bergner changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98873
Michael Meissner changed:
What|Removed |Added
Target||powerpc64le-gnu-linux
Bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
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=98873
Bug ID: 98873
Summary: PowerPC test
gcc.target/powerpc/ppc-fortran/ieee128-math.f90 now
fails
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
Bug ID: 98872
Summary: ICE leads to SEGV on MMA test case
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96137
--- Comment #5 from Marek Polacek ---
A more realistic test:
void
fn ()
{
X.operator T();
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871
1zeeky at gmail dot com changed:
What|Removed |Added
Attachment #50077|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871
Bug ID: 98871
Summary: Cannot silence -Wmaybe-uninitialized at declaration
site
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98866
--- Comment #1 from Andrew Macleod ---
Very large function (16000+ basic blocks) with a lot of exception regions, and
a pattern whereby about 300 pointers are live to all the regions. We spend a
lot of time propagating an unchanging non-zero prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #12 from Jan Hubicka ---
> > Honza, any ideas on this?
> The comment on assert says
> /* In LTO mode we may have speculative edges set. */
> gcc_assert (in_lto_p || size_info->size == size_info->self_size);
>
> Which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #11 from Jan Hubicka ---
> Honza, any ideas on this?
The comment on assert says
/* In LTO mode we may have speculative edges set. */
gcc_assert (in_lto_p || size_info->size == size_info->self_size);
Which seems expecte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
Marek Polacek changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
--- Comment #18 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:513ee7d2cd9a60339a50dc9c4cba39a8f1c707f0
commit r11-6963-g513ee7d2cd9a60339a50dc9c4cba39a8f1c707f0
Author: Marek Polacek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58354
--- Comment #2 from 1zeeky at gmail dot com ---
This has been fixed as of gcc 10.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
--- Comment #12 from CVS Commits ---
The releases/gcc-8 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:dd1537924e18e87a44abbd4063de89f7b48c60d5
commit r8-10744-gdd1537924e18e87a44abbd4063de89f7b48c60d5
Author: Harald Anlauf
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
--- Comment #11 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:2d9597f400e3456240e4499c9a9bc7023380247f
commit r9-9209-g2d9597f400e3456240e4499c9a9bc7023380247f
Author: Harald Anlauf
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-01-28
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
--- Comment #10 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:0f42bb8722204fb83dcd001cc4254ad25b969402
commit r10-9308-g0f42bb8722204fb83dcd001cc4254ad25b969402
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #30 from cqwrteur ---
> Great. So build with --disable-libstdcxx-verbose as well and stop
> complaining about a feature that other people find useful.
But even GCC bootstraps itself with EH, RTTI disabled (of course you are not
allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
david.welch at netronome dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870
Bug ID: 98870
Summary: [11 regression] assembler output count off for
gcc.target/powerpc/ppc-fortran/ieee128-math.f90 after
r11-6959
Product: gcc
Version: 11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #29 from cqwrteur ---
(In reply to Jakub Jelinek from comment #23)
> And memcpy must be provided as documented in the GCC documentation:
> Most of the compiler support routines used by GCC are present in
> @file{libgcc}, but there are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83927
--- Comment #5 from Dominique d'Humieres ---
> Seems fixed... I'll try to commit the test case this evening.
I still get
31 | M = v_array_par(1)%MyFunc()
| 1
Error: Cannot convert TYPE(mytype) to REAL(4) at (1)
with
module Typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #24 from Jakub Jelinek ---
Actually asm (".global pthread_cond_init"); (etc.) is probably better, doesn't
need relocations, just adds the symbol to the symtab as non-weak.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #23 from Jakub Jelinek ---
Unaware of extern directive in gas.
I'd think (but it would need to be surrounded by configury checks) that
something like:
.section .gnu.need.pthread_cond, "e"
.8byte pthread_cond_init
...
.previous
where y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #22 from Jonathan Wakely ---
In that case it finds the no-op symbol in libc.so.6 and doesn't crash.
$ g++ cv.C -g -Wl,--trace-symbol=pthread_cond_destroy
/usr/bin/ld: /lib64/libc.so.6: definition of pthread_cond_destroy
This fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #28 from cqwrteur ---
(In reply to cqwrteur from comment #27)
> > But portable code can't rely on deterministict exceptions either, yet you
> > insist that it's essential and you can't live without it. It seems you're
> > quite happy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #21 from Jakub Jelinek ---
So how does that work for dynamic linking when -lpthread is not linked in?
Does it crash too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #27 from cqwrteur ---
> But portable code can't rely on deterministict exceptions either, yet you
> insist that it's essential and you can't live without it. It seems you're
> quite happy to rely on non-standard things when it suits y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98862
--- Comment #3 from Ye Luo ---
Cool. -foffload=-latomic resolved my problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #20 from Jonathan Wakely ---
I don't think so. The linker just doesn't resolve the undefined weak symbol for
pthread_cond_destroy is left equal to zero, and so there's a segfault when it
gets called.
$ g++ cv.C -static -g -Wl,--trace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #26 from Jonathan Wakely ---
(In reply to cqwrteur from comment #24)
> (In reply to Jonathan Wakely from comment #22)
> > (In reply to cqwrteur from comment #20)
> > > 1. Freestanding C++ in the current situation is very problematic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #25 from cqwrteur ---
> > 1. Freestanding C++ in the current situation is very problematic. (You do
> > not have memcpy, you do not have std::move. You do not have std::forward.
> > You do not have std::addressof(). you do not have st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #24 from cqwrteur ---
(In reply to Jonathan Wakely from comment #22)
> (In reply to cqwrteur from comment #20)
> > 1. Freestanding C++ in the current situation is very problematic. (You do
> > not have memcpy, you do not have std::mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97701
--- Comment #7 from Vladimir Makarov ---
I've reproduced it on gcc-10 branch.
For some reason, LRA does not change register class for reload pseudo.
This bug will take some time for a fix as the fix will probably affect very
sensitive part of L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #23 from Jakub Jelinek ---
And memcpy must be provided as documented in the GCC documentation:
Most of the compiler support routines used by GCC are present in
@file{libgcc}, but there are a few exceptions. GCC requires the
freestand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #22 from Jonathan Wakely ---
(In reply to cqwrteur from comment #20)
> 1. Freestanding C++ in the current situation is very problematic. (You do
> not have memcpy, you do not have std::move. You do not have std::forward.
> You do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98869
--- Comment #2 from Jakub Jelinek ---
It is required by OpenMP 4.5, and the OpenMP 5.0 support that allows this is
not finished yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98869
--- Comment #1 from Ye Luo ---
Full source code at
https://github.com/QMCPACK/qmcpack/blob/a23584738485bb7c948d0ba1841c669fe76500b6/src/Particle/SoaDistanceTableABOMPTarget.h#L63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #21 from Jonathan Wakely ---
(In reply to cqwrteur from comment #20)
> (In reply to Jonathan Wakely from comment #19)
> > (In reply to cqwrteur from comment #16)
> > > That does not work in the real-world since your libstdc++'s freest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98869
Bug ID: 98869
Summary: Allowing mapping this in OpenMP target
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #19 from Jakub Jelinek ---
Is that because some functions are also in libc.a and not just in libpthread.a?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #20 from cqwrteur ---
(In reply to Jonathan Wakely from comment #19)
> (In reply to cqwrteur from comment #16)
> > That does not work in the real-world since your libstdc++'s freestanding
> > header never works correctly, (you get com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #18 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #17)
> (In reply to Jakub Jelinek from comment #16)
> The example in comment 0 fails on Fedora. Nothing in libstdc++.a causes
> anything from libpthread.o to be us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #19 from Jonathan Wakely ---
(In reply to cqwrteur from comment #16)
> That does not work in the real-world since your libstdc++'s freestanding
> header never works correctly, (you get compilation errors).
Try reporting a bug about *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #17 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #16)
> Are those weak refs from libstdc++.a objects or from the user *.o files?
>From libstdc++.a
> If the former, perhaps we could declare some libstdc++ APIs (re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #17 from cqwrteur ---
(In reply to Jonathan Wakely from comment #15)
> > > (In reply to cqwrteur from comment #12)
> > > > stdio.h should not get included in any circumstances for EH. You are
> > > > implementing the operating system,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #16 from cqwrteur ---
(In reply to Jonathan Wakely from comment #15)
> > > (In reply to cqwrteur from comment #12)
> > > > stdio.h should not get included in any circumstances for EH. You are
> > > > implementing the operating system,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98730
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #15 from Jonathan Wakely ---
> > (In reply to cqwrteur from comment #12)
> > > stdio.h should not get included in any circumstances for EH. You are
> > > implementing the operating system, but you need to enable EH by the
> > > stand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98730
--- Comment #5 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:31a0ab9213f780d2fa1da6e4879df214c0f247f9
commit r11-6961-g31a0ab9213f780d2fa1da6e4879df214c0f247f9
Author: Christophe Lyon
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #16 from Jakub Jelinek ---
Are those weak refs from libstdc++.a objects or from the user *.o files?
If the former, perhaps we could declare some libstdc++ APIs (related to
threading) as requiring linking of -lpthread and made them non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #14 from cqwrteur ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to cqwrteur from comment #11)
> > Functions without thread-safety are always terrible. Like all functions in
> > cctype. They should be avoided like plag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #13 from Jonathan Wakely ---
(In reply to cqwrteur from comment #11)
> Functions without thread-safety are always terrible. Like all functions in
> cctype. They should be avoided like plague.
It's thread-safe though. What are you tal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #15 from Jonathan Wakely ---
And the static libc++.a doesn't use weak symbols, so you need to link to
libpthread youself, and the necessary symbols get pulled in correctly.
The problem for libstdc++.a is that the weak symbols do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98065
seurer at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #12 from cqwrteur ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to cqwrteur from comment #3)
> > Relying on stdio.h even stdio.h is not freestanding.
>
> Nonsense.
stdio.h should not get included in any circumstance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #14 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #13)
> Maybe libc++ doesn't bother with supporting not linking against -lpthread.
libc++ is linked to libpthread.so unconditionally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97684
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #11 from cqwrteur ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to cqwrteur from comment #3)
> > Relying on stdio.h even stdio.h is not freestanding.
>
> Nonsense.
>
> (In reply to cqwrteur from comment #4)
> > BTW.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #10 from Jonathan Wakely ---
(In reply to cqwrteur from comment #3)
> Relying on stdio.h even stdio.h is not freestanding.
Nonsense.
(In reply to cqwrteur from comment #4)
> BTW. std::terminate() is not thread-safe which is terrible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98848
--- Comment #4 from Jakub Jelinek ---
Alternatively, couldn't we support truncation in the reductions if
SSA_NAME_RANGE_INFO suggests that the values are always in the narrower range?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|10.3|12.0
Summary|[10/11 Regress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98848
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Summ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #13 from Jakub Jelinek ---
Maybe libc++ doesn't bother with supporting not linking against -lpthread.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Keegan Saunders changed:
What|Removed |Added
CC||ksaunders at nowsecure dot com
--- Com
1 - 100 of 182 matches
Mail list logo
