Hi!
The following testcase FAILs, because replace_rtx replaces a REG with
CONST_WIDE_INT inside of a SUBREG, which is an invalid transformation
because a SUBREG relies on SUBREG_REG having non-VOIDmode but
CONST_WIDE_INT has VOIDmode.
replace_rtx already has code to deal with it, but it was doing
Hi!
The following testcase is miscompiled. We see the constructor is immediate,
in build_over_call we trigger:
if (obj_arg && is_dummy_object (obj_arg))
{
call = build_cplus_new (DECL_CONTEXT (fndecl), call, complain);
obj_arg = NULL_TREE;
On Thu, Jan 13, 2022 at 04:18:33PM -0500, Jason Merrill wrote:
> > Note, address_compare has some special cases, e.g. it assumes that
> > static vars are never adjacent to automatic vars, which is the case
> > for the usual layout where automatic vars are on the stack and after
> > .rodata/.data se
On Tue, Jan 18, 2022 at 11:17:41AM +0100, Jakub Jelinek via Gcc-patches wrote:
> Anyway, the following has been successfully bootstrapped/regtested on
> x86_64-linux and i686-linux, ok for trunk?
Actually, I missed one regression (thought it is caused by PR104025 patch
but it is this one):
On Tue, Jan 18, 2022 at 01:16:14PM +0100, Richard Biener wrote:
> As pointed out by pahole.
>
> Bootstrapped & tested on x86_64-unknown-linux-gnu.
>
> OK?
>
> Thanks,
> Richard.
>
> 2022-01-18 Richard Biener
>
> libcpp/
> * include/line-map.h (class line_maps): Re-arrange fields
>
On Mon, Jan 03, 2022 at 10:15:26PM +0800, Chung-Lin Tang wrote:
> This issue was triggered after the patch extending syntax for component access
> in map clauses
> (https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=0ab29cf0bb68960c)
>
> In gimplify_scan_omp_clauses, the case for handling indirect acc
On Tue, Jan 18, 2022 at 09:08:03AM -0500, Jason Merrill wrote:
> > which makes call a TARGET_EXPR with the dtor in TARGET_EXPR_CLEANUP,
> > but then call cxx_constant_value on it. In cxx_eval_outermost_constant_expr
> > it triggers the:
> >else if (TREE_CODE (t) != CONSTRUCTOR)
> >
On Tue, Jan 18, 2022 at 11:25:38AM -0500, Jason Merrill wrote:
> > Can you please comment on
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369#c1
> > then?
>
> Done.
Thanks.
> About the rest of the patch, I thought I had seen richi comment on IRC (but
> can't find the comment now) that the
On Tue, Jan 18, 2022 at 02:44:34PM -0500, Patrick Palka via Gcc-patches wrote:
> On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely wrote:
> >
> > Tested x86_64-linux, pushed to trunk.
> >
> >
> > Instead of hardcoded preprocessor conditionals with explicit target
> > checks, just rely on the fact th
On Tue, Jan 18, 2022 at 11:51:31AM -0500, Jason Merrill wrote:
> On 1/18/22 09:26, Jakub Jelinek wrote:
> > On Tue, Jan 18, 2022 at 09:08:03AM -0500, Jason Merrill wrote:
> > > > which makes call a TARGET_EXPR with the dtor in TARGET_EXPR_CLEANUP,
> > > > but then call cxx_constant_value on it. In
On Tue, Jan 18, 2022 at 05:56:47PM -0500, Jason Merrill wrote:
> Debug information was getting confused because input_location was different
> depending on whether we had looked ahead to see if the next tokens look like
> a template argument list.
>
> I tried resetting input_location in cp_lexer_r
Hi!
This is a non-C++ related part from the PR89074 address_compare changes.
For "foo" == "foo" we already optimize this from the (cmp @0 @0)
simplification, because we use operand_equal_p in that case
and operand_equal_p also compares the STRING_CSTs bytes rather than
just addresses.
Bootstrappe
Hi!
As reported in the PR or as I've seen since the weekend, asan_test.C fails
because of many warnings like:
/home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1157:10: error:
using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=]
/home/jakub/src/gcc/gcc/testsuite/g
On Sun, Jan 16, 2022 at 12:22:18PM +0800, Hongtao Liu via Gcc-patches wrote:
> On Sun, Jan 16, 2022 at 12:44 AM Uros Bizjak via Gcc-patches
> wrote:
> >
> > On Sat, Jan 15, 2022 at 5:39 PM Hongyu Wang wrote:
> > >
> > > Thanks for the suggestion, here is the updated patch that survived
> > > boot
Hi!
On Wed, Jan 19, 2022 at 09:09:41AM +0800, Hongtao Liu wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> Yes, thanks.
Thanks. Committed.
grep '{[^|}]*}"' *.md
found another spot, though dunno if we have sufficient effective targets
etc. to add an -masm=intel t
On Wed, Jan 19, 2022 at 07:54:19AM +0100, Sebastian Huber wrote:
> On 18/01/2022 22:42, Segher Boessenkool wrote:
> > > +default:
> > > + break;
> > Please don't do that. You can do
> >
> >default:
> > break;
> > break;
> > /* And just to make sure: */
> > break;
Hi!
power10 has modv4si3 expander and so vectorizes the following testcase
where Fortran modulo is FLOOR_MOD_EXPR.
optabs_for_tree_code indicates that the optab for all the *_MOD_EXPR
variants is umod_optab or smod_optab, but that isn't true, that optab
actually expands just TRUNC_MOD_EXPR. For t
Hi!
The testcase from the PR got fixed with r12-3119-g675a3e40567e1d
and looks quite similar to the evrp-trans.c test, except evrp-trans.c
is tested on signed integer types.
I think it would be useful to test it for unsigned comparisons too.
Tested on x86_64-linux (-m32/-m64), ok for trunk?
2022
On Wed, Jan 19, 2022 at 11:29:18PM +0100, Thomas Schwinge wrote:
> (The pass is still disabled by default, by the way.)
>
> We've found that 'gcc/omp-oacc-kernels-decompose.cc' is currently not at
> all considerate of 'GIMPLE_DEBUG' statements -- and it's not always
> straight forward how to handl
On Thu, Jan 20, 2022 at 09:26:50AM +0100, Thomas Schwinge wrote:
> That's what we need to look into, in particular: if we decompose (GIMPLE
> sequence) an OpenACC 'kernels' region into parts, how to move or
> otherwise handle any 'GIMPLE_DEBUG's.
I admit I haven't looked at the pass except now for
On Thu, Jan 20, 2022 at 10:43:55AM +0100, Martin Liška wrote:
> The patch disables "-Wformat-diag" for dump_aggr_type.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> PR c++/104134
>
> gcc/cp/ChangeLog:
>
>
On Thu, Jan 20, 2022 at 10:44:18AM +0100, Martin Liška wrote:
> The patch disables -Wformat-diag for RTL checking diagnostics.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> PR bootstrap/104135
>
> gcc/ChangeLog
On Thu, Jan 20, 2022 at 11:17:28AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > --- a/gcc/cp/error.cc
> > +++ b/gcc/cp/error.cc
> > @@ -768,6 +768,11 @@ class_key_or_enum_as_string (tree t)
> > return "struct";
> > }
> > +#if __GNUC__ >=
On Wed, Jan 19, 2022 at 12:42:22PM +0100, Martin Liška wrote:
> The tests are C++ code, so use a proper file extension.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/ext/boolcomplex-1.c: Moved to...
> * g++.dg/ext/boolcomplex-1.C: ...here.
> * g++.dg/opt/pr47639.c: Moved to...
>
Hi!
riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
due to some aggressive linker optimizations).
As the following testcase shows, we mishandle in index_rnglists the
!HAVE_AS_LEB128 && !have_multiple_function_sections case.
output_rnglists does roughly:
FOR_EACH_VEC_SAFE
On Thu, Jan 20, 2022 at 02:58:21PM +0100, Richard Biener via Gcc-patches wrote:
> The following avoids us ICEing doing constant folding from variables
> with aliases of different types. The formerly used fold_convert
> wasn't entirely correct even for the cases it handled and using
> a VIEW_CONVER
On Thu, Jan 20, 2022 at 09:33:30AM -0700, Martin Sebor wrote:
> > Oh, and one more thing, but this time not about this source file but about
> > the warning. Does it handle the gettext case?
> > I think -Wformat generally does, gettext has format_arg attribute.
> > If the warning handles
> >pp
On Thu, Jan 20, 2022 at 09:56:59AM -0700, Martin Sebor wrote:
> > With normal -Wformat I see all expected warnings in:
> > char *foo (const char *) __attribute__((format_arg(1)));
> > void bar (const char *, ...) __attribute__((format(printf, 1, 2)));
>
> -Wformat-diag is internal to GCC and needs
On Thu, Jan 20, 2022 at 10:52:10AM -0700, Martin Sebor wrote:
> On 1/20/22 10:03, Jakub Jelinek wrote:
> > On Thu, Jan 20, 2022 at 09:56:59AM -0700, Martin Sebor wrote:
> > > > With normal -Wformat I see all expected warnings in:
> > > > char *foo (const char *) __attribute__((format_arg(1)));
> >
On Thu, Jan 20, 2022 at 01:13:45PM -0800, Palmer Dabbelt wrote:
> On Thu, 20 Jan 2022 02:45:53 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> > riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
> > due to some aggressive linker optimizations).
>
> I don't really understand the
Hi!
cond traps can be created during ce3 after reload (and e.g. PR103028
recently fixed some ce3 cond trap related bug, so I think often that
works fine and we shouldn't disable cond traps after RA altogether),
but it calls prepare_cmp_insn. This function can fail, so I don't
see why we couldn't
Hi!
A warning regression fix I'm about to post warns (and breaks bootstrap due
to that) on the following spot. Seems it is a copy and paste from
earlier code that mentions the %qD variable instead of talking about
unnamed temporary.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for t
Hi!
As can be seen on the testcase, GCC 11 no longer warns if the format
string is wrapped inside of ()s.
This regressed with r11-2457-gdf5cf47a978, which added
if (TREE_NO_WARNING (param)) return;
to check_function_arguments_recurse. That function is used with a callback
for two cases, for -Wfor
On Fri, Jan 21, 2022 at 08:16:11PM +0100, soeren--- via Gcc-patches wrote:
> gcc/ChangeLog:
>
> * common/config/s390/s390-common.c (s390_supports_split_stack):
> Only support split-stack on glibc targets.
> * config/i386/gnu-user-common.h (STACK_CHECK_STATIC_BUILTIN): Ditto.
>
On Fri, Jan 21, 2022 at 01:31:32PM -0800, H.J. Lu wrote:
> On Fri, Jan 21, 2022 at 09:18:41PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > On Fri, Jan 21, 2022 at 08:16:11PM +0100, soeren--- via Gcc-patches wrote:
> > > gcc/ChangeLog:
> > >
> > >
On Fri, Jan 21, 2022 at 01:57:57PM -0800, H.J. Lu wrote:
> Revert x86 changes in
>
> commit c163647ffbc9a20c8feb6e079dbecccfe016c82e
> Author: Soren Tempel
> Date: Fri Jan 21 19:22:46 2022 +
>
> Disable -fsplit-stack support on non-glibc targets
>
> and change ix86_supports_split_stac
Hi!
The following patch is infrastructure support for at least 3 different
options that need changes:
1) PR104158 talks about a regression with the -fsanitizer-coverage=
option; in GCC 11 and older and on trunk prior to r12-1177, this
option behaved similarly to -f{,no-}sanitizer{,-recover}=
Hi!
This is incremental patch to fix up -fsanitize-coverage= option
handling, allow -fno-sanitize-coverage= again, allow both
options together in one option or make
-fsanitize-coverage=trace-pc -fsanitize-coverage=trace-cmp
actually enable both suboptions rather than the last one.
Bootstrapped/re
Hi!
This patch on top of the previously posted option handling changes patch
allows specifying -fconvert=swap,r16_ieee etc. (but will error on it
when not on powerpc64le because in the library such swapping is only
implemented for HAVE_REAL_17).
Bootstrapped/regtested on x86_64-linux and i686-lin
On Sat, Jan 22, 2022 at 04:33:08PM +0800, Xi Ruoyao via Gcc-patches wrote:
> On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:
> > +$(srcdir)/config/loongarch/loongarch.opt: \
> > + $(srcdir)/config/loongarch/genopts/genstr.sh \
> > + $(srcdir)/config/loongarch/genopts/loongarch.opt
On Sat, Jan 22, 2022 at 05:05:00PM +0800, Xi Ruoyao wrote:
> On Sat, 2022-01-22 at 16:56 +0800, 程璐璐 wrote:
>
> > Under the MIPS architecture, *.opt files are also generated in
> > $(srcdir).
>
> Well, but then you should put the commands for generating those files
> into contrib/gcc_update instea
On Sat, Jan 22, 2022 at 10:32:21AM +0100, Martin Liška wrote:
> Hello.
>
> I've just noticed the patch broke a few cross compilers:
>
> s390x-ibm-tpf:
>
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/s390/s390-common.cc:
> In function ‘bool s390_supports_split_stack(boo
Hi!
With --disable-plugin, bootstrap fails on x86_64-linux or probably
all other targets with:
../../gcc/opts-global.cc: In function ‘void handle_common_deferred_options()’:
../../gcc/opts-global.cc:420:62: error: unquoted option name ‘--enable-plugin’
in format [-Werror=format-diag]
420 |
On Sat, Jan 22, 2022 at 10:32:21AM +0100, Martin Liška wrote:
> I've just noticed the patch broke a few cross compilers:
>
> s390x-ibm-tpf:
>
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/s390/s390-common.cc:
> In function ‘bool s390_supports_split_stack(bool, gcc_optio
On Sat, Jan 22, 2022 at 01:16:38PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Actually, I suspect we either need something like following patch,
> or need to change gcc/config/{linux,rs6000/linux{,64},alpha/linux}.h
> so that next to those OPTION_GLIBC etc. macros it also defines vers
On Sun, Jan 23, 2022 at 10:06:24AM +0100, Uros Bizjak wrote:
> > 2022-01-22 Jakub Jelinek
> >
> > * config/linux.h (OPTION_GLIBC_P, OPTION_UCLIBC_P,
> > OPTION_BIONIC_P, OPTION_MUSL_P): Define.
> > (OPTION_GLIBC, OPTION_UCLIBC, OPTION_BIONIC, OPTION_MUSL): Redefine
> >
On Sat, Jan 22, 2022 at 01:47:08AM +0100, Jakub Jelinek via Gcc-patches wrote:
> I think with the 2) patch I achieve what we want for Fortran, for 1)
> the only behavior from gcc 11 is that
> -fsanitize-coverage=trace-cmp,trace-cmp is now rejected.
> This is mainly from the desire
On Sat, Jan 22, 2022 at 07:03:48PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Sat, Jan 22, 2022 at 01:16:38PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > Actually, I suspect we either need something like following patch,
> > or need to change gcc/config/{linux,rs6000/l
On Mon, Jan 24, 2022 at 11:17:00AM +0100, Richard Biener wrote:
> > I think with the 2) patch I achieve what we want for Fortran, for 1)
> > the only behavior from gcc 11 is that
> > -fsanitize-coverage=trace-cmp,trace-cmp is now rejected.
>
> But -fsanitize-coverage=trace-cmp -fsanitize-coverage=
On Mon, Jan 24, 2022 at 12:28:53PM +0100, Martin Liška wrote:
> The patch is about FORBIDDEN_FILES that we don't want to be commited.
> So far we have $root/Makefile.am and $root/build.log.
>
> Do you have any other candidates?
I think it shouldn't be about blacklisting all the mistakes from the
On Mon, Jan 24, 2022 at 01:06:25PM +0100, Martin Liška wrote:
> Makes sense, implemented in the attached patch.
>
> Ready to be installed?
LGTM.
> From 55e9774ba91e0acf12102d7c595482c29d5397cb Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Mon, 24 Jan 2022 13:03:01 +0100
> Subject: [PATC
Hi!
In GCC 7.x and earlier, while it had -mabi=ieeelongdouble option, that option
was undocumented and unsupported.
In GCC 8.1 that option got documented and -mabi=ieeelongdouble long double
started
to be mangled as U10__float128.
In GCC 9 and backported to before 8.2 release, that mangling chang
Hi!
As mentioned in the PR, we emit the same
.uleb128 0x3 # (DIE (0x42) DW_TAG_base_type)
.byte 0x10 # DW_AT_byte_size
.byte 0x4 # DW_AT_encoding
.4byte .LASF2 # DW_AT_name: "long double"
(0x4 is DW_ATE_float) whether we on powerpc64le-linux use
On Mon, Jan 24, 2022 at 08:55:37AM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jan 13, 2022 at 02:08:53PM -0300, Raoni Fassina Firmino wrote:
> > Changes since v8[8]:
> > - Refactored and expanded builtin-feclearexcept-feraiseexcept-2.c
> > testcase:
> > + Use a macro to avoid ext
On Mon, Jan 24, 2022 at 11:14:41PM +0100, Mark Wielaard wrote:
> On Mon, Jan 24, 2022 at 08:34:39PM +0100, Jakub Jelinek wrote:
> > The following patch uses DW_ATE_GNU_{,complex_}float128 (new extensions
> > equal to corresponding HP extensions) instead of DW_ATE_float,
> > another possibility woul
On Mon, Jan 24, 2022 at 06:24:11PM -0300, Raoni Fassina Firmino wrote:
> On Mon, Jan 24, 2022 at 02:29:39PM -0600, Bill Schmidt wrote:
> > Adding the patch author for his information.
>
> Thanks Bill.
>
> > On 1/24/22 2:26 PM, Jakub Jelin
On Mon, Jan 24, 2022 at 05:36:58PM -0500, Marek Polacek wrote:
> The implementation is done by using the new EnumSet feature.
>
> PR preprocessor/104030
>
> gcc/c-family/ChangeLog:
>
> * c.opt (Wbidi-chars): Mark as EnumSet. Also accept =ucn.
>
> gcc/ChangeLog:
>
> * doc/inv
On Mon, Jan 24, 2022 at 11:26:27PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Yet another short term solution might be not use DW_TAG_base_type
> for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef
> with DW_AT_name "long double" to __float128 DW_TAG_bas
On Mon, Jan 24, 2022 at 06:11:22PM +0100, Florian Weimer via Gcc-patches wrote:
> _dl_find_object returns success even if no unwind information has been
> found, and dlfo_eh_frame is NULL.
>
> libgcc/ChangeLog:
>
> PR libgcc/104207
> * unwind-dw2-fde-dip.c (_Unwind_Find_FDE): Add NULL
On Mon, Jan 17, 2022 at 12:11:59AM +0100, FX via Gcc-patches wrote:
> This patch is the third in my “signaling NaN” series. For targets with IEEE
> support but without the issignaling macro in libc (i.e., everywhere except
> glibc), this allows us to provide a fallback implementation. In order to
On Tue, Jan 25, 2022 at 01:28:29PM -0300, Raoni Fassina Firmino wrote:
> Below is a patch to do just that. In preliminary tests it seems to work.
> What do you think aboud it Jakub?
Ok for trunk.
> > These days the usual way of doing this is through
> > maybe_expand_insn and create_{output,input}
On Tue, Jan 25, 2022 at 02:24:34PM -0500, Jason Merrill wrote:
> > + machine_mode mode, fmode;
> > + if (TREE_CODE (type) == COMPLEX_TYPE)
> > +mode = TYPE_MODE (TREE_TYPE (type));
> > + else
> > +mode = TYPE_MODE (type);
> > + if (known_eq (GET_MODE_SIZE (mode), 16) && !MODE_COMPOSITE_
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
__builtin_shuffle
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:
> > >
> > > (
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 adjusted
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
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')
> https://gcc.gnu.org/r12-6641-g450c85b81f4dd67bf6211d307afdc0f3c07
Hi!
As mentioned in the PR, reassoc1 miscompiles following testcase.
We have:
if (a.1_1 >= 0)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 440234144]:
_3 = -2147483647 - a.1_1;
_9 = a.1_1 != -2147479551;
_4 = _3 == 1;
_8 = _4 | _9;
if (_8 != 0)
goto ; [34.51%]
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-1742098): New command-line
> option.
> (mfix-cortex-a72-aes-1655431): New option alias.
> --- a/gcc/config/arm/arm.opt
> +++ b/gcc/co
On Thu, Jan 27, 2022 at 04:00:01PM +0530, Siddhesh Poyarekar wrote:
> Signed-off-by: Siddhesh Poyarekar
> ---
> htdocs/gcc-12/changes.html | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index c69b301e..c6baee75 100644
> --- a/
On Thu, Jan 27, 2022 at 11:37:29AM +0100, Martin Liška wrote:
> @@ -665,12 +667,12 @@ diagnostic_action_after_output (diagnostic_context
> *context,
> if (context->abort_on_error)
> real_abort ();
> - fnotice (stderr, "Please submit a full bug report,\n"
> - "with pr
On Thu, Jan 27, 2022 at 11:59:51AM +0100, Martin Liška wrote:
> @@ -1988,7 +1994,7 @@ error_recursion (diagnostic_context *context)
> pp_newline_and_flush (context->printer);
>
>fnotice (stderr,
> -"Internal compiler error: Error reporting routines re-entered.\n");
> +"in
On Thu, Jan 27, 2022 at 12:38:47PM +0100, Martin Liška wrote:
> Yep, we have many more examples where a leading capital letter is used:
>
> gcc/config/cris/cris.cc: internal_error ("MULT case in %");
> gcc/config/cris/cris.h: do { if (!(x)) internal_error ("CRIS-port assertion
> failed: %s",
On Thu, Jan 27, 2022 at 04:06:05PM +0100, Martin Liška wrote:
> I've finished Martin's work and put the 2 aliases into files. The
> git-undescr.sh is basically
> unchanged, while I added better option parsing for git-descr.sh script so
> that it supports:
>
> $ git gcc-descr
> r12-6895-g14f33989
On Thu, Jan 27, 2022 at 07:29:20PM +0100, Martin Liška wrote:
> I would like to support:
>
> $ git gcc-undescr `git gcc-descr`
> 9cbfbe2497c0117b0598e35658248bc723c0b931
>
> Which is done in the patch.
>
> Ready to be installed?
> Thanks,
> Martin
>
> contrib/ChangeLog:
>
> * git-undescr
Hi!
The testcase in the PR (not included for the testsuite because we don't
have an (easy) way to -fcompare-debug LTO, we'd need 2 compilations/linking,
one with -g and one with -g0 and -fdump-rtl-final= at the end of lto1
and compare that) has different code generation for -g vs. -g0.
The differ
On Fri, Jan 28, 2022 at 11:29:38AM +0100, Richard Biener wrote:
> This removes a premature optimization from
> gimple_purge_dead_abnormal_call_edges which, after eliding the
> last setjmp (or computed goto) statement from a function and
> thus clearing cfun->calls_setjmp, leaves us with the abnorma
On Fri, Jan 28, 2022 at 12:04:00PM +0100, Richard Biener wrote:
> Still I think assuming there are no abnormal edges when neither
> of the flag is set is premature (as can be seen here). I also
> don't think what we do in the function is very timing critical,
> but sure, we walk all successor edge
On Thu, Jan 27, 2022 at 01:40:15PM +0100, Martin Liška wrote:
> That's follow up patch based on the discussion with Jakub.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * config/rs6000/host-darwin.cc (segv_crash_handler):
> Do not use leading capital letter.
>
Hi!
As mentioned in the PRthe following testcase fails, because the last
stmt of a bb with -g is a debug stmt and get_status_for_store_merging
uses gimple_seq_last_stmt (bb_seq (bb)) when testing if it is valid
for store merging. The debug stmt isn't valid, while a stmt at that
position with -g0
Hi!
On Fri, Jan 28, 2022 at 11:38:23AM -0700, Jeff Law wrote:
> Thanks. Given the original submission and most of the review work was done
> prior to stage3 closing, I went ahead and installed this on the trunk.
Unfortunately this breaks quite a lot of things.
The main problem is that GIMPLE all
Hi!
This test fails everywhere, because ? doesn't match literal ?.
It should use \\? instead. I've also changed those .s in there.
Tested on x86_64-linux (-m32/-m64) and powerpc64le-linux, ok for trunk?
2022-01-29 Jakub Jelinek
PR tree-optimization/95424
* gcc.dg/tree-ssa/div
On Fri, Jan 28, 2022 at 03:14:16PM -0700, Jeff Law via Gcc-patches wrote:
> > This patch will add the missed pattern described in bug 103514 [1] to the
> > match.pd. [1] includes proof of correctness for the patch too.
> >
> > PR tree-optimization/103514
> > * match.pd (a & b) ^ (a == b) -> !
On Sun, Jan 30, 2022 at 10:16:44AM +, Navid Rahimi via Gcc-patches wrote:
> Thanks Jakob for the correction. Sadly, I didn’t have any access to any non
> x86 architecture. But x86 was fully tested and there was no regression.
>
> In my spare time I will look at implementation of this for shor
Hi!
As reported by Martin, while David has added OPTION_GLIBC define to aix
and Iain to darwin, all the other non-linux targets now fail because
rs6000.md macro isn't defined.
One possibility is to define this macro in option-defaults.h which on rs6000
targets is included last, then we don't need
Hi!
As mentioned in the PR, in some cases we preprocess incorrectly when we
encounter an identifier which is defined as function-like macro, followed
by at least 2 CPP_PADDING tokens and then some other identifier.
On the following testcase, the problem is in the 3rd funlike_invocation_p,
the toke
On Mon, Jan 31, 2022 at 05:12:23PM -0500, Jason Merrill wrote:
> > --- libcpp/macro.cc.jj 2022-01-18 11:59:00.277972128 +0100
> > +++ libcpp/macro.cc 2022-01-31 15:44:49.208847524 +0100
> > @@ -1374,7 +1374,9 @@ funlike_invocation_p (cpp_reader *pfile,
> > if (token->type != CPP_PADDIN
On Wed, Jan 26, 2022 at 06:16:34PM -0500, Jason Merrill via Gcc-patches wrote:
> 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
> de
On Tue, Feb 01, 2022 at 08:20:39AM +0100, Tom de Vries wrote:
> [libgomp, testsuite] Reduce recursion depth in declare_target-*.f90
>
> libgomp/ChangeLog:
>
> 2022-01-27 Tom de Vries
>
> * testsuite/libgomp.fortran/examples-4/declare_target-1.f90: Reduce
> recursion depth.
>
On Tue, Feb 01, 2022 at 12:28:57AM +0100, Jakub Jelinek via Gcc-patches wrote:
> I haven't, but will do so now.
So, I've done another bootstrap/regtest with incremental
--- gcc/c-family/c-lex.cc.jj2022-01-18 00:18:02.558747051 +0100
+++ gcc/c-family/c-lex.cc 202
Hi!
The following testcase fails -fcompare-debug, because expand_vector_comparison
since r11-1786-g1ac9258cca8030745d3c0b8f63186f0adf0ebc27 sets
vec_cond_expr_only when it sees some use other than VEC_COND_EXPR that uses
the lhs in its condition.
Obviously we should ignore debug stmts when doing s
On Tue, Feb 01, 2022 at 10:29:03AM +0100, Richard Biener wrote:
> So I think it's all fine besides the handling of VEC_COND_EXPRs where
> the use is in rhs1 and rhs2 and/or rhs3 - I don't really understand
> your worry here but shouldn't the stmt end up on the vector at least
> once? You can use g
On Fri, Jan 28, 2022 at 10:47:06PM -0500, Michael Meissner via Gcc-patches
wrote:
> 2022-01-28 Michael Meissner
>
> gcc/
> PR target/104253
> * config/rs6000/rs6000.cc (init_float128_ibm): Use the TF names
> for builtin conversions between __ibm128 and DImode when long
>
Hi!
As mentioned in the PR and as can be seen on:
--- gcc/testsuite/gcc.dg/pch/pr104323-1.c.jj2022-02-01 13:06:00.163192414
+0100
+++ gcc/testsuite/gcc.dg/pch/pr104323-1.c 2022-02-01 13:13:41.226712735
+0100
@@ -0,0 +1,16 @@
+/* PR target/104323 */
+/* { dg-require-effective-target pow
On Tue, Feb 01, 2022 at 10:03:57AM +0100, Jakub Jelinek via Gcc-patches wrote:
> I wonder if we shouldn't replace that
> toks[0] = pfile->directive_result;
> line with
> toks[0] = pfile->avoid_paste;
> or even replace those
> toks = XNEW (cpp_to
On Wed, Feb 02, 2022 at 09:19:03AM +0100, Marcel Vollweiler wrote:
> gcc/c-family/ChangeLog:
>
> * c-omp.cc (c_omp_split_clauses): Added OMP_CLAUSE_HAS_DEVICE_ADDR case.
> * c-pragma.h (enum pragma_kind): Added 5.1 in comment.
> (enum pragma_omp_clause): Added PRAGMA_OMP_CLAUSE_H
On Wed, Feb 02, 2022 at 03:42:48PM +0100, 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 occupied it.
> The dangling pointer diagnostics us
On Wed, Feb 02, 2022 at 01:23:44PM -0700, Jeff Law via Gcc-patches wrote:
> Note that I think something similar may be needed to mark EOL for the
> pointer passed to realloc to fix a related set of false positives for code
> like this
>
> bool something = p != q;
> whatever = realloc (p, newsi
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 it was doing weird things if either
some of 1, 3 or 4
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
1101 - 1200 of 4686 matches
Mail list logo
