https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288
--- Comment #6 from Haochen Jiang ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288
--- Comment #5 from GCC Commits ---
The master branch has been updated by Haochen Jiang :
https://gcc.gnu.org/g:4ab847b354ee9e13e6052f78f49f575eae3abf3f
commit r14-7168-g4ab847b354ee9e13e6052f78f49f575eae3abf3f
Author: Haochen Jiang
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 110997, which changed state.
Bug 110997 Summary: [13 Regression] internal compiler error: in
cxx_eval_constant_expression, at cp/constexpr.cc:8005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110997
What|R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107687
Bug 107687 depends on bug 110997, which changed state.
Bug 110997 Summary: [13 Regression] internal compiler error: in
cxx_eval_constant_expression, at cp/constexpr.cc:8005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110997
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110997
Richard Biener changed:
What|Removed |Added
Resolution|FIXED |---
Summary|[13/14 Regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110997
--- Comment #5 from Andrew Pinski ---
Hmm, the target milestone is set to 13.3.0 but only references patches which
have gone in for gcc 14 only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347
Richard Biener changed:
What|Removed |Added
Summary|ICE during gimplification |[13 Regression] ICE during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347
--- Comment #1 from Richard Biener ---
Created attachment 57047
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57047&action=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347
Bug ID: 113347
Summary: ICE during gimplification building TVM
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112280
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112280
--- Comment #10 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:655b6cb1ea3a0e23124d77dccd5d174ac59c429c
commit r14-7166-g655b6cb1ea3a0e23124d77dccd5d174ac59c429c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113346
--- Comment #1 from Richard Biener ---
This was with r14-7159-g1a80e9558dd7fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113346
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code, ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113346
Bug ID: 113346
Summary: [14 Regression] epiphany-elf build failure
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #16 from H.J. Lu ---
I updated users/hjl/pr113312/master branch to handle function pointers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113345
Hongtao Liu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039
--- Comment #4 from GCC Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:75ed46558a2e085ba12641a47112e37f114faee0
commit r14-7164-g75ed46558a2e085ba12641a47112e37f114faee0
Author: liuhongt
Date: Mon Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113345
--- Comment #1 from Hongtao Liu ---
>
> maybe we can just refactor the pattern as blow, then combine can generate
> the pattern for us.
>
> 22115(define_insn "_psign3"
> 22116 [(set (match_operand:VI124_AVX2 0 "register_operand" "=x,x")
> 22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113345
Bug ID: 113345
Summary: miss optimization for psign{b,w,d}.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113338
--- Comment #2 from Brad Richardson ---
The addition of CFI_cdesc_t in 2018 means it is possible to pass
non-interoperable types to C so long as it doesn't need to know anything about
its type (i.e. doesn't try to modify or copy it). And yes, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #15 from H. Peter Anvin ---
That should be fine for this use case, obviously.
I should add the following: the reason the assembly stub isn't a problem for
FRED whereas it is a bit of a nuisance for IDT-style delivery is that with
FR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #14 from H.J. Lu ---
Here is a branch for __attribute__((no_callee_saved_registers)):
https://gitlab.com/x86-gcc/gcc/-/commits/users/hjl/pr113312/master
Calling a function with __attribute__((no_callee_saved_registers))
doesn't wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-01-12
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344
--- Comment #3 from Andrew Pinski ---
https://gcc.gnu.org/pipermail/gcc-regression/2024-January/078983.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344
--- Comment #1 from Andrew Pinski ---
Confirmed, it fails everywhere too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #29 from waffl3x ---
https://cplusplus.github.io/CWG/issues/2789.html
My alteration to CWG2789 came up on reddit and I realized I should
probably post about it here.
Instead of:
"if both are non-static member functions, they have th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #25 from Jonathan Wakely ---
Fixed on trunk only so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344
Bug ID: 113344
Summary: [14 regression] gcc.dg/pr15784-1.c fails after
r14-7139-g897b95a12b7fe5
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113343
Bug ID: 113343
Summary: Float values are not correct when cross-compiling
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110065
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 113200, which changed state.
Bug 113200 Summary: std::char_traits::move is not constexpr when the
argument is a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200
--- Comment #12 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:26a9e8cee4d20e5b08c0336439c8f69a2f06af1c
commit r12-10090-g26a9e8cee4d20e5b08c0336439c8f69a2f06af1c
Author: Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113342
--- Comment #2 from Andrew Pinski ---
Note there was a change between `clang 10` and `clang 11` which changed clang
into accepting the code. So I am 99% sure it is that paper which caused the
change ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113342
--- Comment #1 from Andrew Pinski ---
Note MSVC has the same behavior as GCC here:
```
(13): error C2244: 'Job::create': unable to match function definition
to an existing declaration
(13): note: see declaration of 'Job::create'
(13): note: defi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113342
Bug ID: 113342
Summary: Template parameter does not shadow member enum value.
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105505
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113320
--- Comment #2 from Jonathan Wakely ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642741.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110512
--- Comment #9 from Jonathan Wakely ---
Patch posted for review:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642732.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #8 from Jessica Clarke ---
The clang/ subdirectory should be building itself with -fno-strict-aliasing on
GCC already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #6 from john.harper at vuw dot ac.nz ---
I know nothing about either applying gfortran patches or MatterMost but
I'm willing to try.
On Thu, 11 Jan 2024, jvdelisle at gcc dot gnu.org wrote:
> Date: Thu, 11 Jan 2024 20:18:36 +
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #7 from Andrew Pinski ---
`-fno-lifetime-dse` is already used but I get the feeling there might be strict
aliasing issues in the code though. What happens if you add
-fno-strict-aliasing ?
This code gives me strict aliasing violati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #6 from Andrew Pinski ---
The backtrace in the llvm bug report is not very useful either.
Maybe look into that first to see if it is obvious which function might be
compiling "incorrectly". Maybe there is a bug in the new clang code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #5 from Segher Boessenkool ---
(In reply to John Paul Adrian Glaubitz from comment #3)
> (In reply to Segher Boessenkool from comment #2)
> > We need a reduced testcase.
>
> Any suggestion on how to proceed here?
Nothing in particu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #4 from Andrew Pinski ---
I should mention that LLVM has/had known issues with -flifetime-dse so it might
be useful also to show how stage1 of LLVM/clang was being built.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #3 from John Paul Adrian Glaubitz ---
(In reply to Andrew Pinski from comment #1)
> This could still be a bug in LLVM too.
>
> Without much more information, it is hard to decide.
I fully agree. I filed this bug report to broaden t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #2 from Segher Boessenkool ---
We need a reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
Bug ID: 113341
Summary: Using GCC as the bootstrap compiler breaks LLVM on
32-bit PowerPC
Product: gcc
Version: 13.2.1
URL: https://github.com/llvm/llvm-project/issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113191
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:61b493f17e6fea5a0fb45b6a050259ca326c13a7
commit r14-7157-g61b493f17e6fea5a0fb45b6a050259ca326c13a7
Author: Jason Merrill
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #28 from Jakub Jelinek ---
It doesn't help that the mangling issue doesn't have implementation in form of
a mangling ABI patch, that would help to figure out e.g. whether it either H or
CV-qualifiers ref-qualifiers.
Anyway, I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #27 from Gašper Ažman ---
I think there is an example in the standard that distinguishes those two as
far as overload resolution is concerned.
On Thu, Jan 11, 2024, 21:08 waffl3x at protonmail dot com <
gcc-bugzi...@gcc.gnu.org> wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113308
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113340
--- Comment #2 from Marek Polacek ---
I suppose the following would be one way to fix it:
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -312,6 +312,12 @@ maybe_retrofit_in_chrg (tree fn)
basetype = TREE_TYPE (TREE_VALUE (arg_types));
arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113339
--- Comment #3 from Andrew Pinski ---
So I looked into the wrong part of fold, but anyways PR 23669 added the folding
to fold instead (and I just noticed I implemented it originally).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #26 from waffl3x ---
(In reply to corentinjabot from comment #25)
> Hey folks.
> Congrats on landing support for deducing this in GCC.
Thanks!
> While there is no spec for it, after discussion here,
> https://github.com/itanium-cxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113340
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Ever confirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113340
Bug ID: 113340
Summary: ICE when an explicit object parameter is attempted to
be used in a destructor
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477
--- Comment #11 from GCC Commits ---
The releases/gcc-13 branch has been updated by Francois Dumont
:
https://gcc.gnu.org/g:ffc5684a4d3d3c457e5d311e7088f3487cf5083e
commit r13-8212-gffc5684a4d3d3c457e5d311e7088f3487cf5083e
Author: François Dum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
corentinjabot at gmail dot com changed:
What|Removed |Added
CC||corentinjabot at gmail d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #5 from kargl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113324
Roland Illig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113338
--- Comment #1 from anlauf at gcc dot gnu.org ---
NAG also rejects the code.
The code compiles with gfortran if one declares t interoperable:
type, bind(c) :: t
Note that F2008 still had:
"(5) any dummy argument without the VALUE attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2024-01-11
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113339
--- Comment #2 from Andrew Pinski ---
Note the fold was added here:
https://gcc.gnu.org/pipermail/gcc-patches/1999-October/020476.html .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113339
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #20 from dave.anglin at bell dot net ---
On 2024-01-11 2:05 p.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
>
> --- Comment #19 from Jakub Jelinek ---
> I think stringpool hash table is nev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113339
Bug ID: 113339
Summary: `-a/-b` is not simplified to `a/b` if done in seperate
statements
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #19 from Jakub Jelinek ---
I think stringpool hash table is never purged (unless libgccjit and
reinitializes stuff), so once something is looked up, it will be findable later
on as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #18 from dave.anglin at bell dot net ---
On 2024-01-11 1:25 p.m., jakub at gcc dot gnu.org wrote:
> The allocation is completely intentional, exactly to be able to track whether
> it was referenced or not. Otherwise the exercise make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113338
Bug ID: 113338
Summary: Valid Code Rejected, bind(C) procedure with pointer
argument
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477
--- Comment #10 from GCC Commits ---
The master branch has been updated by Francois Dumont :
https://gcc.gnu.org/g:46afbeb81414302829fbf10c107e5466a3cf44d7
commit r14-7151-g46afbeb81414302829fbf10c107e5466a3cf44d7
Author: François Dumont
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #17 from Jakub Jelinek ---
The allocation is completely intentional, exactly to be able to track whether
it was referenced or not. Otherwise the exercise makes no sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550
--- Comment #4 from Patrick Palka ---
The perfect forwarding issue is incidentally fixed in C++23 mode (when deducing
this is available) after r14-7150-gd2cb4693a0b383.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #16 from dave.anglin at bell dot net ---
On 2024-01-11 12:37 p.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
>
> --- Comment #14 from Jakub Jelinek ---
> (In reply to John David Anglin from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113322
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113322
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:a2be4e155992151b60fca6969a97d6efd91e82b5
commit r14-7149-ga2be4e155992151b60fca6969a97d6efd91e82b5
Author: Andrew Pinski
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:7f56a90269b393fcc55ef08e0990fafb7b1c24b4
commit r14-7148-g7f56a90269b393fcc55ef08e0990fafb7b1c24b4
Author: Andrew Pinski
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #24 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:f50f2efae9fb0965d8ccdb62cfdb698336d5a933
commit r14-7146-gf50f2efae9fb0965d8ccdb62cfdb698336d5a933
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477
--- Comment #9 from Jonathan Wakely ---
I see that this is actually causing lots of failures for PSTL tests when run
with -D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #15 from Jakub Jelinek ---
So, I'm going to bootstrap/regtest:
2024-01-11 John David Anglin
Jakub Jelinek
PR middle-end/113182
* varasm.cc (process_pending_assemble_externals,
assemble_extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #14 from Jakub Jelinek ---
(In reply to John David Anglin from comment #13)
> Although the patch fixes the udlit-namespace.C test, I think the patch
> still isn't correct. I think the code should use maybe_get_identifier
> instead o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012
--- Comment #12 from GCC Commits ---
The releases/gcc-13 branch has been updated by Siddhesh Poyarekar
:
https://gcc.gnu.org/g:db86a6009fc83e8cb21cae49c7c55fc2b1186008
commit r13-8210-gdb86a6009fc83e8cb21cae49c7c55fc2b1186008
Author: Siddhesh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113337
Bug ID: 113337
Summary: Rethrown uncaught exceptions don't invoke
std::terminate if SEH-based unwinding is used
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #13 from John David Anglin ---
Although the patch fixes the udlit-namespace.C test, I think the patch
still isn't correct. I think the code should use maybe_get_identifier
instead of get_identifier. See assemble_name_resolve.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113334
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #13 from Vineet Gupta ---
Yeah Greg from Rivos started working on it. He'll update here as he makes
progress.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #13 from H. Peter Anvin ---
No, it will not. Most OSes flows will want to merge the kernel and user flows
at some point for some handlers, so it isn't clear that that makes sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113336
Bug ID: 113336
Summary: libatomic (testsuite) regressions on
armv6-linux-gnueabihf
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113335
Bug ID: 113335
Summary: [C++23] Implement LWG3617 function/packaged_task
deduction guides and deducing this
Product: gcc
Version: unknown
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
St
1 - 100 of 163 matches
Mail list logo
