In the three-parameter version of satisfy_declaration_constraints, when
't' isn't the most general template, then 't' doesn't correspond with
the augmented template arguments 'args', and so the instantiation
context that we push via push_tinst_level isn't quite correct. This
manifests as
My r10-7705 patch for PR94521 made us set TFF_NO_FUNCTION_ARGUMENTS when
pretty printing the function scope of a local class type in order to
eliminate infinite recursion with a function signature that contains
decltype([]{}). But due to the way dump_function_decl works, this
change regressed our
On 2021/2/25 00:57, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Feb 24, 2021 at 09:06:24AM +0800, Xionghu Luo wrote:
>> vec_insert defines the element argument type to be signed int by ELFv2
>> ABI, When expanding a vector with a variable rtx, convert the rtx type
>> SImode.
>
> But that is
The gcc.misc-tests/outputs.exp tests can take some effort to
digest.
Navigating and debugging causes for failing tests here isn't
helped by the existence of tests with duplicate names.
Let's stop that from happening. This requires that test-run
output is actually reviewed, as Tcl errors don't
The outputs.exp tests check what temporary files are created
and left behind with e.g. -save-temps.
Additional files are created in presence of @file option.
Adding an -I or -L option causes *another* temporary file to
appear. I take it that's deliberate, as there are tests for
that behavior.
(please keep me in CC, I'm not subscribed...)
On Thu Feb 18, 2021 Qing Zhao said:
> Initialize automatic variables with new first class option
> -ftrivial-auto-var-init=[uninitialized|pattern|zero]
Yay! I'm really excited to see this. Thank you for working on
it! I've built GCC with this
On 2/24/21 4:17 PM, Anthony Sharp wrote:
"special"
It wouldn't be my code if it didn't have sp3ling mstakes innit!
Actually to be fair I already changed that spelling mistake a few days
ago in my local code ;)
I was actually thinking about this last night as I was falling asleep
(as you do)
On 2/24/21 5:34 PM, Marek Polacek wrote:
Here we reject
constexpr const int *p = nullptr;
constexpr int *q = const_cast(p);
with "conversion of 'const int*' null pointer to 'int*' is not a
constant expression", which seems bogus. This code has been rejected
since r238909 which added the
On 2/24/21 5:25 PM, Martin Sebor wrote:
In r11-6900 (PR 98646 - static_cast confuses -Wnonnull) we decided
that issuing -Wnonnull for dereferencing the result of dynamic_cast
was helpful despite the false positives it causes when the pointer
is guaranteed not to be null because of a prior test.
Hi Jim:
Could you take a look for this patch,
I am not sure it's the right change or not for big-endian,
On Thu, Feb 25, 2021 at 6:39 AM Marcus Comstedt wrote:
>
> These all intend the least significant subpart of the register.
> Use the same endian-neutral "subreg_lowpart_operator" predicate
On Wed, 24 Feb 2021, Segher Boessenkool wrote:
> The other option, which we need for correctness *anyway*, is to have
> libgcc do the conversion without using any specific libc.
Which ends up being quite complicated (see e.g.
https://www.cl.cam.ac.uk/~jrh13/papers/decimal.pdf for a more
PR analyzer/99193 describes various false positives from
-Wanalyzer-mismatching-deallocation on realloc(3) calls
of the form:
| 31 | void *p = malloc (1024);
| | ^
| | |
| | (1) allocated here (expects deallocation
On 2/24/21 5:13 AM, Jakub Jelinek via Gcc-patches wrote:
On Wed, Feb 24, 2021 at 11:50:10AM +0100, Richard Biener wrote:
In the PR using NOP_EXPR has been discussed as one possibility and has been
rejected because at expansion it will emit a superfluous & 1 operation.
I still think it is a good
Hi!
On Wed, Feb 24, 2021 at 11:12:54PM +, Joseph Myers wrote:
> This change appears to have broken builds for powerpc in a configuration
> that bootstraps a cross toolchain starting with a GCC build with no libc
> available.
>
> Specifically, such a bootstrap build uses
On 2/23/21 6:07 PM, Martin Sebor wrote:
On 2/23/21 2:52 PM, Jason Merrill wrote:
On 2/23/21 11:02 AM, Martin Sebor wrote:
[CC Jason for any further comments/clarification]
On 2/9/21 10:49 AM, Martin Sebor wrote:
On 2/8/21 4:11 PM, Jeff Law wrote:
On 2/8/21 3:44 PM, Martin Sebor wrote:
On
Ping.
On Fri, Feb 12, 2021 at 06:12:12PM -0500, Marek Polacek via Gcc-patches wrote:
> We represent deduction guides with FUNCTION_DECLs, but they are built
> without DECL_CONTEXT, leading to an ICE in type_dependent_expression_p
> on the assert that the type of a function template with no
On 2/16/21 1:52 PM, Jeff Law wrote:
On 2/11/21 10:18 PM, Jason Merrill via Gcc-patches wrote:
The patch for PR92372 made us start warning about a flatten attribute on an
alias. But in the case of C++ 'tor base/complete variants, the user didn't
create the alias, so we shouldn't warn.
I
This change appears to have broken builds for powerpc in a configuration
that bootstraps a cross toolchain starting with a GCC build with no libc
available.
Specifically, such a bootstrap build uses --disable-decimal-float among
other options (in the first GCC build before libc has been
On Mon, Feb 22, 2021 at 09:24:04PM -0600, acsaw...@linux.ibm.com wrote:
> This patch implements a RTL pass that looks for pc-relative loads of the
> address of an external variable using the PCREL_GOT relocation and a
> single load or store that uses that external address.
>
> Produced by a cast
Here we reject
constexpr const int *p = nullptr;
constexpr int *q = const_cast(p);
with "conversion of 'const int*' null pointer to 'int*' is not a
constant expression", which seems bogus. This code has been rejected
since r238909 which added the can_convert check when converting a null
On 24/02/21 17:00 +, Jonathan Wakely via Libstdc++ wrote:
@@ -815,6 +852,39 @@ template
return result;
}
+namespace
+{
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wabi"
+ template
+ inline int
+ sprintf_ld(char* buffer, const char* format_string, T value,
In r11-6900 (PR 98646 - static_cast confuses -Wnonnull) we decided
that issuing -Wnonnull for dereferencing the result of dynamic_cast
was helpful despite the false positives it causes when the pointer
is guaranteed not to be null because of a prior test.
The test case in PR 99251 along with the
On 24/02/21 17:14 -0500, Patrick Palka via Libstdc++ wrote:
The code path in __floating_to_chars_precision for handling long double
by going through printf now also handles __float128, so the condition
that guards this code path needs to be updated accordingly.
Tested on x86_64-pc-linux-gnu
The code path in __floating_to_chars_precision for handling long double
by going through printf now also handles __float128, so the condition
that guards this code path needs to be updated accordingly.
Tested on x86_64-pc-linux-gnu (i.e. it compiles :)), does this look OK
for trunk?
This patch fixes lowering of derived-type mappings which select elements
of arrays of derived types, and similar. These would previously lead
to ICEs.
With this change, OpenACC directives can pass through constructs that
are no longer recognized by the gimplifier, hence alterations are needed
This patch disallows selecting components of array sections in update
directives for OpenACC, as specified in OpenACC 3.0, "2.14.4. Update
Directive":
In Fortran, members of variables of derived type may appear, including
a subarray of a member. Members of subarrays of derived type may
not
From: Tobias Burnus
gcc/fortran/ChangeLog:
* expr.c (gfc_is_simplify_contiguous): Handle REF_INQUIRY, i.e.
%im and %re which are EXPR_VARIABLE.
* openmp.c (resolve_omp_clauses): Diagnose %re/%im explicitly.
gcc/testsuite/ChangeLog:
*
From: Tobias Burnus
gcc/fortran/ChangeLog:
* openmp.c (resolve_omp_clauses): Explicitly diagnose
substrings as not permitted.
gcc/testsuite/ChangeLog:
* gfortran.dg/goacc/substring.f90: New test.
* gfortran.dg/gomp/substring.f90: New test.
(cherry picked from
Elsewhere in the Fortran front-end, the class_pointer attribute is
used for BT_CLASS entities instead of the pointer attribute. This patch
follows suit for OpenACC. I couldn't actually come up with a test case
where this makes a difference (i.e., where "class_pointer" and "pointer"
have different
This patch adds some tests for character types that are components
of derived types used in OpenACC data-movement clauses (some of which
currently fail and are thus XFAILed), and tests (also XFAILed) mixing
arrays and derived types. The XFAILs are addressed by follow-on patches.
Originally a
The stanza in gfc_trans_omp_clauses that handles derived type members
that are themselves derived type pointers or class pointers now adds
an explicit dereference only for the latter. The former is already
dereferenced transparently in gfc_conv_component_ref.
gcc/fortran/
* trans-openmp.c
This series contains several backports from mainline to the og10 branch
concerning character and complex types and mixed derived types and array
accesses in OpenACC directive clauses.
Tested with offloading to AMD GCN. I will apply shortly.
Julian Brown (5):
[og10] openacc: Dereference
These all intend the least significant subpart of the register.
Use the same endian-neutral "subreg_lowpart_operator" predicate that
ARM does instead.
gcc/
* config/riscv/predicates.md (subreg_lowpart_operator): New predicate
* config/riscv/riscv.md (*addsi3_extended2,
gcc/
* testsuite/gcc.target/riscv/shift-shift-5.c (sub): Change
order of struct fields depending on byteorder.
---
gcc/testsuite/gcc.target/riscv/shift-shift-5.c | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/testsuite/gcc.target/riscv/shift-shift-5.c
gcc/
* config/riscv/riscv.c (riscv_swap_instruction): New function
to byteswap an SImode rtx containing an instruction.
(riscv_trampoline_init): Byteswap the generated instructions
when needed.
---
gcc/config/riscv/riscv.c | 19 +++
1 file changed,
libgcc/
* config/riscv/sfp-machine.h (__BYTE_ORDER): Set according
to __BYTE_ORDER__.
---
libgcc/config/riscv/sfp-machine.h | 4
1 file changed, 4 insertions(+)
diff --git a/libgcc/config/riscv/sfp-machine.h
b/libgcc/config/riscv/sfp-machine.h
index db2697157ce..8adbf4b8b2e
gcc/
* common/config/riscv/riscv-common.c
(TARGET_DEFAULT_TARGET_FLAGS): Set default endianness.
* config.gcc (riscv32be-*, riscv64be-*): Set
TARGET_BIG_ENDIAN_DEFAULT to 1.
* config/riscv/elf.h (LINK_SPEC): Change -melf* value
depending on default
gcc/
* config/riscv/elf.h (LINK_SPEC): Pass linker endianness flag.
* config/riscv/freebsd.h (LINK_SPEC): Likewise.
* config/riscv/linux.h (LINK_SPEC): Likewise.
* config/riscv/riscv.h (ASM_SPEC): Pass -mbig-endian and
-mlittle-endian.
New update of the RISC-V big endian support.
Changes since v2:
* Replaced matches of (subreg ... 0) in riscv.md with calls to
a predicate "subreg_lowpart_operator", modeled on how
arm.md and aarch64.md works.
Testsuite result on 64-bit is now
rv64gc/ lp64/
> "special"
It wouldn't be my code if it didn't have sp3ling mstakes innit!
Actually to be fair I already changed that spelling mistake a few days
ago in my local code ;)
I was actually thinking about this last night as I was falling asleep
(as you do) and I realised that the whole of my using
This fixes some issues with macro maps. We were incorrectly calculating
the number of macro expansions in a location span, and I had a
workaround that partially covered that up. Further, while macro
location spans are monotonic, that is not true of ordinary location
spans. Thus we need to
Hi,
This is not a GCC problem, but a fault in the static linker where,
when a source file is used multiple times, with conditional compilation
the source file is only referenced by the linker for the first object.
Then, when dsymutil tries to find the source file for next object based
off that
Hi,
As the PR notes, we were calling the promise CTOR with the original
function parameters, not the copy (as pointed, a previous wording of
the section on this was unambiguous). Fixed thus.
tested on x86_64-darwin, x86_64-linux-gnu,
this is a wrong-code bug,
OK for master / 10.x?
thanks
Iain
Hi,
The FE contains a mechanism for cleaning up return expressions if a
function throws during the execution of cleanups prior to the return.
If the original function has a return value with a non-trivial DTOR
and the body contains a var with a DTOR that might throw, the function
decl is marked
On Wed, Feb 24, 2021 at 08:52:44PM +0100, Marc Glisse wrote:
> On Wed, 24 Feb 2021, Jakub Jelinek via Gcc-patches wrote:
>
> > The following patch adds single_use case which restores these testcases
> > but keeps the testcases the patch meant to improve as is.
>
> Hello,
>
> I wonder if :s
On Wed, 24 Feb 2021, Jakub Jelinek via Gcc-patches wrote:
The following patch adds single_use case which restores these testcases
but keeps the testcases the patch meant to improve as is.
Hello,
I wonder if :s would be sufficient here? I don't have an opinion on which
one is better for this
On Wed, Feb 24, 2021 at 06:17:01PM +, Kwok Cheung Yeung wrote:
> > 1) while linux --enable-futex and accel gomp_sem_t is small (int), rtems
> > and especially posix gomp_sem_t is large; so while it might be a good
> > idea to inline gomp_sem_t on config/{linux,accel} into the union,
Hi,
The wording of [dcl.fct.def.coroutine]/15 states:
The expression co_await promise.final_suspend() shall not be
potentially-throwing. A fair number of testcases are not correctly
marked. Fixed here.
mechanical patch,
tested on x86_64-darwin, x86-64-linux-gnu,
pushed as obvious
thanks
Iain
Hi again.
I've found the reason for the shift-and test fails.
riscv.md does a match on
(subreg:QI (and:SI ...) 0)
Unfortunately, due to the way "subreg" is defined, this needs to be
(subreg:QI (and:SI ...) 3)
on big endian. I can fix the failures by duplicating the rule and
making the
Hi!
The OpenMP standard says:
"A teams region can only be strictly nested within the implicit parallel region
or a target region. If a teams construct is nested within a target construct,
that target construct must contain no statements, declarations or directives
outside of the teams construct."
Hi!
When these functions are called with integer minimum, there is UB on the libgcc
side. Fixed in the obvious way, the code in the end wants ABSU_EXPR behavior.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2021-02-24 Jakub Jelinek
PR
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99123
The patch was successfully bootstrapped and tested on x86-64
commit b6680c2084521d2612c3a08aa01b274078c4f3e3
Author: Vladimir N. Makarov
Date: Wed Feb 24 13:54:10 2021 -0500
[PR99123] inline-asm: Don't use
Hi!
The r10-2806 change regressed following testcases, instead of doing
int -> unsigned long sign-extension once and then add 8, 16, ... 56 to it
for each of the memory access, it adds 8, 16, ... 56 in int mode and then
sign extends each. So that means:
+ movq$0, (%rsp,%rax,8)
+
On 23/02/21 23:13 +0100, Matthias Kretz wrote:
I like the idea.
On Dienstag, 23. Februar 2021 14:25:10 CET Cassio Neri via Libstdc++ wrote:
((__m ^ (__m >> 3)) & 1) | 30
Note that you can drop the `& 1` part. 30 in binary is 0b0. ORing with a
value in [0, 0b01101] will only toggle the
On Wed, Feb 24, 2021 at 01:32:02PM +0100, Richard Biener wrote:
> Small comment about the patch below, which otherwise is OK:
>
> I think that !INTEGRAL_TYPE_P (TREE_TYPE (innerop)) is a sufficient
> condition here.
Unfortunately as shown during the bootstrap, that patch contained a fatal
On 22/02/2021 1:49 pm, Jakub Jelinek wrote:
I see three issues with the union of completion_sem and detach_team done
that way.
1) while linux --enable-futex and accel gomp_sem_t is small (int), rtems
and especially posix gomp_sem_t is large; so while it might be a good
idea to inline
Hi Kito,
Kito Cheng writes:
> I just spend some time on those two testcase, I think this those two
> testcase could just skip in big-endinan.
Well, that sounds like a pretty big cop out. If the software doesn't
behave like we expect it too I feel we should at least have some idea
_why_...
On 23/02/21 16:18 +0100, Andreas Schwab wrote:
libstdc++-v3/
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/ia64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
*
All the bits were there, used with a pre-existing
-mmax-stackframe=SIZE which unfortunately seems to lack
test-cases.
Note that the early-return for -mno-prologue-epilogue (what
some targets call -mnaked) is deliberately not clearing
current_function_static_stack_size, as I consider that
Hi!
On Tue, Feb 23, 2021 at 09:48:28AM +0100, Richard Biener wrote:
> On Tue, Feb 23, 2021 at 4:48 AM acsawdey--- via Gcc-patches
> wrote:
> >
> > From: Aaron Sawdey
> >
> > This patch implements a RTL pass that looks for pc-relative loads of the
> > address of an external variable using the
On 23/02/21 13:24 +, Cassio Neri via Libstdc++ wrote:
This patch reimplements std::chrono::year_month_day::_S_from_days() which
retrieves a date from the number of elapsed days since 1970/01/01. The new
implementation is based on Proposition 6.3 of Neri and Schneider, "Euclidean
Affine
On 24/02/21 17:00 +, Jonathan Wakely via Libstdc++ wrote:
libstdc++: Define std::to_chars overloads for __ieee128 [PR 98389]
This adds overloads of std::to_chars for powerpc64's __ieee128, so that
std::to_chars can be used for long double when -mabi=ieeelongdouble is
in used.
On 24/02/21 12:04 -0500, Patrick Palka via Libstdc++ wrote:
On Wed, 24 Feb 2021, Jonathan Wakely wrote:
On 23/02/21 11:30 -0500, Patrick Palka via Libstdc++ wrote:
> On Mon, 22 Feb 2021, Patrick Palka wrote:
>
> > This makes the hexadecimal section of the long double std::to_chars
> > testcase
On Wed, 24 Feb 2021, Jonathan Wakely wrote:
> On 23/02/21 11:30 -0500, Patrick Palka via Libstdc++ wrote:
> > On Mon, 22 Feb 2021, Patrick Palka wrote:
> >
> > > This makes the hexadecimal section of the long double std::to_chars
> > > testcase more robust by avoiding false-negative FAILs due to
This adds overloads of std::to_chars for powerpc64's __ieee128, so that
std::to_chars can be used for long double when -mabi=ieeelongdouble is
in used.
Eventually we'll want to extend these new overloads to work for
__float128 on all targets that support that type. For now, we're only
doing it
When we read preprocessed source, we deal with a couple of special
location lines at the start of the file. These provide information
about the original filename of the source and the current directory, so
we can process the source in the same manner. When updating that code,
I had a
Hi!
On Wed, Feb 24, 2021 at 09:06:24AM +0800, Xionghu Luo wrote:
> vec_insert defines the element argument type to be signed int by ELFv2
> ABI, When expanding a vector with a variable rtx, convert the rtx type
> SImode.
But that is true for the intrinsics, not for all other callers of
On 23/02/21 11:30 -0500, Patrick Palka via Libstdc++ wrote:
On Mon, 22 Feb 2021, Patrick Palka wrote:
This makes the hexadecimal section of the long double std::to_chars
testcase more robust by avoiding false-negative FAILs due to printf
using a different leading hex digit than us, and by
libstdc++-v3/ChangeLog:
* testsuite/17_intro/names.cc: Undefine 'u' on powerpc*-linux*.
Tested powerpc64le-linux. Committed to trunk.
commit d0453cf5c68b6aa0e8c57a7a99d4285f047387b7
Author: Jonathan Wakely
Date: Wed Feb 24 16:24:34 2021
libstdc++: Fix failing tests due to 'u'
Hi Paul,
On 24.02.21 15:05, Paul Richard Thomas via Fortran wrote:
This problem was caused by the compiler attempting to use 0 as an lvalue
and to assign 0 to it.
I did recall the problem – and indeed: PR95868.
The trans-array.c patch does effectively the same as mine there, some
other use
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 24 February 2021 15:14
> To: gcc Patches
> Subject: Re: arm: Fix CMSE support detection in libgcc (PR target/99157)
>
> On Tue, 23 Feb 2021 at 18:29, Christophe Lyon
> wrote:
> >
> > As
On Tue, 23 Feb 2021 at 18:29, Christophe Lyon
wrote:
>
> As discussed in the PR, the Makefile fragment lacks a double '$' to
> get the return-code from GCC invocation, resulting is CMSE support
> missing from multilibs.
>
> I checked that the simple patch proposed in the PR fixes the problem.
On Wed, 24 Feb 2021, Tamar Christina wrote:
> Hi Richi,
>
> This is an updated patch with your suggestion.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
OK.
Thanks,
Richard.
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> PR tree-optimization/99220
Hi All,
This patch disables the test for PR99149 on Big-endian
where for standard AArch64 the patterns are disabled.
Regtested on aarch64-none-linux-gnu and no issues.
Committed under the obvious rule.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
PR tree-optimization/99149
*
> -Original Message-
> From: Christophe Lyon
> Sent: Wednesday, February 24, 2021 2:17 PM
> To: Richard Biener
> Cc: Tamar Christina ; nd ; gcc
> Patches
> Subject: Re: [PATCH v2] middle-end slp: fix sharing of SLP only patterns.
>
> On Wed, 24 Feb 2021 at 09:38, Richard Biener wrote:
On Wed, 24 Feb 2021 at 09:38, Richard Biener wrote:
>
> On Tue, 23 Feb 2021, Tamar Christina wrote:
>
> > Hi Richi,
> >
> > The attached testcase ICEs due to a couple of issues.
> > In the testcase you have two SLP instances that share the majority of their
> > definition with each other. One
Hi Richi,
This is an updated patch with your suggestion.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR tree-optimization/99220
* tree-vect-slp.c (optimize_load_redistribution_1): Remove
node from cache
This problem was caused by the compiler attempting to use 0 as an lvalue
and to assign 0 to it. Understandably, this upset the gimplifer quite a bit
:-) The fix is to use the ss_info string length for deferred length
character components, where the hidden string length component has been
used. The
On Wed, 24 Feb 2021, Jakub Jelinek wrote:
> On Wed, Feb 24, 2021 at 11:50:10AM +0100, Richard Biener wrote:
> > > In the PR using NOP_EXPR has been discussed as one possibility and has
> > > been
> > > rejected because at expansion it will emit a superfluous & 1 operation.
> > > I still think it
On Wed, Feb 24, 2021 at 11:50:10AM +0100, Richard Biener wrote:
> > In the PR using NOP_EXPR has been discussed as one possibility and has been
> > rejected because at expansion it will emit a superfluous & 1 operation.
> > I still think it is a good idea to use NOP_EXPR and so have changed
> >
On Wed, 24 Feb 2021, Jakub Jelinek wrote:
> Hi!
>
> This optimization was written purely with scalar integers in mind,
> can work fine even with vectors, but we can't use build_int_cst but
> need to use build_one_cst instead.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
On Wed, 24 Feb 2021, Jakub Jelinek wrote:
> Hi!
>
> SRA creates a VCE from integer to bool and that VCE then prevents other
> optimizations or e.g. prevents the uninit pass from avoiding a false
> positive warning.
>
> In the PR using NOP_EXPR has been discussed as one possibility and has been
Hi!
This optimization was written purely with scalar integers in mind,
can work fine even with vectors, but we can't use build_int_cst but
need to use build_one_cst instead.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-02-24 Jakub Jelinek
PR
Hi!
SRA creates a VCE from integer to bool and that VCE then prevents other
optimizations or e.g. prevents the uninit pass from avoiding a false
positive warning.
In the PR using NOP_EXPR has been discussed as one possibility and has been
rejected because at expansion it will emit a superfluous
Revert: "Don't build insn-extract.o with rtl checking".
PR target/98746 is now fixed, compilation is now below 100MB from 8GB.
Approved on irc by Richard Biener.
Matthias
--- a/gcc/genextract.c
+++ b/gcc/genextract.c
@@ -365,8 +365,6 @@ print_header (void)
#define IN_TARGET_CODE 1\n\
This avoids crashes with __builtin_next_arg on non-parameters. For
the specific testcase we arrive with an anonymous SSA_NAME so that
SSA_NAME_VAR becomes NULL and we crash.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-02-24 Richard Biener
PR c/99224
*
On Feb 23, 2021, Jim Wilson wrote:
> If we add default multilibs for you, then to be fair, we need to add
> default multilibs for other people that ask, and before long we are trying
> to build hundreds or maybe even thousands of multilibs by default which is
> unworkable.
*nod*, it's a very
On Tue, Feb 23, 2021 at 8:53 PM Martin Sebor via Gcc-patches
wrote:
>
> Adding attribute access to declarations of functions that take
> VLA arguments relies on the front end adding attribute "arg spec"
> to each VLA parameter. Like the VLA bounds in attribute access,
> the same VLA bounds in
On Tue, 23 Feb 2021, Tamar Christina wrote:
> Hi Richi,
>
> The attached testcase shows a bug where two nodes end up with the same
> pointer.
> During the loop that analyzes all the instances
> in optimize_load_redistribution_1 we do
>
> if (value)
> {
>
On Tue, 23 Feb 2021, Tamar Christina wrote:
> Hi Richi,
>
> The attached testcase ICEs due to a couple of issues.
> In the testcase you have two SLP instances that share the majority of their
> definition with each other. One tree defines a COMPLEX_MUL sequence and the
> other tree a
90 matches
Mail list logo
