https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80135
Martin Liška changed:
What|Removed |Added
CC||nipatriknilsson at gmail dot
com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88746
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #4 from Jürgen Reuter ---
The linker before throws this warning:
ld: warning: direct access in function 'operator new[](unsigned long,
std::nothrow_t const&) [clone .cold]' from file
'/usr/local/lib/libstdc++.a(new_opvnt.o)' to global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71003
--- Comment #5 from Eric Gallager ---
(In reply to Manuel López-Ibáñez from comment #3)
> I'm pretty sure that this applies to all pedantic warnings that occur while
> preprocessing:
>
> const int a0 = 0b101010;
> const int a1 = __extension__ 0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46636
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46495
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88717
--- Comment #6 from 刘袋鼠 ---
(In reply to H.J. Lu from comment #5)
> (In reply to 刘袋鼠 from comment #4)
> >
> > My thought is AVX_U128_DIRTY would be set when ymm/zmm appeared, and
> > AVX_U128_CLEAN for xmm, AVX_U128_ANY for other situations. Thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82295
Eric Gallager changed:
What|Removed |Added
Status|NEW |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88717
--- Comment #5 from H.J. Lu ---
(In reply to 刘袋鼠 from comment #4)
>
> My thought is AVX_U128_DIRTY would be set when ymm/zmm appeared, and
> AVX_U128_CLEAN for xmm, AVX_U128_ANY for other situations. This also works
> for this case.
>
Your cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88717
--- Comment #4 from 刘袋鼠 ---
(In reply to H.J. Lu from comment #3)
> Like this
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index d01278d866f..9b49a2c1d9c 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #18 from Chris Elrod ---
I can confirm that the inlined packing does allow gfortran to vectorize the
loop. So allowing packing to inline does seem (to me) like an optimization well
worth making.
However, performance seems to be ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88747
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88747
--- Comment #2 from David Malcolm ---
Author: dmalcolm
Date: Tue Jan 8 01:39:09 2019
New Revision: 267671
URL: https://gcc.gnu.org/viewcvs?rev=267671&root=gcc&view=rev
Log:
Fix jit test case (PR jit/88747)
Amongst other changes, r266077 update
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #8 from Romain Geissler ---
Your patch is working.
I may add some context to better understand this strange scenario. In my case,
the config log says:
configure:80434: checking for utimensat
configure:80484: x86_64-1a-linux-gnu-g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #29 from Eric Botcazou ---
> Types with linkage are C++ ODR types. They have associated mangled name
> (which is after free lang data available by DECL_ASSEMBLER_NAME of
> the TYPE_DECL of TYPE_NAME) and if the names match in differen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86934
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> The current header doesn't account for the fact that many features
> are not defined for freestanding builds.
>
> Also, the --enable-libstdcxx-filesystem-ts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #7 from Jonathan Wakely ---
What does your $target/libstdc++-v3/config.log show for the utime tests?
With glibc-2.28 I get:
configure:80229: checking for utime.h
configure:80229: result: yes
configure:80254: checking whether to buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #11 from Jonathan Wakely ---
(In reply to Will Wray from comment #9)
> The patch below seems to work as far as I've tested - please review.
>
> It looks like the bool first_initializer_p argument to reshape_init_r
> gives the context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #3 from Jürgen Reuter ---
And I am seeing the same problem on another Macbook (Macbook Air) since roughly
Christmas (maybe a bit before).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #2 from Jürgen Reuter ---
The tests worked till yesterday, but only today major parts of gcc recompiled
because all files in gcc got a new timstamp. I am now trying to recompile also
gmp, mpfr and mpc with the llvm-clang from XCode 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #5 from Romain Geissler ---
Note that it was building fine with gcc commit
4a4bec8257aa255cca9be7f24a61159cadb36942 from Fri Dec 28 (aka r267451), and the
same glibc commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #6 from Jonathan Wakely ---
That makes no sense, because you should have _GLIBCXX_USE_UTIMENSAT defined and
never reach the lines that give errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #17 from Thomas Koenig ---
What an inline packing would (approximately) produce is this:
subroutine processBPP(X, BPP, N)
integer,intent(in) :: N
real, dimension(N,3), intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #4 from Romain Geissler ---
Thanks I will test this ASAP.
I am using x86-64, and a very recent glibc near current master:
GLIBC_VERSION="2.28.90"
GLIBC_COMMIT="0253580a75decdaf22b6abce60d8265b2adb7dea"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #3 from Jonathan Wakely ---
I don't understand why the configure script would not have set
_GLIBCXX_USE_UTIME when utimbuf and utime() are apparently available (because
GCC is suggesting them as alternatives for posix::utimbuf and pos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #28 from Jan Hubicka ---
> > I already did printf debugging and indeed we only need to decide how to
> > adjust type_with_linkage_p so it returns false for all Ada types. Maybe
> > cleanest would be to add flag to TYPE_DECL which C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
Jonathan Wakely changed:
What|Removed |Added
Keywords||build
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #27 from Eric Botcazou ---
> I already did printf debugging and indeed we only need to decide how to
> adjust type_with_linkage_p so it returns false for all Ada types. Maybe
> cleanest would be to add flag to TYPE_DECL which C++ FE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79593
--- Comment #24 from Jeffrey A. Law ---
Given how rare this is, I won't object to trying to deal with it via a
peephole.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
Bug ID: 88750
Summary: [9.0 regression] runtime error in statically binaries
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86020
--- Comment #7 from Bill Schmidt ---
Thanks! I've asked our performance team to re-measure with this change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88701
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Mon Jan 7 22:55:48 2019
New Revision: 267667
URL: https://gcc.gnu.org/viewcvs?rev=267667&root=gcc&view=rev
Log:
PR c/88701
* c-decl.c (build_compound_literal): If not TRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88614
--- Comment #1 from Alan Modra ---
Author: amodra
Date: Mon Jan 7 22:54:40 2019
New Revision: 267666
URL: https://gcc.gnu.org/viewcvs?rev=267666&root=gcc&view=rev
Log:
genattrtab bit-rot, and if_then_else in values
This patch started off just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #1 from Andrew Pinski ---
What target is this on? If Linux what libc (including version)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88726
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88720
Joseph S. Myers changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88726
--- Comment #1 from Joseph S. Myers ---
Author: jsm28
Date: Mon Jan 7 22:39:43 2019
New Revision: 267665
URL: https://gcc.gnu.org/viewcvs?rev=267665&root=gcc&view=rev
Log:
Fix diagnostics for never-defined inline and nested functions (PR c/8872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88720
--- Comment #1 from Joseph S. Myers ---
Author: jsm28
Date: Mon Jan 7 22:39:43 2019
New Revision: 267665
URL: https://gcc.gnu.org/viewcvs?rev=267665&root=gcc&view=rev
Log:
Fix diagnostics for never-defined inline and nested functions (PR c/8872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88748
Harald Anlauf changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #10 from Will Wray ---
Re: warnings; I certainly prefer to have this accepted with no warning
(i.e. remove the 'else if' warning in the patch above).
Saves having to disable the warning in GCC, as I have to do in Clang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
Bug ID: 88749
Summary: Failure while building
libstdc++-v3/src/filesystem/ops.cc on trunk
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #9 from Will Wray ---
The patch below seems to work as far as I've tested - please review.
It looks like the bool first_initializer_p argument to reshape_init_r
gives the context that is needed, according to the function comment;
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84436
--- Comment #13 from Romain Geissler ---
Apparently the clang-tlbgen failures started with r265241. Checking if it still
happens on gcc trunk with r265463 reverted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88748
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56428
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88748
Bug ID: 88748
Summary: IS_CONTIGUOUS mishandles arrays of derived type
components
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88731
--- Comment #2 from joseph at codesourcery dot com ---
GCC makes the integer type of the bit-field in question "unsigned:4".
See DR#315 (also, see the line of C90 DRs that led to the wording changes
in C99 relating to types of bit-fields, refe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88747
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
Thomas Koenig changed:
What|Removed |Added
CC||koenigni at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88721
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Eric Botcazou ---
>> I've just successfully finished a sparc-sun-solaris2.11 with it: worked fine.
>
> Thanks, same for me but for some reason I didn't have the ori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82295
--- Comment #3 from Jonathan Wakely ---
This was already fixed for GCC 8, by r258003
PR c++/84447 - ICE with deleted inherited ctor with default arg.
* call.c (build_over_call): Handle deleted functions in one place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84849
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88747
Bug ID: 88747
Summary: jit testsuite failures: test-sum-of-squares.c.exe (and
test-combination)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87851
--- Comment #6 from Thomas Koenig ---
Here is the result of running f951 with -O under the debugger
and breaking on optimize_expr:
Breakpoint 1, optimize_expr (e=0x2688cf0, walk_subtrees=0x7fffd81c,
data=0x0) at ../../trunk/gcc/fortran/front
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88746
--- Comment #2 from Patrik Nilsson ---
Created attachment 45374
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45374&action=edit
s file produced by the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88746
--- Comment #1 from Patrik Nilsson ---
Created attachment 45373
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45373&action=edit
ii file from the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88746
Bug ID: 88746
Summary: structs: internal compiler error: in
output_constructor_regular_field, at varasm.c:5030
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738
Bug 82738 depends on bug 88728, which changed state.
Bug 88728 Summary: Boostrap with -Og fails with garbled file libgcov-profiler.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88728
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88728
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80916
--- Comment #6 from Davin McCall ---
> The wording could be improved, but why do you think the warning is spurious?
I guess I think that the warning is spurious given the current wording? It may
well be legitimate to warn that there is a declara
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53320
Bug 53320 depends on bug 45424, which changed state.
Bug 45424 Summary: [F08] Add IS_CONTIGUOUS intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39627
Bug 39627 depends on bug 45424, which changed state.
Bug 45424 Summary: [F08] Add IS_CONTIGUOUS intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424
--- Comment #9 from Thomas Koenig ---
Author: tkoenig
Date: Mon Jan 7 19:30:28 2019
New Revision: 267657
URL: https://gcc.gnu.org/viewcvs?rev=267657&root=gcc&view=rev
Log:
2019-01-07 Thomas Koenig
Harald Anlauf
Tobias Burnus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88745
Iain Sandoe changed:
What|Removed |Added
Target||*-*-darwin*
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88745
Bug ID: 88745
Summary: Darwin lacks an implementation for libbacktrace
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88741
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88741
--- Comment #4 from Marek Polacek ---
Author: mpolacek
Date: Mon Jan 7 19:25:41 2019
New Revision: 267656
URL: https://gcc.gnu.org/viewcvs?rev=267656&root=gcc&view=rev
Log:
PR c++/88741 - wrong error with initializer-string.
* d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80912
--- Comment #4 from Eric Gallager ---
(In reply to m...@gcc.gnu.org from comment #3)
> Yes, what you say seems reasonable.
cool, thanks for confirming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82295
Eric Gallager changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283
Eric Gallager changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88692
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88733
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80228
Bernd Edlinger changed:
What|Removed |Added
Keywords|diagnostic, rejects-valid |wrong-code
--- Comment #3 from Bernd Ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88727
--- Comment #1 from joseph at codesourcery dot com ---
This was the case mentioned in bug 26581 comment 4, but without a separate
bug filed for it at the time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88584
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88744
Bug ID: 88744
Summary: class non-type template parameters doesn't work with
default template parameters
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88584
--- Comment #8 from joseph at codesourcery dot com ---
Yes, I consider this a confirmed (and, strictly, regression from 3.4) bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88743
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88711
Dominique d'Humieres changed:
What|Removed |Added
CC||seurer at linux dot
vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88538
Marek Polacek changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88743
Bug ID: 88743
Summary: [9 regression] test case gfortran.dg/pr79966.f90 fails
starting with r267600
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698
Bug 69698 depends on bug 69697, which changed state.
Bug 69697 Summary: incorrect runtime initialization of static flexible array
members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69697
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69697
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698
Bug 69698 depends on bug 69696, which changed state.
Bug 69696 Summary: incorrect initialization of block-scope flexible array
members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69696
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69696
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69338
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698
Bug 69698 depends on bug 69338, which changed state.
Bug 69338 Summary: incorrect ctor initialization of a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69338
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88742
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #4 from Richard Earnshaw ---
manual inspection of the output from gcc-5.4.0 suggests this version produces
correct code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497
Iain Sandoe changed:
What|Removed |Added
Attachment #45369|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88261
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88741
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88742
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994
Bug 59994 depends on bug 84497, which changed state.
Bug 84497 Summary: link errors with trivial external thread_local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497
Iain Sandoe changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88261
--- Comment #12 from Bernd Edlinger ---
Author: edlinger
Date: Mon Jan 7 17:08:51 2019
New Revision: 267653
URL: https://gcc.gnu.org/viewcvs?rev=267653&root=gcc&view=rev
Log:
PR c++/88261
PR c++/69338
PR c++/69696
1 - 100 of 264 matches
Mail list logo
