Hello Andrew,
Can you please let me know your feedback on the patch?
Thanks,
Sundeep K.
-Original Message-
From: sundeep.kokko...@gmail.com
Sent: Wednesday, January 19, 2022 10:40 AM
To: 'Andrew Pinski'
Cc: 'GCC Patches'
Subject: RE: [PATCH] Fix for GCC '-MF' option cannot deal with
On 2/3/22 17:33, Martin Sebor wrote:
On 2/3/22 17:18, David Edelsohn wrote:
On Thu, Feb 3, 2022 at 6:09 PM Martin Sebor wrote:
On 2/3/22 15:56, David Edelsohn wrote:
This series of patches has exploded memory usage and I can no longer
bootstrap GCC on AIX.
As with the Ranger problem exposed
On Thu, 3 Feb 2022, David Seifert via Gcc-patches wrote:
> On Thu, 2022-02-03 at 12:50 +0100, Jakub Jelinek wrote:
> > On Thu, Feb 03, 2022 at 12:30:11PM +0100, David Seifert wrote:
> > > * `-Werror` can cause issues when a more recent version of GCC
> > > compiles
> > > ? an older version:
> > >
Hi!
Please Cc: me on combine patches, I cannot keep up with gcc-patches@,
and even if I could I would miss things.
On Thu, Feb 03, 2022 at 11:05:48AM -, Roger Sayle wrote:
> This patch addresses PR rtl-optimization/101885 which is a P2 wrong code
> regression. In combine, if the resulting fu
Hi!
On Thu, Feb 03, 2022 at 08:44:48AM -0600, Bill Schmidt wrote:
> Although the previous patch was correct, the logic around what to do when
> the number of arguments is wrong was still hard to understand. It should
> be better now. I'm now explicitly counting the number of expected arguments
>
On 2/3/22 17:18, David Edelsohn wrote:
On Thu, Feb 3, 2022 at 6:09 PM Martin Sebor wrote:
On 2/3/22 15:56, David Edelsohn wrote:
This series of patches has exploded memory usage and I can no longer
bootstrap GCC on AIX.
As with the Ranger problem exposed by Aldy's patch last September,
somet
On Thu, Feb 3, 2022 at 6:09 PM Martin Sebor wrote:
>
> On 2/3/22 15:56, David Edelsohn wrote:
> > This series of patches has exploded memory usage and I can no longer
> > bootstrap GCC on AIX.
> >
> > As with the Ranger problem exposed by Aldy's patch last September,
> > something is not freeing m
On 2/3/22 15:56, David Edelsohn wrote:
This series of patches has exploded memory usage and I can no longer
bootstrap GCC on AIX.
As with the Ranger problem exposed by Aldy's patch last September,
something is not freeing memory.
Even on systems where GCC still bootstrap, this excessive memory
This series of patches has exploded memory usage and I can no longer
bootstrap GCC on AIX.
As with the Ranger problem exposed by Aldy's patch last September,
something is not freeing memory.
Even on systems where GCC still bootstrap, this excessive memory usage
severely damages GCC compile perfor
This patch fixes various issues with how -fanalyzer handles "realloc"
seen when debugging PR analyzer/104369.
Previously it wasn't correctly copying over the contents of the old
buffer for the success-with-move case, leading to false
-Wanalyzer-use-of-uninitialized-value diagnostics.
I also notic
It turned out that the analyzer wasn't treating calloc regions
as zero-filled, due to binding_cluster::fill_region getting an
unknown value for the byte_size_size_sval, and thus
get_or_create_repeated_svalue returning an unknown_svalue, which
was then used to fill the region.
Fixed thusly.
Succes
On Thu, Feb 03, 2022 at 04:29:39PM -0500, Marek Polacek wrote:
> On Thu, Feb 03, 2022 at 10:13:36PM +0100, Martin Liška wrote:
> > On 2/3/22 19:44, Andreas Schwab wrote:
> > > On Feb 03 2022, Martin Liška wrote:
> > >
> > > > +cd $LIB
> > > > +echo "$all_dirs" | xargs mkdir -p
> > > > +cd ..
> > >
On 2/3/22 16:06, Patrick Palka wrote:
On Thu, 3 Feb 2022, Jason Merrill wrote:
On 2/3/22 14:58, Patrick Palka wrote:
When synthesizing a defaulted comparison op from
maybe_instantiate_noexcept, we seem to be forgetting to instantiate the
noexcept-spec afterwards.
Hmm, there shouldn't be any
%ecx can't be used for both DRAP register and eh_return. Adjust find_drap_reg
to choose %edi for functions that uses __builtin_eh_return to avoid the assert
in ix86_expand_epilogue that enforces this rule.
2022-02-03 Uroš Bizjak
gcc/ChangeLog:
PR target/104362
* config/i386/i386.cc (
On 2/3/22 16:18, Jakub Jelinek wrote:
On Thu, Feb 03, 2022 at 04:04:57PM -0500, Jason Merrill wrote:
I think it would be clearer to leave the !DECL_P case alone and add
/* In C++ it is unspecified, and so non-constant, whether two
equivalent strings have the same address. */
else if (fold
On Thu, Feb 03, 2022 at 10:13:36PM +0100, Martin Liška wrote:
> On 2/3/22 19:44, Andreas Schwab wrote:
> > On Feb 03 2022, Martin Liška wrote:
> >
> > > +cd $LIB
> > > +echo "$all_dirs" | xargs mkdir -p
> > > +cd ..
> > > +
> >
> > $LIB always contains slashes.
> >
>
> And what is the problem?
On 2/3/22 15:55, Patrick Palka wrote:
On Thu, Feb 3, 2022 at 3:20 PM Jason Merrill wrote:
On 2/3/22 12:04, Patrick Palka wrote:
On Wed, 2 Feb 2022, Jason Merrill wrote:
On 2/2/22 12:09, Patrick Palka wrote:
The satisfaction cache needs to look through ARGUMENT_PACK_SELECT
template argument
On Thu, Feb 03, 2022 at 04:04:57PM -0500, Jason Merrill wrote:
> > > I think it would be clearer to leave the !DECL_P case alone and add
> > >
> > > /* In C++ it is unspecified, and so non-constant, whether two
> > > equivalent strings have the same address. */
> > > else if (folding_cxx_cons
On 2/3/22 19:44, Andreas Schwab wrote:
On Feb 03 2022, Martin Liška wrote:
+cd $LIB
+echo "$all_dirs" | xargs mkdir -p
+cd ..
+
$LIB always contains slashes.
And what is the problem? You're too brief..
Martin
On Thu, 3 Feb 2022, Jason Merrill wrote:
> On 2/3/22 14:58, Patrick Palka wrote:
> > When synthesizing a defaulted comparison op from
> > maybe_instantiate_noexcept, we seem to be forgetting to instantiate the
> > noexcept-spec afterwards.
>
> Hmm, there shouldn't be any need to instantiate the n
On 2/3/22 15:33, Jakub Jelinek wrote:
On Thu, Feb 03, 2022 at 03:07:03PM -0500, Jason Merrill wrote:
--- gcc/fold-const.h.jj 2022-02-01 20:10:51.235856007 +0100
+++ gcc/fold-const.h2022-02-03 15:02:02.700228631 +0100
-/* Non-zero if we are folding constants inside an initializer; zero
- ot
This patch addresses the "increased register pressure" regression on
nvptx-none caused by my change to transition the backend to a
STORE_FLAG_VALUE = 1 target. This improved code generation for the
more common case of producing 0/1 Boolean values, but unfortunately
made things marginally worse wh
On Thu, Feb 3, 2022 at 3:20 PM Jason Merrill wrote:
>
> On 2/3/22 12:04, Patrick Palka wrote:
> > On Wed, 2 Feb 2022, Jason Merrill wrote:
> >
> >> On 2/2/22 12:09, Patrick Palka wrote:
> >>> The satisfaction cache needs to look through ARGUMENT_PACK_SELECT
> >>> template arguments before calling
On Thu, Feb 03, 2022 at 03:07:03PM -0500, Jason Merrill wrote:
> > --- gcc/fold-const.h.jj 2022-02-01 20:10:51.235856007 +0100
> > +++ gcc/fold-const.h2022-02-03 15:02:02.700228631 +0100
> > -/* Non-zero if we are folding constants inside an initializer; zero
> > - otherwise. */
> >
On 2/3/22 14:58, Patrick Palka wrote:
When synthesizing a defaulted comparison op from
maybe_instantiate_noexcept, we seem to be forgetting to instantiate the
noexcept-spec afterwards.
Hmm, there shouldn't be any need to instantiate the noexcept-spec
afterwards, it should have been set by ~com
On 2/3/22 12:04, Patrick Palka wrote:
On Wed, 2 Feb 2022, Jason Merrill wrote:
On 2/2/22 12:09, Patrick Palka wrote:
The satisfaction cache needs to look through ARGUMENT_PACK_SELECT
template arguments before calling iterative_hash_template_arg and
template_args_equal, which would otherwise cr
On 2/3/22 11:49, Patrick Palka wrote:
Here a stale value of TYPE_DEPENDENT_P/_P_VALID for f's function
type after replacing its DEFERRED_NOEXCEPT with its parsed (dependent)
noexcept-spec leads us to try to instantiate g's noexcept-spec (which
incorrectly appears non-dependent) ahead of time, cau
On 2/3/22 10:52, Jakub Jelinek wrote:
On Tue, Jan 18, 2022 at 05:40:48PM +0100, Jakub Jelinek via Gcc-patches wrote:
About the rest of the patch, I thought I had seen richi comment on IRC (but
can't find the comment now) that these cases where we could give a constant
answer but decide not to be
When synthesizing a defaulted comparison op from
maybe_instantiate_noexcept, we seem to be forgetting to instantiate the
noexcept-spec afterwards.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk and perhaps 11?
PR c++/96242
gcc/cp/ChangeLog:
* pt.c
On Thu, Feb 03, 2022 at 10:19:37AM -0700, Jeff Law wrote:
> > > Is getconf and expr length sufficiently portable?
> > > Can't you use
> > > echo "$all_dirs" | xargs mkdir -p
> > > instead?
> >
> > Oh, even better!
> Definitely. I suspect getconf wouldn't have worked across all the hosts we
> supp
On Feb 03 2022, Martin Liška wrote:
> +cd $LIB
> +echo "$all_dirs" | xargs mkdir -p
> +cd ..
> +
$LIB always contains slashes.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On 2/3/22 09:45, Martin Liška wrote:
On 2/3/22 17:43, Martin Sebor wrote:
On 2/3/22 01:59, Martin Liška wrote:
On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote:
Hi Martin,
Either this:
error ("% is unknown", orig_p);
or this would be better:
error ("attribute % is unknown", orig_
Hi Harald,
Indeed, this is obvious, as you say. OK for the affected branches.
Regards
Paul
On Tue, 1 Feb 2022 at 22:38, Harald Anlauf via Fortran
wrote:
> Dear Fortranners,
>
> a check in gfc_calculate_transfer_sizes had a bug in the logic:
> it did not trigger for MOLD having a storage size
Hi Harald and Mikael,
This looks fine to me. OK for all the listed branches.
Thanks for the patch
Paul
On Wed, 2 Feb 2022 at 20:20, Harald Anlauf via Fortran
wrote:
> Hi Mikael,
>
> Am 29.01.22 um 15:24 schrieb Mikael Morin:
> > Hello,
> >
> > the attached patch is a fix for PR104228.
> > Ev
On 2/3/2022 9:21 AM, Martin Liška wrote:
On 2/3/22 17:12, Jakub Jelinek wrote:
On Thu, Feb 03, 2022 at 04:40:25PM +0100, Martin Liška wrote:
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -258,12 +258,23 @@ then echo "All directories (including links to
directories):"
ec
On Wed, 2 Feb 2022, Jason Merrill wrote:
> On 2/2/22 13:21, Patrick Palka wrote:
> > On Wed, 2 Feb 2022, Patrick Palka wrote:
> >
> > > Here we're crashing during satisfaction of the lambda's placeholder type
> > > constraints because the constraints depend on the template arguments
> > > from
This patch has been an excessively long time in coming. Please accept my
apologies for that.
All but two of the PR37336 dependencies are fixed, The two exceptions are
PRs 59694 and 65347. The former involves lack of finalization of an
unreferenced entity declared in a block, which I am sure is tri
On Wed, 2 Feb 2022, Jason Merrill wrote:
> On 2/2/22 12:09, Patrick Palka wrote:
> > The satisfaction cache needs to look through ARGUMENT_PACK_SELECT
> > template arguments before calling iterative_hash_template_arg and
> > template_args_equal, which would otherwise crash.
>
> Maybe we should ha
Here a stale value of TYPE_DEPENDENT_P/_P_VALID for f's function
type after replacing its DEFERRED_NOEXCEPT with its parsed (dependent)
noexcept-spec leads us to try to instantiate g's noexcept-spec (which
incorrectly appears non-dependent) ahead of time, causing an ICE.
This patch fixes this by c
On 2/3/22 17:43, Martin Sebor wrote:
On 2/3/22 01:59, Martin Liška wrote:
On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote:
Hi Martin,
Either this:
error ("% is unknown", orig_p);
or this would be better:
error ("attribute % is unknown", orig_p);
The %< %> directives will render
On 2/3/22 01:59, Martin Liška wrote:
On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote:
Hi Martin,
Either this:
error ("% is unknown", orig_p);
or this would be better:
error ("attribute % is unknown", orig_p);
The %< %> directives will render it in single quotes like keywords and
On 2/3/22 17:12, Jakub Jelinek wrote:
On Thu, Feb 03, 2022 at 04:40:25PM +0100, Martin Liška wrote:
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -258,12 +258,23 @@ then echo "All directories (including links to
directories):"
echo $all_dirs
fi
-for file in $all_dirs; d
On Thu, Feb 03, 2022 at 04:40:25PM +0100, Martin Liška wrote:
> --- a/fixincludes/fixinc.in
> +++ b/fixincludes/fixinc.in
> @@ -258,12 +258,23 @@ then echo "All directories (including links to
> directories):"
> echo $all_dirs
> fi
>
> -for file in $all_dirs; do
> - rm -rf $LIB/$file
> -
On Feb 03 2022, Martin Liška wrote:
> What do you think now?
xargs?
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On 2/3/22 17:06, Andreas Schwab wrote:
On Feb 03 2022, Martin Liška wrote:
-mkdir $LIB/root
Why did you remote that line?
That was an accidental removal, fixed in V2.
Martin
On Feb 03 2022, Martin Liška wrote:
> -mkdir $LIB/root
Why did you remote that line?
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Tue, Jan 18, 2022 at 05:40:48PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > About the rest of the patch, I thought I had seen richi comment on IRC (but
> > can't find the comment now) that these cases where we could give a constant
> > answer but decide not to because of C++ rules should be
On 2/3/22 16:19, Jeff Law wrote:
On 2/3/2022 7:56 AM, Martin Liška wrote:
In my case:
$ rm ./stmp-fixinc ; time make -j16
takes 17 seconds, where I can reduce it easily with the suggested
change. Then I get to 11.2 seconds.
The scripts searches ~2500 folders in my case with total 20K header
On 2/3/2022 7:56 AM, Martin Liška wrote:
In my case:
$ rm ./stmp-fixinc ; time make -j16
takes 17 seconds, where I can reduce it easily with the suggested
change. Then I get to 11.2 seconds.
The scripts searches ~2500 folders in my case with total 20K header
files.
Ready to be installed?
Th
On Thu, Feb 03, 2022 at 03:06:07PM +0100, David Seifert wrote:
> * `-Werror` can cause issues when a more recent version of GCC compiles
> an older version:
> - https://bugs.gentoo.org/229059
> - https://bugs.gentoo.org/475350
> - https://bugs.gentoo.org/667104
Now committed as https://gcc
This adds a flag to CONSTRUCTOR nodes indicating that for
clobbers this marks the end-of-life of storage as opposed to
just ending the lifetime of the object that occupied it.
The dangling pointer diagnostics uses CLOBBERs but is confused
by those emitted by the C++ frontend for example which emits
Richard Biener writes:
> On Thu, Feb 3, 2022 at 11:52 AM Richard Sandiford via Gcc-patches
> wrote:
>>
>> After the fix for PR102659, the vectoriser can no longer group
>> conditional accesses of the form:
>>
>> for (int i = 0; i < n; ++i)
>> if (...)
>> ...a[i * 2] + a[i * 2 + 1]...;
In my case:
$ rm ./stmp-fixinc ; time make -j16
takes 17 seconds, where I can reduce it easily with the suggested
change. Then I get to 11.2 seconds.
The scripts searches ~2500 folders in my case with total 20K header
files.
Ready to be installed?
Thanks,
Martin
fixincludes/ChangeLog:
The fur_list constructor for two ranges is leaving [1] in an undefined
state. The reason we haven't noticed is because after all the
shuffling in the last cycle there are no remaining users of it
(similarly for fur_list(unsigned, irange *)).
Since it's very late in the cycle, I would prefer to fi
On 1/20/22 17:54, Martin Sebor wrote:
The updated patch ensures the tighter bound isn't used to compute
the sprintf result and adds a test to verify that. (This is messy
in the strlen/sprintf pass and should be cleaned up to avoid this
mistake in the future.)
Rested on x86_64-linux.
OK, thank
Hi!
Although the previous patch was correct, the logic around what to do when
the number of arguments is wrong was still hard to understand. It should
be better now. I'm now explicitly counting the number of expected arguments
and comparing against that. The way the argument list is represented
Hello,
On Thu, 3 Feb 2022, Richard Biener via Gcc-patches wrote:
> /* Preserve explicit divisions by 0: the C++ front-end wants to detect
>undefined behavior in constexpr evaluation, and assuming that the
> division
>traps enables better optimizations than these anyway. */
> (for div (t
On Thu, Feb 3, 2022 at 11:52 AM Richard Sandiford via Gcc-patches
wrote:
>
> After the fix for PR102659, the vectoriser can no longer group
> conditional accesses of the form:
>
> for (int i = 0; i < n; ++i)
> if (...)
> ...a[i * 2] + a[i * 2 + 1]...;
>
> on LP64 targets. It has to tr
Hello,
On Thu, 3 Feb 2022, Richard Biener via Gcc-patches wrote:
> > > It indeed did occur to me as well, so as we're two now I tried to
> > > see how it looks like. It does like the following (didn't bother to
> > > replace all build_clobber calls but defaulted the parameter - there
> > > ar
On 2/3/22 05:27, Richard Biener wrote:
The following avoids NRV from massaging DECL_ABSTRACT_ORIGIN after
variable creation since NRV runs _after_ the function was inlined and thus
affects the inlined variables copy indirectly. We may adjust the abstract
origin of a variable only at the point we
* `-Werror` can cause issues when a more recent version of GCC compiles
an older version:
- https://bugs.gentoo.org/229059
- https://bugs.gentoo.org/475350
- https://bugs.gentoo.org/667104
Bootstrapped/regtested x86_64-linux, tested without --disable-werror and
with ./configure --disable-w
On Thu, 3 Feb 2022, Richard Biener wrote:
> On Thu, 3 Feb 2022, Michael Matz wrote:
>
> > Hello,
> >
> > On Thu, 3 Feb 2022, Richard Biener wrote:
> >
> > > > > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers
> > > > > this
> > > > > marks the end-of-life of storage as oppo
On Thu, 3 Feb 2022, Michael Matz wrote:
> Hello,
>
> On Thu, 3 Feb 2022, Richard Biener wrote:
>
> > > > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this
> > > > marks the end-of-life of storage as opposed to just ending the lifetime
> > > > of the object that occupied i
Hello,
On Thu, 3 Feb 2022, Richard Biener wrote:
> > > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this
> > > marks the end-of-life of storage as opposed to just ending the lifetime
> > > of the object that occupied it. The dangling pointer diagnostics uses
> > > CLOBBER
On Thu, Feb 3, 2022 at 2:21 PM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> I'd like to ping the following patch.
OK (note the patch is obvious IMHO)
Richard.
> Thanks.
>
> On Thu, Jan 27, 2022 at 11:07:26AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > On Thu, Jan 20, 2022 at 11:27:20AM
Hi!
I'd like to ping the following patch.
Thanks.
On Thu, Jan 27, 2022 at 11:07:26AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Jan 20, 2022 at 11:27:20AM +, Richard Earnshaw via Gcc-patches
> wrote:
> > gcc/ChangeLog:
> >
> > * config/arm/arm.opt (mfix-cortex-a57-aes-174209
On Thu, 3 Feb 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > On Thu, 3 Feb 2022, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > On Wed, 2 Feb 2022, Michael Matz wrote:
> >> >
> >> >> Hello,
> >> >>
> >> >> On Wed, 2 Feb 2022, Richard Biener via Gcc-patches wrote:
>
> Yes, I think the intent is clear. The question is whether we should
> re-instantiate the clear intent of preserving a literal / 0 as well
> (for C, without -fnon-call-exceptions).
Note that the code is precisely compiled with -fnon-call-exceptions:
ifeq ($(LIB2_DIVMOD_EXCEPTION_FLAGS),)
# Prov
On Thu, Feb 03, 2022 at 01:13:29PM +0100, Richard Biener wrote:
> On Thu, 3 Feb 2022, Jakub Jelinek wrote:
>
> > On Thu, Feb 03, 2022 at 12:03:15PM +0100, Richard Biener wrote:
> > > But as said, for the libgcc2.c case I'd simply remove all of it.
> >
> > I can't read RMS' mind, it is indeed UB,
Richard Biener writes:
> On Thu, 3 Feb 2022, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Wed, 2 Feb 2022, Michael Matz wrote:
>> >
>> >> Hello,
>> >>
>> >> On Wed, 2 Feb 2022, Richard Biener via Gcc-patches wrote:
>> >>
>> >> > This adds a flag to CONSTRUCTOR nodes indicating t
On Thu, 3 Feb 2022, Jakub Jelinek wrote:
> On Thu, Feb 03, 2022 at 12:03:15PM +0100, Richard Biener wrote:
> > But as said, for the libgcc2.c case I'd simply remove all of it.
>
> I can't read RMS' mind, it is indeed UB, so we can do anything, but I bet
> it was just a QoI attempt, when (most of
On Thu, 3 Feb 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > On Wed, 2 Feb 2022, Michael Matz wrote:
> >
> >> Hello,
> >>
> >> On Wed, 2 Feb 2022, Richard Biener via Gcc-patches wrote:
> >>
> >> > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this
> >> > marks
On Thu, Feb 03, 2022 at 12:59:43PM +0100, David Seifert wrote:
> I have an FSF copyright assignment, is there anything you need me to do
> to this end?
Ok.
> > > --- a/libsanitizer/configure.ac
> > > +++ b/libsanitizer/configure.ac
> > > @@ -400,6 +400,15 @@ fi
> > > AC_SUBST([TSAN_TARGET_DEPEND
Richard Biener writes:
> On Wed, 2 Feb 2022, Michael Matz wrote:
>
>> Hello,
>>
>> On Wed, 2 Feb 2022, Richard Biener via Gcc-patches wrote:
>>
>> > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this
>> > marks the end-of-life of storage as opposed to just ending the lifeti
On Thu, 2022-02-03 at 12:50 +0100, Jakub Jelinek wrote:
> On Thu, Feb 03, 2022 at 12:30:11PM +0100, David Seifert wrote:
> > * `-Werror` can cause issues when a more recent version of GCC
> > compiles
> > an older version:
> > - https://bugs.gentoo.org/229059
> > - https://bugs.gentoo.org/475
On Thu, Feb 03, 2022 at 12:30:11PM +0100, David Seifert wrote:
> * `-Werror` can cause issues when a more recent version of GCC compiles
> an older version:
> - https://bugs.gentoo.org/229059
> - https://bugs.gentoo.org/475350
> - https://bugs.gentoo.org/667104
>
> libatomic/ChangeLog:
>
On Wed, 2 Feb 2022, Michael Matz wrote:
> Hello,
>
> On Wed, 2 Feb 2022, Richard Biener via Gcc-patches wrote:
>
> > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this
> > marks the end-of-life of storage as opposed to just ending the lifetime
> > of the object that occupi
* `-Werror` can cause issues when a more recent version of GCC compiles
an older version:
- https://bugs.gentoo.org/229059
- https://bugs.gentoo.org/475350
- https://bugs.gentoo.org/667104
libatomic/ChangeLog:
* libatomic/configure.ac: Support --disable-werror.
* libatomic
On Thu, 2022-02-03 at 11:23 +, Jonathan Wakely wrote:
> On 03/02/22 12:08 +0100, David Seifert wrote:
> > * `-Werror` can cause issues when a more recent version of GCC
> > compiles
> > an older version:
> > - https://bugs.gentoo.org/229059
> > - https://bugs.gentoo.org/475350
> > - https:/
On 03/02/22 12:08 +0100, David Seifert wrote:
* `-Werror` can cause issues when a more recent version of GCC compiles
an older version:
- https://bugs.gentoo.org/229059
- https://bugs.gentoo.org/475350
- https://bugs.gentoo.org/667104
Honouring --disable-werror everywhere seems reasonable t
On Thu, Feb 03, 2022 at 12:03:15PM +0100, Richard Biener wrote:
> But as said, for the libgcc2.c case I'd simply remove all of it.
I can't read RMS' mind, it is indeed UB, so we can do anything, but I bet
it was just a QoI attempt, when (most of the time) normal single-word
or smaller division for
* `-Werror` can cause issues when a more recent version of GCC compiles
an older version:
- https://bugs.gentoo.org/229059
- https://bugs.gentoo.org/475350
- https://bugs.gentoo.org/667104
---
libatomic/configure.ac| 6 --
libbacktrace/configure.ac | 7 -
This patch addresses PR rtl-optimization/101885 which is a P2 wrong code
regression. In combine, if the resulting fused instruction is a parallel
of two sets which fails to be recognized by the backend, combine tries to
emit these as two sequential set instructions (known as split_i2i3).
As each
On Thu, 3 Feb 2022, Jakub Jelinek wrote:
> On Thu, Feb 03, 2022 at 10:40:10AM +0100, Richard Biener wrote:
> > Yes, we definitely have multiple of those cases. I do think
> > preserving "an idiom", for example literal 0/0 or all x/0 might be
> > worth considering. But I also think we have to sor
At some point we started generating the intended code for
aarch64/sve/struct_vect_25.c. This patch removes the xfails
and the scan-assembler-times that replaced the xfailed forms.
Tested on aarch64-linux-gnu & pushed.
Richard
gcc/testsuite/
* gcc.target/aarch64/sve/struct_vect_25.c: Re
After the fix for PR102659, the vectoriser can no longer group
conditional accesses of the form:
for (int i = 0; i < n; ++i)
if (...)
...a[i * 2] + a[i * 2 + 1]...;
on LP64 targets. It has to treat them as two independent
gathers instead.
This was causing failures in the sve mask_st
The Advanced SIMD movmisalign patterns didn't handle 16-bit
FP modes, which meant that the vector loop for:
void
test (_Float16 *data)
{
_Pragma ("omp simd")
for (int i = 0; i < 8; ++i)
data[i] = 1.0;
}
would be versioned for alignment.
This was causing some new failures in
The VALL_F16MOV iterator now has the same modes as VALL_F16,
in the same order. This patch removes the former in favour
of the latter.
This doesn't fix a bug as such, but it's ultra-safe (no change in
object code) and it saves a follow-up patch from having to make
a false choice between the itera
Many of the XFAILed TSVC tests pass for SVE. This patch updates
the markup accordingly.
Tested on aarch64-linux-gnu & pushed.
Richard
gcc/testsuite/
* gcc.dg/vect/tsvc/vect-tsvc-s1115.c: Don't XFAIL for SVE.
* gcc.dg/vect/tsvc/vect-tsvc-s114.c: Likewise.
* gcc.dg/vect/t
Following on from GCC 11 patch g:f31ddad8ac8, this one gives clean
guality.exp test results for aarch64-linux-gnu with modern gdb
(this time gdb 11.2).
The justification is the same as previously:
--
For people using older gdbs, it will trade one set of noisy results for
another set. I still
The following avoids NRV from massaging DECL_ABSTRACT_ORIGIN after
variable creation since NRV runs _after_ the function was inlined and thus
affects the inlined variables copy indirectly. We may adjust the abstract
origin of a variable only at the point we create it, not further along the
path si
On 2/3/22 10:40, Thomas Schwinge wrote:
Hi Tom!
On 2021-05-19T14:56:17+0200, I wrote:
On 2020-08-12T15:57:23+0200, Tom de Vries wrote:
When enabling sync_int_long for nvptx, we run into a failure in
gcc.dg/pr86314.c:
...
nvptx-run: error getting kernel result: operation not supported on \
On Thu, Feb 03, 2022 at 10:40:10AM +0100, Richard Biener wrote:
> Yes, we definitely have multiple of those cases. I do think
> preserving "an idiom", for example literal 0/0 or all x/0 might be
> worth considering. But I also think we have to sort out different
> language standards requirements
> The optimization can be useful, it doesn't have to be for user written
> y = 1 / x; but can appear through inlining or some other optimizations, e.g.
> jump threading and suddenly we have constant 1 in some bb, if it a never
> executed at runtime block, it will be likely shorter because of the
>
Hi Tom!
On 2021-05-19T14:56:17+0200, I wrote:
> On 2020-08-12T15:57:23+0200, Tom de Vries wrote:
>> When enabling sync_int_long for nvptx, we run into a failure in
>> gcc.dg/pr86314.c:
>> ...
>> nvptx-run: error getting kernel result: operation not supported on \
>>global/shared address spac
On Thu, 3 Feb 2022, Jakub Jelinek wrote:
> On Thu, Feb 03, 2022 at 10:06:42AM +0100, Eric Botcazou wrote:
> > > Well, yes, we have to fix it. I will share my thoughts when coming
> > > along the bugreport.
> >
> > IMO we should simply scrap it, as it does not serve any useful purpose,
> > break
On Thu, Feb 03, 2022 at 10:06:42AM +0100, Eric Botcazou wrote:
> > Well, yes, we have to fix it. I will share my thoughts when coming
> > along the bugreport.
>
> IMO we should simply scrap it, as it does not serve any useful purpose,
> breaks
> a very ancient and useful idiom and also introduc
Pushed based on Jakub's comment.
Martin
gcc/ChangeLog:
* config/i386/i386-options.cc (ix86_valid_target_attribute_inner_p):
Change subject and object in the error message.
* config/s390/s390.cc (s390_valid_target_attribute_inner_p):
Likewise.
---
gcc/config/i386
On 2/3/22 10:08, Jakub Jelinek wrote:
This is backwards, isn't it? It should be
"attribute % argument %qs is unknown", no?
Oh, correct:
cat x.c && gcc x.c -c
int __attribute__((target("-ff"))) foo() { }
x.c:1:36: error: attribute ‘-ff’ argument ‘target’ is unknown
1 | int __attribute__((t
On Thu, Feb 03, 2022 at 09:56:25AM +0100, Martin Liška wrote:
> gcc/ChangeLog:
>
> * config/s390/s390.cc (s390_valid_target_attribute_inner_p):
> Use the error message for i386 target.
> ---
> gcc/config/s390/s390.cc | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> d
1 - 100 of 111 matches
Mail list logo
