> Do you need to adjust anything now that this is emitting into TEMP
> rather than TARGET?
The idea now is to emit to TEMP in the first pass and check if we read
the initial condition. Overwriting the condition (and of course reading
it in every sequence) is the reason temporaries were needed
Hi!
The testcase shows some cases that weren't verified and we ICE on
invalid because of that.
One problem is that unlike before, we weren't checking if some expression
is EXPR_VARIABLE with non-NULL symtree in the case where there was
a conversion around it.
The other two issues is that we check
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
> identifiers. Using %qs would render it in double quotes like a string,
>
ping ?
On Fri, Jan 28, 2022 at 9:50 PM chenglulu wrote:
>
> The LoongArch architecture (LoongArch) is an Instruction Set
> Architecture (ISA) that has a Reduced Instruction Set Computer (RISC)
> style.
> The documents are on
> https://loongson.github.io/LoongArch-Documentation/README-EN.html
>
>
On Thu, 3 Feb 2022, Jakub Jelinek wrote:
> Hi!
>
> The wide-int.h templates expect that when an int/long etc. operand is used
> it will be sign-extended based on the types precision.
> wi_fold_in_parts passes 3 such non-zero constants to wi::lt_p, wi::gt_p
> and wi::eq_p - 1, 3 and 4, which
Hi!
Eric mentioned we have a code trying to divide by zero intentionally
in gcc (since r0-241 !).
But, it clearly doesn't do what it wanted (which I think is raise
SIGFPE if the target normally raises it upon division by zero)
since r7-4470-g606f928d3805614, because we replace the division
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(-)
diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index
On Thu, 3 Feb 2022, Jakub Jelinek wrote:
> Hi!
>
> Eric mentioned we have a code trying to divide by zero intentionally
> in gcc (since r0-241 !).
> But, it clearly doesn't do what it wanted (which I think is raise
> SIGFPE if the target normally raises it upon division by zero)
> since
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
> > -
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
> > >
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,
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
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
* `-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
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
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
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
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
* `-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.
*
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:
>
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
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.
*
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
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
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."
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
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:
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
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?
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
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
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
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
> > -
> 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),)
#
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
> > >
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
* `-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
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
> >> >
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
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:
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
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 +
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 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:
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
> > >
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
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,
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
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
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
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
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
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
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
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.
> >
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
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
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
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
> > >
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,
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;
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 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 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: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 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
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
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
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
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
>
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 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",
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:
*
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
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):"
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
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 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
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
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 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,
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
-
%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 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 ..
> >
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.
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
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
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
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
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
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
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 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
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 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
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
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
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
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:
> > >
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
identifiers. Using %qs would render
1 - 100 of 111 matches
Mail list logo
