Iain Sandoe writes:
> HI Sam,
Hi Iain,
>
> I think this qualifies as obvious (it’s on my list, but I did not get to it
> yet,
> so go ahead).
Thanks. I can't push it myself - could you do that for me?
thanks again,
sam
>
> Iain
>
>> On 2 Dec 2023, at 05:30, Sam James wrote:
>>
>> From:
HI Sam,
I think this qualifies as obvious (it’s on my list, but I did not get to it yet,
so go ahead).
Iain
> On 2 Dec 2023, at 05:30, Sam James wrote:
>
> From: Iain Sandoe
>
> r12-3005-g220c410162ebece4f missed a cast for the set_32 call.
> Fixed thus.
>
> Signed-off-by: Iain Sandoe
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #15 from Andrew Pinski ---
Patch set finally posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639019.html
When I moved two_value to match.pd, I removed the check for the {0,+-1}
as I had placed it after the {0,+-1} case for cond in match.pd.
In the case of {0,+-1} and non boolean, before we would optmize those
case to just `(convert)a` but after we would get `(convert)(a != 0)`
which was not handled
This patch set fixes PR 111972 and the fallout from it.
The first patch is a fix to zero_one_valued_p's convert pattern
which I hit while running the testsuite with the last patch.
The second patch is a fix for -fanalyzer which I had implemented with
a different version of the 3rd patch while I
From: Andrew Pinski
The check for the type seems unnecessary and gets in the way sometimes.
Also with a patch I am working on for match.pd, it causes a failure to happen.
Before my patch the IR was:
_1 = BIT_FIELD_REF ;
_2 = _1 & 1;
_3 = _2 != 0;
_4 = (int) _3;
__analyzer_eval (_4);
While working on PR 111972, I was getting a regression
due to zero_one_valued_p matching a signed 1 bit integer
when it came to convert. This patch fixes that by checking
the outer type too.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* match.pd
Jeff Law writes:
> On 12/1/23 18:13, Sam James wrote:
>> 钟居哲 writes:
>>
>>> Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:
>>>
>>>
From: Iain Sandoe
r12-3005-g220c410162ebece4f missed a cast for the set_32 call.
Fixed thus.
Signed-off-by: Iain Sandoe
Signed-off-by: Sam James
libiberty/ChangeLog:
PR other/112823
* simple-object-mach-o.c (simple_object_mach_o_write_segment):
Cast the first argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112823
Andrew Pinski changed:
What|Removed |Added
Keywords||build
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112823
--- Comment #1 from Sam James ---
At some point, I think we should consider using formal Fixes: git trailers or
something to help find missed backports, but that's another story.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112823
Bug ID: 112823
Summary: -Wincompatible-pointer-types errors in
libiberty/simple-object-mach-o.c (missing backport for
gcc-11)
Product: gcc
Version: 14.0
On 12/1/23 18:13, Sam James wrote:
钟居哲 writes:
Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40:
error: passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112801
--- Comment #5 from JuzheZhong ---
Should be fixed on the trunk. Plz verify it and close it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112801
--- Comment #4 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:1461b431da51f80c90c3bea03d587d76e3e50843
commit r14-6069-g1461b431da51f80c90c3bea03d587d76e3e50843
Author: Juzhe-Zhong
Date: Fri Dec 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
Eric Gallager changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70819
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #1 from
That failure is is due to newlib files:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../*newlib*/newlib/libm/complex/ccoshl.c:
In function 'ccoshl':
To build gcc w/ glibc with riscv-gnu-toolchain, run make linux.
A temporary fix for
Committed, thanks Juzhe.
Pan
From: 钟居哲
Sent: Saturday, December 2, 2023 9:10 AM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in
zve32f
LGTM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112743
--- Comment #5 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:e5bbeedcf7020dfa3870d11cf2b85bc048655698
commit r14-6068-ge5bbeedcf7020dfa3870d11cf2b85bc048655698
Author: Pan Li
Date: Thu Nov 30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
--- Comment #1 from Andrew Pinski ---
>This is a huge C++ program that I have not cut down yet.
I think it didn't attach because it was too big, maybe compress and attach
that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
Bug ID: 112822
Summary: [14 regression] ICE: invalid RHS for gimple memory
store after r14-5831-gaae723d360ca26
Product: gcc
Version: 14.0
Status: UNCONFIRMED
No. GLIBC 2.37 also failed:
make[4]: Leaving directory
'/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/build-newlib/riscv64-unknown-elf/newlib'
CC libm/complex/libm_a-casinhl.o
make[3]: *** [Makefile:5283: all] Error 2
make[3]: Leaving
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112821
Bug ID: 112821
Summary: GNAT issues bug box on mismatched []
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112820
Bug ID: 112820
Summary: vtable not emitted correctly from module when
compiling with -g
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
On Friday, December 1st, 2023 at 9:52 AM, Jason Merrill
wrote:
>
>
> On 12/1/23 01:02, waffl3x wrote:
>
> > I ran into another issue while devising tests for redeclarations of
> > xobj member functions as static member functions and vice versa. I am
> > pretty sure by the literal
钟居哲 writes:
> Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:
>
> /work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40:
> error: passing argument 3 of 'syscall_errno' makes
Hi Juzhe,
I can confirm the failure on Newlib.
I'm not seeing any issues on glibc 2.37.
I haven't tried to build musl.
Since this patch promotes warnings to errors breakages were probably
expected.
The fix may require changes to newlib to remove the errors.
I've hacked together a series of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112819
Bug ID: 112819
Summary: rearrange branches to improve code generation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-12-02 08:59
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in
zve32f
From: Pan Li
If we want to extract 64bit value but ELEN < 64, we use RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112818
--- Comment #3 from Sam James ---
Created attachment 56766
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56766=edit
reduced.i
cvise just finished here with this, not massaged it by hand though
From: Pan Li
If we want to extract 64bit value but ELEN < 64, we use RVV
vector mode with EEW = 32 to extract the highpart and lowpart.
However, this approach doesn't honor DFmode when movdf pattern
when ZVE32f and of course results in ICE when zve32f.
This patch would like to reuse the
On 12/1/23 18:37, Marek Polacek wrote:
On Thu, Nov 30, 2023 at 06:34:01PM -0500, Jason Merrill wrote:
On 11/23/23 11:46, Marek Polacek wrote:
v5 greatly simplifies the code.
Indeed, it's much cleaner now.
I still need a new ff_ flag to signal that we can return immediately
after seeing an
Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40:
error: passing argument 3 of 'syscall_errno' makes integer from pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28278
--- Comment #5 from Jonathan Wakely ---
Created attachment 56765
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56765=edit
Martin's test code
Attaching the test code here, in case the link stops working.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112775
--- Comment #2 from Andrew Pinski ---
Note the workaround is to do just this:
```
template
class A {};
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112775
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786
--- Comment #3 from Hans-Peter Nilsson ---
(In reply to Richard Biener from comment #2)
> Note they XPASS on the 13 branch as well IIRC.
XPASS without Alex patch? Is that XPASS a typo for FAIL or PASS?
Either way, they FAIL, for ia32 say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112782
--- Comment #6 from Andrew Pinski ---
My bet is the code for -mfix-r5900 is not expecting the extra labels that is
produced for debuging ...
Anyways as I mentioned if -mfix-r5900 is the issue then it is a gas issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112782
Andrew Pinski changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112782
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112782
--- Comment #3 from Andrew Pinski ---
I thought this was reported beforehand ...
<<< image/gif: EXCLUDED >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Thu, Nov 30, 2023 at 06:34:01PM -0500, Jason Merrill wrote:
> On 11/23/23 11:46, Marek Polacek wrote:
> > v5 greatly simplifies the code.
>
> Indeed, it's much cleaner now.
>
> > I still need a new ff_ flag to signal that we can return immediately
> > after seeing an i-e expr.
>
> That's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783
--- Comment #2 from Andrew Pinski ---
0x0040d178 <+152>: call 0x401280 <__ctype_b_loc@plt>
=> 0x0040d17d <+157>: movsbq (%r15),%rcx
r150x0 0
Seeing if I can reduce it ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #7 from JuzheZhong ---
(In reply to Vineet Gupta from comment #6)
> (In reply to JuzheZhong from comment #5)
>
> > Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
> > landed on GCC-14.
>
> I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #6 from Vineet Gupta ---
(In reply to JuzheZhong from comment #5)
> Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
> landed on GCC-14.
I don't think that is the reqmt for this issue. Just defining the
> Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET)
> From: Richard Biener
> On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote:
>
> > > From: Hans-Peter Nilsson
> > > Date: Thu, 30 Nov 2023 18:09:10 +0100
> >
> > Richard B.:
> > > > > In the end we might need to move/duplicate the test to some
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112818
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112818
--- Comment #2 from Andrew Pinski ---
Created attachment 56764
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56764=edit
A little more
lgtm
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 23:23
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Add vectorized strcmp.
Hi,
this patch adds a vectorized strcmp implementation and tests. Similar
to strlen,
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 23:21
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Add vectorized strlen.
Hi,
this patch implements a vectorized strlen by re-using and slightly
adjusting the
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 23:21
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Rename and unify stringop strategy handling [NFC].
Hi,
now split into multiple patches.
In preparation for the
LGTM。
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 23:20
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Fix rawmemchr implementation.
Hi,
this fixes a bug in the rawmemchr implementation by incrementing the
source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112818
--- Comment #1 from Andrew Pinski ---
Created attachment 56763
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56763=edit
start of reduction
On Fri, 1 Dec 2023, Jason Merrill wrote:
> On 12/1/23 12:32, Patrick Palka wrote:
> > On Tue, 14 Nov 2023, Jason Merrill wrote:
> >
> > > On 11/14/23 11:10, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > > trunk?
> > > >
> > > > -- >8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112818
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Snapshot gcc-12-20231201 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20231201/
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=112818
Bug ID: 112818
Summary: [14 regression] ICE when building accel-ppp (error:
conversion of register to a different size in
‘view_convert_expr’, verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #5 from JuzheZhong ---
Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
landed on GCC-14.
But currently we are busy with fixing bugs (me, Robin, Lixu@eswin, Li
Pan@intel).
You can see gcc-patch list...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112810
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112810
--- Comment #1 from Andrew Pinski ---
Created attachment 56761
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56761=edit
C++14 testcase (removes the auto argument and changes into an explict template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112651
--- Comment #4 from Vineet Gupta ---
(In reply to JuzheZhong from comment #3)
> The reason we use --param=riscv-autovec-lmul instead of -mvect-lmul which is
> not documented because we don't have ratifed compile option.
>
> I have mentioned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #4 from Andrew Pinski ---
(In reply to Vineet Gupta from comment #3)
> I agree, but what xsimd does is not under our control. Whoever wants to use
> xsimd for whatever reasons, we can allow gcc to be used similarly to llvm
> and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #2 from Andrew Pinski ---
Note the reality is xsimd was not thought out for SIMD but rather just fixed
length extensions. It seems more like a major shift that needs to happen to
these libraries and stop just thinking fixed length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #1 from Andrew Pinski ---
>gcc doesn't, which is a bit of pain for downstream projects such as xsimd.
Does it even make sense to define this? Projects like xsimd seems to be good
for fixed length SIMD but it seems to have a broken
Dear all,
this patch extends the previous version by adding further code testing
the presence of an optional deferred-length character argument also
in the function initialization code. This allows to re-enable a
commented-out test in v2.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
Bug ID: 112817
Summary: RISC-V: RVV: provide a preprocessor macro for VLS
codegen
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112772
--- Comment #4 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:7317275497e10c4a0fb3fbaa6ca87f3463ac124d
commit r14-6066-g7317275497e10c4a0fb3fbaa6ca87f3463ac124d
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816
--- Comment #1 from Andrew Pinski ---
Created attachment 56760
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56760=edit
C testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816
Andrew Pinski changed:
What|Removed |Added
Summary|internal compiler error: in |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #13 from Robin Dapp ---
Mostly an issue because our expander is definitely not prepared to handle that
:)
It looks like aarch64's is, though, and ours can/should be changed then.
aarch64 doesn't need to implement a qi/bi extract
Hi Mikael,
On 12/1/23 21:24, Mikael Morin wrote:
Hello,
Le 30/11/2023 à 22:06, Harald Anlauf a écrit :
the attached rather obvious patch fixes the first testcase of pr112772:
we unconditionally generated copy-out code for optional class arguments,
while the copy-in properly checked the
On Fri, Dec 01, 2023 at 03:53:14PM -0500, Marek Polacek wrote:
> On Fri, Dec 01, 2023 at 11:44:28AM -0800, Andrew Pinski wrote:
> > On Fri, Dec 1, 2023, 11:36 Marek Polacek wrote:
> >
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > -- >8 --
> > > It came up that a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816
Bug ID: 112816
Summary: internal compiler error: in extract_insn, at
recog.cc:2804, unrecognizable_insn for
__builtin_signbit
Product: gcc
Version: unknown
zlib zstd
gcc version 14.0.0 20231201 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112772
--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 56758
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56758=edit
Patch for testcase 2
This patch makes the initialization code seen in testcase 2
dependent on the
On Fri, Dec 01, 2023 at 11:44:28AM -0800, Andrew Pinski wrote:
> On Fri, Dec 1, 2023, 11:36 Marek Polacek wrote:
>
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > It came up that a good hardening strategy is to disable trampolines
> > which may require
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112814
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112814
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
On 12/1/23 15:40, Alexandre Oliva wrote:
On Nov 9, 2023, Jonathan Wakely wrote:
On Thu, 9 Nov 2023 at 01:56, Alexandre Oliva wrote:
g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
a platform that lacks __cxa_thread_atexit_impl, even if the program is
built and run
On Nov 9, 2023, Jonathan Wakely wrote:
> On Thu, 9 Nov 2023 at 01:56, Alexandre Oliva wrote:
>> g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
>> a platform that lacks __cxa_thread_atexit_impl, even if the program is
>> built and run using that toolchain on a (later)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112814
Bug ID: 112814
Summary: `Plus , PHI>` is not optimized to just
PLUS
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
On 12/1/23 12:32, Patrick Palka wrote:
On Tue, 14 Nov 2023, Jason Merrill wrote:
On 11/14/23 11:10, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
For decltype((x)) within a lambda where x is not captured, we dubiously
require
Hello,
Le 30/11/2023 à 22:06, Harald Anlauf a écrit :
the attached rather obvious patch fixes the first testcase of pr112772:
we unconditionally generated copy-out code for optional class arguments,
while the copy-in properly checked the presence of arguments.
Regtested on x86_64-pc-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112813
Bug ID: 112813
Summary: [14 Regression] RISCV ICE: vsetvl pass: in merge at
config/riscv/riscv-vsetvl.cc:1968 on rv32gcv_zvl256b
Product: gcc
Version: 14.0
Status:
On Fri, Dec 1, 2023, 11:36 Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> It came up that a good hardening strategy is to disable trampolines
> which may require executable stack. Therefore the following patch
> adds -Werror=trampolines to
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
It came up that a good hardening strategy is to disable trampolines
which may require executable stack. Therefore the following patch
adds -Werror=trampolines to -fhardened.
gcc/ChangeLog:
* common.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
--- Comment #2 from Andrew Macleod ---
(In reply to Kewen Lin from comment #1)
>
> ranger makes use of type precision directly instead of something like
> types_compatible_p. I wonder if we can introduce a target hook (or hookpod)
> to make
Comments in PR 112788 correctly brought up that the new
check_operands_p() routine is directly checking precision rather than
calling range_compatible_p().
Most earlier iterations of the original patch had ranges as arguments,
and it wasn't primarily a CHECKING_P only call then...
On Thu, 30 Nov 2023, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> In review of the deducing 'this' patch it came up that LAMBDA_EXPR_MUTABLE_P
> doesn't make sense for a lambda with an explicit object parameter. And it
> was never necessary, so let's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111880
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111880
--- Comment #10 from GCC Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:246760b37f1239b3b97c20fb4a914f21154389a3
commit r11-9-g246760b37f1239b3b97c20fb4a914f21154389a3
Author: Harald
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
The patch was successfully bootstrapped and tested on x86-64, aarch64,
ppc64le.
commit 1390bf52c17a71834a1766c0222e4f8a74efb162
Author: Vladimir N. Makarov
Date: Fri Dec 1 11:46:37 2023 -0500
[PR112445][LRA]:
ping.
On Sat, 25 Nov 2023 at 13:52, Cassio Neri wrote:
> The following invoke signed integer overflow (UB) [1]:
>
> month + months{MAX} // where MAX is the maximum value of months::rep
> month + months{MIN} // where MIN is the maximum value of months::rep
> month - months{MIN} //
1 - 100 of 294 matches
Mail list logo
