On Mon, Jan 31, 2022 at 7:56 PM H.J. Lu via Gcc-patches
wrote:
>
> Backport -mindirect-branch-cs-prefix:
LGTM in case a x86 maintainer also acks this. Can you amend
the 10.3 release gcc-11/changes.html notes accordingly?
Thanks,
Richard.
> commit 48a4ae26c225eb018ecb59f131e2c4fd4f3cf89a
>
Hi,
When running libgomp test-case broadcast-many.c on an nvptx accelerator
(T400, driver version 470.86), I run into:
...
libgomp: The Nvidia accelerator has insufficient resources to launch \
'main$_omp_fn$0' with num_workers = 32 and vector_length = 32; \
recompile the program with
Hi,
When running the libgomp testsuite with GOMP_NVPTX_JIT=-O0 using an nvptx
accelerator (Nvidia T400, 2GB), I run into:
...
libgomp: cuCtxSynchronize error: unspecified launch failure \
(perhaps abort was called)
libgomp: cuMemFree_v2 error: unspecified launch failure
libgomp: device
On Tue, Feb 1, 2022 at 6:10 AM Xi Ruoyao wrote:
>
> Bootstrapped and tested on x86_64-linux-gnu. Ok for trunk, gcc-11, and
> gcc-10? (I'd consider PR 95115 a 10/11/12 regression because GCC
> 10/11/12 miscompiles glibc acos/asin function, but not GCC 9.)
>
> These operations should raise an
On Tue, Feb 1, 2022 at 5:54 AM Arjun Shankar via Gcc-patches
wrote:
>
> Expressions of the form "X + CST < Y + CST" where X and Y are of int
> type and CST is of unsigned type with only the MSB on can be simplified
> to "X < Y" because "X + 0x8000" increases monotonically with X.
+/* As a
On Mon, Jan 31, 2022 at 10:34 PM Jason Merrill via Gcc-patches
wrote:
>
> Ping.
OK.
Richard.
> On 1/26/22 18:16, Jason Merrill wrote:
> > The problem with this testcase was that since my patch for PR97900 we
> > weren't preserving DECL_UID identity for parameters of instantiations of
> >
On Mon, Jan 31, 2022 at 5:26 PM Tom de Vries wrote:
>
> [ was: Re: [RFC] ldist: Recognize rawmemchr loop patterns ]
>
> On 1/31/22 16:00, Richard Biener wrote:
> >> I'm running into PR56888 (
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 ) on nvptx due to
> >> this, f.i. in
> Am 31.01.2022 um 22:05 schrieb Eugene Rozenfeld
> :
>
> Thank you for the review Richard. Is it ok to commit this change to trunk
> now or should I wait till GCC 13 development starts?
> This seems like a very low risk change.
Yes, it’s Ok now.
Richard
> Thanks,
>
> Eugene
>
>
On Mon, Jan 31, 2022 at 2:13 AM Jakub Jelinek wrote:
>
> On Sun, Jan 30, 2022 at 10:16:44AM +, Navid Rahimi via Gcc-patches wrote:
> > Thanks Jakob for the correction. Sadly, I didn’t have any access to any non
> > x86 architecture. But x86 was fully tested and there was no regression.
> >
>
Bootstrapped and tested on x86_64-linux-gnu. Ok for trunk, gcc-11, and
gcc-10? (I'd consider PR 95115 a 10/11/12 regression because GCC
10/11/12 miscompiles glibc acos/asin function, but not GCC 9.)
These operations should raise an invalid operation exception at runtime.
So they should not be
Expressions of the form "X + CST < Y + CST" where X and Y are of int
type and CST is of unsigned type with only the MSB on can be simplified
to "X < Y" because "X + 0x8000" increases monotonically with X.
gcc/
* match.pd (X + C < Y + C -> X < Y, if C is 0x8000): New
Hans-Peter Nilsson via Gcc-patches writes:
> I'm not seriously submitting this patch for approval. I just thought
> it'd be interesting to some people, at least those maintaining ports
> still using reload; I know it's reload and major ports don't really
> care about that anymore. TL;DR: scroll
Christophe Lyon via Gcc-patches writes:
> On Mon, Jan 31, 2022 at 7:01 PM Richard Sandiford via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
>> Sorry for the slow response, was out last week.
>>
>> Christophe Lyon via Gcc-patches writes:
>> > diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
>>
I'm not seriously submitting this patch for approval. I just thought
it'd be interesting to some people, at least those maintaining ports
still using reload; I know it's reload and major ports don't really
care about that anymore. TL;DR: scroll down for the mystery part.
The *benevolent*
On Wed, Jan 26, 2022 at 06:16:34PM -0500, Jason Merrill via Gcc-patches wrote:
> The problem with this testcase was that since my patch for PR97900 we
> weren't preserving DECL_UID identity for parameters of instantiations of
> templated functions, so using those parameters as the keys for the
>
On Mon, 31 Jan 2022, Richard Biener via Gcc-patches wrote:
> I wonder if it would make sense to handle it similar to
>
> inexact = real_arithmetic (, code, , );
> real_convert (, mode, );
>
> /* Don't constant fold this floating point operation if
> the result has
On Mon, Jan 31, 2022 at 05:12:23PM -0500, Jason Merrill wrote:
> > --- libcpp/macro.cc.jj 2022-01-18 11:59:00.277972128 +0100
> > +++ libcpp/macro.cc 2022-01-31 15:44:49.208847524 +0100
> > @@ -1374,7 +1374,9 @@ funlike_invocation_p (cpp_reader *pfile,
> > if (token->type !=
From: Andrew Pinski
The OEP_* enums were moved to tree-core.h in
r0-124973-g5e351e960763 but the comment was correct
when it was added added to fold-const.h in
r10-4231-g7f4a8ee03d40. This fixes the reference
to the OEP_* enum to reference tree-core.
Committed as obvious after a bootstrap/test
Use `gcc-dg-runtest' test driver rather than `dg-runtest' to run the
RISC-V testsuite as several targets already do. Adjust test options
across individual test cases accordingly where required.
As some tests want to be run at `-Og', add a suitable optimization
variant via
On Mon, Jan 31, 2022 at 7:01 PM Richard Sandiford via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Sorry for the slow response, was out last week.
>
> Christophe Lyon via Gcc-patches writes:
> > diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
> > index f16d320..5f559f8fd93 100644
> > ---
On Mon, Jan 31, 2022 at 04:01:58PM -0600, Bill Schmidt wrote:
> On 1/31/22 3:32 PM, Segher Boessenkool wrote:
> > On Fri, Jan 28, 2022 at 11:50:22AM -0600, Bill Schmidt wrote:
> >> Overloading support remains in rs6000-c.cc.
> > So, what is needed to move that as well? Is moving that in the plan?
On 1/31/22 14:03, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, in some cases we preprocess incorrectly when we
encounter an identifier which is defined as function-like macro, followed
by at least 2 CPP_PADDING tokens and then some other identifier.
On the following testcase, the problem is
Hi Segher,
On 1/31/22 3:32 PM, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jan 28, 2022 at 11:50:22AM -0600, Bill Schmidt wrote:
>> Continuing with the refactoring effort, this patch moves as much of the
>> target-specific built-in support code into a new file, rs6000-builtin.cc.
>> However, we
Make riscv-sr.o depend on target machine headers, removing spurious test
failures:
FAIL: gcc.target/riscv/save-restore-3.c scan-assembler-not call[
\t]*t0,__riscv_save_0
FAIL: gcc.target/riscv/save-restore-3.c scan-assembler-not tail[
\t]*__riscv_restore_0
FAIL:
On Mon, Jan 31, 2022 at 02:38:27PM -0500, Michael Meissner wrote:
> On Mon, Jan 31, 2022 at 12:52:28PM -0600, Segher Boessenkool wrote:
> > Hi!
> >
> > On Mon, Jan 31, 2022 at 01:49:03PM -0500, Michael Meissner wrote:
> > > * config/rs6000/rs6000.cc (TARGET_IEEEQUAD_DEFAULT): If the
> > >
Hi!
On Fri, Jan 28, 2022 at 11:50:22AM -0600, Bill Schmidt wrote:
> Continuing with the refactoring effort, this patch moves as much of the
> target-specific built-in support code into a new file, rs6000-builtin.cc.
> However, we can't easily move the overloading support code out of
>
Ping.
On 1/26/22 18:16, Jason Merrill wrote:
The problem with this testcase was that since my patch for PR97900 we
weren't preserving DECL_UID identity for parameters of instantiations of
templated functions, so using those parameters as the keys for the
defarg_inst map broke. I think this was
Thank you for the review Richard. Is it ok to commit this change to trunk now
or should I wait till GCC 13 development starts?
This seems like a very low risk change.
Thanks,
Eugene
-Original Message-
From: Richard Biener
Sent: Monday, January 31, 2022 1:23 AM
To: Eugene Rozenfeld
On 1/31/22 11:14, Patrick Palka wrote:
On Mon, Jan 31, 2022 at 11:07 AM Patrick Palka wrote:
Here during deduction guide generation for the nested class template
B::C, the computation of outer_targs yields the template
arguments relative to the primary template for B (i.e. {char(int)})
but
On Mon, Jan 31, 2022 at 12:52:28PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jan 31, 2022 at 01:49:03PM -0500, Michael Meissner wrote:
> > * config/rs6000/rs6000.cc (TARGET_IEEEQUAD_DEFAULT): If the
> > compiler used to build the current compiler defaults to IEEE
> > 128-bit
On 25/01/2022 10:32, Tobias Burnus wrote:
> On 25.01.22 10:19, Thomas Schwinge wrote:
>>> I am trying to figure out if the problem you observed
>>> is a general one or just specific to fortran testcase.
>> So, unless the '-fsanitize=thread' issues are bogus -- unlikely ;-) -- it
>> seems a latent
On 1/28/22 20:21, Marek Polacek wrote:
Weird things are going to happen if you define your std::initializer_list
as a union. In this case, we crash in output_constructor_regular_field.
Let's not allow such a definition in the first place.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for
On 1/28/22 15:49, Marek Polacek wrote:
On Thu, Jan 27, 2022 at 10:17:00PM -0500, Jason Merrill wrote:
On 1/27/22 20:02, Marek Polacek wrote:
@@ -11159,8 +11159,16 @@ create_array_type_for_decl (tree name, tree type, tree
size, location_t loc)
/* Figure out the index type for the array.
On 1/31/22 12:27, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/104291
gcc/cp/ChangeLog:
* pt.cc (for_each_template_parm_r) : Don't
walk subtrees if !include_nondeduced_p. Simplify given that
Hi!
As mentioned in the PR, in some cases we preprocess incorrectly when we
encounter an identifier which is defined as function-like macro, followed
by at least 2 CPP_PADDING tokens and then some other identifier.
On the following testcase, the problem is in the 3rd funlike_invocation_p,
the
Generate INT3 after indirect jmp in exception return for -fcf-protection
with -mharden-sls=indirect-jmp.
gcc/
PR target/103925
* config/i386/i386.c (ix86_output_indirect_function_return):
Generate INT3 after indirect jmp for -mharden-sls=indirect-jmp.
gcc/testsuite/
Add -mindirect-branch-cs-prefix to add CS prefix to call and jmp to
indirect thunk with branch target in r8-r15 registers so that the call
and jmp instruction length is 6 bytes to allow them to be replaced with
"lfence; call *%r8-r15" or "lfence; jmp *%r8-r15" at run-time.
gcc/
PR
Indirect branch also includes indirect call instructions. Rename
-harden-sls=indirect-branch to -harden-sls=indirect-jmp to match its
intended behavior.
PR target/102952
* config/i386/i386-opts.h (harden_sls): Replace
harden_sls_indirect_branch with
Add -mharden-sls= to mitigate against straight line speculation (SLS)
for function return and indirect branch by adding an INT3 instruction
after function return and indirect branch.
gcc/
PR target/102952
* config/i386/i386-opts.h (harden_sls): New enum.
*
Before MPX was removed, "%!" was mapped to
case '!':
if (ix86_bnd_prefixed_insn_p (current_output_insn))
fputs ("bnd ", file);
return;
After CET was added and MPX was removed, "%!" was mapped to
case '!':
if (ix86_notrack_prefixed_insn_p
Backport -mindirect-branch-cs-prefix:
commit 48a4ae26c225eb018ecb59f131e2c4fd4f3cf89a
Author: H.J. Lu
Date: Wed Oct 27 06:27:15 2021 -0700
x86: Add -mindirect-branch-cs-prefix
Add -mindirect-branch-cs-prefix to add CS prefix to call and jmp to
indirect thunk with branch target in
Hi!
On Mon, Jan 31, 2022 at 01:49:03PM -0500, Michael Meissner wrote:
> * config/rs6000/rs6000.cc (TARGET_IEEEQUAD_DEFAULT): If the
> compiler used to build the current compiler defaults to IEEE
> 128-bit long double, make that the default for this build.
NAK. The compiler
Hi!
On Mon, Jan 31, 2022 at 07:43:32PM +0100, Jakub Jelinek wrote:
> As reported by Martin, while David has added OPTION_GLIBC define to aix
> and Iain to darwin, all the other non-linux targets now fail because
> rs6000.md macro isn't defined.
>
> One possibility is to define this macro in
This patch is critical to be installed when distros start making the switch
from IBM 128-bit long double to IEEE 128-bit long double, so that users don't
have to explicitly set the floating point format.
Note because the patch was posted before the .c files were renamed to .cc, the
following
Hi!
As reported by Martin, while David has added OPTION_GLIBC define to aix
and Iain to darwin, all the other non-linux targets now fail because
rs6000.md macro isn't defined.
One possibility is to define this macro in option-defaults.h which on rs6000
targets is included last, then we don't
Sorry for the slow response, was out last week.
Christophe Lyon via Gcc-patches writes:
> diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
> index f16d320..5f559f8fd93 100644
> --- a/gcc/emit-rtl.c
> +++ b/gcc/emit-rtl.c
> @@ -6239,9 +6239,14 @@ init_emit_once (void)
>
>/* For BImode, 1
On 1/31/22 11:28 AM, Segher Boessenkool wrote:
> On Mon, Jan 31, 2022 at 11:21:32AM -0600, Bill Schmidt wrote:
>> On 1/28/22 5:24 PM, Segher Boessenkool wrote:
>>> On Fri, Jan 28, 2022 at 11:50:21AM -0600, Bill Schmidt wrote:
When introducing the new built-in support, I tried to match as many
On Mon, Jan 31, 2022 at 11:21:32AM -0600, Bill Schmidt wrote:
> On 1/28/22 5:24 PM, Segher Boessenkool wrote:
> > On Fri, Jan 28, 2022 at 11:50:21AM -0600, Bill Schmidt wrote:
> >> When introducing the new built-in support, I tried to match as many
> >> existing error messages as possible. One
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/104291
gcc/cp/ChangeLog:
* pt.cc (for_each_template_parm_r) : Don't
walk subtrees if !include_nondeduced_p. Simplify given that
cp_walk_subtrees already walks
On 1/28/22 5:24 PM, Segher Boessenkool wrote:
> On Fri, Jan 28, 2022 at 11:50:21AM -0600, Bill Schmidt wrote:
>> When introducing the new built-in support, I tried to match as many
>> existing error messages as possible. One common form was "argument X must
>> be a Y-bit unsigned literal".
Dan Li writes:
> Shadow Call Stack can be used to protect the return address of a
> function at runtime, and clang already supports this feature[1].
>
> To enable SCS in user mode, in addition to compiler, other support
> is also required (as discussed in [2]). This patch only adds basic
>
This patch adds yet missing support for creating function pointer
types and to call functions through functions pointers in the C++ API
of libgccjit.
The method gccjit::context::new_call is overloaded so that it accepts
an rvalue instead of a function argument. Instead of creating ad-hoc
This patch adds yet missing C++ API entry points to create union types
and to set the fields of structs previously defined as opaque. A
missing convenience method returning NULL pointer values is also added
and used in one of the two provided tests.
gcc/jit/ChangeLog:
*
[ was: Re: [RFC] ldist: Recognize rawmemchr loop patterns ]
On 1/31/22 16:00, Richard Biener wrote:
I'm running into PR56888 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 ) on nvptx due to
this, f.i. in gcc/testsuite/gcc.c-torture/execute/builtins/strlen.c,
where
Thanks for the discussion and sorry for the slow reply, was out most of
last week.
Dan Li writes:
> Thanks, Ard,
>
> On 1/26/22 00:10, Ard Biesheuvel wrote:
>> On Wed, 26 Jan 2022 at 08:53, Dan Li wrote:
>>>
>>> Hi, all,
>>>
>>> Sorry for bothering.
>>>
>>> I'm trying to commit aarch64 scs code
On Mon, Jan 31, 2022 at 11:07 AM Patrick Palka wrote:
>
> Here during deduction guide generation for the nested class template
> B::C, the computation of outer_targs yields the template
> arguments relative to the primary template for B (i.e. {char(int)})
> but what we really what is those
Here during deduction guide generation for the nested class template
B::C, the computation of outer_targs yields the template
arguments relative to the primary template for B (i.e. {char(int)})
but what we really what is those relative to the enclosing scope, the
partial specialization of B (i.e.
On Mon, Jan 31, 2022 at 2:16 PM Tom de Vries wrote:
>
> On 9/17/21 10:08, Richard Biener via Gcc-patches wrote:
> > On Mon, Sep 13, 2021 at 4:53 PM Stefan Schulze Frielinghaus
> > wrote:
> >>
> >> On Mon, Sep 06, 2021 at 11:56:21AM +0200, Richard Biener wrote:
> >>> On Fri, Sep 3, 2021 at 10:01
On Mon, Jan 31, 2022 at 11:07 AM Xi Ruoyao wrote:
>
> On Mon, 2022-01-31 at 10:35 +0100, Richard Biener wrote:
> > On Sun, Jan 30, 2022 at 7:39 PM Xi Ruoyao via Gcc-patches
> > wrote:
> > >
> > > 'inf/inf' should raise an invalid operation exception at runtime.
> > > So it
> > > should not be
21766085775bd52c9db53629636c830fc9dc6fa0 openmp: Add support for
'target_device' context selector set
I have committed an extra fix to remove an extra comma in an error
message changed by this patch. This causes regressions in an existing
test for 'declare variant' because the expected
Hello.
It's about 5 months since the last project status update:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577108.html
Now it's pretty clear that it won't be merged before GCC 12.1 gets released.
So where we are? I contacted documentation maintainers (Gerald, Sandra and
Joseph) at
From: Bernd Kuhls
The detection of pthread support fails on OpenRISC unless _REENTRANT
is defined. Added the CPP_SPEC definition to correct this.
gcc/ChangeLog:
PR target/94372
* config/or1k/linux.h (CPP_SPEC): Define.
Signed-off-by: Bernd Kuhls
---
This was brought up on the
On 9/17/21 10:08, Richard Biener via Gcc-patches wrote:
On Mon, Sep 13, 2021 at 4:53 PM Stefan Schulze Frielinghaus
wrote:
On Mon, Sep 06, 2021 at 11:56:21AM +0200, Richard Biener wrote:
On Fri, Sep 3, 2021 at 10:01 AM Stefan Schulze Frielinghaus
wrote:
On Fri, Aug 20, 2021 at 12:35:58PM
Attached to this email is the patch updated to the recent renaming from *.c
to *.cc.
Am So., 23. Jan. 2022 um 14:18 Uhr schrieb Marc Nieper-Wißkirchen <
m...@nieper-wisskirchen.de>:
> Am Sa., 15. Jan. 2022 um 14:56 Uhr schrieb Marc Nieper-Wißkirchen
> :
> >
> > Jeff, David, do you need any more
This patch adds yet missing C++ API entry points to create union types
and to set the fields of structs previously defined as opaque. A
missing convenience method returning NULL pointer values is also added
and used in one of the two provided tests.
gcc/jit
*
The recent update on this script to handle strings rather than bytes
missed a call to ".decode()", leading to a crash:
AttributeError: 'str' object has no attribute 'decode'
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* doc/share/conf.py: Remove spurious call to
The previous change was short-circuiting too much, the regular
processing (in particular writing ALI files) was bypassed, causing
troubles with e.g. gnatmake or gprbuild down the road.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
PR ada/104027
* gnat1drv.adb
On Sun, Jan 30, 2022 at 10:16:44AM +, Navid Rahimi via Gcc-patches wrote:
> Thanks Jakob for the correction. Sadly, I didn’t have any access to any non
> x86 architecture. But x86 was fully tested and there was no regression.
>
> In my spare time I will look at implementation of this for
On Mon, 2022-01-31 at 10:35 +0100, Richard Biener wrote:
> On Sun, Jan 30, 2022 at 7:39 PM Xi Ruoyao via Gcc-patches
> wrote:
> >
> > 'inf/inf' should raise an invalid operation exception at runtime.
> > So it
> > should not be folded during compilation unless -fno-trapping-math is
> > used.
>
On Sun, Jan 30, 2022 at 7:39 PM Xi Ruoyao via Gcc-patches
wrote:
>
> 'inf/inf' should raise an invalid operation exception at runtime. So it
> should not be folded during compilation unless -fno-trapping-math is
> used.
I wonder if it would make sense to handle it similar to
inexact =
On Sat, Jan 29, 2022 at 12:24 AM Eugene Rozenfeld via Gcc-patches
wrote:
>
> param_early_inliner_max_iterations specifies the maximum number
> of nested indirect inlining iterations performed by early inliner.
> Normally, the default value is 1.
>
> For AutoFDO this parameter was also used as the
Pushed as obvious.
Martin
PR d/104287
gcc/d/ChangeLog:
* decl.cc (d_finish_decl): Remove trailing dot.
---
gcc/d/decl.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index 5ecc6269780..b08d797c851 100644
--- a/gcc/d/decl.cc
On 1/28/22 23:01, Jonathan Wakely wrote:
On Fri, 28 Jan 2022 at 18:17, Jeff Law wrote:
On 1/24/2022 4:11 AM, Martin Liška wrote:
On 1/21/22 17:54, Jonathan Wakely wrote:
Yes, OK (but please CC the libstdc++ list, not just me).
Hello.
Sorry for that. Anyway, I would like to install the
On Sat, 29 Jan 2022, Andrew Pinski wrote:
> On Sat, Jan 29, 2022 at 6:30 PM Zhao Wei Liew via Gcc-patches
> wrote:
> >
> > Sincere apologies for the issues. I wasn't aware of the need for a cast but
> > after reading the PRs, I understand that now. On the other hand, the
> > incorrect test case
On Sat, 29 Jan 2022, Jakub Jelinek wrote:
> On Fri, Jan 28, 2022 at 03:14:16PM -0700, Jeff Law via Gcc-patches wrote:
> > > This patch will add the missed pattern described in bug 103514 [1] to the
> > > match.pd. [1] includes proof of correctness for the patch too.
> > >
> > > PR
On Sat, 29 Jan 2022, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Jan 28, 2022 at 11:38:23AM -0700, Jeff Law wrote:
> > Thanks. Given the original submission and most of the review work was done
> > prior to stage3 closing, I went ahead and installed this on the trunk.
>
> Unfortunately this breaks
This is what has been done for ages on SPARC/Solaris and makes it possible to
use 64-bit atomic instructions even in 32-bit mode.
Tested on SPARC64/Linux, applied on the mainline.
2022-01-31 Eric Botcazou
PR target/104189
* config/sparc/linux64.h (TARGET_DEFAULT): Add
> Unfortunately this breaks quite a lot of things.
Right, for example in Ada where we now happily turn a division by zero, which
should raise an exception with -gnatp, into nonsense. Do we really need this
rather useless optimization in GCC? Blindly mimicing LLVM is not a reason...
I have
On Fri, 28 Jan 2022, Jeff Law wrote:
>
>
> On 1/24/2022 7:45 AM, Richard Biener via Gcc-patches wrote:
> > There are a few cases where we know we're dealing with (poly-)integer
> > constants, so remove the use of multiple_of_p in those cases to make
> > the PR100499 fix less impactful.
> >
> >
79 matches
Mail list logo
