https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113608
--- Comment #2 from JuzheZhong ---
vuint16m2_t vadd(vuint16m2_t a, vuint8m1_t b) {
int vl = __riscv_vsetvlmax_e8m1();
vuint16m2_t c = __riscv_vzext_vf2_u16m2(b, vl);
return __riscv_vadd_vv_u16m2(a, c, vl);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
ChangeLog/
* MAINTAINERS: Update my e-mail address.
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d92be1f301..b47e0465852 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -100,7 +100,7 @@ msp430 port Nick
On 2/1/24 18:24, Greg McGary wrote:
On 1/18/24 9:24 AM, Jeff Law wrote:
On 1/17/24 20:53, Greg McGary wrote:
While the code comment is true, perhaps it obscures the primary intent,
which is recognition that the pattern (SIGN_EXTEND (mem ...) ) is
destined
to expand into a single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #13 from Andrew Pinski ---
Only need SGFTree.cpp, GTP.cpp to reproduce the issue.
Reducing it further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #12 from Lehua Ding ---
(In reply to Andrew Pinski from comment #7)
> Works for me with r14-8399-ge6fbc3cc786a74.
>
> My -march=native expands to: `-march=skylake-avx512 -mmmx -mpopcnt -msse
> -msse2 -msse3 -mssse3 -msse4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #11 from Lehua Ding ---
(In reply to Andrew Pinski from comment #10)
> Finally able to reproduce it using -fno-use-linker-plugin .
I compile GCC with this commit e0701f8f7b6dcddb299eb5345e510cf9ea419150, but
the as and ld are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #9 from Andrew Pinski ---
Maybe related to
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586290.html .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #8 from Andrew Pinski ---
I just tried with a cross to aarch64-linux-gnu and that does not reproduce the
error either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #7 from Andrew Pinski ---
Works for me with r14-8399-ge6fbc3cc786a74.
My -march=native expands to: `-march=skylake-avx512 -mmmx -mpopcnt -msse -msse2
-msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop
-mfma
Hi Edwin,
Just rerun the newlib and there is no ICE but still 160 dump failures as below.
Pan
-Original Message-
From: Li, Pan2
Sent: Friday, February 2, 2024 11:57 AM
To: Edwin Lu ; juzhe.zh...@rivai.ai; gcc-patches
Cc: Robin Dapp ; kito.cheng ;
jeffreyalaw ; palmer ; vineetg
;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #6 from Lehua Ding ---
(In reply to Lehua Ding from comment #5)
> Created attachment 57287 [details]
> All source file
Decompress the attachment and cd to it, then you can reproduce by these
command:
g++ -std=c++03 -m64 -c -o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #5 from Lehua Ding ---
Created attachment 57287
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57287=edit
All source file
gcc/ChangeLog:
* config/riscv/riscv-cores.def: Add sifive-p450, sifive-p670.
* doc/invoke.texi (RISC-V Options): Add sifive-p450,
sifive-p670.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/mcpu-sifive-p450.c: New test.
* gcc.target/riscv/mcpu-sifive-p670.c:
Add sifive p400 series scheduler module. For more information
see https://www.sifive.com/cores/performance-p450-470.
gcc/ChangeLog:
* config/riscv/riscv.md: Include sifive-p400.md.
* config/riscv/sifive-p400.md: New file.
* config/riscv/riscv-cores.def (RISCV_TUNE): Add
Sorry, it seems the log was eliminated by my cleanup script(s). Let me know
rerun one newlib for commit id 23cd2961bd2ff63583f46e3499a07bd54491d45c.
Pan
-Original Message-
From: Edwin Lu
Sent: Friday, February 2, 2024 1:43 AM
To: Li, Pan2 ; juzhe.zh...@rivai.ai; gcc-patches
Cc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #9 from Andrew Pinski ---
Note I think GCC should be able to vectorize this loop but it goes wrong.
SVE the 7 part gets lost:
```
vect__3.12_54 = .MASK_LOAD (_48, 16B, loop_mask_52);
_32 = cond_17(D) + POLY_INT_CST [16, 16];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #21 from JuzheZhong ---
Hi, Richard. I looked into ivcanon.
I found that:
/* If the loop has more than one exit, try checking all of them
for # of iterations determinable through scev. */
if (!exit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #8 from Andrew Pinski ---
Created attachment 57286
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57286=edit
Testcase that shows this is wrong code
I reduced the testcase into something which shows it is wrong code too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #3 from Lehua Ding ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Lehua Ding from comment #1)
> > Reproduce steps:
> > 1. download these object files(bugzilla has size limit):
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112439
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:f4998609908e4926fc095ce97cb84b187294fd1d
commit r14-8727-gf4998609908e4926fc095ce97cb84b187294fd1d
Author: Jason Merrill
Date:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here, because we don't build a CONSTRUCTOR for an empty base, we were
wrongly marking the Foo CONSTRUCTOR as complete after initializing the Empty
member. Fixed by checking empty_base here as well.
PR c++/112439
gcc/cp/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113638
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:0b786ff38ab398087820d91241e030a28c451df9
commit r14-8726-g0b786ff38ab398087820d91241e030a28c451df9
Author: Jason Merrill
Date:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When we added variable templates, we didn't extend the VAR_HAD_UNKNOWN_BOUND
handling for class template static data members to handle them as well.
PR c++/113638
gcc/cp/ChangeLog:
* cp-tree.h: Adjust comment.
*
LGTM!
Thanks!
在 2024/2/2 上午5:54, Xi Ruoyao 写道:
When bootstrapping GCC 14 --with-build-config=bootstrap-lto, an ODR
violation is detected:
../../gcc/config/loongarch/loongarch-opts.cc:57: warning:
'abi_minimal_isa' violates the C++ One Definition Rule [-Wodr]
57 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #2 from Andrew Pinski ---
(In reply to Lehua Ding from comment #1)
> Reproduce steps:
> 1. download these object files(bugzilla has size limit):
> https://github.com/lhtin/temp/raw/main/objects.zip
> 2. cd the object files dir and
Committed, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Thursday, February 1, 2024 9:39 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ;
kito.ch...@gmail.com
Subject: Re: [PATCH v1] RISC-V: Cleanup the comments for the psabi
On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #1 from Lehua Ding ---
Reproduce steps:
1. download these object files(bugzilla has size limit):
https://github.com/lhtin/temp/raw/main/objects.zip
2. cd the object files dir and run the command: /path/to/your/g++ -std=c++03
-m64
Pushed to r14-8723.
在 2024/1/24 下午5:19, Jiahao Xu 写道:
gcc/ChangeLog:
* config/loongarch/larchintrin.h
(__frecipe_s): Update function return type.
(__frecipe_d): Ditto.
(__frsqrte_s): Ditto.
(__frsqrte_d): Ditto.
gcc/testsuite/ChangeLog:
*
This patch fixes the following:
vsetvli a5,a1,e32,m1,tu,ma
sllia4,a5,2
sub a1,a1,a5
vle32.v v2,0(a0)
add a0,a0,a4
vadd.vv v1,v2,v1
bne a1,zero,.L3
vsetivlizero,1,e32,m1,ta,ma
vmv.s.x v2,zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
Bug ID: 113712
Summary: lto crash: when building 641.leela_s peek with
Example-gcc-linux-x86.cfg (SPEC2017 1.1.9)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
This FAIL was introduced from r14-6908. The reason is that when merging
constant vector permutation implementations, the 128-bit matching situation
was not fully considered. In fact, the expansion of 128-bit vectors after
merging only supports value-based 4 elements set shuffle, so this time is a
Ping?
在 2024/1/30 上午10:09, Lulu Cheng 写道:
From: chenguoqi
libsanitizer/ChangeLog:
* configure.tgt: Enable tsan and lsan for loongarch64.
* tsan/Makefile.am: Add tsan_rtl_loongarch64.S to
EXTRA_libtsan_la_SOURCES.
* tsan/Makefile.in: Regenerate.
---
On 1/18/24 9:24 AM, Jeff Law wrote:
On 1/17/24 20:53, Greg McGary wrote:
While the code comment is true, perhaps it obscures the primary intent,
which is recognition that the pattern (SIGN_EXTEND (mem ...) ) is
destined
to expand into a single memory-load instruction and no simplification
Pushed to r14-8722.
在 2024/1/26 下午4:41, Li Wei 写道:
We found that when only 128-bit vectorization was enabled, 549.fotonik3d_r
failed to vectorize effectively. For this reason, we adjust the cost of
128-bit vector_stmt that match the multiply-add pattern to facilitate 128-bit
vectorization.
The
Pushed to r14-8717...r14-8721.
在 2024/1/29 下午4:21, Lulu Cheng 写道:
When cmodel=extreme, since the symbol address is obtained through four
instructions,
errors may occur in some cases during linking. Xi Ruoyao fixes this problem.
On Thu, Feb 1, 2024 at 8:42 AM Richard Sandiford
wrote:
>
> Tamar Christina writes:
> >> -Original Message-
> >> From: Richard Sandiford
> >> Sent: Thursday, February 1, 2024 2:24 PM
> >> To: Andrew Pinski
> >> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd
> >> ; Richard Earnshaw ;
Pushed to r14-8716.
在 2024/1/30 下午3:55, Lulu Cheng 写道:
Modify address calculation logic from (((a x C) + fp) + offset) to ((fp +
offset) + a x C).
Thereby modifying the register dependencies and optimizing the code.
The value of C is 2 4 or 8.
The following is the assembly code before and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #8 from chenglulu ---
(In reply to Xi Ruoyao from comment #7)
> Any update? :)
Well, I haven't run it yet. Since this does not have a big impact on the spec
score, I am currently testing it on a single-channel machine, so the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
--- Comment #13 from Li Pan ---
I'll try to understand it and make it happen recently.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113682
--- Comment #6 from Andrew Pinski ---
(In reply to Mathias Stearn from comment #5)
> Do you know if that applies to any cores that support x86_64? I checked
> Agner Fog's tables, and only very very old cores (P4 era) had high
> reciprocal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113694
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113694
--- Comment #2 from Matheus Afonso Martins Moreira ---
That's true but in that case the __stack_chk_* symbols will remain in the
compiler output and in the final binary. They will show up in readelf output,
GDB function disassemblies.
I think
On Jan 24, 2024, at 1:01 AM, Rainer Orth wrote:
>
> gcc.target/i386/pr70321.c FAILs on 32-bit Solaris/x86 since its
> introduction in
>
> commit 43201f2c2173894bf7c423cad6da1c21567e06c0
> Author: Roger Sayle
> Date: Mon May 30 21:20:09 2022 +0100
>
>PR target/70321: Split double word
On Jan 24, 2024, at 1:12 AM, Rainer Orth wrote:
>
> gcc.target/i386/avx512vl-stv-rotatedi-1.c FAILs on 32-bit Solaris/x86
> since its introduction in
>
> commit 4814b63c3c2326cb5d7baa63882da60ac011bd97
> Author: Roger Sayle
> Date: Mon Jul 10 09:04:29 2023 +0100
>
>i386: Add AVX512
On Jan 30, 2024, at 2:30 AM, Iain Sandoe wrote:
>
> tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux,
> OK for trunk?
Ok. If asan people want to chime in...
On Jan 30, 2024, at 2:31 AM, Iain Sandoe wrote:
>
> tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux,
> OK for trunk?
Ok. If the ubsan people want to review this, certainly, happy to have them
chime in.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
Andrew Pinski changed:
What|Removed |Added
Target Milestone|14.0|---
Summary|Warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113335
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-02-01
nction
foo:
.LFB0:
.cfi_startproc
addl$2000, %fs:0, %eax
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 14.0.1 20240201 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-3 apx
On Jan 28, 2024, at 7:03 AM, Iain Sandoe wrote:
>
> Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux,
> OK for trunk?
Ok. If you discover needed updates, please feel free to drop them in.
t;x.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
addl$2000, 8000(%esi,%edi,4), %eax
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 14.0.1 2024020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111790
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103701
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
On Thu, Feb 1, 2024 at 10:32 AM Jakub Jelinek wrote:
>
> On Thu, Feb 01, 2024 at 10:15:30AM -0800, H.J. Lu wrote:
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -22749,6 +22749,31 @@ current_fentry_section (const char **name)
> >return true;
> > }
> >
> > +/*
Changes in v2:
1. Add int_parameter_registers to machine_function to track integer
registers used for parameter passing.
2. Update x86_64_select_profile_regnum to try %r10 first and use an
caller-saved register, which isn't used for parameter passing.
---
2 scratch registers, %r10 and %r11, are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103701
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
On Tue, Jan 30, 2024 at 07:33:10AM -, Roger Sayle wrote:
+ wide_int bits = wide_int::from (tree_nonzero_bits (rhs),
+ prec,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113360
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Snapshot gcc-11-20240201 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20240201/
and on various mirrors, see https://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=113690
Roger Sayle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111895
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
I'm going to push this as obvious.
-- >8 --
gcc/ChangeLog:
* doc/extend.texi (Common Type Attributes): Fix typo in
description of hardbool.
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108166
Andrew Pinski changed:
What|Removed |Added
CC||jiajing_zheng at 163 dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113709
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
On 2/1/24 16:23, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
aarch64-unknown-linux-gnu now bootstraps.
-- >8 --
My recent -Wdangling-reference change to not warn on std::span-like classes
unfortunately caused a new warning: extending
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
Marek Polacek changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113709
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.3
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112439
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
Andre Vieira writes:
> This patch finalizes adding support for the generation of SVE simd clones when
> no simdlen is provided, following the ABI rules where the widest data type
> determines the minimum amount of elements in a length agnostic vector.
>
> gcc/ChangeLog:
>
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #29 from Sam James ---
Created attachment 57285
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57285=edit
testcase w abort
Tweaked https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467#c26 so it can be
used as a testcase.
When bootstrapping GCC 14 --with-build-config=bootstrap-lto, an ODR
violation is detected:
../../gcc/config/loongarch/loongarch-opts.cc:57: warning:
'abi_minimal_isa' violates the C++ One Definition Rule [-Wodr]
57 | abi_minimal_isa[N_ABI_BASE_TYPES][N_ABI_EXT_TYPES];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112836
--- Comment #5 from Bruno Haible ---
(In reply to John Paul Adrian Glaubitz from comment #4)
> I tried this patch but it does not address the issue with posix_spawn that I
> am seeing.
>
> Trying to build gcc from git on Linux sparc64 with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113638
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
> >
> > If the above is correct then I think I understand what you're saying and
> > will update the patch and do some Checks.
>
> Yes, I think that's what I wanted to say.
>
As discussed:
Bootstrapped Regtested on aarch64-none-linux-gnu and x86_64-pc-linux-gnu no
issues.
Also checked both
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
aarch64-unknown-linux-gnu now bootstraps.
-- >8 --
My recent -Wdangling-reference change to not warn on std::span-like classes
unfortunately caused a new warning: extending reference_like_class_p also
opens the door to new warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98935
Roman Lozko changed:
What|Removed |Added
CC||lozko.roma at gmail dot com
--- Comment
This commit is specifically targeting enhancements in
Nix support for GCC development. This initiative stems
from the recognized need within our community for a more
streamlined and efficient development process when using Nix.
Please not that in this case the Nix tool is used to define
what
Hi Eli,
Yeah sorry I forgot to tag with -v2, so I am creating a -v3, after a while that
I do not use email to send patches I get a little bit rusty.
Thanks for your useful feedback, I am sending the v3 now.
Cheers,
Vincent.
On Wed, Jan 31, 2024 at 11:19 PM Eli Schwartz wrote:
>
> On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113710
Patrick Palka changed:
What|Removed |Added
Blocks||103524
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113710
Bug ID: 113710
Summary: [14 Regression] g++.dg/modules/hello-1 ICE: canonical
types differ for identical types since
r14-8710-g65b4cba9d6a9ff
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506
--- Comment #9 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Gaius Mulley from comment #7)
> > I doubt the m2date and testclock are related to filesystem case (but I could
> > be wrong) as I've built gcc on a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111627
--- Comment #6 from Iain Sandoe ---
FWIW. testing on i686-darwin9 and x86_64-darwin14 with
case-preserving-non-case-sens shows these fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82580
Uroš Bizjak changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
The fix for PR70321 introduced a splitter that split a doubleword
comparison into a pair of XORs followed by an IOR to set the (zero)
flags register. To help the reload, splitter forced SUBREG pieces of
double-word input values to a pseudo, but this regressed
gcc.target/i386/pr82580.c
int f0 (U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113701
--- Comment #6 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:44764984cf24e27cf7756cffd197283b9c62db8b
commit r14-8713-g44764984cf24e27cf7756cffd197283b9c62db8b
Author: Uros Bizjak
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113686
--- Comment #2 from H. Peter Anvin ---
The intermediate alignment for lui is known, so if an object is known to fit
*entirely* within its natural alignment then it can be safely CSE'd, but this
is typically not the case with structures or
On Wed, 3 Jan 2024, Hans-Peter Nilsson wrote:
> > > Hmm. I think it would be more correct to emphasize that the
> > > existing dg-timeout-factor affects both the tool execution *and*
> > > the test execution, whereas your new dg-test-timeout-factor only
> > > affects the test execution. (And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553
--- Comment #11 from Andrew Pinski ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> (In reply to Andrew Pinski from comment #9)
> > oh look at this a memset issue on sparc glibc:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553
--- Comment #11 from Andrew Pinski ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> (In reply to Andrew Pinski from comment #9)
> > oh look at this a memset issue on sparc glibc:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e9b2f15d989addc1c2ad4604f5fa5ee1bda6023b
commit r14-8712-ge9b2f15d989addc1c2ad4604f5fa5ee1bda6023b
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
--- Comment #18 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:03519175e21f4c2940aeb446cd2b81fdf995cad5
commit r14-8711-g03519175e21f4c2940aeb446cd2b81fdf995cad5
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553
--- Comment #10 from John Paul Adrian Glaubitz ---
(In reply to Andrew Pinski from comment #9)
> oh look at this a memset issue on sparc glibc:
> https://sourceware.org/bugzilla/show_bug.cgi?id=31068 .
Hmm, but this would be sparc32. Are you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553
--- Comment #10 from John Paul Adrian Glaubitz ---
(In reply to Andrew Pinski from comment #9)
> oh look at this a memset issue on sparc glibc:
> https://sourceware.org/bugzilla/show_bug.cgi?id=31068 .
Hmm, but this would be sparc32. Are you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749
Bug 106749 depends on bug 113309, which changed state.
Bug 113309 Summary: [C++23] Implement P2165R4, Compatibility between tuple and
tuple-like objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113309
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113309
--- Comment #1 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:65b4cba9d6a9ffe9b4d4bdff90727a7064cc0e3b
commit r14-8710-g65b4cba9d6a9ffe9b4d4bdff90727a7064cc0e3b
Author: Patrick Palka
Date:
1 - 100 of 326 matches
Mail list logo
