On Dec 10, 2021, Jeff Law wrote:
> The patch is clearly safe. My question is should we have caught this
> earlier in the call chain?
Callers will call try_store_by_multiple_pieces if set_storage_via_setmem
fails. setmem doesn't necessarily need min and max len to do its job,
so if we were to m
While doing tests of the PCH changes, I noticed that all the
plugin tests were being omitted from m32 Darwin under some
permutations of flags. It turned out to be a broken config
test - it was not removing -mdynamic-no-pic properly.
We now use a C++ compiler so that we need to process CXXFLAGS
as
We include libgcc_tm.h to provide a prototype for this shim
so add that to the make dependencies.
tested on x86_64-darwin, pushed to master, thanks
Iain
Signed-off-by: Iain Sandoe
libgcc/ChangeLog:
* config/t-darwin: Add libgcc_tm.h to the dependencies
for darwin10-unwind-find-
libgccjit was failing to set the DECL_CONTEXT of function RESULT_DECLs,
leading to them failing to be properly handled by the inlining machinery.
Fixed thusly.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-5903-ga2f4b4b76cdd0a4150e82e69fae4a70c54b523d2.
gcc
Hi!
OK to push the attached "testsuite: Be more informative for ICEs"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesell
On 12/9/2021 3:18 PM, Alexandre Oliva via Gcc-patches wrote:
The conversion of a MEM address to ptr_mode in
try_store_by_multiple_pieces was misguided: copy_addr_to_reg expects
Pmode for addresses.
Regstrapped on x86_64-linux-gnu, testcase verified with a cross to
aarch64. Ok to install?
f
On 12/9/2021 3:16 PM, Alexandre Oliva via Gcc-patches wrote:
The testcase confuses the code that detects min and max len for the
memset, so max_len ends up less than min_len. That shouldn't be
possible, but the testcase requires us to handle this case.
The store-by-mult-pieces algorithm actu
My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says
"If the placeholder-type-specifier is of the form type-constraint[opt]
decltype(auto), T shall be the placeholder alone." But this made us
reject 'constexpr decltype(auto)', which, after clarification from CWG,
should be valid.
Dear all,
when accessing CLASS components we need to ensure that the
corresponding class container has already been built.
Invalid code, e.g. the testcase in PR103606, may otherwise
generate segfaults due to invalid reads.
Regtested on x86_64-pc-linux-gnu. OK for mainline / branches?
Thanks,
Ha
On 10/12/21 21:20 +, Jonathan Wakely wrote:
Ping
Oh sorry, Jakub already replied to this (after I mentioned it on IRC)
and approved it.
Un-ping!
On 09/11/21 17:51 +, Jonathan Wakely wrote:
Now that GCC is compiled as C++11 there is no need to keep the C++03
implementation of gnu:
On 12/10/2021 5:56 AM, Jakub Jelinek wrote:
On Thu, Dec 09, 2021 at 05:59:54PM +0100, Jakub Jelinek via Gcc-patches wrote:
/tmp/6140018_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/aarch64-sve-builtins.cc:3920:0:
./gt-aarch64-sve-builtins.h: In function 'void
gt_pch_p_19regi
Ping
On 09/11/21 17:51 +, Jonathan Wakely wrote:
Now that GCC is compiled as C++11 there is no need to keep the C++03
implementation of gnu::unique_ptr.
This removes the unique-ptr.h header and replaces it with in
system.h, and changes the INCLUDE_UNIQUE_PTR macro to INCLUDE_MEMORY.
Uses o
On 12/9/2021 10:32 AM, Hafiz Abid Qadeer wrote:
Commit 13b6c7639cf assumed that registers in a span will be in a certain
order. But that assumption is not true at least for the big endian targets.
Currently amdgcn is probably only target where CFA is split into multiple
registers so build_span
On 12/10/2021 8:41 AM, Patrick Palka via Gcc-patches wrote:
The function comment for adjust_field_tree_exp says this special case
is for handling trees whose operands may contain pointers to RTL instead
of to trees. But ever since r0-59671, which fixed/removed the last two
tree codes for whic
Robin Dapp writes:
> Hi Kewen, Richard,
>
> thanks for the comments, I addressed them in the attached v4.
Sorry again for the slow review. I only have some very minor
comments left:
> Bootstrap and regtest are good as before.
>
> Regards
> Robin
>
> diff --git a/gcc/config/rs6000/vsx.md b/gcc/
We use processing_template_decl in two slightly different ways: as
a flag to signal that we're dealing with templated trees, and its
magnitude is also used as a proxy for the current syntactic template
depth. This overloaded meaning of p_t_d is conceptually confusing and
leads to bugs that we end
Hi,
I would favor adding support for this kind of initialization to libgccjit.
Does it also support the libgccjit equivalent of the following C module,
which contains forward references in the struct initializers?
struct bar bar;
struct foo foo;
struct foo
{
struct bar *b;
};
struct bar
{
On Tue, Nov 09, 2021 at 05:51:27PM +, Jonathan Wakely via Gcc-patches wrote:
> Now that GCC is compiled as C++11 there is no need to keep the C++03
> implementation of gnu::unique_ptr.
>
> This removes the unique-ptr.h header and replaces it with in
> system.h, and changes the INCLUDE_UNIQUE_
Joel Hutton writes:
> ok for backport to 11?
Yes, thanks.
Richard
Hello,
The build of a VxWorks toolchain relies a lot on system headers
and VxWorks has a few very specific features that require special
processing. For example, different sets of headers for the kernel
vs the rtp modes, which the compiler knows about by way of -mrtp
on the command line.
If we ma
On Fri, 10 Dec 2021 at 17:07, Olivier Hainque via Libstdc++
wrote:
>
> Hello,
>
> The attached patch helps fix a build failure of libstdc++
> on some variants of VxWorks where the system headers expose
> an "isblank" macro.
>
> I understand this kind of thing normally is handled through
> fixinclu
On Fri, 10 Dec 2021 at 17:17, Jakub Jelinek wrote:
>
> On Fri, Dec 10, 2021 at 10:11:04AM -0700, Martin Sebor via Gcc-patches wrote:
> > On 12/10/21 9:41 AM, Jakub Jelinek wrote:
> > > On Fri, Dec 10, 2021 at 09:35:50AM -0700, Martin Sebor via Gcc-patches
> > > wrote:
> > > > The above was just a
On Fri, 10 Dec 2021 at 16:35, Martin Sebor wrote:
>
> On 12/10/21 3:12 AM, Jonathan Wakely wrote:
> > On Fri, 10 Dec 2021 at 01:50, Martin Sebor via Libstdc++
> > wrote:
> >>
> >> On 12/9/21 5:38 PM, Martin Sebor wrote:
> >>> On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:
> These
I was curious if our auto(x) works in contexts like bit-field width
and similar. It appears that it does. Might be worth adding a test
for it.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/auto-fncast10.C: New test.
---
gcc/testsuite/g++.dg/cpp
This patch adds support for an -Oz command line option, aggressively
optimizing for size at the expense of performance. GCC's current -Os
provides a reasonable balance of size and performance, whereas -Oz is
probably only useful for code size benchmarks such as CSiBE. Or so I
thought until I rea
This adds testcases for metadirectives.
KwokFrom d3f80b603298fb2f3501a28b888acfdbc02a64e7 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Tue, 7 Dec 2021 11:25:33 +
Subject: [PATCH 7/7] openmp: Add testcases for metadirectives
2021-12-10 Kwok Cheung Yeung
gcc/testsuite/
This patch implements metadirective parsing in the Fortran frontend.
The code previously used to process context selectors in 'declare
variant' is refactored so that it can be reused in metadirectives. The
big case lists in parse_executable are moved into macros, since
parse_omp_metadirective_
This patch adds metadirective parsing support to the C++ parser. This is
basically just a straight port of the C code to the C++ front end.
KwokFrom e9bb138d4c3f560e48e408facce2361533685a98 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Mon, 6 Dec 2021 22:58:01 +
Subject: [PATCH 5/7
This patch adds support for streaming the Gimple metadirective
representation during LTO. An extra pass (also using
omp_get_dynamic_candidates) is also added to resolve metadirectives
after LTO, which is required for selectors that need to be resolved on
the accel compiler.
KwokFrom 85826d05e
This patch contains code to resolve metadirectives, either during
parsing or Gimplification.
The dynamic candidate selection algorithm from the OpenMP 5.1 spec is
implemented in omp_get_dynamic_candidates in omp-general.c, which
returns a vector containing information on the top-scoring candid
This patch contains the required support for metadirectives in the
middle-end.
The tree metadirective representation is gimplified into the high Gimple
representation, which is structured like this:
#pragma omp metadirective
when ():
goto body_label|end_label
when (>:
go
This patch adds support for parsing metadirectives in the C parser.
Metadirectives are represented by a OMP_METADIRECTIVE tree node. It has
a single operand (accessed by OMP_METADIRECTIVE_CLAUSES) which contains
a chain of TREE_LIST nodes, each one representing a clause from the
metadirective.
Hello
This is my current patchset for OpenMP metadirectives support. It aims
to implement the specification from OpenMP 5.1, with dynamic selector
support (though currently only the dynamic user selector set is
supported), and supports the C, C++ and Fortran front ends.
The patch has been bo
Hello
It has been several months since I posted my WIP patch, and my current
patch set (which I will post separately) has evolved considerably since
then. I have added C++ and Fortran support, as well as dynamic selectors
from the OpenMP 5.1 spec (currently only the 'user={condition()}'
selec
On Fri, Dec 10, 2021 at 10:11:04AM -0700, Martin Sebor via Gcc-patches wrote:
> On 12/10/21 9:41 AM, Jakub Jelinek wrote:
> > On Fri, Dec 10, 2021 at 09:35:50AM -0700, Martin Sebor via Gcc-patches
> > wrote:
> > > The above was just a quick proof of concept experiment. You're
> > > of course righ
On 12/10/21 9:41 AM, Jakub Jelinek wrote:
On Fri, Dec 10, 2021 at 09:35:50AM -0700, Martin Sebor via Gcc-patches wrote:
The above was just a quick proof of concept experiment. You're
of course right that the final solution can't be so crude(*).
But if the required functions are always_inline (I
Hello,
The attached patch helps fix a build failure of libstdc++
on some variants of VxWorks where the system headers expose
an "isblank" macro.
I understand this kind of thing normally is handled through
fixincludes, however fixincludes on VxWorks is very tricky and
we already have
libstdc++-
On 10/12/2021 16:36, Andrea Corallo via Gcc-patches wrote:
Richard Earnshaw via Gcc-patches writes:
On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:
-Original Message-
From: Gcc-patches On Behalf Of Tejas Belagod via
Gcc-patches
Sent: Friday, October 8, 2021 1:19 PM
To:
On 10/12/2021 16:36, Andrea Corallo via Gcc-patches wrote:
Richard Earnshaw via Gcc-patches writes:
On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:
-Original Message-
From: Gcc-patches On Behalf Of Tejas Belagod via
Gcc-patches
Sent: Friday, October 8, 2021 1:19 PM
To:
On Fri, Dec 10, 2021 at 09:35:50AM -0700, Martin Sebor via Gcc-patches wrote:
> The above was just a quick proof of concept experiment. You're
> of course right that the final solution can't be so crude(*).
> But if the required functions are always_inline (I think member
> functions defined in th
Richard Earnshaw via Gcc-patches writes:
> On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:
>>
>>> -Original Message-
>>> From: Gcc-patches >> bounces+belagod=gcc.gnu@gcc.gnu.org> On Behalf Of Tejas Belagod via
>>> Gcc-patches
>>> Sent: Friday, October 8, 2021 1:19 PM
>>> To
On 12/10/21 3:12 AM, Jonathan Wakely wrote:
On Fri, 10 Dec 2021 at 01:50, Martin Sebor via Libstdc++
wrote:
On 12/9/21 5:38 PM, Martin Sebor wrote:
On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:
These warnings are triggered by perfectly valid code using std::string.
They're parti
'arglist' can be captured by a conversion within 'candidates', but if we
use a releasing_vec then we'll be sure to free it only after
'candidates' is freed by obstack_free.
Bootstrapped and regtested in x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
* call.c (build_n
> On 10 Dec 2021, at 16:42, Jonathan Wakely wrote:
>
>
> OK to commit then, thanks.
>
> The comment is a bit misleading though:
>
> +// libstdc++ relies on C99 features for virtually all versions of C++,
> +// up to at least C++98.
> +#undef _C99
> +#define _C99 1
>
> The "up to" seems bac
On Fri, Dec 10, 2021 at 10:48:00AM -0500, Patrick Palka via Gcc-patches wrote:
> This flag is never set because non-dependent COMPOUND_EXPRs are fully
> resolved into a CALL_EXPR at template definition time (in
> build_x_compound_expr) ever since r6-5772.
>
> Bootstrapped and regtested on x86_64-p
On Fri, Dec 10, 2021 at 10:48 AM Patrick Palka wrote:
>
> This flag is never set because non-dependent COMPOUND_EXPRs are fully
Whoops, this should say, ... non-dependent COMPOUND_EXPRs that resolve
to an overload are expressed as a CALL_EXPR at template definition
time ...
> resolved into a CAL
On Fri, 10 Dec 2021 at 12:49, Jakub Jelinek via Libstdc++
wrote:
>
> Hi!
>
> This incremental patch adds std::time_get %r support (%p was added already
> in the previous patch). The _M_am_fm_format method previously in the header
> unfortunately had wrong arguments and so was useless, so the larg
On Thu, 9 Dec 2021 at 14:20, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch is an attempt to fix various time_get related issues.
> Sorry, it is long...
>
> One of them is PR78714. It seems _M_extract_via_format has been written
> with how strftime behaves in mind rather than how strptime be
This flag is never set because non-dependent COMPOUND_EXPRs are fully
resolved into a CALL_EXPR at template definition time (in
build_x_compound_expr) ever since r6-5772.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
* cp-tree.h (COMPOU
On Fri, 10 Dec 2021 at 15:16, Rasmus Villemoes via Libstdc++
wrote:
>
> On 10/12/2021 16.06, Olivier Hainque wrote:
> > Hello,
> >
> > The attached patch for libstdc++ / VxWorks helps building
> > the library for old versions of the OS, as witnessed with
> > VxWorks 6.9 in particular.
> >
> > It e
The function comment for adjust_field_tree_exp says this special case
is for handling trees whose operands may contain pointers to RTL instead
of to trees. But ever since r0-59671, which fixed/removed the last two
tree codes for which this was possible (GOTO_SUBROUTINE_EXPR and
WITH_CLEANUP_EXPR),
On 10/12/2021 16.06, Olivier Hainque wrote:
> Hello,
>
> The attached patch for libstdc++ / VxWorks helps building
> the library for old versions of the OS, as witnessed with
> VxWorks 6.9 in particular.
>
> It explicitly requests C99 features from old system headers,
> on which libstc++ relies s
> On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote:
>
> These declarations prevent the priority given in the
> constructor/destructor attributes from taking effect, thus emitting
> the function pointers in the ordinary (lowest-priority)
> .init_array/.fini_array sections.
>
> libgcc/
> *
> On 10 Dec 2021, at 16:07, Rasmus Villemoes wrote:
>
>>
>> This is OK, can you please commit?
>
> Well, yes, but it depends contextually (but not functionally) on patch
> 2/4. Should I redo this one, or can I get you to take a look at 2/4 first?
>
> You've already ok'ed 1/4 and 4/4 (which
This patch to the mips backend updates the representations used
internally for MIPS' wsbh, dsbh and dshd instructions. These were
previously described using an UNSPEC rtx, which prevents simplification
at the RTL level. In addition to now being able to eliminate rotate
instructions before/after
On 10/12/2021 15.20, Olivier Hainque wrote:
> Hi again Rasmus,
>
>> On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote:
>>
>> When the translation unit itself creates pointers to the ctors/dtors
>> in a specific section handled by the linker (whether .init_array or
>> .ctors.*), there's no reason fo
Hi Jeff,
> I'd generally prefer to refactor the bits between the restart label and
> the goto restart into a function and call it twice, passing in the
> additional bits to allow for better costing. Can you look into that?
> If it's going to be major surgery, then the goto approach will be OK
Hello,
The attached patch for libstdc++ / VxWorks helps building
the library for old versions of the OS, as witnessed with
VxWorks 6.9 in particular.
It explicitly requests C99 features from old system headers,
on which libstc++ relies since at least c++98. The specific
issue that exposed this wa
In order to properly implement two-stage name lookup for dependent
operator expressions, we need to remember the result of unqualified
lookup of the operator at template definition time, and reuse that
result rather than performing another unqualified lookup at
instantiation time.
Ideally we could
Richard Earnshaw writes:
> On 09/12/2021 17:36, Andrea Corallo via Gcc-patches wrote:
>> Richard Earnshaw via Gcc-patches writes:
>>
>>> On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:
> -Original Message-
> From: Gcc-patches bounces+belagod=gcc.gnu@gcc.g
This patch is the middle-end piece of a set of patches for PR target/43892,
that improves combine's ability to optimize instructions with multiple
side-effects, such as updating explicit carry (flag) registers.
In RTL, an instruction that updates multiple registers is represented
as a PARALLEL of
Hi again Rasmus,
> On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote:
>
> When the translation unit itself creates pointers to the ctors/dtors
> in a specific section handled by the linker (whether .init_array or
> .ctors.*), there's no reason for the functions to have external
> linkage. That end
Tested powerpc64le-linux --enable-threads={posix,single}, pushed to
trunk. The testsuite is now clean for --enable-threads=single (apart
from the expected abi-check failures, because the baselines are for the
posix thread model).
A mutex and condition variable is used for timed waits on atomics
Tested powerpc64le-linux --enable-threads={posix,single}, pushed to trunk.
If no OS function to sleep (e.g. nanosleep, usleep, Win32 Sleep etc.) is
available then configure defines the macro NO_SLEEP. But this will not
get prefixed with "_GLIBCXX_" because include/Makefile.am only does that
for m
Hello,
The attached patch fixes a couple of incorrect things in
the VxWorks default LINK_SPEC, exposed during our work on
the support for building shared libraries.
-v needs to generate a -V not -v, as most/all other ports do,
to output the available emulations.
The latter causes collect2 to out
Excerpts from Iain Buclaw's message of December 9, 2021 11:11 pm:
> Excerpts from Andreas Schwab's message of December 9, 2021 11:09 am:
>> Breaks aarch64:
>>
>> ../../../../libphobos/libdruntime/core/sys/linux/unistd.d:10:15: error:
>> module 'core.sys.linux.syscalls' import 'SystemCall' not fou
Hello,
The attached patch just removes the assignment to STMP_FIXINC
from t-vxworks.
This aligns VxWorks with what the vast majority of targets do
and the value set was redundant with the default Makefile setting
anyway, possibly confusing on a target when the management
of fixincludes is pretty
> On 10 Dec 2021, at 14:29, Rasmus Villemoes wrote:
>
> On 10/12/2021 14.08, Olivier Hainque wrote:
>> Hello,
>>
>> The attached patch is the one originally sent by Rasmus at
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2018-October/508026.html. (*)
>>
>> and which escaped the radar at
On 10/12/2021 14.08, Olivier Hainque wrote:
> Hello,
>
> The attached patch is the one originally sent by Rasmus at
>
> https://gcc.gnu.org/pipermail/gcc-patches/2018-October/508026.html. (*)
>
> and which escaped the radar at the time.
>
> The change looked good and turned out helpful in the
ok for backport to 11?
From: Richard Sandiford
Sent: 10 December 2021 10:22
To: Joel Hutton
Cc: GCC Patches ; Richard Biener
Subject: Re: pr103523: Check for PLUS/MINUS support
Joel Hutton writes:
> Hi all,
>
> This is to address pr103523.
>
> bootstrapped and
Hello,
The attached patch is the one originally sent by Rasmus at
https://gcc.gnu.org/pipermail/gcc-patches/2018-October/508026.html. (*)
and which escaped the radar at the time.
The change looked good and turned out helpful in the context of
work on the support of shared library for VxWorks.
> Fixes ICE spotted by Honza where we have a better place where
> to check for no_profile_instrument_function attribute.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> PR ipa/103636
>
> gcc/ChangeLog:
>
>
On Thu, Dec 09, 2021 at 05:59:54PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > /tmp/6140018_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/aarch64-sve-builtins.cc:3920:0:
> > ./gt-aarch64-sve-builtins.h: In function 'void
> > gt_pch_p_19registered_function(void*, void*, gt_point
Fixes ICE spotted by Honza where we have a better place where
to check for no_profile_instrument_function attribute.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR ipa/103636
gcc/ChangeLog:
* ipa-inline.c (can_in
Hi!
This incremental patch adds std::time_get %r support (%p was added already
in the previous patch). The _M_am_fm_format method previously in the header
unfortunately had wrong arguments and so was useless, so the largest
complication in this patch is exporting a new symbol in the right symbol
Fixes:
FAIL: compiler driver --help=param option(s): "^ +-.*[^:.]$" absent from output:
"
--param=max-inline-functions-called-once-loop-depth= Maximum loop depth of a call
which is considered for inlining functions called once"
FAIL: compiler driver --help=params option(s): "[^.]$" absent from o
On 09/12/2021 23:05, Harald Anlauf wrote:
Hi Mikael,
Am 08.12.21 um 10:32 schrieb Mikael Morin:
On 07/12/2021 21:46, Harald Anlauf wrote:
Hi Mikael,
Am 07.12.21 um 21:17 schrieb Mikael Morin:
The existing code looks dubious to me (or at least difficult to
understand), and your patch doesn’t
On 09/12/2021 17:36, Andrea Corallo via Gcc-patches wrote:
Richard Earnshaw via Gcc-patches writes:
On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:
-Original Message-
From: Gcc-patches On Behalf Of Tejas Belagod via
Gcc-patches
Sent: Friday, October 8, 2021 1:18 PM
To:
While working on a middle-end patch to more aggressively use highpart
multiplications on targets that support them, I noticed that the RTL
expanded by the x86 backend interacts poorly with register allocation
leading to suboptimal code.
For the testcase,
typedef int __attribute ((mode(TI))) ti_t;
Hi!
On Thu, Dec 09, 2021 at 06:09:12PM -0500, Jason Merrill wrote:
> For the more general comparison of decls like your a != b example above I
> think clang is in the right; in manifestly constant-evaluated context
> (folding_initializer) we should return that they are unequal and prevent a
> late
> On Fri, Dec 10, 2021 at 2:30 AM Roger Sayle
> wrote:
> >
> >
> > This patch fixes PR ipa/103061 which is P1 regression that shows up as
> > an ICE in ipa-modref-tree.c's insert_kill when compiling the CSiBE
> > benchmark. I believe the underlying cause is that the new kill tracking
> > functio
On Fri, Dec 10, 2021 at 2:30 AM Roger Sayle wrote:
>
>
> This patch fixes PR ipa/103061 which is P1 regression that shows up as
> an ICE in ipa-modref-tree.c's insert_kill when compiling the CSiBE
> benchmark. I believe the underlying cause is that the new kill tracking
> functionality wasn't ant
This patch fixes PR ipa/103061 which is P1 regression that shows up as
an ICE in ipa-modref-tree.c's insert_kill when compiling the CSiBE
benchmark. I believe the underlying cause is that the new kill tracking
functionality wasn't anticipating memory accesses that are zero bits
wide!?. The faili
Joel Hutton writes:
> Hi all,
>
> This is to address pr103523.
>
> bootstrapped and regression tested on aarch64.
>
> Check for PLUS_EXPR/MINUS_EXPR support in vectorizable_induction.
> PR103523 is an ICE on valid code:
>
> void d(float *a, float b, int c) {
> float e;
> for (; c; c--, e +
On Fri, 10 Dec 2021 at 01:50, Martin Sebor via Libstdc++
wrote:
>
> On 12/9/21 5:38 PM, Martin Sebor wrote:
> > On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:
> >> These warnings are triggered by perfectly valid code using std::string.
> >> They're particularly bad when --enable-fully-
It happens that options are parsed and various diagnostics happen
in finish_options. That's a proper place as the function is also called
for optimize/target attributes (pragmas). However, it is possible that
target overwrites an option from command line and so the diagnostics
does not happen. Tha
Hi all,
This is to address pr103523.
bootstrapped and regression tested on aarch64.
Check for PLUS_EXPR/MINUS_EXPR support in vectorizable_induction.
PR103523 is an ICE on valid code:
void d(float *a, float b, int c) {
float e;
for (; c; c--, e += b)
a[c] = e;
}
This is due to no
On Fri, 10 Dec 2021 at 00:39, Martin Sebor via Libstdc++
wrote:
>
> On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:
> > These warnings are triggered by perfectly valid code using std::string.
> > They're particularly bad when --enable-fully-dynamic-string is used,
> > because even std::
Richard Earnshaw via Gcc-patches writes:
> On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:
>>
>>> -Original Message-
>>> From: Gcc-patches >> bounces+belagod=gcc.gnu@gcc.gnu.org> On Behalf Of Tejas Belagod via
>>> Gcc-patches
>>> Sent: Friday, October 8, 2021 1:19 PM
>>> To
89 matches
Mail list logo
