Hi!
On 2022-12-10T07:39:24+0100, I wrote:
> I've pushed "Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust"
> to master branch in commit 325529e21e81fbc3561d2568cb7e8a26296e5b2f, see
> attached.
>
> Please let me know if there is anything that I need to do to actually
> generate the
Hi!
On 2022-12-10T07:39:24+0100, I wrote:
> I've pushed "Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust"
> to master branch in commit 325529e21e81fbc3561d2568cb7e8a26296e5b2f, see
> attached.
>
> Please let me know if there is anything that I need to do to actually
> generate the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105207
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55242
Andrew Pinski changed:
What|Removed |Added
CC||pavel.morozkin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-12-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Target
On Fri, 2022-12-09 at 11:07 +0100, Martin Liška wrote:
> Hi.
>
> As make 4.4 has been release, it switches to FIFO by default. That makes
> troubles to the latest GCC release, version 12. Right now, we've been using
> the following 4 patches in openSUSE gcc12 package:
>
>
Hi!
On 2022-12-06T12:03:56+0100, Richard Biener via Gcc-patches
wrote:
> On Tue, Dec 6, 2022 at 11:11 AM wrote:
>> This patchset contains the fixed version of our most recent patchset. [...]
>
> Thanks a lot - this is OK to merge now
Hey, hey! :-)
Still working on some final edits to make
Hi!
On 2022-12-06T12:03:56+0100, Richard Biener via Gcc-patches
wrote:
> On Tue, Dec 6, 2022 at 11:11 AM wrote:
>> This patchset contains the fixed version of our most recent patchset. [...]
>
> Thanks a lot - this is OK to merge now
Hey, hey! :-)
Still working on some final edits to make
I omit the body of resize_screen() and place its instructions
directly in main(), then the analyzer doesn't report anything is wrong. It
seems the extra layer of indirection with the resize_screen() function trips it
up.
This problem happens with GCC 11.3.0, 12.1.0, and 13.0-20221209 nightly from
Compile
sable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-4583-20221209191939-g71b31d13757-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221209 (experimental) (GCC)
zstd
gcc version 13.0.0 20221209 (experimental) (GCC)
On Fri, Dec 9, 2022 at 7:17 PM 刘畅 via Gcc wrote:
>
> Hi all,
>
> I met a problem when I was testing the weak attribute and the weakref
> attribute of GCC. I've read the documentation and in the 6.33.1 Common
> Function Attributes - weakref part I found:
>
> Without a target given as an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108042
Andrew Pinski changed:
What|Removed |Added
Known to work||4.5.3
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108042
Bug ID: 108042
Summary: [10/11/12/13 Regression] weakref on an extern decl is
incorrectly ignored
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords:
Hi all,
I met a problem when I was testing the weak attribute and the weakref
attribute of GCC. I've read the documentation and in the 6.33.1 Common
Function Attributes - weakref part I found:
Without a target given as an argument to weakref or to alias,
weakref is equivalent to weak (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107995
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
--- Comment #15 from Steve Kargl ---
On Sat, Dec 10, 2022 at 01:47:44AM +, barrowes at alum dot mit.edu wrote:
>
> Thanks for engaging, and thanks for the suggestion. I might be able to do this
> over the winter. Could you give me a hint as
Thank you for your response.
Jonathan Wakely 于2022年12月9日周五 22:40写道：
> This question belongs on the gcc-help mailing list, not here.
>
> On Fri, 9 Dec 2022 at 12:01, hongjie wu via Gcc wrote:
> >
> > Dear Sir or Madam，
> > I want to know how to obtain optimal level of the value of the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
--- Comment #14 from Ben Barrowes ---
Thanks for engaging, and thanks for the suggestion. I might be able to do this
over the winter. Could you give me a hint as to where to look. Which files.
On Wed, Dec 7, 2022 at 4:22 PM Ian Lance Taylor wrote:
>
> This patch adds zstd support to libbacktrace, to support the new
> linker option --compress-debug-sections=zstd.
This patch rewrites and simplifies the main zstd decompression loop
using some ideas from the reference implementation.
While writing the ChangeLog entries git gcc-verify spotted an oversight
with v3 of this patch set. I had forgotten to post gm2.texi and also a
tiny patchlet in gcc/configure.ac (to detect Python). HAVE_PYTHON is
used within gcc/m2/Make-lang.in to avoid generating the library section
included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108000
Eugene Rozenfeld changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921
--- Comment #3 from Andrew Pinski ---
The following patterns has the same problem too:
(define_insn "aarch64_bfdot_lane"
[(set (match_operand:VDQSF 0 "register_operand" "=w")
(plus:VDQSF
(unspec:VDQSF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921
--- Comment #2 from Andrew Pinski ---
(define_insn "aarch64_bfmlal_lanev4sf"
[(set (match_operand:V4SF 0 "register_operand" "=w")
(plus: V4SF (match_operand:V4SF 1 "register_operand" "0")
(unspec:V4SF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #15 from Thomas Neumann ---
> You cannot use 'relaxed' atomic load in is_object_initialized - as thread
> performing such load will not observe/synchronize with any modifications
> (other than atomic variable itself) performed by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108041
Bug ID: 108041
Summary: ivopts results in extra instruction in simple loop
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Snapshot gcc-11-20221209 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20221209/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872
--- Comment #8 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:01254aa2eb766c7584fd047568d7277d4d65d067
commit r13-4585-g01254aa2eb766c7584fd047568d7277d4d65d067
Author: Paul Thomas
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039
--- Comment #2 from Andrew Pinski ---
I did something similar years ago:
https://gcc.gnu.org/pipermail/gcc-patches/2010-October/297761.html
https://gcc.gnu.org/pipermail/gcc-patches/2010-October/297762.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108040
Bug ID: 108040
Summary: -fdevirtualize causes part of function to be missing
in output
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Hi Harald,
Thanks for doing that. My attention is elsewhere gfortran-wise.
Good for mainline.
Paul
On Fri, 9 Dec 2022 at 21:27, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> I am submitting the attached simple - and obvious - patch on
> behalf of Paul. It prevents a resource exhaustion
Here during partial instantiation of the constexpr if, extra_local_specs
walks the statement looking for local specializations within to save and
possibly capture. However, we're thwarted by the fact that 'ts' first
appears inside an unevaluated context, and so the calls to
process_outer_var_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039
Andrew Pinski changed:
What|Removed |Added
Target|riscv-64|riscv64 aarch64
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039
Bug ID: 108039
Summary: Unnecessary extension on riscv-64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot
Dear all,
I am submitting the attached simple - and obvious - patch on
behalf of Paul. It prevents a resource exhaustion due to an
infinite loop, and has been regtested by multiple contributers, ;-)
at least on x86_64-pc-linux-gnu.
I intend to commit it to mainline within 24 hours, unless
there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108038
Bug ID: 108038
Summary: GCC generates poor code for select of consecutive
constants
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
On 2022-12-09 14:23, Georg-Johann Lay wrote:
There is the following code size regression, filed as
https://gcc.gnu.org/PR90706
I am sorry, I feel your frustration. I was not aware of this PR.
Unfortunately, the PR was marked as P4 and I have too many open PRs and
should prioritize them.
Found when working on the just submitted/committed patch.
I intent to commit it to mainline as obvious tomorrow (or Sun or Mon),
unless there are comments.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107579
--- Comment #7 from Patrick Palka ---
This is essentially a dup of PR100295, except here the unevaluated context is a
requires-expr instead of sizeof, and r12-2862 exposed this bug by making us
correctly recognize a requires-expr as an
On Fri, Dec 09, 2022 at 09:14:55PM +0100, Tobias Burnus wrote:
> Implementing the 5.1 syntax inside the 'allocate' clause. That's a
> fallout of working on something else...
>
> OK for mainline?
>
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße
On 12/9/22 21:19, Alejandro Colomar wrote:
Hi Martin,
On 12/9/22 21:04, mse...@gmail.com wrote:
Most of these warnings are designed to find simple mistakes in common use
cases so "tricky," unusual, or otherwise unexpected code is likely to lead to
surprises. This warning expects that in
Hi Martin,
On 12/9/22 21:04, mse...@gmail.com wrote:
Most of these warnings are designed to find simple mistakes in common use cases so
"tricky," unusual, or otherwise unexpected code is likely to lead to surprises.
This warning expects that in calls to a function, every parameter declared
Implementing the 5.1 syntax inside the 'allocate' clause. That's a
fallout of working on something else...
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
> On Dec 6, 2022, at 9:22 AM, Alejandro Colomar via Gcc wrote:
>
> Hi!
>
> In the following function, past_end is a pointer to one-past-the-end of the
> array. Holding such a pointer is legal in C. I use it as a sentinel value
> that helps (1) avoid overrunning the buffer, and (2) detect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107495
--- Comment #3 from Andrew Pinski ---
(In reply to Giuseppe D'Angelo from comment #1)
> Variation of the above:
The testcase in comment #1 is almost definitely the same as PR 59328.
Note the testcase in comment #0 is also rejected by clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
kargl at gcc dot gnu.org changed:
What|Removed |Added
Severity|normal |enhancement
There is the following code size regression, filed as
https://gcc.gnu.org/PR90706
Simple test cases are, for example
#define PORT (*((unsigned char volatile*) 0x24))
unsigned short var16;
void func (void)
{
if (2048000ul * var16 > 120ul)
PORT |= 1;
}
When I compile it with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036
--- Comment #5 from Alejandro Colomar ---
Interesting. Thanks for clarifying :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036
--- Comment #4 from Andrew Pinski ---
(In reply to Alejandro Colomar from comment #3)
> - In the reduced test case, you call the pointer to one past the end as
> 'end'. That is misleading, since 'end' is commonly also used for pointers
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036
--- Comment #3 from Alejandro Colomar ---
Hi Andrew!
Just a few nitpicks:
- In the first testcase you posted, the [] is missing the 0: [0].
- In the reduced test case, you call the pointer to one past the end as 'end'.
That is misleading,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036
--- Comment #2 from Andrew Pinski ---
Created attachment 54056
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54056=edit
Reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036
--- Comment #1 from Andrew Pinski ---
Created attachment 54055
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54055=edit
Full testcase that actually compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108035
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108037
Bug ID: 108037
Summary: prefer for affinity with OMP_PROC_BIND=true to match
"spread" instead of "close"
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108035
--- Comment #2 from Jonathan Wakely ---
Right, if Clang doesn't provide a name then there's nothing libstdc++ can do
about it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108035
--- Comment #1 from Jakub Jelinek ---
That looks solely like a clang issue. It implements the builtin gcc has added
for - __builtin_source_location () - but fills in
_M_function_name
with just "" rather than a pretty name.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997
--- Comment #10 from Jan-Benedict Glaw ---
I gave that patch a try: GCC build is successful, as is the Linux build
afterwards using that toolchain. (Cannot test the resulting kernel of
course---I don't have the hardware.)
Changes since v1:
- Fixed formatting issues.
- Added a name to the define_insn_and_split pattern.
- Set the target on the 'dg-do compile' in pr106602.c.
- Removed the rv32 restriction in pr95632.c.
-- >8 --
Due to RISC-V limitations on operations with big
Model the divider in Lujiazui processors as a separate automaton to
significantly reduce the overall model size. This should also result
in improved accuracy, as pipe 0 should be able to accept new
instructions while the divider is occupied.
It is unclear why integer divisions are modeled as if
Thanks Iain for the summary/thanks everyone for the discussion!
On Fri, Dec 9, 2022 at 9:33 AM Iain Sandoe wrote:
>
> Hello all.
>
> > On 9 Dec 2022, at 01:58, chuanqi.xcq wrote:
> >
> > It looks like `-fmodule-file` is better from the discussion. So let's take
> > it. Thanks for everyone here
When registering an unwind frame with __register_frame_info_bases
we currently initialize that fde object eagerly. This has the
advantage that it is immutable afterwards and we can safely
access it from multiple threads, but it has the disadvantage
that we pay the initialization cost even if the
Hello all.
> On 9 Dec 2022, at 01:58, chuanqi.xcq wrote:
>
> It looks like `-fmodule-file` is better from the discussion. So let's take
> it. Thanks for everyone here
So FAOD (after this discussion) Chuanqi's current patchset implements the
following in clang:
-fmodule-output
- this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036
Bug ID: 108036
Summary: Spurious warning for zero-sized array parameters to a
function
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Hi Richard,
On 12/7/22 09:17, Richard Biener wrote:
[...]
The warnings are invalid. While it's true that I'm referencing a pointer of
size 0, it's false that I'm "accessing 1 byte" in that region. I guess this is
all about the bogus design of 'static' in ISO C, where you can have an array
Hi!
I expect mempcpy(3) to be at least as fast as memcpy(3), since it performs the
same operations, with the exception that mempcpy(3) returns something useful (as
opposed to memcpy(3), which could perfectly return void), and in fact something
more likely to be in cache, if the copy is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108035
Bug ID: 108035
Summary: std::source_location::function_name() provides an
empty string when used with clang++
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #43 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #42)
> On #c0 foo, this was previously optimized in dom2 which optimized
> _4 = ABS_EXPR ;
> _3 = _4 u>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107333
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108034
Bug ID: 108034
Summary: cannot use bug alias name in see also
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: web
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106658
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106657
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106653
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-12-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106650
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105595
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652
Andrew Pinski changed:
What|Removed |Added
CC||thiago at kde dot org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105509
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104951
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi!
I'd like to ping a few pending patches:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606973.html
- PR107465 - c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607104.html
- PR107465 - c-family: Incremental fix for
Wilco Dijkstra writes:
> Enable TARGET_CONST_ANCHOR to allow complex constants to be created via
> immediate add.
> Use a 24-bit range as that enables a 3 or 4-instruction immediate to be
> replaced by
> 2 additions. Fix the costing of immediate add to support 24-bit immediate
> and 12-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104471
--- Comment #2 from Andrew Pinski ---
This patch should fix the issue (I might get to it in a few weeks though):
diff --git a/libcpp/files.cc b/libcpp/files.cc
index a18b1caf48d..eb90fa4f65a 100644
--- a/libcpp/files.cc
+++ b/libcpp/files.cc
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104471
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
--- Comment #4 from Jakub Jelinek ---
(In reply to Matthias Kretz (Vir) from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > I bet by adding too many always_inline functions that call normal inlines
> > that is what is bound to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108033
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108033
Bug ID: 108033
Summary: -G should be an alias to -msmall-data-limit=
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
--- Comment #3 from Matthias Kretz (Vir) ---
(In reply to Jakub Jelinek from comment #2)
> I bet by adding too many always_inline functions that call normal inlines
> that is what is bound to happen, one runs into inline growth limits. It is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108032
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
On Tue, Dec 06, 2022 at 08:45:07AM +0100, Tobias Burnus wrote:
> 32bit vs. 64bit: libgomp itself is compiled with both -m32 and -m64; however,
> nvptx and gcn requires -m64 on the device side and assume that the device
> pointers are representable on the host (i.e. all are 64bit). The new code
>
This question belongs on the gcc-help mailing list, not here.
On Fri, 9 Dec 2022 at 12:01, hongjie wu via Gcc wrote:
>
> Dear Sir or Madam，
> I want to know how to obtain optimal level of the value of the
What do you mean by optimal?
They have pros and cons.
> specific compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107977
Andrew Pinski changed:
What|Removed |Added
Summary|[11/12/13 Regression] ICE: |ICE: in
|in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108032
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
--- Comment #9 from fiesh at zefix dot tv ---
I forgot to mention that my test case requires -flto to be present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108032
Bug ID: 108032
Summary: internal compiler error : in final_scan_insn_1, at
final.c:3079
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
1 - 100 of 150 matches
Mail list logo
