On Mon, Aug 10, 2020 at 11:39:26PM -0300, Alexandre Oliva wrote:
> Erhm, I don't get why it's important that they be zeroed. It seems to
> me that restoring their original values, or setting them to random
> values, would be just as good defenses from having them set within the
In the
Hi:
The issue is described in the bugzilla.
Bootstrap is ok, regression test for i386/x86-64 backend is ok.
Ok for trunk?
ChangeLog
gcc/
PR target/96350
* config/i386/i386.c (ix86_legitimate_constant_p): Return
false for ENDBR immediate.
On Aug 7, 2020, Qing Zhao wrote:
> So, I believe that the call-used registers (especially those registers
> that pass parameters) need to be zeroed
> In order to mitigate the ROP attack.
Erhm, I don't get why it's important that they be zeroed. It seems to
me that restoring their original
On Mon, 2020-08-10 at 13:51 +0300, Darius Galis wrote:
>
> I've found the following patch
> https://gcc.gnu.org/legacy-ml/gcc-patches/2018-11/msg00983.html, but it
> is not in the latest sources.
> Could please let me know why it was not added? I'm willing to do any
> rework necessary in order
Now that dg-ice is available, let's try it out.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
PR c++/88003
* g++.dg/cpp1y/auto-fn61.C: New test.
---
gcc/testsuite/g++.dg/cpp1y/auto-fn61.C | 13 +
1 file changed, 13 insertions(+)
create
This patch by Clément Chigot changes the Go frontend and library to
use an eqtype function on AIX. The AIX linker is not able to merge
identical type descriptors in a single symbol if they are coming from
different object or shared object files. This results into several
pointers referencing the
Hi JOJO,
The patch looks good but the changlog lacks a leading text with commit
description.
On 8/10/20 4:17 PM, Jojo R wrote:
From: jojo
gcc/ChangeLog:
* config/csky/csky_opts.h (float_abi_type): New.
* config/csky/csky.h (TARGET_SOFT_FLOAT): New.
On Aug 10, 2020, at 2:30 PM, Marek Polacek via Gcc-patches
wrote:
>
> Thanks a lot. Here's the latest version of my patch, which only adds dg-ice
> at this point.
>
> So, um, OK?
Ok.
On Mon, Aug 10, 2020 at 05:16:15PM +0100, Richard Sandiford wrote:
> Senthil Kumar via Gcc-patches writes:
> > The wiki suggests using post-reload splitters, so that's the
> > direction I took, but I ran into an issue where split_insn
> > bails out early if RTX_FRAME_RELATED_P is true -
On Aug 7, 2020, at 6:16 AM, Nathan Sidwell wrote:
>
> On 8/6/20 8:01 PM, Mike Stump wrote:
>> On Aug 6, 2020, at 7:01 AM, Nathan Sidwell wrote:
>>>
XFAIL: g++.dg/foo.C -std=c++17 (internal compiler error)
PASS: g++.dg/foo.C -std=c++17 (test for excess errors)
Which one of
On Mon, Aug 10, 2020 at 08:58:54AM -0400, Nathan Sidwell wrote:
> On 8/10/20 4:48 AM, Richard Sandiford wrote:
> > Marek Polacek via Gcc-patches writes:
> > > > > > sure.
> > > > > > * develop patch
> > > > > > * run testsuite
> > > > > > * observe unexpected ICEs
> > > > > > * load g++.log into
On 8/10/20 2:18 PM, Patrick Palka wrote:
On Mon, 10 Aug 2020, Patrick Palka wrote:
In the below testcase, semantic analysis of the requires-expressions in
the generic lambda must be delayed until instantiation of the lambda
because the requirements depend on the lambda's template arguments.
On Mon, Aug 10, 2020 at 09:48:06AM +0100, Richard Sandiford wrote:
> Marek Polacek via Gcc-patches writes:
> >> > > sure.
> >> > > * develop patch
> >> > > * run testsuite
> >> > > * observe unexpected ICEs
> >> > > * load g++.log into editor
> >> > > * ^sinternal comp
> >> > > * gets to first
Hi!
On Mon, Aug 10, 2020 at 05:47:53PM +0200, Hans-Peter Nilsson wrote:
> > All of this was added in https://gcc.gnu.org/g:64b8935d4809 , which also
> > adds the
> >
> > + /* Disallow this recombination if both new_cost and old_cost are
> > + greater than zero, and new_cost is greater than
On 8/10/20 2:08 PM, Andrew MacLeod wrote:
On 8/10/20 2:46 PM, Martin Sebor wrote:
On 8/10/20 11:50 AM, Andrew MacLeod wrote:
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
int_range is the type which allows for up to X subranges.
On 8/10/20 2:46 PM, Martin Sebor wrote:
On 8/10/20 11:50 AM, Andrew MacLeod wrote:
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
int_range is the type which allows for up to X subranges.
calculations will be merged to fit within X
On 8/10/20 2:46 PM, Martin Sebor wrote:
On 8/10/20 11:50 AM, Andrew MacLeod wrote:
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ //
>>
>>> If so, I am okay with name “call-clobbered” if this name sounds better.
>>
>> It's more obvious, at least to me.
In the current option list of GCC:
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options
Gentle reminder, this time with tests.
I've added one for list::remove cause I think there was none, for
forward_list we had remove_freed.cc.
I added
// { dg-options "-g -O0" }
in the new tests otherwise it doesn't fail, that's life with UB. I know
that it can pass also with those options.
"Stubbs, Andrew" writes:
> Is GET_INNER_MODE valid for scalers though?
Yeah, GET_MODE_INNER (x) == x for scalars. That makes GET_MODE_INNER
useful for stripping vectorness or complexness without having to check
for them first. It's also useful when working out what the valid shift
ranges are
On Thu, 6 Aug 2020, Patrick Palka wrote:
> On Wed, 5 Aug 2020, Jason Merrill wrote:
>
> > On 8/4/20 8:00 PM, Patrick Palka wrote:
> > > On Tue, 4 Aug 2020, Patrick Palka wrote:
> > >
> > > > In the testcase below, we never substitute function-template arguments
> > > > into f15's
On 8/10/20 11:50 AM, Andrew MacLeod wrote:
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ // Remove the unknown parts of a multi-range.
+
On 8/9/20 10:03 PM, Peter Bergner wrote:
> PR96506 shows a problem where we ICE on illegal usage, namely using MMA
> types for function arguments and return values. The solution is to flag
> these illegal usages as errors early, before we ICE.
>
> The patch below is currently bootstrapping and
On 10 Aug 2020 17:23, Richard Sandiford wrote:
Andrew Stubbs writes:
> On 06/08/2020 04:54, Richard Sandiford wrote:
>>> diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
>>> index f9b0e9714d9..d7067989ad7 100644
>>> --- a/gcc/emit-rtl.c
>>> +++ b/gcc/emit-rtl.c
>>> @@ -947,6 +947,11 @@
On Mon, Aug 10, 2020 at 1:49 PM Jonathan Wakely wrote:
>
> On 10/08/20 09:45 -0400, Andres Rodriguez wrote:
> >*ping*
>
> As it says at https://gcc.gnu.org/lists.html all patches for libstdc++
> need to be sent to the libstdc++ mailing as well as the gcc-patches
> list. Otherwise I won't see
On Mon, 10 Aug 2020, Patrick Palka wrote:
> In the below testcase, semantic analysis of the requires-expressions in
> the generic lambda must be delayed until instantiation of the lambda
> because the requirements depend on the lambda's template arguments. But
> tsubst_requires_expr does
On 10/08/20 13:24 +0100, Jonathan Wakely wrote:
The configure switch should only affect the optional Filesystem TS, not
the std::filesystem features of C++17.
libstdc++-v3/ChangeLog:
PR libstdc++/94681
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Do not depend on
On Mon, Aug 10, 2020 at 05:29:49PM +, GT wrote:
> > For PowerPC, if all you want to support is b which requires VSX, then the
> > right thing is for !TREE_PUBLIC functions return 0 if !TARGET_VSX and
> > otherwise set vecsize_mangle to 'b' and in the end return 1, for exported
> > functions
On Mon, Aug 10, 2020 at 03:05:26PM +0200, Aldy Hernandez wrote:
> For the record. The final patch (below) passes tests on ppc64le for both
> trunk, and the ranger-staging branch with ranger enabled.
>
> Aldy
>
> gcc/ChangeLog:
>
> * ipa-fnsummary.c (evaluate_conditions_for_known_args):
>
Yes, the goal is that anything that may take multi ranges be rewritten to
use an irange * and use the API exclusively. Then when multi ranges are
passed down eventually, things will work transparently.
Aldy
On Mon, Aug 10, 2020, 19:50 Andrew MacLeod wrote:
> On 8/10/20 12:35 PM, Martin Sebor
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ // Remove the unknown parts of a multi-range.
+ // This will transform [5,10][20,MAX] into
On 10/08/20 09:45 -0400, Andres Rodriguez wrote:
*ping*
As it says at https://gcc.gnu.org/lists.html all patches for libstdc++
need to be sent to the libstdc++ mailing as well as the gcc-patches
list. Otherwise I won't see them, and everybody else will ignore them.
On Tue, Aug 4, 2020 at
‐‐‐ Original Message ‐‐‐
On Friday, August 7, 2020 4:59 PM, Jakub Jelinek wrote:
> On Fri, Aug 07, 2020 at 08:35:52PM +, Bert Tenjy via Gcc-patches wrote:
>
> > The document describing POWER Architecture Vector Function interface is
> > tentatively at:
> >
On Mon, Aug 10, 2020 at 06:58:52PM +0200, Richard Biener wrote:
> We want to construct / destruct on push/pop, not on allocation.
> We also want to use std::move upon reallocation (but then we can't use
> realloc, can we?)
I guess so, but we could stop using xrealloc or ggc_realloc only for
Hi,
in the code about DO loop warning I recently introduced, there was
a hidden NULL pointer dereference found by Jürgen Reuter and fixed
as obvious and simple in r11-2636.
Fix NULL pointer dereference in doloop_contained_function_call.
Thanks to Jürgen for the bug report and to Dominique for
On August 10, 2020 3:51:28 PM GMT+02:00, Jakub Jelinek via Gcc-patches
wrote:
>On Mon, Aug 10, 2020 at 02:57:31PM +0200, Aldy Hernandez wrote:
>> > I think it would be nice to see e.g. in -fdump-tree-gimple dump
>> > on ipa-fnsummary.c what value_range ctors does it call for the
>auto_vec and
>>
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
On 7/26/20 11:41 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
On 7/16/20 4:53 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
On 7/26/20 11:42 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
On 7/13/20 6:05 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/551152.html
On 7/31/20 5:55 PM, Martin Sebor wrote:
The folders for these functions (and some others) call c_getsr
which relies on string_constant to return the representation of
constant strings. Because the function doesn't handle
Hi,
> On Aug 7, 2020, at 5:59 PM, Segher Boessenkool
> wrote:
>
>> From my understanding (I am not a security expert though), this patch should
>> serve two purpose:
>>
>> 1. Erase the registers upon return to avoid information leak;
>
> But only some of the registers.
All the call-used
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ // Remove the unknown parts of a multi-range.
+ // This will transform [5,10][20,MAX] into [5,10].
Is this comment correct? Wouldn't this result
Andrew Stubbs writes:
> On 06/08/2020 04:54, Richard Sandiford wrote:
>>> diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
>>> index f9b0e9714d9..d7067989ad7 100644
>>> --- a/gcc/emit-rtl.c
>>> +++ b/gcc/emit-rtl.c
>>> @@ -947,6 +947,11 @@ validate_subreg (machine_mode omode, machine_mode
>>> imode,
Senthil Kumar via Gcc-patches writes:
> Hi,
>
> I'm working on converting the AVR backend to MODE_CC, following
> the steps described for case #2 in the CC0 transition wiki page,
> and I've implemented the first three bullet
> points
In the below testcase, semantic analysis of the requires-expressions in
the generic lambda must be delayed until instantiation of the lambda
because the requirements depend on the lambda's template arguments. But
tsubst_requires_expr does semantic analysis even during regeneration of
the lambda,
On 7/23/20 3:29 PM, Jeff Law wrote:
>>> What's driving this change?
>>
>> Peter noticed IRA allocates stuff to volatile registers while it is life
>> through a call, and then LRA has to correct that, not optimal.
> I can't recall if IRA or LRA handles the need to save them to the stack, but
> the
> From: Segher Boessenkool
> Date: Fri, 17 Jul 2020 02:05:19 +0200
> On Tue, Jul 14, 2020 at 04:33:42PM -0500, Segher Boessenkool wrote:
> > > If combine only did lower-cost combinations (perhaps with
> > > Richard Sandifords lower-size-when-tied suggestion), I guess
> > > this wouldn't happen.
(Back from vacation, found that this had an unanswered question,
quoted last.)
> From: Segher Boessenkool
> Date: Tue, 14 Jul 2020 23:58:05 +0200
> Hi!
>
> On Mon, Jul 06, 2020 at 04:01:54AM +0200, Hans-Peter Nilsson via Gcc-patches
> wrote:
> > Most comments, including the second sentence in
On 8/8/20 5:23 AM, Jakub Jelinek wrote:
Hi!
The following valid testcase is rejected, because cxx_eval_binary_expression
is called on the SPACESHIP_EXPR with lval = true, as the address of the
spaceship needs to be passed to a method call.
After recursing on the operands and calling
Christophe Lyon writes:
> On Wed, 5 Aug 2020 at 16:33, Richard Sandiford
> wrote:
>>
>> The stack_protect_test patterns were leaving the canary value in the
>> temporary register, meaning that it was often still in registers on
>> return from the function. An attacker might therefore have been
Hi folks,
long time, no see. I was asked by Damian to do some Coarray stuff in gfortran
so here is the first step on fixing a bug. The issue at hand is, that the
coarray handling is not propagated correctly and later on the coarray-token
not generated/retrieved from the correct position leading
Hi Bin,
on 2020/8/10 下午8:38, Bin.Cheng wrote:
> On Mon, Aug 10, 2020 at 12:27 PM Kewen.Lin wrote:
>>
>> Hi Bin,
>>
>> Thanks for the review!!
>>
>> on 2020/8/8 下午4:01, Bin.Cheng wrote:
>>> Hi Kewen,
>>> Sorry for the late reply.
>>> The patch's most important change is below cost computation:
From: Joe Ramsay
Hi,
This patch rearranges feature bits for MVE and FP to implement the
following flags for -mcpu=cortex-m55.
- +nomve:equivalent to armv8.1-m.main+fp.dp+dsp.
- +nomve.fp: equivalent to armv8.1-m.main+mve+fp.dp (+dsp is implied by +mve).
- +nofp: equivalent to
On Mon, Aug 10, 2020 at 02:57:31PM +0200, Aldy Hernandez wrote:
> > I think it would be nice to see e.g. in -fdump-tree-gimple dump
> > on ipa-fnsummary.c what value_range ctors does it call for the auto_vec and
> > if that is what we want, other than that LGTM.
>
> I see the following in the
On Tue, 28 Jul 2020, Patrick Palka wrote:
> Currently the -Wmisleading-indentation warning doesn't do any analysis
> when the guarded statement or the statement after it is produced by a
> macro, as the mentioned PR illustrates. This means that we warn for:
>
> if (flag)
> foo ();
>
*ping*
On Tue, Aug 4, 2020 at 10:51 AM Andres Rodriguez wrote:
>
> On binaries compiled against gcc5 the impl_type parameter is None,
> which results in an exception being raised by is_specialization_of()
>
> These versions of std::unique_ptr have the tuple as a root element.
> ---
>
> Hi,
>
> I
On Fri, 7 Aug 2020, Jason Merrill wrote:
> On 8/6/20 1:50 PM, Patrick Palka wrote:
> > This patch eliminates an exponential dependence in cxx_eval_vec_init on
> > the array dimension of a VEC_INIT_EXPR when the RANGE_EXPR optimization
> > applies. This is achieved by using a single
On Wed, 5 Aug 2020 at 16:33, Richard Sandiford
wrote:
>
> The stack_protect_test patterns were leaving the canary value in the
> temporary register, meaning that it was often still in registers on
> return from the function. An attacker might therefore have been
> able to use it to defeat
For the record. The final patch (below) passes tests on ppc64le for
both trunk, and the ranger-staging branch with ranger enabled.
Aldy
gcc/ChangeLog:
* ipa-fnsummary.c (evaluate_conditions_for_known_args):
(evaluate_properties_for_edge):
On 8/10/20 4:48 AM, Richard Sandiford wrote:
Marek Polacek via Gcc-patches writes:
sure.
* develop patch
* run testsuite
* observe unexpected ICEs
* load g++.log into editor
* ^sinternal comp
* gets to first unexpected ICE
* debug it.
What does '^sinternal comp' become? As there could be
On 8/7/20 8:33 PM, Jakub Jelinek wrote:
On Fri, Aug 07, 2020 at 08:04:57PM +0200, Aldy Hernandez wrote:
--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -82,7 +82,6 @@ along with GCC; see the file COPYING3. If not see
#include "gimplify.h"
#include "stringpool.h"
#include
On Mon, Aug 10, 2020 at 12:27 PM Kewen.Lin wrote:
>
> Hi Bin,
>
> Thanks for the review!!
>
> on 2020/8/8 下午4:01, Bin.Cheng wrote:
> > Hi Kewen,
> > Sorry for the late reply.
> > The patch's most important change is below cost computation:
> >
> >> @@ -5890,6 +5973,10 @@ determine_iv_cost (struct
The configure switch should only affect the optional Filesystem TS, not
the std::filesystem features of C++17.
libstdc++-v3/ChangeLog:
PR libstdc++/94681
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Do not depend on
$enable_libstdcxx_filesystem_ts.
* configure:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ // Remove the unknown parts of a multi-range.
+ // This will transform [5,10][20,MAX] into [5,10].
Is this comment correct? Wouldn't this result in returning smaller
sizes than the actual
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (inserter): Do not deduce
iterator type (LWG 561).
* testsuite/24_iterators/insert_iterator/dr561.cc: New test.
Tested powerpc64le-linux. Committed to trunk.
commit 2203a80a72cb582364245b6997d0724a5f84e062
Author:
On 8/10/20 12:22 PM, Gerald Pfeifer wrote:
On Mon, 10 Aug 2020, Aldy Hernandez wrote:
My bad. I thought Gerald had committed the inline fix as well.
Oh, and I thought you were going to after my success report. :-)
(I did not run into problems because my own tester passed since I
still
On 10/08/20 10:22 +0100, Jozef Lawrynowicz wrote:
Hi,
On Thu, Aug 06, 2020 at 06:48:36PM +, Jonathan Wakely via Gcc-patches wrote:
I've now pushed that combined patch to master.
In libstdc++-v3/include/bits/basic_string.tcc around line 1190, there's a
missing "#if __cpp_exceptions" test
This file was unintentionally added by r271568 when backporting a change
from trunk.
* src/c++17/Makefile.in: Remove unused file.
Tested x86_64-linux. Pushed to releases/.gcc-8 branch.
[no attachment, because it's just deleting a generated file]
Hello,
I've found the following patch
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-11/msg00983.html, but it
is not in the latest sources.
Could please let me know why it was not added? I'm willing to do any
rework necessary in order for it to be accepted to the latest sources.
Thank you
On 8/10/20 12:22 PM, Gerald Pfeifer wrote:
If your test bootstraping with GCC passes, I think (especially as
the original author of this code) you can invoke the obvious rule
and go ahead.
Yes, I would also consider it an obvious change.
Martin
On 8/3/20 12:29 PM, Richard Biener wrote:
You are always passing NULL here so simply avoid this and the following changes.
Are you sure about this?
Note that vect_slp_bb does:
+ if (!vect_find_stmt_data_reference (NULL, stmt, ,
+ _groups,
On Mon, 10 Aug 2020, Aldy Hernandez wrote:
> My bad. I thought Gerald had committed the inline fix as well.
Oh, and I thought you were going to after my success report. :-)
(I did not run into problems because my own tester passed since I
still had your patch locally.9
> OK pending tests?
>
>
In order to handle large files on Windows we need to use stat API with
64-bit st_size member.
libstdc++-v3/ChangeLog:
PR libstdc++/95749
* src/filesystem/ops-common.h [_GLIBCXX_FILESYSTEM_IS_WINDOWS]
(stat_type): Change to __stat64.
(stat): Use _wstat64.
Tested
Ping^3
On Tue, Aug 4, 2020 at 4:21 PM Hongtao Liu wrote:
>
> ping ^2
>
> On Mon, Jul 27, 2020 at 5:31 PM Hongtao Liu wrote:
> >
> > ping
> >
> > On Wed, Jul 22, 2020 at 12:59 PM Hongtao Liu wrote:
> > >
> > > Those two define_insns have same pattern, and
> > > _load_mask would always be
Ping^3
On Tue, Aug 4, 2020 at 4:21 PM Hongtao Liu wrote:
>
> ping ^2
>
> On Mon, Jul 27, 2020 at 5:31 PM Hongtao Liu wrote:
> >
> > ping
> >
> > On Wed, Jul 22, 2020 at 3:57 PM Hongtao Liu wrote:
> > >
> > > Bootstrap is ok, regression test is ok for i386 backend.
> > >
> > > gcc/
> > >
Hi,
On Thu, Aug 06, 2020 at 06:48:36PM +, Jonathan Wakely via Gcc-patches wrote:
>
> I've now pushed that combined patch to master.
In libstdc++-v3/include/bits/basic_string.tcc around line 1190, there's a
missing "#if __cpp_exceptions" test for the try/catch block that was
added by this
On Mon, Aug 10, 2020 at 10:36 AM Roger Sayle wrote:
>
>
> To make amends for the recent (temporary) testsuite failure
> of my new gcc.target/i386/minmax-9.c when compiled with -m32,
> this patch improves the -m32 code we generate for the examples
> in that test case.
>
> Currently, smax(x,0)
Marek Polacek via Gcc-patches writes:
>> > > sure.
>> > > * develop patch
>> > > * run testsuite
>> > > * observe unexpected ICEs
>> > > * load g++.log into editor
>> > > * ^sinternal comp
>> > > * gets to first unexpected ICE
>> > > * debug it.
>> > >
>> > > What does '^sinternal comp' become?
On Sun, Aug 09, 2020 at 11:24:54PM +0200, Marc Glisse wrote:
> Odd numbers are invertible in Z / 2^n Z, so X * C1 == C2 can be rewritten as
> X == C2 * inv(C1) when overflow wraps.
>
> mod_inv should probably be updated to better match the other wide_int
> functions, but that's a separate issue.
To make amends for the recent (temporary) testsuite failure
of my new gcc.target/i386/minmax-9.c when compiled with -m32,
this patch improves the -m32 code we generate for the examples
in that test case.
Currently, smax(x,0) generates the very cool implementation:
smax0: movl4(%esp), %eax
From: jojo
gcc/ChangeLog:
* config/csky/csky_opts.h (float_abi_type): New.
* config/csky/csky.h (TARGET_SOFT_FLOAT): New.
(TARGET_HARD_FLOAT): New.
(TARGET_HARD_FLOAT_ABI): New.
(OPTION_DEFAULT_SPECS): Use mfloat-abi.
* config/csky/csky.opt
On 8/7/20 12:04 AM, Segher Boessenkool wrote:
I think this makes a lot of sense.
Hello.
I also support the patch (as Segher, I can't approve it).
Martin
On 8/10/20 5:42 AM, Martin Liška wrote:
On 8/5/20 4:27 PM, Gerald Pfeifer wrote:
Hi Aldy,
On Fri, 31 Jul 2020, Aldy Hernandez via Gcc-patches wrote:
Jeff approved this patch off-list. I will re-run tests once again and
commit by Monday.
I believe this has broken the bootstrap with clang
82 matches
Mail list logo
