Configuring with --enable-default-ssp triggers various testsuite
failures. These contain asm statements that are not compatible with
-fstack-protector. Adding -fno-stack-protector to dg-options to
work around this issue.
Tested on x86_64-linux.
2022-01-26 Allan McRae
PR
On 1/26/22 18:55, Marek Polacek wrote:
In r12-1933 I attempted to implement DR2397 aka allowing
int a[3];
auto ()[3] = a;
by removing the type_uses_auto check in create_array_type_for_decl.
That may have gone too far, because it also allows arrays of
CLASS_PLACEHOLDER_TEMPLATE and it
In r12-1933 I attempted to implement DR2397 aka allowing
int a[3];
auto ()[3] = a;
by removing the type_uses_auto check in create_array_type_for_decl.
That may have gone too far, because it also allows arrays of
CLASS_PLACEHOLDER_TEMPLATE and it looks like [dcl.type.class.deduct]
prohibits
The problem with this testcase was that since my patch for PR97900 we
weren't preserving DECL_UID identity for parameters of instantiations of
templated functions, so using those parameters as the keys for the
defarg_inst map broke. I think this was always fragile given the
possibility of
On Wed, 26 Jan 2022, Patrick Palka wrote:
> On Wed, Jan 19, 2022 at 2:19 PM Jason Merrill wrote:
> >
> > On 1/19/22 11:15, Patrick Palka wrote:
> > > Here we're emitting a bogus error during ahead of time evaluation of a
> > > non-dependent immediate member function call such as a.f(args)
Hi!
On Thu, Dec 23, 2021 at 10:12:19AM +0800, Kewen.Lin wrote:
> PR target/103627
> * config/rs6000/rs6000.c (rs6000_option_override_internal): Move the
> hunk affecting VSX and ALTIVEC to the appropriate place.
>
> gcc/testsuite/ChangeLog:
>
> PR target/103627
> *
On Wed, Jan 19, 2022 at 2:19 PM Jason Merrill wrote:
>
> On 1/19/22 11:15, Patrick Palka wrote:
> > Here we're emitting a bogus error during ahead of time evaluation of a
> > non-dependent immediate member function call such as a.f(args) because
> > the defacto templated form for such a call is
Hi!
On Thu, Dec 23, 2021 at 10:09:27AM +0800, Kewen.Lin wrote:
> As PR103627 shows, there is an unexpected case where !TARGET_VSX
> and TARGET_MMA co-exist. As ISA3.1 claims, SIMD is a requirement
> for MMA. By looking into the ICE, I noticed that the current
> MMA implementation depends on
On Wed, Jan 26, 2022 at 11:14:54PM +0100, Tobias Burnus wrote:
> ]I saw that the following now is implemented:
>
> * requires: dynamic_allocators is now also works
> (by assuming that it is supported, no longer giving 'sorry')
>
]I saw that the following now is implemented:
* requires: dynamic_allocators is now also works
(by assuming that it is supported, no longer giving 'sorry')
https://gcc.gnu.org/r12-6641-g450c85b81f4dd67bf6211d307afdc0f3c07ef44f
* in_reduction on target: Now also supported for Fortran
On Wed, 26 Jan 2022 at 22:08, Dimitar Dimitrov wrote:
>
> On Tue, Jan 25, 2022 at 09:09:51PM +, Jonathan Wakely via Gcc-patches
> wrote:
> > Tested x86_64-linux, pushed to trunk. Backports to follow.
> >
> >
> > This adds a new internal flag to the filesystem::directory_iterator
> >
On Tue, Jan 25, 2022 at 09:09:51PM +, Jonathan Wakely via Gcc-patches wrote:
> Tested x86_64-linux, pushed to trunk. Backports to follow.
>
>
> This adds a new internal flag to the filesystem::directory_iterator
> constructor that makes it fail if the path is a symlink that resolves to
> a
Hi!
On Wed, Jan 26, 2022 at 10:03:36PM +0100, Jakub Jelinek wrote:
> When writing testcases for the previously posted patch, I have noticed
> that 3 of the headers aren't valid C89 (I didn't have any dg-options
> so -ansi -pedantic-errors was implied and these errors were reported).
Hrm. Do
On Wed, 26 Jan 2022, Joseph Myers wrote:
> fmin and fmax:
Also:
* If the arguments are +0 and -0 in some order, it's unspecified what sign
the result has.
> fminimum and fmaximum:
> fminimum_num and fmaximum_num:
Also:
* These four functions are required to treat -0 as less than +0.
--
Hi!
When writing testcases for the previously posted patch, I have noticed
that 3 of the headers aren't valid C89 (I didn't have any dg-options
so -ansi -pedantic-errors was implied and these errors were reported).
The following patch fixes those, ok for trunk?
Note, as can be seen even in this
Dear Fortranners,
the use of -fdefault-integer-8 exhibits several cases where
we missed to convert the result of an intrinsic from the
declared to the effective resulting type.
The attached obvious patch fixes this for IMAGE_STATUS,
TEAM_NUMBER, and POPCNT/POPPAR.
OK for mainline if regtesting
On Wed, Jan 26, 2022 at 3:45 PM Jakub Jelinek wrote:
>
> Hi!
>
> r12-4717-g7d37abedf58d66 added immintrin.h and x86gprintrin.h headers
> to rs6000, these headers are on x86 standalone headers that various
> programs include directly rather than including them through
> .
> Unfortunately, for that
Hi!
r12-4717-g7d37abedf58d66 added immintrin.h and x86gprintrin.h headers
to rs6000, these headers are on x86 standalone headers that various
programs include directly rather than including them through
.
Unfortunately, for that change the bmiintrin.h and bmi2intrin.h
headers haven't been
On Wed, 26 Jan 2022, Joseph Myers wrote:
> fmin and fmax:
>
> * Treat quiet NaN as missing data and return the other argument (if a
> number).
>
> * Treat signaling NaN like most functions (raise invalid, return quiet
> NaN).
>
> fminimum and fmaximum:
>
> * Treat quiet NaN like most
As at r2.2 of the RISC-V ISA specification[1] the FMIN and FMAX machine
instructions fully match our requirement for the `fminM3' and `fmaxM3'
standard RTL patterns:
"For FMIN and FMAX, if at least one input is a signaling NaN, or if both
inputs are quiet NaNs, the result is the canonical NaN.
On Wed, 26 Jan 2022, Maciej W. Rozycki wrote:
> > The newer instruction semantics correspond to the functions fminimum_num
> > and fmaximum_num, not fminimum and fmaximum (which are functions that
> > treat both quiet and signaling NaNs like most libm functions do - any
> > argument a NaN
My patch for PR101072 removed the specific VECTOR_TYPE handling here, which
broke pr72747-2.c on PPC; this patch restores it.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104206
PR c++/101072
gcc/cp/ChangeLog:
* semantics.cc (finish_compound_literal): Restore
On Wed, 26 Jan 2022, YunQiang Su wrote:
> Since MIPS r2, the IPL section in Cause register has been expand
> to 8bit instead of 6bit.
Hmm, I cannot see it in my copy of the architecture manual I'm afraid.
The interpretation may have changed, but the field is still 6-bit (not
counting the
Hi!
On Wed, Jan 26, 2022 at 10:26:45AM +0800, Kewen.Lin wrote:
> on 2022/1/14 上午12:31, David Edelsohn wrote:
> Yeah, but IMHO it still can confuse new comers at first glance.
Yes, or at least cause to read (well, grep) the whole backend and
scratch heads.
> >> 2) Bootstrapped and tested one
From: Andrew Pinski
The function aarch64_evpc_ins would reuse the target even though
it might be the same register as the two inputs.
Instead of checking to see if we can reuse the target, just use the
original input directly.
Committed as approved after bootstrapped and tested on
In the nested_name_specifier branch within cp_parser_class_head, we need
to update TYPE with the result of maybe_process_partial_specialization
just like we do in the template_id_p branch.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/92944
On Wed, Jan 26, 2022 at 09:39:46AM -0700, Martin Sebor wrote:
> On 1/26/22 08:24, Jason Merrill via Gcc-patches wrote:
> > On 1/25/22 18:33, Marek Polacek wrote:
> > > Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
> > > return, as mandated by the EABI. To be entirely
On 1/26/22 08:24, Jason Merrill via Gcc-patches wrote:
On 1/25/22 18:33, Marek Polacek wrote:
Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
return, as mandated by the EABI. To be entirely correct, it only
requires it for C1 and C2 ctors and D2 and D1 dtors, but I don't
cp_parser_template_id wasn't prepared to handle getting a USING_DECL back
from cp_parser_template_name. Let's defer that case to instantiation time,
as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104235
gcc/cp/ChangeLog:
* parser.cc (cp_parser_template_name):
On 1/26/2022 8:56 AM, Richard Biener via Gcc-patches wrote:
This adds the capability to value-numbering of treating complex
address expressions where the offset becomes invariant as equal
to a POINTER_PLUS_EXPR. This restores CSE that is now prevented
by early lowering of [ptr + CST] to a
This adds the capability to value-numbering of treating complex
address expressions where the offset becomes invariant as equal
to a POINTER_PLUS_EXPR. This restores CSE that is now prevented
by early lowering of [ptr + CST] to a POINTER_PLUS_EXPR.
Unfortunately this regresses
On Wed, Jan 26, 2022 at 12:05:54PM -0300, Raoni Fassina Firmino wrote:
> Commit 4343f5e25679 ("rtl: builtins: (not just) rs6000: Add builtins
> for fegetround, feclearexcept and feraiseexcept [PR94193]") broke gcc
> bootstra when building with --enable-checking=rtl[1].
>
> The function
On Wed, Jan 26, 2022 at 3:49 PM Martin Liška wrote:
>
> The patch fixed bad --param param=foo names.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK.
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * ipa-modref-tree.cc
Hi Guys,
I would like to propose the patch below to fix a couple of sources
of infinite recursion in libiberty's rust demangling code. This patch
is based upon the one submitted for PR 99935, but extended to cope
with the case presented in PR 98886 and also fixed so that the "uint"
On 1/25/22 18:33, Marek Polacek wrote:
Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
return, as mandated by the EABI. To be entirely correct, it only
requires it for C1 and C2 ctors and D2 and D1 dtors, but I don't feel
like changing that now and possibly running into
On 1/26/22 04:33, Jakub Jelinek wrote:
Hi!
The middle-end uses sometimes VECTOR_TYPE CONSTRUCTORs that contain
some other VECTOR_TYPE elements in it (should be with compatible element
size and smaller number of elements, e.g. a V8SImode vector can be
constructed as { V4SImode_var_1,
Tested on top of master (e0b8716f53ed6455e9f18931940141692793068d)
using --enable-checking=yes,rtl, on the following plataforms with no
regression:
- powerpc64le-linux-gnu (Power 9)
- powerpc64le-linux-gnu (Power 8)
- powerpc64-linux-gnu (Power 9, with 32 and 64 bits tests)
I did not
We were failing to check for uninitialized arguments to stdio builtins,
such as when passing local "go" to the call to "printf" in "main" in
the testcase.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-6876-g9ff3e2368d86c1bf7d1e8876a14e58c0d6617ffe.
On Sun, 2022-01-23 at 17:34 +0100, Mikael Morin wrote:
> Hello,
>
> Le 21/01/2022 à 00:59, David Malcolm via Gcc-patches a écrit :
> > diff --git a/gcc/analyzer/constraint-manager.cc
> > b/gcc/analyzer/constraint-manager.cc
> > index 568e7150ea7..7c4a85bbb24 100644
> > ---
The patch fixed bad --param param=foo names.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* ipa-modref-tree.cc (modref_access_node::update):
Remove "--param param=foo" with "--param foo".
On Mon, 24 Jan 2022, Joseph Myers wrote:
> > I think we have consensus that we can ignore pre-r2.2 hardware. What we
> > actually support is `-misa-spec=<2.2|20190608|20191213>', so we can assume
> > r2.2 semantics as the absolute minimum, matching the description in my
> > submission.
>
>
Hello
Just noticed a bug in the ISA checking in the nvptx plugin - the minor
version should only be compared if the major version is equal, otherwise
it would reject an isa of sm_35 if the card is capable of supporting
sm_52, for example. This patch fixes the issue.
Thanks
Kwokdiff --git
On 1/26/22 03:09, Ard Biesheuvel wrote:
On Wed, 26 Jan 2022 at 11:40, Dan Li wrote:
Thanks, Ard,
On 1/26/22 00:10, Ard Biesheuvel wrote:
On Wed, 26 Jan 2022 at 08:53, Dan Li wrote:
Hi, all,
Sorry for bothering.
I'm trying to commit aarch64 scs code to the gcc and there is an issue
niter analysis uses multiple_of_p which currently assumes
operations like MULT_EXPR do not wrap. We've got to rely on this
for optimizing size expressions like those in DECL_SIZE and those
generally use unsigned arithmetic with no indication that they
are not expected to wrap. To preserve that
Hello.
Right now, switch lowering does not update basic_block::count values
so that they are uninitiliazed. Moreover, I've updated probability scaling
when a more complex expansion happens. There are still some situations where
the profile is a bit imprecise, but the patch improves rapidly the
On Sun, Jan 23, 2022 at 04:39:34PM -0800, H.J. Lu via Gcc-patches wrote:
> On Sun, Jan 23, 2022 at 4:35 PM Hongtao Liu wrote:
> >
> > On Sun, Jan 23, 2022 at 8:28 PM H.J. Lu via Gcc-patches
> > wrote:
> > >
> > > Return false for invalid mode on memory broadcast in bcst_mem_operand:
> > >
> > >
On Wed, 26 Jan 2022 at 11:40, Dan Li wrote:
>
> Thanks, Ard,
>
> On 1/26/22 00:10, Ard Biesheuvel wrote:
> > On Wed, 26 Jan 2022 at 08:53, Dan Li wrote:
> >>
> >> Hi, all,
> >>
> >> Sorry for bothering.
> >>
> >> I'm trying to commit aarch64 scs code to the gcc and there is an issue
> >> that
Thanks, Ard,
On 1/26/22 00:10, Ard Biesheuvel wrote:
On Wed, 26 Jan 2022 at 08:53, Dan Li wrote:
Hi, all,
Sorry for bothering.
I'm trying to commit aarch64 scs code to the gcc and there is an issue
that I'm not sure about, could someone give me some suggestions?
(To avoid noise, I did't cc
Hi!
The middle-end uses sometimes VECTOR_TYPE CONSTRUCTORs that contain
some other VECTOR_TYPE elements in it (should be with compatible element
size and smaller number of elements, e.g. a V8SImode vector can be
constructed as { V4SImode_var_1, V4SImode_var_2 }), and expansion of
Ping?
As discussed elsewhere with André, I'll drop patch #15 from this series,
since his patch
is a better fix.
Since v2 of this series had been approved, I think only patches 4,7,8,9,12
and 13 need
proper review.
Thanks,
Christophe
On Fri, Jan 14, 2022 at 3:22 PM Kyrylo Tkachov
wrote:
>
On Wed, 26 Jan 2022 at 08:53, Dan Li wrote:
>
> Hi, all,
>
> Sorry for bothering.
>
> I'm trying to commit aarch64 scs code to the gcc and there is an issue
> that I'm not sure about, could someone give me some suggestions?
> (To avoid noise, I did't cc PING^3 [1] to the kernel mail list :) )
>
>
51 matches
Mail list logo
