This patch correspond to the upstream PR:
https://github.com/libffi/libffi/pull/817
libffi/ChangeLog:
* src/loongarch64/ffi.c: Avoid defining floats
in struct call_context if the ABI is soft-float.
---
libffi/src/loongarch64/ffi.c | 2 ++
1 file changed, 2 insertions(+)
diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
H.J. Lu changed:
What|Removed |Added
Attachment #57233|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113627
--- Comment #1 from Andrew Pinski ---
My gut feeling is there is some variable is not being treated as atomic.
That is there is a race condition somewhere. I am not saying you example code
has a race condition in it but rather that seems like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
--- Comment #5 from GCC Commits ---
The master branch has been updated by Lewis Hyatt :
https://gcc.gnu.org/g:5200ef26ac1771a75596394c20c5f1a348694d5e
commit r14-8465-g5200ef26ac1771a75596394c20c5f1a348694d5e
Author: Lewis Hyatt
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113627
Bug ID: 113627
Summary: Detached tasks released without call to
omp_fulfill_event
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Andrew Pinski changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113626
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113626
Bug ID: 113626
Summary: The r14-8450 commit causes the loongarch
[x]vfcmp-{d/f}.c test case to fail
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
On Mon, Dec 4, 2023 at 11:02 PM Tatsuyuki Ishi wrote:
>
> This implements TLS Descriptors (TLSDESC) as specified in [1].
>
> The 4-instruction sequence is implemented as a single RTX insn for
> simplicity, but this can be revisited later if instruction scheduling or
> more flexible RA is desired.
在 2024/1/26 下午6:57, Xi Ruoyao 写道:
On Fri, 2024-01-26 at 16:59 +0800, chenglulu wrote:
在 2024/1/26 下午4:49, Xi Ruoyao 写道:
On Fri, 2024-01-26 at 15:37 +0800, Lulu Cheng wrote:
v3 -> v4:
1. Add macro support for TLS symbols
2. Added support for loading __get_tls_addr symbol address
The pr113429 testcase fails with newlib spike runs. Adding
require-effective-target rv64 and riscv_v fixes the issue.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/pr113429.c: Add
require-effective-target rv64 and riscv_v
Signed-off-by: Patrick O'Neill
---
Tested using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #13 from Oleg Endo ---
(In reply to Roger Sayle from comment #12)
> It should be mentioned that the fwprop fix for PR11267 also resolved several
> FAILs in gcc.target/sh/pr59533.c. I mention this as tweaking the cost of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113625
Bug ID: 113625
Summary: Interesting behavior with and without -mcpu=generic
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
newlib rv32gcv
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2024-01-27 08:38
To: juzhe.zh...@rivai.ai; gcc-patches
CC: kito.cheng; law; rdapp; vineetg
Subject: Re: [Committed] RISC-V: Add regression test for vsetvl bug pr113429
What target/config are these failures on?
I tried rv64gcv,
What target/config are these failures on?
I tried rv64gcv, rv64gc, rv32gcv, and rv32gc with RUNTESTFLAGS="rvv.exp"
and don't see these failures.
Thanks,
Patrick
On 1/25/24 23:20, juzhe.zh...@rivai.ai wrote:
This patch causes the following regression:
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
x86_64-w64-mingw32
Configured with: ../configure --disable-multilib --disable-nls
--target=x86_64-w64-mingw32 --prefix=/tmp/rt/mingw14
--with-sysroot=/tmp/rt/mingw14
--enable-languages=c,ada,c++,d,fortran,lto,m2,objc,obj-c++,rust
Thread model: win32
Supported LTO compression algorithms: zlib zstd
gcc version
On Fri, Jan 26, 2024 at 3:40 PM NightStrike via Gcc wrote:
>
> On Thu, Jan 25, 2024, 11:27 Iain Sandoe wrote:
>
> > E.g. with Ada it is possible to port to a new platform by first building a
> > cross-compiler and then to use that cross-compiler to build a “native
> > cross” (build != host ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
--- Comment #21 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #20)
> vect_long_mult is wrong again for powerpc (32bit).
>
> vect_long_mult should return true for ILP32 powerpc still. Because long is
> 32bit there ...
See
On Mon, Jan 15, 2024 at 6:43 PM Kewen.Lin wrote:
>
> Hi,
>
> As pointed out by the discussion in PR109705, the current
> vect_long_mult effective target check on Power is broken.
> This patch is to fix it accordingly.
>
> With additional change by adding a guard vect_long_mult
> in
Snapshot gcc-12-20240126 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20240126/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 113580, which changed state.
Bug 113580 Summary: -Wunused-parameter in template imported from module causes
segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113580
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113580
Nathaniel Shead changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
Andrew Pinski changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113580
--- Comment #1 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:ec57d183d35412aa5e0bcd7a448ccb75a4e1eab7
commit r14-8462-gec57d183d35412aa5e0bcd7a448ccb75a4e1eab7
Author: Nathaniel Shead
On 1/26/24 17:11, Jason Merrill wrote:
On 1/26/24 16:52, Jason Merrill wrote:
On 1/25/24 14:18, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13? This isn't a very satisfactory fix, but at least
it safely fixes these testcases I guess.
On 1/26/24 16:52, Jason Merrill wrote:
On 1/25/24 14:18, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13? This isn't a very satisfactory fix, but at least
it safely fixes these testcases I guess. Note that there's
implementation
On 1/25/24 14:18, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13? This isn't a very satisfactory fix, but at least
it safely fixes these testcases I guess. Note that there's
implementation disagreement about the second testcase, GCC
On Wed, 24 Jan 2024, Jeff Law wrote:
> > Do we have consensus now to move forward with this change as posted? I'd
> > like to get these patches ticked off ASAP.
> I think it should move forward. I think having the RTL tests deals with
> Andrew's concern and the testcase adjustment has value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314
--- Comment #11 from GCC Commits ---
The master branch has been updated by Maciej W. Rozycki :
https://gcc.gnu.org/g:3e3b9b708d390074f7825401b808e0ed41552c1d
commit r14-8459-g3e3b9b708d390074f7825401b808e0ed41552c1d
Author: Maciej W. Rozycki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #15 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:861997a9c7088da25ed4dc0bd339060ca063514f
commit r14-8457-g861997a9c7088da25ed4dc0bd339060ca063514f
Author: Robin Dapp
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
Alex Coplan changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to fail|
On Mon, Jan 22, 2024, 12:31 Arthur Cohen wrote:
> I am aware that this would mean restricting the Rust
> GCC front-end to platforms where the official Rust compiler is also
> available, which is less than ideal. However, this would only be
> temporary - as soon as the Rust front-end is able to
On Thu, Jan 25, 2024, 11:27 Iain Sandoe wrote:
> E.g. with Ada it is possible to port to a new platform by first building a
> cross-compiler and then to use that cross-compiler to build a “native
> cross” (build != host == target) to provide an initial compiler on the
> target platform.
>
And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
--- Comment #19 from Andrew Pinski ---
(In reply to seurer from comment #17)
> This still fails on power.
Just so I can start to trying to reproduce it, how was your compiler
configured? I want to make sure the testsuite choices are done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
--- Comment #18 from Andrew Pinski ---
Hmm. this loop should almost definitely get vectorized if vect_double is true:
for (i=0;ic+i) = num__infty;
I wonder why it is not on powerpc.
vect_double for powerpc does:
|| ([istarget
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
Roger Sayle changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
seurer at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
On 12/5/23 20:52, Lewis Hyatt wrote:
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
There are two related issues here really, a regression since GCC 11 where we
can ICE after restoring a PCH, and a deeper issue with bogus locations
assigned to macros that were defined prior to
On 1/25/24 20:38, Marek Polacek wrote:
Low prio and not a regression. Feel free to ignore till GCC 15.
OK for stage 1.
Bootstrapped/regtested on x86_64-pc-linux-gnu.
-- >8 --
The PR complains that
void do_something(){
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 Regression] ICE in |[14 Regression] ICE in
On 1/25/24 20:37, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Since -Wdangling-reference has false positives that can't be
prevented, we should offer an easy way to suppress the warning.
Currently, that is only possible by using a #pragma, either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #6)
> This is currently regtesting.
Regtesting succeeded.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113621
--- Comment #2 from anlauf at gcc dot gnu.org ---
I guess the following reduced testcase shows the same crash:
program test
implicit none
character(4) :: c(7) = "*"
call three_val (c)
contains
subroutine three_val (i, j)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
--- Comment #6 from Andrew Pinski ---
The assert by the way:
```
if (!MEM_P (to_rtx))
{
/* We can get constant negative offsets into arrays with broken
user code. Translate this to a trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
Bug ID: 113623
Summary: [14 Regression] ICE in aarch64_pair_mem_from_base
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #11 from H.J. Lu ---
Created attachment 57233
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57233=edit
An untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
--- Comment #5 from Andrew Pinski ---
Here is a "valid" x86_64 testcase:
```
typedef float __attribute__ ((vector_size (64))) vec;
register vec a asm("zmm2"), b asm("zmm0"), c asm("zmm1");
void
test (void)
{
for (int i = 0; i < 8; i++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Jakub Jelinek changed:
What|Removed |Added
Summary|ICE with vectors in named |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
--- Comment #3 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #2)
> x86_64 Testcase (which invokes undefined behavior) which has been failing
> since at least 4.9.1 even:
> ```
> typedef double __attribute__ ((vector_size (16)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113621
--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to seurer from comment #0)
> This appears to be a problem just on big endian.
This is only for -m32, right?
> Program received signal SIGSEGV: Segmentation fault - invalid memory
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.9.1
Summary|r14-8450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113526
--- Comment #2 from Thiago Jung Bauermann
---
I verified the fix here.
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed||2024-01-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908
--- Comment #6 from anlauf at gcc dot gnu.org ---
Studying the cases that ICE (CLASS array dummy) and testcase PR95331.f90
which fixes an unlimited polymorphic problem, I tried the following change:
diff --git a/gcc/fortran/trans-array.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Bug ID: 113622
Summary: r14-8450 regression: ICE with vectors in named
registers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113621
Bug ID: 113621
Summary: New test case gfortran.dg/optional_absent_10.f90 from
r14-8400-g186ae6d2cb93ad fails
Product: gcc
Version: 14.0
Status: UNCONFIRMED
On 1/26/24 10:49, Patrick Palka wrote:
On Fri, 26 Jan 2024, Nathaniel Shead wrote:
This patch just adds enough of the fields from 'function' to fix the ICE
in the linked PR. I suppose there might be more fields from this type
that should be propagated, but I don't know enough to find out which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
Kacper Słomiński changed:
What|Removed |Added
CC||kacper.slominski72 at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109419
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #27 from Jerry DeLisle ---
(In reply to anlauf from comment #26)
> (In reply to Jerry DeLisle from comment #24)
> > Currently gfortran does the following:
> >
> > character(20) :: fmt
> > character(9) :: buffer
> > fmt =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
--- Comment #6 from Andrew Pinski ---
(In reply to Patrick Palka from comment #5)
> Seems to be a name lookup issue ultimately:
>
> struct A {
> template
> struct B;
>
> template
> struct B {
> int x = V::value; // error: 'V' has
On 1/25/2024 9:06 AM, Robin Dapp wrote:
/* If we ever encounter an insn without an insn reservation, trip
an assert so we can find and fix this problem. */
-#if 0
+ if (! insn_has_dfa_reservation_p (insn)) {
+print_rtl(stderr, insn);
+fprintf(stderr, "%d", get_attr_type
On 1/25/2024 9:06 AM, Robin Dapp wrote:
39 additional unique testsuite failures (scan dumps) will still be present.
I don't know how optimal the new output is compared to the old. Should I update
the testcase expected output to match the new scan dumps?
Currently, without vector op latency,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #26 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #24)
> Currently gfortran does the following:
>
> character(20) :: fmt
> character(9) :: buffer
> fmt = "(1a1,d0.2,1a1)"
> write(buffer,fmt) ">", 3.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113600
--- Comment #4 from Martin Jambor ---
(In reply to Hongtao Liu from comment #2)
> A patch is posted at
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640276.html
>
> Would you give a try to see if it fixes the regression, I don't
This patch addresses a missed optimization opportunity in the RTL
optimization passes. The function simplify_const_binary_operation
will constant fold binary operators with two CONST_INT operands,
and those with two CONST_VECTOR operands, but is missing compile-time
evaluation of binary
On 1/25/2024 9:06 AM, Robin Dapp wrote:
Thanks, that looks better IMHO.
+;; Copyright (C) 2011-2024 Free Software Foundation, Inc.
+;; Contributed by Andrew Waterman (and...@sifive.com).
+;; Based on MIPS target for GNU compiler.
You might want to change that, as well as the date. While at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113614
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107946
Martin Jambor changed:
What|Removed |Added
Last reconfirmed||2024-01-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113616
--- Comment #3 from Alex Coplan ---
Testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
Hi all,
I am an experienced software developer, with an interest in compilers, and
an admirer of gcc.
I would like to contribute, hopefully reusing some of my existing skills,
experience and interests, but unfortunately the (current) overlap is not
great, so I am asking for some guidance/reality
Hi everyone,
Let me explain a reason of the issue connected with _PSTL_USAGE_WARNINGS macro
with GCC14.
Firstly, there is no such issue on version GCC 13.2.0, because
_PSTL_PRAGMA_MESSAGE is defined in #pragma message only if _PSTL_USAGE_WARNINGS
> 0, please have a look:
Well, the pdf I have dates from 2022, but it hasn’t any reference to those
instructions. But that link works, THANKS A LOT!
I will now use that documentation.
Jacob
P.S. I am going through EACH one of the instructions in the instruction table,
and documenting what it does, syntax, abstract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113568
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
--- Comment #4 from Andrew Pinski ---
Created attachment 57229
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57229=edit
Reduced testcase
I reduced the testcase slightly to show it is NSDMI related dealing with a
dependent value only
Mention that gfx1030/gfx1100 are now supported.
As noted in another thread, LLVM 15's assembler is now required, before
LLVM 13.0.1 would do. (Alternatively, disabling gfx1100 support would
do.) Hence, the added link to the install documentation.
Comments, suggestions?
Tobias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.9.0
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
Andrew Pinski changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Hi,
Thomas Schwinge wrote:
amdgcn: config.gcc - enable gfx1030 and gfx1100 multilib; add them to
the docs
...
Further down in that file, we state:
@anchor{amdgcn-x-amdhsa}
@heading amdgcn-*-amdhsa
AMD GCN GPU target.
Instead of GNU Binutils, you will need to install
> Am 26.01.2024 um 17:22 schrieb Thomas Schwinge :
>
> Hi!
>
> Great progress that you've made! :-)
>
>> On 2024-01-26T13:32:02+0100, Tobias Burnus wrote:
>> Tobias Burnus wrote:
>>> Am 24.01.24 um 17:01 schrieb Tobias Burnus:
Okay to enable gfx1100 multilib building and to document
Hi!
Great progress that you've made! :-)
On 2024-01-26T13:32:02+0100, Tobias Burnus wrote:
> Tobias Burnus wrote:
>> Am 24.01.24 um 17:01 schrieb Tobias Burnus:
>>> Okay to enable gfx1100 multilib building and to document gfx1100 in
>>> the manual?
>>
>> and, with this patch, additionally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #10 from Jakub Jelinek ---
The difference with that revision is
--- pr113617-aux.s1 2024-01-26 11:00:05.532246309 -0500
+++ pr113617-aux.s 2024-01-26 11:00:36.291552459 -0500
@@ -80,22 +80,21 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #9 from Sam James ---
Ah, this explains a failure I started seeing recently with folly/watchman/etc
too. I just hadn't looked at it yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #8 from Jakub Jelinek ---
Created attachment 57228
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57228=edit
pr113617-aux.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #7 from Jakub Jelinek ---
Created attachment 57227
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57227=edit
pr113617.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #6 from Jakub Jelinek ---
Created attachment 57226
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57226=edit
pr113617.h
Reduced testcase:
./cc1plus -quiet -O2 -std=c++11 -fPIC pr113617.C; ./cc1plus -quiet -O2
-std=c++11 -fPIC
On Fri, 26 Jan 2024, Nathaniel Shead wrote:
> This patch just adds enough of the fields from 'function' to fix the ICE
> in the linked PR. I suppose there might be more fields from this type
> that should be propagated, but I don't know enough to find out which
> they might be yet, since a lot of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
v2: Formatting and test options fix.
Adds missing bti instruction at the beginning of a virtual
thunk, when bti is enabled.
gcc/ChangeLog:
* config/arm/arm.cc (arm_output_mi_thunk): Emit
insn for bti_c when bti is enabled.
gcc/testsuite/ChangeLog:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
Bug ID: 113620
Summary: Specialized Template
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618
Alex Coplan changed:
What|Removed |Added
Last reconfirmed||2024-01-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113619
Bug ID: 113619
Summary: -Wanalyzer-tainted-divisor false positive seen in
Linux kernel's fs/ceph/ioctl.c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618
Bug ID: 113618
Summary: [14 Regression] AArch64: memmove idiom regression
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113529
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |13.3
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113529
--- Comment #3 from GCC Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:663d9e168bc1f2649721436f5188563eda9d04f0
commit r13-8255-g663d9e168bc1f2649721436f5188563eda9d04f0
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #5 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to H.J. Lu from comment #3)
> > LEA is changed to load through an indirection. Isn't it a regression?
>
> LEA + moving a GPR register to SSE register.
> So
1 - 100 of 220 matches
Mail list logo