On 4/28/21 3:48 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Tested with valgrind
> too (PR 100278 is now fixed). Ok for master?
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568771.html
> v1 -> v2: Use the UNSPEC pattern, which is less efficient
The vsel instruction is a bit-wise select instruction. Using an
IF_THEN_ELSE to express it in RTL is wrong and leads to wrong code
being generated in the combine pass. Per element selection is a
subset of per bit-wise selection,with the patch the pattern is
written using bit operations. But ther
The problem appears to be triggered by two locations in the front-end
where non-POINTER_SIZE pointers aren't handled right now.
1. An assertion in strip_typedefs is triggered because the alignment
of the types don't match. This in turn is caused by creating the new
type with build_pointer_type ins
On Fri, 30 Apr 2021, Senthil Kumar Selvaraj wrote:
>
> Could someone please approve this patch too? The base conversion patch
> (https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568658.html) was
> approved and committed, and fixing peepholes addresses a bunch of code
> size regressions introd
On Thu, 29 Apr 2021, Indu Bhagat wrote:
> Hello,
>
> On 4/29/21 5:10 AM, Richard Biener wrote:
> > On Thu, 29 Apr 2021, Jose E. Marchesi wrote:
> >
> >> This commit introduces support for generating CTF debugging
> >> information and BTF debugging information from GCC.
> >
> > Comments inline.
Could someone please approve this patch too? The base conversion patch
(https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568658.html) was
approved and committed, and fixing peepholes addresses a bunch of code
size regressions introduced by the base patch.
No regressions on all 4 devices, as
We have had an implementation of __builtin__clear_cache since the
beginning, but didn't have the cooresponding __clear_cache library
routine implemented. This directly conflicts the GCC manual in a
handful of places, which indicates that __clear_cache should work and
that __builtin_clear_cache sho
Hi:
For v{,p}expand* When mask is 0, -1, or has all all one bits in its
lower part, it can be optimized to simple mov or mask mov.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,} and
x86_64-linux-gnu{m32\ -march=cascadelake,-m64\ -march=cascadelake},
gcc/ChangeLog:
* config/i38
Hi:
This patch is to fix ice which was introduced by my
r11-5696-g35c4c67e6c534ef3d6ba7a7752ab7e0fbc91755b.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok for trunk and backport to GCC11?
gcc/ChangeLog
PR target/100310
* config/i386/i386-expand.c
(ix86_e
>> This patch implements a new loop optimization according to the proposal
>> in RFC given at
>> https://gcc.gnu.org/pipermail/gcc/2021-January/234682.html.
>> So do not repeat the idea in this mail. Hope your comments on it.
>
> With the caveat that I'm not an optimization expert (but no one else
On Wed, Apr 28, 2021 at 1:30 AM Geng Qi via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> gcc/ChangeLog:
> * config/riscv/riscv.opt (march=,mabi=): Negative itself.
>
Thanks. I committed this.
Do we need to backport to release branches? This looks like an uncommon
problem, or we woul
On Wed, Apr 28, 2021 at 1:11 PM Joseph Myers
wrote:
> Could you please explain the bug at the *user-visible* level? That is,
> the particular options passed to the compiler, how those options behave,
> and how you think they should behave instead.
I added this to the riscv.opt file to create s
On Wed, Apr 28, 2021 at 10:43 PM Levy Hsu wrote:
> From: LevyHsu
>
> Added implementation for builtin overflow detection, new patterns are
> listed below.
>
This looks OK. You are missing a ChangeLog entry. I added one. I had to
fix some whitespace and formatting issues. Open parens should
On Thu, Apr 29, 2021 at 07:23:03PM -0400, Michael Meissner wrote:
> On Thu, Apr 29, 2021 at 05:50:03PM -0500, Segher Boessenkool wrote:
> > On Thu, Apr 29, 2021 at 05:48:53PM -0400, Michael Meissner wrote:
> > > This patch defines the constants needed for libgcc for the PowerPC
> > > specific IEEE
On Thu, Apr 29, 2021 at 05:50:03PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Apr 29, 2021 at 05:48:53PM -0400, Michael Meissner wrote:
> > This patch defines the constants needed for libgcc for the PowerPC
> > specific IEEE 128-bit floating point types (KFmode).
>
> It doesn't do that th
Hi!
On Thu, Apr 29, 2021 at 05:48:53PM -0400, Michael Meissner wrote:
> This patch defines the constants needed for libgcc for the PowerPC
> specific IEEE 128-bit floating point types (KFmode).
It doesn't do that though?
> The 4/28 changes to libgcc need these constants defined.
I wondered what
On 4/29/21 1:02 PM, Indu Bhagat wrote:
+{
+ dw_die_ref c;
+
+ if (!ctf_do_die (die))
+ return;
+
+ FOR_EACH_CHILD (die, c, ctf_do_die (c));
+}
+
/* Perform any cleanups needed after the early debug generation pass
has run. */
@@ -32471,6 +32491,16 @@ dwarf2out_early_finish (const
On Wed, Apr 28, 2021 at 4:04 PM Andrew Waterman wrote:
> > This is a good suggestion, but in the interests of making forward
> progress here, I'd like to accept the patch and then file these as
> bugzillas as ways to further improve the patch.
>
> Agreed, these potential improvements are definite
[PATCH, V2] Define KFmode constants for libgcc.
This patch defines the constants needed for libgcc for the PowerPC
specific IEEE 128-bit floating point types (KFmode). The 4/28 changes to
libgcc need these constants defined.
We only define the KFmode constants if IEEE 128-bit floating point is
s
On Thu, Apr 29, 2021 at 04:48:07PM +, Joseph Myers wrote:
> On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote:
>
> > On Thu, Apr 29, 2021 at 04:31:50PM +, Joseph Myers wrote:
> > > On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote:
> > >
> > > > Fix PR bootstrap/100327
On 29/04/21 11:04 -0400, Patrick Palka via Libstdc++ wrote:
This implements the wording changes of P2367R0 "Remove misuses of
list-initialization from Clause 24", modulo the parts that depend
on P1739R4 which we don't yet implement (due to LWG 3407).
Tested on x86_64-pc-linux-gnu, does this look
On 29/04/21 16:06 -0400, David Edelsohn wrote:
On Fri, Jan 8, 2021 at 1:37 PM Jonathan Wakely wrote:
On 06/01/21 19:41 -0500, David Edelsohn wrote:
>Thanks for clarifying the issue.
>
>As you implicitly point out, GCC knows the type of INT64 and defines
>the macro __INT64_TYPE__ . The revised
On Fri, Jan 8, 2021 at 1:37 PM Jonathan Wakely wrote:
>
> On 06/01/21 19:41 -0500, David Edelsohn wrote:
> >Thanks for clarifying the issue.
> >
> >As you implicitly point out, GCC knows the type of INT64 and defines
> >the macro __INT64_TYPE__ . The revised code can use that directly,
> >such as
In ix86_int_compare, opportunistically swap operands of GTU and LEU comparisons
to emit carry flag comparison, with the expectation that the comparison will
combine to *add3_carry_0 or *sub3_carry_0 insn pattern.
Do not use ix86_expand_carry_flag_compare because this function prefers
carry flag co
Hello,
On 4/29/21 5:10 AM, Richard Biener wrote:
On Thu, 29 Apr 2021, Jose E. Marchesi wrote:
This commit introduces support for generating CTF debugging
information and BTF debugging information from GCC.
Comments inline.
Thanks for your reviews.
My responses and questions inline at resp
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-11.1.0.sv.po', has ju
I've now committed this patch as preparation for further digit separator
fixes and enabling digit separators for C2x, but would still welcome any
C++ maintainer comments.
--
Joseph S. Myers
jos...@codesourcery.com
-fdata-sections places data symbols into their own, unique, named sections.
-fsection-anchors create an anchor to access neighboring symbols
within a section.
When both are enabled, a separate section anchor is created for each
symbol, which provides no benefit.
This patch
In discussion of PR98463, Jakub noted that cxx_fold_indirect_ref_1 was
bailing out early for empty bases even when we do have fields for them (in
C++17 mode or later). This corrects that.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* constexpr.c (cxx_fold_indirect_r
51344 was a problem with calling save_template_attributes twice for the same
friend function: once from do_friend and once from grokmethod. The 2012
patch for the bug avoided creating an infinite loop when this happens, but
it's better to avoid the duplication in the first place. This also restor
While working on the GCC 11 patch, it occurred to me that we could move
the errors about invalid members from finish_struct_anon_r to here, so we
properly get a diagnostic in g++.law/union4.C.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/97974
* class.c
My GCC 11 patch for PR93314 turned off cp_unevaluated_operand while
processing an id-expression that names a non-static data member, but the
broader issue is that in general, a constant-expression is evaluated even in
an unevaluated operand.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/C
Once a CONSTRUCTOR has been digested and used as an initializer, it no
longer represents a compound literal by itself, so we can clear the flag,
letting us use it consistently to distinguish between digested and
undigested initializer-lists.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/C
On Thu, Apr 29, 2021 at 8:52 AM Jeff Law wrote:
>
> This change:
>
> 985b3a6837dee7001e6b618f073ed74f0edf5787 is the first bad commit
> commit 985b3a6837dee7001e6b618f073ed74f0edf5787
> Author: H.J. Lu
> Date: Mon Jun 10 09:57:15 2019 -0700
>
> Generate offset adjusted operation for op_by_
We correctly accept this testcase since r11-1571.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
PR c++/94102
* g++.dg/cpp1z/class-deduction87.C: New test.
---
gcc/testsuite/g++.dg/cpp1z/class-deduction87.C | 15 +++
1 file changed, 15 insert
On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote:
> On Thu, Apr 29, 2021 at 04:31:50PM +, Joseph Myers wrote:
> > On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote:
> >
> > > Fix PR bootstrap/100327 (_divkf3.c) on PowerPC.
> > >
> > > This patch fixes the PowerPC _divkf3
On Thu, Apr 29, 2021 at 04:31:50PM +, Joseph Myers wrote:
> On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote:
>
> > Fix PR bootstrap/100327 (_divkf3.c) on PowerPC.
> >
> > This patch fixes the PowerPC _divkf3.c module to use the appropriate
> > FLT128 constants if long double is no
On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote:
> Fix PR bootstrap/100327 (_divkf3.c) on PowerPC.
>
> This patch fixes the PowerPC _divkf3.c module to use the appropriate
> FLT128 constants if long double is not IEEE 128-bit.
>
> I have tested this patch by doing a bootstrap on a li
Hi!
I've re-based and re-tested this patch on current trunk.
Otherwise the patch is unchanged, from the previous v2 version.
This patch is fixing two issues with functions where we
do not have proper debug info:
1. Functions without line-numbers at all, are excluded from
the CU's address range
Fix PR bootstrap/100327 (_divkf3.c) on PowerPC.
This patch fixes the PowerPC _divkf3.c module to use the appropriate
FLT128 constants if long double is not IEEE 128-bit.
I have tested this patch by doing a bootstrap on a little endian power9
system running Linux. Can I check this into the trunk?
This change:
985b3a6837dee7001e6b618f073ed74f0edf5787 is the first bad commit
commit 985b3a6837dee7001e6b618f073ed74f0edf5787
Author: H.J. Lu
Date: Mon Jun 10 09:57:15 2019 -0700
Generate offset adjusted operation for op_by_pieces operations
Add an overlap_op_by_pieces_p target hook
On 4/29/21 6:22 AM, Richard Biener via Gcc-patches wrote:
On Wed, Apr 21, 2021 at 11:12 AM Martin Liška wrote:
Now living in the 21st century, we don't longer need using the following tuple:
cl_decoded_option **decoded_options,
unsigned int *decoded_options_count)
but we can rather use a sta
The recent improvements to complex divide added this nugget to
c-cppbuiltins:
#ifdef HAVE_adddf3
builtin_define_with_int_value ("__LIBGCC_HAVE_HWDBL__",
HAVE_adddf3);
#endif
This is breaking the nios2 port:
In file included from ./tm.h:33,
This implements the wording changes of P2367R0 "Remove misuses of
list-initialization from Clause 24", modulo the parts that depend
on P1739R4 which we don't yet implement (due to LWG 3407).
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bit
On Thu, Apr 29, 2021 at 9:25 AM Richard Biener wrote:
> > > It eventually runs into the gcc_unreachable () at the very end of
> > > ix86_expand_builtin since IX86_BUILTIN_MASKLOADD and friends are
> > > no longer in the range of IX86_BUILTIN__BDESC_SPECIAL_ARGS_FIRST
> > > to IX86_BUILTIN__BDESC_
On Thu, 2021-01-21 at 06:27 +, Feng Xue OS via Gcc-patches wrote:
> This patch implements a new loop optimization according to the proposal
> in RFC given at
> https://gcc.gnu.org/pipermail/gcc/2021-January/234682.html.
> So do not repeat the idea in this mail. Hope your comments on it.
With
On 4/28/21 3:03 PM, Patrick Palka wrote:
Here, at template definition time, ordinary name lookup for 'foo(t)'
finds the deleted function, and so we form a CALL_EXPR thereof. Later
at instantiation time, when initially substituting into this CALL_EXPR
with T=N::A, we end up calling mark_used on t
CCCmode is allowed only with GEU and LTU comparison codes. Also allow
CCGZmode for these two codes. There is no need to check for trivial FP
comparison operator, ix86_fp_compare_code_to_integer will return
UNKNOWN code for unsupported operators.
2021-04-29 Uroš Bizjak
gcc/
* config/i386/
Also pass -mno-avx to sw-1.c for ia32 since copying data with YMM or ZMM
registers disables shrink-wrapping when the second argument is passed on
stack.
* gcc.target/i386/sw-1.c: Also pass -mno-avx for ia32.
---
gcc/testsuite/gcc.target/i386/sw-1.c | 1 +
1 file changed, 1 insertion(+)
d
* gcc.target/i386/pieces-memcpy-10.c: New test.
* gcc.target/i386/pieces-memcpy-11.c: Likewise.
* gcc.target/i386/pieces-memcpy-12.c: Likewise.
* gcc.target/i386/pieces-memcpy-13.c: Likewise.
* gcc.target/i386/pieces-memcpy-14.c: Likewise.
* gcc.targe
Also pass -mno-avx to pr72839.c to avoid copying data with YMM or ZMM
registers.
* gcc.target/i386/cold-attribute-1.c: Also pass -mno-avx.
---
gcc/testsuite/gcc.target/i386/cold-attribute-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386
Expect no stack realignment since we no longer realign stack when
copying data.
* gcc.target/i386/incoming-11.c: Expect no stack realignment.
---
gcc/testsuite/gcc.target/i386/incoming-11.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/i
Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
target instructions to duplicate QImode value to TImode/OImode/XImode
value for memmset.
gcc/
PR middle-end/90773
* builtins.c (builtin_memset_read_str): Call
targetm.read_memset_value.
(builtin_me
Also pass -mno-avx to pr72839.c to avoid copying data with YMM or ZMM
registers.
* gcc.target/i386/pr72839.c: Also pass -mno-avx.
---
gcc/testsuite/gcc.target/i386/pr72839.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr72839.c
b/gcc/
It is only defined for i386 and everyone uses the default:
#define MAX_BITSIZE_MODE_ANY_INT (64*BITS_PER_UNIT)
Whatever problems we had before, they have been fixed now.
* config/i386/i386-modes.def (MAX_BITSIZE_MODE_ANY_INT): Removed.
---
gcc/config/i386/i386-modes.def | 15 +++---
We can use TImode/OImode/XImode integers for piecewise move and store.
When vector register is used for piecewise move and store, we don't
increase stack_alignment_needed since vector register spill isn't
required for piecewise move and store. Since stack_realign_needed is
set to true by checking
alignment_for_piecewise_move is called only with MOVE_MAX_PIECES or
STORE_MAX_PIECES, which are the number of bytes at a time that we
can move or store efficiently. We should call mode_for_size without
limit to MAX_FIXED_MODE_SIZE, which is an integer expression for the
size in bits of the largest
Pass UNITS_PER_WORD * BITS_PER_UNIT to force_reg, when copying data from
one memory location to another with vector registers, to avoid stack
realignment.
* config/i386/i386-expand.c (ix86_expand_vector_move): Pass
UNITS_PER_WORD * BITS_PER_UNIT to force_reg when copying data
PR middle-end/90773
* gcc.target/i386/pr90773-20.c: New test.
* gcc.target/i386/pr90773-21.c: Likewise.
* gcc.target/i386/pr90773-22.c: Likewise.
* gcc.target/i386/pr90773-23.c: Likewise.
---
gcc/testsuite/gcc.target/i386/pr90773-20.c | 13 +
gcc
The maximum size of the current op_by_pieces operations are limited by
MAX_FIXED_MODE_SIZE which is an integer expression for the size in bits
of the largest integer machine mode that should actually be used. But
a target can use TImode/OImode/XImode, which can be larger than
MAX_FIXED_MODE_SIZE,
gen_reg_rtx tracks stack alignment needed for pseudo registers so that
associated hard registers can be properly spilled onto stack. But there
are cases where associated hard registers will never be spilled onto
stack. gen_reg_rtx is changed to take an argument for register alignment
so that stac
On 4/27/2021 7:01 PM, Tom Tromey wrote:
Both plugins in libcc1 share a fair amount of boilerplate. They both
share error-emission code, context management code, and tree GC code.
This patch unifies these two bodies of code, avoiding needless
duplication.
libcc1/ChangeLog
2021-04-27 Tom Trome
On 4/27/2021 7:01 PM, Tom Tromey wrote:
Both libcc1 plugins have nearly identical copies of code to find the
underlying compiler. This seemed wasteful to me, so this patch
unifies the copies.
Two minor API changes were needed.
First, the old code used a back-link from the compiler object to
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes libcc1 to use unique_ptr in a few more places, removing
some manual memory management.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1.cc (struct libcp1) : Use
unique_ptr.
(~libcp1): Remove.
(libcp1_compil
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes libcc1 to use the 'deleter' template in a few more
places. The template and basic specializations are moved to a new
header, then some unmarshall functions are changed to use this code.
This change avoids the need to repeat cleanup code in t
On 4/22/21 1:46 PM, Tom de Vries wrote:
> On 12/17/20 5:46 PM, Tom de Vries wrote:
>> On 10/15/20 5:05 PM, Tom de Vries wrote:
>>> On 10/2/20 3:21 PM, Tom de Vries wrote:
Hi,
Consider the test-case libgomp.c/pr81778.c added in this commit, with
this core loop (note: CANARY_SIZE
On Thu, Apr 29, 2021 at 1:20 PM Eric Botcazou wrote:
>
> Hi,
>
> if you attempt a profiled bootstrap on the MinGW platforms with -jN, N > 1,
> it miserably fails because of profile mismatches all over the place, the
> reason being that gcov has no support for parallelism on these platforms.
>
> Th
On Wed, Apr 21, 2021 at 11:19 AM Martin Liška wrote:
>
> The check is redundant.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK.
> Thanks,
> Martin
>
> gcc/cp/ChangeLog:
>
> PR c++/99616
> * decl.c (grokdeclarator): Remove
On Wed, Apr 21, 2021 at 11:12 AM Martin Liška wrote:
>
> Now living in the 21st century, we don't longer need using the following
> tuple:
> cl_decoded_option **decoded_options,
> unsigned int *decoded_options_count)
> but we can rather use a standard (our) vector.
>
> Patch can bootstrap on x86
On Wed, Apr 21, 2021 at 10:13 AM Martin Liska wrote:
>
OK.
> lto-plugin/ChangeLog:
>
> * lto-plugin.c (LTO_SEGMENT_NAME): Remove.
> (LTO_SYMTAB_PREFIX): Likewise.
> (LTO_SYMTAB_PREFIX_LEN): Likewise.
> (LTO_SYMTAB_EXT_PREFIX): Likewise.
> (LTO_SYMTAB_EXT_P
Tested on SPARC/Solaris and SPARC64/Linux, applied on the mainline.
2021-04-29 Eric Botcazou
* config/sparc/sparc.c (gen_load_pcrel_sym): Delete.
(load_got_register): Do the PIC dance here.
(sparc_legitimize_tls_address): Simplify.
(sparc_emit_probe_stack_range
On Wed, 28 Apr 2021, Jason Merrill wrote:
> On 4/28/21 2:24 PM, Patrick Palka wrote:
> > This makes tsubst_arg_types substitute into a function's parameter types
> > in left-to-right order instead of right-to-left order, in accordance with
> > DR 1227.
> >
> > Bootstrapped and regtested on x86_64
Hello again,
sorry to reopen this issue, but one part was skipped. It was just now found
out, because it doesn't cause build issues, but only runtime issues (GCC fails
to build binaries):
/usr/local/bin/ld: /usr/local/lib/gcc10/libgcc_s.so: undefined reference to
`.__udivmodti4'
/usr/local/bin/
On Mon, Apr 19, 2021 at 7:32 PM Jose E. Marchesi via Gcc-patches
wrote:
>
> This patch introduces a dwarf_debuginfo_p predicate that abstracts and
> replaces complex checks on write_symbols.
I've heard you're considering more changes in this area but the patch would
be OK as-is with me as well.
On Mon, Apr 19, 2021 at 7:31 PM Jose E. Marchesi via Gcc-patches
wrote:
>
> This patch introduces a dwarf2int.h header, to be used by code that
> needs access to the internal DIE structures and their attributes.
>
> The following functions which were previously defined as static in
> dwarf2out.c a
On Mon, Apr 19, 2021 at 7:30 PM Jose E. Marchesi via Gcc-patches
wrote:
>
> [Changes from V6:
> - Rebased to today's master.
> - A GC related regression introduced in V5 has been fixed. This
> regression also uncovered a related bug that has been also fixed in
> this version. Basically ctfc_t
On Tue, Apr 27, 2021 at 3:14 AM H.J. Lu wrote:
>
> Add an overlap_op_by_pieces_p target hook for op_by_pieces operations
> between two areas of memory to generate one offset adjusted operation
> in the smallest integer mode for the remaining bytes on the last piece
> operation of a memory region t
At some point DR_MISALIGNMENT was supposed to be -1 when the
access was not element aligned. That's obviously not true at this
point so this adjusts both store and load vectorizing to no longer
assume this which in turn allows simplifying the code.
Bootstrapped and tested on x86_64-unknown-linux-
On Wed, Apr 28, 2021 at 9:07 PM Richard Sandiford via Gcc-patches
wrote:
>
> This patch fixes an oversight in the handling of debug instructions
> in rtl-ssa. At the moment (and whether this is a good idea or not
> remains to be seen), we maintain a linear RPO sequence of definitions
> and non-de
On Wed, Apr 28, 2021 at 1:52 PM Andreas Krebbel wrote:
>
> On 4/28/21 10:12 AM, Richard Biener wrote:
> > On Wed, Apr 28, 2021 at 8:54 AM Andreas Krebbel via Gcc-patches
> > wrote:
> >>
> >> The problem appears to be triggered by two locations in the front-end
> >> where non-POINTER_SIZE pointers
Jakub Jelinek writes:
> Hi!
>
> The test FAILs on i?86-linux (due to -Wpsabi warnings). But, on closer
> inspection it seems there is another problem, the dg-options in the testcase
> means that the test is compiled with -O0 -O, -O1 -O, -O2 -O, -O3 -O, -Os -O
> etc. options, so effectively is tes
When there is the possibility that overflow may happen on the loop index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
while (++k != n)
a[k] = b[k] + 1;
}
For this code, if "l > n", overflow may happen. if "l < n" at begining,
it c
Hi!
The test FAILs on i?86-linux (due to -Wpsabi warnings). But, on closer
inspection it seems there is another problem, the dg-options in the testcase
means that the test is compiled with -O0 -O, -O1 -O, -O2 -O, -O3 -O, -Os -O
etc. options, so effectively is tested multiple times with the same o
Hi,
if you attempt a profiled bootstrap on the MinGW platforms with -jN, N > 1,
it miserably fails because of profile mismatches all over the place, the
reason being that gcov has no support for parallelism on these platforms.
The attached patch adds it and, therefore, makes it possible to do a p
Hi!
The standard says that "The event-handle will be considered as if it
was specified on a firstprivate clause." which means that it can't
be explicitly specified in some other data-sharing clause.
The checking is implemented correctly for C, but for C++ when detach_seen
is true (i.e. the constru
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators. The file is available at:
https://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-11.1.0.fr.po', has jus
Jakub Jelinek writes:
> Hi!
>
> In PR94121 I've changed aarch64_add_offset_1 to use absu_hwi instead of
> abs_hwi because offset can be HOST_WIDE_INT_MIN. As can be seen with
> the testcase below, aarch64_add_offset_1_temporaries suffers from the same
> problem and should be in sync with aarch64_
Hi!
In PR94121 I've changed aarch64_add_offset_1 to use absu_hwi instead of
abs_hwi because offset can be HOST_WIDE_INT_MIN. As can be seen with
the testcase below, aarch64_add_offset_1_temporaries suffers from the same
problem and should be in sync with aarch64_add_offset_1, i.e. for
HOST_WIDE_I
GNAT does not accept a declaration of the form:
type Rec (D : access Rec) is null record;
To solve this, we factor out Check_Anonymous_Access_Components and
reuse it from Process_Discriminants and adjust Freeze_Record_Type
accordingly.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada
This gets rid of overflow checks done using a 128-bit integer type on
64-bit platforms and that can be done in a narrower type, by reusing
the machinery already implemented to narrow the type of operations.
This runs afoul of the processing for Max_Size_In_Storage_Elements
in Expand_N_Attribute_Re
The -gnato2 mode of overflow checking, aka Minimized overflow checking,
cannot work for 128-bit integer types because it is implemented using
64-bit integer types.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch4.adb (Expand_Compare_Minimize_Eliminate_Overflow): Remov
The expansion performed in Expand_N_If_Statement only at -O1 and above
can create inconsistencies in the tree that can cause trouble when
compiling different files with different optimization levels. This
is visible in particular in GNAT LLVM when generating C code on ACATS
test cc50a01.
Fixed by
This changes the rounding mode used for the static evaluation of the
Machine attribute of floating-point types to the mode used for the
static evaluation of real expressions, for the sake of consistency.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_attr.adb (Eval_Attr
ADA_EXCLUDE_SRCS and ADA_INCLUDE_SRCS contain old references to non
existing files.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* Makefile.rtl (ADA_EXCLUDE_SRCS): Remove unused files.
(ADA_INCLUDE_SRCS): Remove libgnat/system.adsdiff --git a/gcc/ada/Makefile.rtl b/
This patch fixes a bug that caused the compiler to crash on T'Reduce, if
T is something like Integer.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_attr.adb (Analyze_Attribute): Change "$" to "&".
Otherwise, Errout will trip over an uninitialized (invalid)
Add the possibility for a tool to enable colored output using SGR when
outputting to a terminal. This is currently used only in GNATprove, but
could be enabled for compiler messages in the future. Use the same colors
(including bold) as gcc/g++ as much as possible.
Tested on x86_64-pc-linux-gnu, c
The Extra digit is not correctly set when the precision limit is reached
by means of trailing zeros.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/s-valuer.adb (Scan_Decimal_Digits): Set Extra to zero
when the precision limit is reached by means of trailing
The compiler was failing to generate a required constraint check in the
case of a type conversion between access-to-discriminated types. This
patch fixes this bug.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* checks.adb (Apply_Type_Conversion_Checks): Move out constraint
In GNATprove mode, inlining is used to make it easier to perform proof
without forcing the user to annotate all local subprograms with
contracts. But the compiled code will not be similarly inlined, thus
the analysis should not assume that the compiler will have access to the
same extended precisi
The Duration type of package Standard can be either a 32-bit or a 64-bit
fixed-point type depending on a flag in the system.ads file, but it needs
to be 32-bit when a target configuration file sets a 32-bit size for all
the predefined integer types.
Tested on x86_64-pc-linux-gnu, committed on trun
1 - 100 of 116 matches
Mail list logo
