https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #7 from cqwrteur ---
configure:3736: $? = 0
configure:3725: /home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960
--- Comment #27 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:a523add327c6cfdd68cf9b788ea808068d0f508c
commit r11-6948-ga523add327c6cfdd68cf9b788ea808068d0f508c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #3 from Martin Liška ---
(In reply to Richard Biener from comment #2)
> The cxx bench Botan doesn't know --cxxflags, what Botan version are you
> looking at?
I used this fixed version:
https://gitlab.suse.de/marxin/cpp-benchmarks/-/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #8 from cqwrteur ---
I tried to build this commit and it is successful.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0411ae7f08e0f5a8b02ff313d26d27a0f6d1bb34
which means it is another commit that breaks it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
--- Comment #9 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:33a7a93218b1393d0135e3c4a9ad9ced87808f5e
commit r11-6950-g33a7a93218b1393d0135e3c4a9ad9ced87808f5e
Author: Harald Anlauf
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #9 from cqwrteur ---
I tried to build this commit and it is successful.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0411ae7f08e0f5a8b02ff313d26d27a0f6d1bb34
which means it is another commit that breaks it.
Daily bump of 2021-01-18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
Jakub Jelinek changed:
What|Removed |Added
CC|jakub at redhat dot com|
--- Comment #10 from Jakub Jelin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #11 from cqwrteur ---
(In reply to Jakub Jelinek from comment #10)
> In that range guess the only important change was the switch from -gdwarf-4
> to -gdwarf-5 by default. So either a bug in your assembler or linker or
> something el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #12 from Jakub Jelinek ---
So you need to figure it out, most people here don't have any access to
Windows.
If mingw64 is using binutils, there were important DWARF 5 related bugs in in
binutils 2.35, but for the known ones we've adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #13 from cqwrteur ---
$ as --version
GNU assembler (GNU Binutils) 2.35.1
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98294
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #4 from Richard Biener ---
Slow:
Samples: 4K of event 'cycles:u', Event count (approx.): 4565667242
Overhead Samples Command Shared Object Symbol
30.88% 1252 botanlibbo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #14 from cqwrteur ---
(In reply to Jakub Jelinek from comment #12)
> So you need to figure it out, most people here don't have any access to
> Windows.
> If mingw64 is using binutils, there were important DWARF 5 related bugs in
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #15 from Liu Hao ---
Why did you add me in CC without asking for my acknowledgement?
If you had asked MSYS2 people, I am pretty sure you would have received more
constructive suggestions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #1 from Jonathan Wakely ---
(In reply to cqwrteur from comment #0)
> The mailing list requires me to request the feature here. I put it here.
> https://www.mail-archive.com/gcc@gcc.gnu.org/msg94104.html
> "However, I desperately need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #2 from cqwrteur ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to cqwrteur from comment #0)
> > The mailing list requires me to request the feature here. I put it here.
> > https://www.mail-archive.com/gcc@gcc.gnu.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #3 from cqwrteur ---
> Ridiculous claims like "totally unusable" aren't going to convince anybody.
It is totally unusable. Binary bloat of runtime in bare-metal systems. Relying
on stdio.h even stdio.h is not freestanding.
C++ EH is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #4 from cqwrteur ---
(In reply to cqwrteur from comment #3)
> > Ridiculous claims like "totally unusable" aren't going to convince anybody.
>
> It is totally unusable. Binary bloat of runtime in bare-metal systems.
> Relying on stdio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #5 from cqwrteur ---
(In reply to cqwrteur from comment #4)
> (In reply to cqwrteur from comment #3)
> > > Ridiculous claims like "totally unusable" aren't going to convince
> > > anybody.
> >
> > It is totally unusable. Binary bloa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #39 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:f7a6d314e7f7eeb6240a4f62511c189c90ef300c
commit r11-6951-gf7a6d314e7f7eeb6240a4f62511c189c90ef300c
Author: Eric Botcazou
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #40 from CVS Commits ---
The releases/gcc-10 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:4be929be0317b2baf1c67b430ad0a2fbaed05152
commit r10-9307-g4be929be0317b2baf1c67b430ad0a2fbaed05152
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #41 from CVS Commits ---
The releases/gcc-9 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:faed344ee5f17b9a19961b3b1f8ea0ed10db6f2d
commit r9-9208-gfaed344ee5f17b9a19961b3b1f8ea0ed10db6f2d
Author: Eric Botcazou
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98499
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98331
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #5 from Richard Biener ---
Looks like STLF issues. There's a ls_stlf counter, with SLP vectorization
disabled I see
34.39% 1417 botanlibbotan-2.so.17 [.]
Botan::Block_Cipher_Fixed_Params<16ul, 16ul, 0ul, 1ul, Botan:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98331
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|9.4 |8.5
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #6 from Richard Biener ---
The following testcase reproduces the assembly:
typedef __UINT64_TYPE__ uint64_t;
void poly_double_le2 (unsigned char *out, const unsigned char *in)
{
uint64_t W[2];
__builtin_memcpy (&W, in, 16);
ui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
Bug ID: 98863
Summary: WRF with LTO consumes a lot of memory in split2 pass
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
--- Comment #8 from Stam Markianos-Wright ---
I have a liiitle bit more progress here, but I have a question about
vect_get_smallest_scalar_type.
If we look at the comment before the function:
>/* Return the smallest scalar part of STMT_INFO.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
Stam Markianos-Wright changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |stammark at gcc dot
gnu.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #7 from Richard Biener ---
OK, and the spill is likely because we expand as
(insn 7 6 0 (set (reg:TI 84 [ _9 ])
(mem:TI (reg/v/f:DI 93 [ in ]) [0 MEM <__int128 unsigned> [(char *
{ref-all})in_8(D)]+0 S16 A8])) -1
(nil))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
--- Comment #9 from rsandifo at gcc dot gnu.org
---
(In reply to Stam Markianos-Wright from comment #8)
> I have a liiitle bit more progress here, but I have a question about
> vect_get_smallest_scalar_type.
>
> If we look at the comment before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98770
--- Comment #1 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:af66f4f1b06f5e0c099dfced2fcf7b1b23fa53e7
commit r11-6954-gaf66f4f1b06f5e0c099dfced2fcf7b1b23fa53e7
Author: Nathan Sidwell
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98770
Nathan Sidwell changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98761
Nathan Sidwell changed:
What|Removed |Added
Last reconfirmed||2021-01-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98862
Jakub Jelinek changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
--- Comment #10 from Richard Biener ---
Still reproduces on trunk with -fdisable-tree-fre4.
So the issue is that for the case of 'long int' and 'float'
get_vectype_for_scalar_type when passed 8 as group_size returns
V8DI and V4SF - where eventua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98864
Bug ID: 98864
Summary: Warning for unnecessary final keyword
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #2 from Richard Biener ---
Huh. I guess you need to trace that with detailed mem stats, split itself
should be really OK it should be linear in the number of (split) insns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #3 from Martin Liška ---
It's 521.wrf_r from SPEC 2017.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98331
--- Comment #4 from Jakub Jelinek ---
Created attachment 50073
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50073&action=edit
gcc11-pr98331.patch
Untested fix. If there are debug insns in between a flow control insn and
barrier after it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98865
Bug ID: 98865
Summary: Missed transform of (a >> 63) * b
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98865
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98866
Bug ID: 98866
Summary: [11 Regresion] Compile time hog in VRP since
r11-3685-gfcae5121154d1c33
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: compile-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #4 from Martin Liška ---
Created attachment 50075
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50075&action=edit
time and memory report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98862
--- Comment #2 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #1)
> libstdc++-v3 isn't supported ATM on either nvptx* or amdgcn* offloading, so
> if one needs anything from libstdc++, it will not work.
I can confirm that it does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #5 from Richard Biener ---
So GC memory according to -ftime-report isn't so bad. tail of sorted (after
time):
TOTAL : 25.40 0.32 25.75
244M
TOTAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98294
David Malcolm changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #6 from Richard Biener ---
df-problems.c:228 (df_rd_alloc)702M: 6.9% 705M
18M: 0.7% 0 0 heap
df-problems.c:509 (df_rd_transfer_function) 3709M: 36.6% 3709M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83927
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98865
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
cqwrteur changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #16 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
Jakub Jelinek changed:
What|Removed |Added
CC|jakub at gcc dot gnu.org |
--- Comment #17 from Jakub Jelin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98867
Bug ID: 98867
Summary: Failure to use SRI instruction for
shift-right-and-insert vector operations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #7 from Martin Liška ---
I set up ulimit -v 16GB and I attached gdb. Allocation failure happens here:
(gdb) p *current_pass
$1 = {
= {
type = RTL_PASS,
name = 0x19f43ae "ree",
(gdb) bt
#0 xmalloc_failed (size=size@entry=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98847
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6bb207b468da36d9d99c63409dc4098514759c90
commit r11-6958-g6bb207b468da36d9d99c63409dc4098514759c90
Author: Jakub Jelinek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33661
--- Comment #18 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6bb207b468da36d9d99c63409dc4098514759c90
commit r11-6958-g6bb207b468da36d9d99c63409dc4098514759c90
Author: Jakub Jelinek
Date: T
c-linux-gnu/11.0.0/lto1
> -quiet -dumpbase ./wrf_r.ltrans34.ltrans -march=znver2 -g0 -Ofast -Ofast
> -version -fno-openacc -fno-pie -fcf-protection=none -fno-openmp -ftime-report
> -fltrans @./wrf_r.ltrans34.ltrans.args.0 -o ./wrf_r.ltrans34.ltrans.s
GNU GIMPLE (GCC) version 11.0.0 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #9 from Richard Biener ---
Ah, I guess -fno-ree on the lto1 command-line gets ignored :/ So yeah, there's
known issues with REE (PR80930 and PR98144).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98570
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #10 from Richard Biener ---
But I wonder why the mem-report doesn't show these? They dont' sum up to 20GB
for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98868
Bug ID: 98868
Summary: [8/9/10/11 Regression] polyhedron rnflow.f90
regression since r8-2555-g344be1fd47d7d64e
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98847
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
Richard Biener changed:
What|Removed |Added
Depends on||80930
--- Comment #11 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #18 from cqwrteur ---
I can confirm it is the commit that breaks the bootstrap on windows 10
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/doc/invoke.texi;h=c290b6f4938f45e8d491d76d4940060e7b59be36;hp=3f30230b0c244245e23e29ea40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98864
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #19 from cqwrteur ---
After reverting the change, the compilation succeeds. However, this is a
temporary solution.
https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/9000-Revert-testsuite-Skip-DWARF-5-testcases-on-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #7 from cqwrteur ---
(In reply to Marek Polacek from comment #6)
> I don't think this is a useful bug report. If/when the proposal gets
> accepted, it will be useful to track who's working on it, but until then I
> see no point.
I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
--- Comment #17 from Marek Polacek ---
Another attempt:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564461.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #8 from cqwrteur ---
(In reply to Marek Polacek from comment #6)
> I don't think this is a useful bug report. If/when the proposal gets
> accepted, it will be useful to track who's working on it, but until then I
> see no point.
Bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98849
--- Comment #12 from Jakub Jelinek ---
Created attachment 50076
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50076&action=edit
gcc11-pr98849.patch
So like this then? From quick skimming of iwmmxt.md, it does have the vector
by scalar sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #9 from Marek Polacek ---
You can clone the gcc repo as explained here https://gcc.gnu.org/git.html and
then start your own local branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96045
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #10 from Jakub Jelinek ---
Honza, any ideas on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91849
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92005
--- Comment #5 from Jakub Jelinek ---
But ideally should be able to adjust already converted switches if e.g. better
range info allows to optimize them further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Keegan Saunders changed:
What|Removed |Added
CC||ksaunders at nowsecure dot com
--- Com
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=98848
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Summ
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
--- 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=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=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=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=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=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=98065
seurer at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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=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=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=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=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
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
1 - 100 of 182 matches
Mail list logo
