> 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 in
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 means
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 instruc
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 2db12d4
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 r7-4470-g
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 i
> 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 introduces an artificial discrepancy
between 1/X and 2/X for example.
--
Eric Bot
On Thu, Feb 3, 2022 at 12:35 AM Martin Sebor wrote:
>
> Richard, as we discussed(*), this patch series enables the pointer_query
> cache in the remaining two passes where it's currently disabled. Since
> not using the cache is not an option anymore, the first patch in
> the series makes it a priv
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
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
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 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
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
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
> 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
>
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
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 \
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
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
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
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
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
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
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
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
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, 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
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, 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:/
* `-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 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
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 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
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, 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
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, 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
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, 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,
> 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, 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:
>
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, 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
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, 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
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
* `-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 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
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 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:
> /* 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
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
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
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
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:
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]...;
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
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
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 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 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 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 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:
> 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 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 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 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: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
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 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
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 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
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
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
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
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_
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 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
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 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
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 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 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 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 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 wh
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
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 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, 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 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 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: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
%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: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
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 ..
> > >
1 - 100 of 111 matches
Mail list logo
