Re: [PATCH] strlen: Return TODO_update_address_taken when memcmp has been optimized [PR96271]

On January 16, 2021 2:00:38 AM GMT+01:00, Jakub Jelinek wrote: >On Fri, Jan 15, 2021 at 10:02:41PM +0100, Jakub Jelinek via Gcc-patches >wrote: >> Like this? > >Bootstrapped/regtested successfully on x86_64-linux and i686-linux. OK. Thanks, Richard. >> 2021-01-15 Jakub Jelinek >> >>

Re: [PATCH] match.pd: Optimize ((cst << x) & 1) [PR96669]

On January 16, 2021 1:59:50 AM GMT+01:00, Jakub Jelinek wrote: >On Fri, Jan 15, 2021 at 09:21:07PM +0100, Richard Biener wrote: >> >BTW, I've tried to also fix what the PR wanted primarily by adding >> >/* Simplify (CST << x) & 1 to 0 if CST is even or to x == 0 if it is >> >odd. / >>

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 --- Comment #10 from Steve Kargl --- On Sat, Jan 16, 2021 at 04:48:09AM +, Bahram.shahrooz at uc dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 > > --- Comment #9 from Bahram.shahrooz at uc dot edu --- > Yes, thank you

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 --- Comment #9 from Bahram.shahrooz at uc dot edu --- Yes, thank you for finding this bug. Things didn't change after changing estart to estrt. Sorry, I don't know how to use -freal-init=nan. I tried to use it like this but got an error. %

[Bug tree-optimization/98703] New: Failure to optimize out non-zero check relative to multiplication overflow check

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98703 Bug ID: 98703 Summary: Failure to optimize out non-zero check relative to multiplication overflow check Product: gcc Version: 11.0 Status: UNCONFIRMED

[PATCH] libstdc++-v3: Add -fcf-protection=none to -march=i486

-fcf-protection is automatically enabled in libstdc++ on Linux/x86. Starting from commit 77d372abec0fbf2cfe922e3140ee3410248f979e Author: H.J. Lu Date: Thu Jan 14 05:56:46 2021 -0800 x86: Error on -fcf-protection with incompatible target GCC issues an error on -fcf-protection with

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 --- Comment #8 from Steve Kargl --- On Fri, Jan 15, 2021 at 05:21:22PM -0800, Steve Kargl wrote: > > You're using undefined variables. > I little more debugging, read(5,*) estrt,esfinal,eincr if(eincr.gt.0)

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 --- Comment #7 from Steve Kargl --- On Sat, Jan 16, 2021 at 12:51:38AM +, Bahram.shahrooz at uc dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 > > --- Comment #6 from Bahram.shahrooz at uc dot edu --- > I get wrong

Re: [PATCH] strlen: Return TODO_update_address_taken when memcmp has been optimized [PR96271]

On Fri, Jan 15, 2021 at 10:02:41PM +0100, Jakub Jelinek via Gcc-patches wrote: > Like this? Bootstrapped/regtested successfully on x86_64-linux and i686-linux. > 2021-01-15 Jakub Jelinek > > PR tree-optimization/96271 > * passes.def: Pass false argument to first two pass_cd_dce >

[PATCH] match.pd: Optimize ((cst << x) & 1) [PR96669]

On Fri, Jan 15, 2021 at 09:21:07PM +0100, Richard Biener wrote: > >BTW, I've tried to also fix what the PR wanted primarily by adding > >/* Simplify (CST << x) & 1 to 0 if CST is even or to x == 0 if it is > >odd. / > >(simplify > > (bit_and (lshift INTEGER_CST@1 @0) integer_onep) > > (if

[Bug middle-end/98702] New: linker failure with a very simple testing case for gcc10

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98702 Bug ID: 98702 Summary: linker failure with a very simple testing case for gcc10 Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal

[r11-6725 Regression] FAIL: g++.dg/modules/dep-2.C -std=c++2a scan-file \\n\\.PHONY: m\\\\:part\\.c\\+\\+m on Linux/x86_64

On Linux/x86_64, 1ba71fabb78b18884e9f479f45a257bab50e8959 is the first bad commit commit 1ba71fabb78b18884e9f479f45a257bab50e8959 Author: Nathan Sidwell Date: Fri Jan 15 06:47:13 2021 -0800 preprocessor: Make quoting : [PR 95253] caused FAIL: g++.dg/modules/dep-1_a.C -std=c++17

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 --- Comment #6 from Bahram.shahrooz at uc dot edu --- I get wrong answers doing this: gfortran FiberAnalysis.f -o FiberAnalysis I get correct answers doing this: gfortran FiberAnalysis.f -fcheck=all -ffpe-trap=zero,invalid -o FiberAnalysis

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 --- Comment #5 from Steve Kargl --- On Sat, Jan 16, 2021 at 12:41:56AM +, Bahram.shahrooz at uc dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 > > --- Comment #4 from Bahram.shahrooz at uc dot edu --- > I compiled with

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 --- Comment #4 from Bahram.shahrooz at uc dot edu --- I compiled with the suggested options (below) and now the code gives the same result as g77. -fcheck=all -ffpe-trap=zero,invalid Things look good now! Sorry for starting this bug report

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 --- Comment #3 from Bahram.shahrooz at uc dot edu --- Created attachment 49979 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49979=edit source code Sorry, I had to zip several files. Readme file in Archive.zip explains what the files are.

[Bug rtl-optimization/98692] Unitialized Values reported only with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 Segher Boessenkool changed: What|Removed |Added CC||acsawdey at gcc dot gnu.org ---

[Bug rtl-optimization/98692] Unitialized Values reported only with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #4 from Segher Boessenkool --- Are you sure that target is correct?!

[Bug d/98607] GDC merging computations but rounding mode has changed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607 --- Comment #9 from Marc Glisse --- Since I doubt gdc handles rounding modes correctly for scalars, I think you can ignore this issue in the implementation of the vector intrinsics for now (same as we do in C and C++). Note that gcc isn't alone

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2

Re: [PATCH, rs6000] Update pr88233.c test (pr91799)

Hi! On Thu, Jan 14, 2021 at 03:25:46PM -0600, will schmidt wrote: > This is a follow-up fix to clean up pr91799. Per review of test results, > it appears that the combination of target and dg-require stanzas is > not sufficient to properly limit the test to 64-bit only on darwin. > > This adds

gcc-9-20210115 is now available

Snapshot gcc-9-20210115 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20210115/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org ---

Re: [PATCH 1/2] nios2: Add -mcustom-fpu-cfg=fph2

On 1/15/21 2:27 PM, Sebastian Huber wrote: Hello Sandra, On 15/01/2021 20:12, Sandra Loosemore wrote: The following instructions supported by this component are not enabled by this option: * -mcustom-fmins * -mcustom-fmaxs * -mcustom-round The reason is that these instructions are only in

[patch] Reset force_source_line in final.c

Unlike the other global variables, it is not reset at the beginning of a function so can leak into the next one. Tested on x86-64/Linux, applied on the mainline as obvious. 2021-01-15 Eric Botcazou * final.c (final_start_function_1): Reset force_source_line. -- Eric Botcazoudiff

Re: [PATCH] PowerPC: Add float128/Decimal conversions.

On Thu, Jan 14, 2021 at 12:09:36PM -0500, Michael Meissner wrote: > [PATCH] PowerPC: Add float128/Decimal conversions. Same question here. Segher

Re: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.

Hi! On Thu, Jan 14, 2021 at 11:59:19AM -0500, Michael Meissner wrote: > >From 78435dee177447080434cdc08fc76b1029c7f576 Mon Sep 17 00:00:00 2001 > From: Michael Meissner > Date: Wed, 13 Jan 2021 21:47:03 -0500 > Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins. > > This patch

[Bug c++/96623] [11 Regression] ICE in inject_parm_decls, at cp/parser.c:23893

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96623 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED

Re: [PATCH][testsuite] (committed) Fix sed script errors in complex tests

On Jan 15, 2021, at 1:13 AM, Tamar Christina via Gcc-patches wrote: > I ran sed script late over the tests which accidentally > introduced a syntax error in the tests. > > This fixes it. > > Committed under the obvious rule. > > Ok for master? :-) Which is it? Anyway, Ok.

Re: [PATCH 1/2] nios2: Add -mcustom-fpu-cfg=fph2

Hello Sandra, On 15/01/2021 20:12, Sandra Loosemore wrote: The following instructions supported by this component are not enabled by this option: * -mcustom-fmins * -mcustom-fmaxs * -mcustom-round The reason is that these instructions are only in effect in combination with other options. If

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98538 --- Comment #8 from Marek Polacek --- (In reply to Nathan Sidwell from comment #5) > I don;t think your patch is quite right. the call afterwards is making the > assumption that DEPENDENT_TYPE_P is only ever set when > DEPENDENT_TYPE_P_VALID is

Re: [PATCH] strlen: Return TODO_update_address_taken when memcmp has been optimized [PR96271]

On Fri, Jan 15, 2021 at 09:31:10PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Fri, Jan 15, 2021 at 09:16:31PM +0100, Richard Biener wrote: > > >Apparently not. The passes after strlen1 are: > > >pr96271.c.191t.thread4 > > >pr96271.c.192t.vrp2 > > >pr96271.c.193t.copyprop5 > >

[Bug fortran/89891] [meta-bug] Accessing memory in rejected statements or expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891 Bug 89891 depends on bug 98661, which changed state. Bug 98661 Summary: Valgrind errors during error recovery of invalid derived type declarations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661 What|Removed

[Bug other/86656] [meta-bug] Issues found with -fsanitize=address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 98661, which changed state. Bug 98661 Summary: Valgrind errors during error recovery of invalid derived type declarations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661 What|Removed

[Bug fortran/98661] Valgrind errors during error recovery of invalid derived type declarations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug libgomp/98699] Reset OMP_NESTED to true if OMP_MAX_ACTIVE_LEVELS is > 1.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98699 anlauf at gcc dot gnu.org changed: What|Removed |Added Component|fortran |libgomp

[Bug fortran/98701] New: I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 Bug ID: 98701 Summary: I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98538 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98538 --- Comment #6 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:9beb6d88effdab4209beb8bc5e4b8773317f1d33 commit r11-6741-g9beb6d88effdab4209beb8bc5e4b8773317f1d33 Author: Nathan Sidwell Date:

[Bug preprocessor/95253] [10/11 Regression] Build failure on MSys. Wrong dependency file escaping on Windows.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95253 --- Comment #9 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:e1efa6af61ab54faf0d8d091328e0c6a1141050c commit r11-6740-ge1efa6af61ab54faf0d8d091328e0c6a1141050c Author: Nathan Sidwell Date:

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98538 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Nathan

Re: [PATCH] strlen: Return TODO_update_address_taken when memcmp has been optimized [PR96271]

On Fri, Jan 15, 2021 at 09:16:31PM +0100, Richard Biener wrote: > >Apparently not. The passes after strlen1 are: > >pr96271.c.191t.thread4 > >pr96271.c.192t.vrp2 > >pr96271.c.193t.copyprop5 > >pr96271.c.194t.wrestrict > >pr96271.c.195t.dse4 > >pr96271.c.196t.cddce3 > >pr96271.c.197t.forwprop4 >

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487 Federico Kircheis changed: What|Removed |Added CC||federico.kircheis at gmail dot com

Re: [PATCH] match.pd: Generalize the PR64309 simplifications [PR96669]

On January 15, 2021 9:03:58 PM GMT+01:00, Jakub Jelinek wrote: >On Fri, Jan 15, 2021 at 08:50:20PM +0100, Richard Biener wrote: >> On January 15, 2021 7:38:35 PM GMT+01:00, Jakub Jelinek > wrote: >> >Hi! >> > >> >The following patch generalizes the PR64309 simplifications, so that >> >instead >>

Re: [PATCH] strlen: Return TODO_update_address_taken when memcmp has been optimized [PR96271]

On January 15, 2021 8:57:39 PM GMT+01:00, Jakub Jelinek wrote: >On Fri, Jan 15, 2021 at 08:48:32PM +0100, Richard Biener wrote: >> On January 15, 2021 7:32:35 PM GMT+01:00, Jakub Jelinek > wrote: >> >Hi! >> > >> >On the following testcase, handle_builtin_memcmp in the strlen pass >> >folds >>

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96681, which changed state. Bug 96681 Summary: Failure to optimize xor of comparisons with specific constants to comparison of xor-ed of compared variables https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96681

[Bug tree-optimization/96681] Failure to optimize xor of comparisons with specific constants to comparison of xor-ed of compared variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96681 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug tree-optimization/96669] Failure to optimize shift by variable+and by 1 to test for 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96669 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0425f4c1b63107bf3bc4778d1fe53c91ace7838d commit r11-6739-g0425f4c1b63107bf3bc4778d1fe53c91ace7838d Author: Jakub Jelinek Date:

[Bug tree-optimization/96681] Failure to optimize xor of comparisons with specific constants to comparison of xor-ed of compared variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96681 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5c046034e3ea61dd68965154a398f8f813daf8f2 commit r11-6738-g5c046034e3ea61dd68965154a398f8f813daf8f2 Author: Jakub Jelinek Date:

Re: [PATCH] match.pd: Generalize the PR64309 simplifications [PR96669]

On Fri, Jan 15, 2021 at 08:50:20PM +0100, Richard Biener wrote: > On January 15, 2021 7:38:35 PM GMT+01:00, Jakub Jelinek > wrote: > >Hi! > > > >The following patch generalizes the PR64309 simplifications, so that > >instead > >of working only with constants 1 and 1 it works with any two power

Re: [PATCH] strlen: Return TODO_update_address_taken when memcmp has been optimized [PR96271]

On Fri, Jan 15, 2021 at 08:48:32PM +0100, Richard Biener wrote: > On January 15, 2021 7:32:35 PM GMT+01:00, Jakub Jelinek > wrote: > >Hi! > > > >On the following testcase, handle_builtin_memcmp in the strlen pass > >folds > >the memcmp into comparison of two MEM_REFs. But nothing triggers >

Re: [PATCH] match.pd: Generalize the PR64309 simplifications [PR96669]

On January 15, 2021 7:38:35 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >The following patch generalizes the PR64309 simplifications, so that >instead >of working only with constants 1 and 1 it works with any two power of >two >constants, and works also for right shift (in that case it rules out

[Bug c++/98062] [11 regression] Crash in type_as_string from plugin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98062 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED CC|

Re: [PATCH] match.pd: Optimize (x < 0) ^ (y < 0) to (x ^ y) < 0 etc. [PR96681]

On January 15, 2021 7:25:33 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >This patch simplifies comparisons that test the sign bit xored >together. >If the comparisons are both < 0 or both >= 0, then we should xor the >operands >together and compare the result to < 0, if the comparisons are

Re: [PATCH] strlen: Return TODO_update_address_taken when memcmp has been optimized [PR96271]

On January 15, 2021 7:32:35 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >On the following testcase, handle_builtin_memcmp in the strlen pass >folds >the memcmp into comparison of two MEM_REFs. But nothing triggers >updating >of addressable vars afterwards, so even when the parameters are no

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98538 --- Comment #4 from Marek Polacek --- Oops, I hadn't noticed that this PR has an assignee, since it's still in NEW. Anyway, this was my patch: --- a/gcc/cp/tree.c +++ b/gcc/cp/tree.c @@ -1341,7 +1341,9 @@ cp_build_qualified_type_real (tree

Re: Add dg-require-wchars to libstdc++ testsuite

On Fri, 15 Jan 2021, 16:19 Alexandre Oliva, wrote: > On Jan 15, 2021, Jonathan Wakely wrote: > > > On Thu, 14 Jan 2021, 22:22 Alexandre Oliva, wrote: > >> ... it is definitely the case that the target currently defines wchar_t, > >> and it even offers wchar.h and a lot of (maybe all?) wcs*

[Bug c++/98624] UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98624 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED

c++: Fix qualified array-type construction [PR 98538]

This was an assert that was too picky. The reason I had to alter array construction was that on stream in, we cannot dynamically determine a type's dependentness. Thus on stream out of the 'problematic' types, we save the dependentness for reconstruction. Fortunately the paths into

Re: preprocessor: Make quoting : [PR 95253]

I missed some testsuite fall out with my patch to fix mkdeps file mangling. PR preprocessor/95253 gcc/testsuite/ * g++.dg/modules/dep-1_a.C: Adjust expected output. * g++.dg/modules/dep-1_b.C: Likewise. * g++.dg/modules/dep-2.C: Likewise. --

[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #13 from Marius Hillenbrand --- gnat applies different choices for the calling convention on x86 and s390 for Get_Next_Interp. though, by massaging gcc/ada/sem_type.ads, I got them to produce the same GIMPLE. while compiling

Re: [patch] gcc.dg/analyzer tests: relax dependency on alloca.h

On Jan 15, 2021, David Malcolm wrote: > I think an issue here was that I assumed check_effective_target_alloca > checks that "alloca" is supported, whereas I now see that I was wrong; > it actually checks for "__builtin_alloca". Yeah, it's a little misleading. And it only tests

Re: Erroneous results from gfortran

Hello Professor, Shahrooz, Bahram (shahrobm) via Gcc wrote: I’ve used gfortran to compile a program on Mac Big Sur using gcc-10.2 and on Windows 10 using g77. I’ve used -o0 for both cases. The results for identical input values are vastly different between the two executables and

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

Hello, Martin, Our testing detected unexpected -dumpbase-ext options making to the producer string. I tracked it down to something weird that happened in this patch: On Dec 4, 2020, Martin Liška wrote: > +++ b/gcc/dwarf2out.c > - case OPT_dumpbase: > - case OPT_dumpbase_ext: > -

Re: [PATCH 2/2] RTEMS: Add -mcustom-fpu-cfg=fph2 multilib

On 1/14/21 12:16 PM, Sebastian Huber wrote: This multilib supports Nios II configurations with the "Nios II Floating Point Hardware 2 Component". gcc/ * config/nios2/t-rtems: Reset all MULTILIB_* variables. Shorten multilib directory names. Use MULTILIB_REQUIRED instead of

[Bug c++/98642] [10/11 Regression] wrong "use of deleted function" error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98642 --- Comment #3 from Jason Merrill --- Created attachment 49977 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49977=edit possible patch to elide more copies This implements a suggestion I made in

Re: [PATCH 1/2] nios2: Add -mcustom-fpu-cfg=fph2

On 1/14/21 12:16 PM, Sebastian Huber wrote: The new -mcustom-fpu-cfg=fph2 option variant is useful to build a multilib for the "Nios II Floating Point Hardware 2 Component": https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_nios2_custom_instruction.pdf Directly

Erroneous results from gfortran

Hello, I’ve used gfortran to compile a program on Mac Big Sur using gcc-10.2 and on Windows 10 using g77. I’ve used -o0 for both cases. The results for identical input values are vastly different between the two executables and wrong from gfortran. I’m not sure if there’s a big in gfortran

Re: [PATCH] Add a new pattern in 4-insn combine

On Mon, Nov 30, 2020 at 11:08:22AM +0800, HAO CHEN GUI wrote: >   This patch adds a new pattern(combine 4 insns to 3 insns) in 4-insn > combine. In the patch, newpat is split twice. The newpat, newi2pat and As I said before, that has a lot of problems, and is only suitable for stage 1 (after

[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707 Jason Merrill changed: What|Removed |Added Known to work||11.0 Known to fail|11.0

[Bug c++/98642] [10/11 Regression] wrong "use of deleted function" error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98642 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:d75199f782348bfc401f925b60f33ffc9822b7cc commit r11-6736-gd75199f782348bfc401f925b60f33ffc9822b7cc Author: Jason Merrill Date:

[pushed] c++: Improve copy elision for base subobjects [PR98642]

Three patches: 1) Rewrite a complete constructor call to call a base constructor if we're eliding a copy into a base subobject. 2) Elide the copy from a prvalue built for list-initialization into a base subobject. 3) Elide other copies from prvalues representing a constructor call into base

Re: [PATCH v5] rs6000, vector integer multiply/divide/modulo instructions

Hi! On Wed, Jan 13, 2021 at 02:15:04PM -0800, Carl Love wrote: > The patch was compiled and tested on: > >powerpc64le-unknown-linux-gnu (Power 8 BE) (I assume you mean powerpc64-linux instead?) > > Presumably it is safe (no side affects) when adding V4SI and V2DI here, > > with respect to

[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707 --- Comment #17 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:cd09079cfd50d289cbb05eadb728a0713f6bae8a commit r11-6733-gcd09079cfd50d289cbb05eadb728a0713f6bae8a Author: Jason Merrill Date:

[pushed] c++: Fix list-init of array of no-copy type [PR63707]

build_vec_init_elt models initialization from some arbitrary object of the type, i.e. copy, but in the case of list-initialization we don't do a copy from the elements, we initialize them directly. Tested x86_64-pc-linux-gnu, applying to trunk. And 9/10, soon. gcc/cp/ChangeLog: PR

[PATCH] match.pd: Generalize the PR64309 simplifications [PR96669]

Hi! The following patch generalizes the PR64309 simplifications, so that instead of working only with constants 1 and 1 it works with any two power of two constants, and works also for right shift (in that case it rules out the first one being negative, as it is arithmetic shift then).

[PATCH] strlen: Return TODO_update_address_taken when memcmp has been optimized [PR96271]

Hi! On the following testcase, handle_builtin_memcmp in the strlen pass folds the memcmp into comparison of two MEM_REFs. But nothing triggers updating of addressable vars afterwards, so even when the parameters are no longer address taken, we force the parameters to stack and back anyway. The

[Bug target/97847] [11 Regression] ICE in insert_insn_on_edge, at cfgrtl.c:1976

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847 --- Comment #6 from Vladimir Makarov --- I've reproduced the bug too. The fix will be on the next week.

[committed] bootstrap: fix failing diagnostic selftest on Windows [PR98696]

In one of the selftests in g:f10960558540636800cf5d3d6355969621fbc17e I didn't consider that paths can contain backslashes, which happens for the tempfiles on Windows hosts. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Confirmed by the reporter as fixing the issue on Windows.

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96671, which changed state. Bug 96671 Summary: Failure to optimize a 3 xor+and pattern to xor+andnot https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96671 What|Removed |Added

[Bug tree-optimization/96671] Failure to optimize a 3 xor+and pattern to xor+andnot

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96671 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[committed] testsuite: Add testcase coverage for already fixed [PR96671]

Hi! The fix for this PR didn't come with any test coverage, I've added tests that make sure we optimize it no matter what order of the x ^ y ^ z operands is used. Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk. 2021-01-15 Jakub Jelinek PR

[Bug bootstrap/98696] [11 Regression] ICE when build x86_64-elf-cross compiler with MinGW-w64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98696 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug tree-optimization/96671] Failure to optimize a 3 xor+and pattern to xor+andnot

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96671 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:aaec739250b1b148f7db5aa86719fe76645efc06 commit r11-6731-gaaec739250b1b148f7db5aa86719fe76645efc06 Author: Jakub Jelinek Date:

[Bug c++/98700] New: Infinite stream of error messages from bad concept code

(C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. and g++ (GCC) 11.0.0 20210115 (experimental) Copyright © 2021 Free Software Foundation, Inc. This is free

[Bug bootstrap/98696] [11 Regression] ICE when build x86_64-elf-cross compiler with MinGW-w64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98696 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:a3128bf01289a243a9e0ebb4e34c23bcb04cb938 commit r11-6730-ga3128bf01289a243a9e0ebb4e34c23bcb04cb938 Author: David Malcolm Date:

[PATCH] match.pd: Optimize (x < 0) ^ (y < 0) to (x ^ y) < 0 etc. [PR96681]

Hi! This patch simplifies comparisons that test the sign bit xored together. If the comparisons are both < 0 or both >= 0, then we should xor the operands together and compare the result to < 0, if the comparisons are different, we should compare to >= 0. Bootstrapped/regtested on x86_64-linux

[Bug tree-optimization/98597] [11 Regression] ICE in print_mem_ref since r11-6508-gabb1b6058c09a7c0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98597 --- Comment #12 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:adb520606ce3e1e1f8aa8c5d0c59a5f3196fc545 commit r11-6729-gadb520606ce3e1e1f8aa8c5d0c59a5f3196fc545 Author: Jakub Jelinek Date:

[PATCH] aarch64: Implement vmlsl[_high]* intrinsics using builtins

Hi all, This patch reimplements some more intrinsics using RTL builtins in the straightforward way. Thankfully most of the RTL infrastructure is already in place for it. Bootstrapped and tested on aarch64-none-linux-gnu. Pushing to trunk. Thanks, Kyrill gcc/ *

Re: [PATCH 1/3] PowerPC: Add long double target-supports.

On Thu, 14 Jan 2021, Michael Meissner via Gcc-patches wrote: > +return [check_runtime_nocache ppc_long_double_ovveride_ibm128 { > +return [check_runtime_nocache ppc_long_double_ovveride_ieee128 { > +return [check_runtime_nocache ppc_long_double_ovveride_64bit { All these places

Re: [patch] gcc.dg/analyzer tests: relax dependency on alloca.h

On Fri, 2021-01-15 at 14:45 -0300, Alexandre Oliva wrote: > On Jan 15, 2021, Olivier Hainque wrote: > > > On 14 Jan 2021, at 22:13, Alexandre Oliva > > wrote: > > > Would you mind if I submitted an alternate patch to do so? > > Not at all, thanks for your feedback and for proposing > > an

[Bug bootstrap/98696] [11 Regression] ICE when build x86_64-elf-cross compiler with MinGW-w64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98696 --- Comment #4 from cqwrteur --- (In reply to David Malcolm from comment #3) > Created attachment 49976 [details] > Patch to fix the failing selftest > > Does the attached patch fix the build on Windows hosts? Thank you it is working now. You

Re: [PATCH] [WIP] openmp: Add OpenMP 5.0 task detach clause support

On Fri, Jan 15, 2021 at 04:58:25PM +, Kwok Cheung Yeung wrote: > On 15/01/2021 3:07 pm, Kwok Cheung Yeung wrote: > > I have tested bootstrapping on x86_64 (no offloading) with no issues, > > and running the libgomp testsuite with Nvidia offloading shows no > > regressions. I have also tested

[Bug target/98688] C++ modules support does not work on PowerPC with opaque MMA types vector_pair/vector_quad

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98688 --- Comment #3 from acsawdey at gcc dot gnu.org --- Yeah it's pretty clear that something needs to be output, as with that code I get an error like this: In module imported at mma-module-2.C:1:1: mma_foo0: In function ‘int bar(__vector_quad*,

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

> On Jan 15, 2021, at 11:22 AM, Richard Biener wrote: > > On January 15, 2021 5:16:40 PM GMT+01:00, Qing Zhao > wrote: >> >> >>> On Jan 15, 2021, at 2:11 AM, Richard Biener >> wrote: >>> >>> >>> >>> On Thu, 14 Jan 2021, Qing Zhao wrote: >>> Hi,

Re: [patch] gcc.dg/analyzer tests: relax dependency on alloca.h

On Jan 15, 2021, Olivier Hainque wrote: > On 14 Jan 2021, at 22:13, Alexandre Oliva wrote: >> Would you mind if I submitted an alternate patch to do so? > Not at all, thanks for your feedback and for proposing > an alternative! Here's the modified patch. Regstrapped on x86_64-linux-gnu,

[Bug c++/98682] g++ allows goto inside statement expr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98682 --- Comment #1 from Andrew Pinski --- I think this is a dup of bug 772.

[Bug target/98694] [11 Regression] GCC produces incorrect code for loops with -O3 for skylake-avx512 and icelake-server

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98694 --- Comment #6 from Hongtao.liu --- (In reply to Hongtao.liu from comment #5) > and rewritten pattern > (define_insn "*vec_dupv4hi" > [(set (match_operand:V4HI 0 "register_operand" "=y,xYw") > (vec_duplicate:V4HI >

Re: [PATCH]AArch64: Add NEON, SVE and SVE2 RTL patterns for Multiply, FMS and FMA.

Tamar Christina writes: > Hi All, > > This adds implementation for the optabs for complex operations. With this the > following C code: > > void g (float complex a[restrict N], float complex b[restrict N], > float complex c[restrict N]) > { > for (int i=0; i < N; i++) >

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

On January 15, 2021 5:16:40 PM GMT+01:00, Qing Zhao wrote: > > >> On Jan 15, 2021, at 2:11 AM, Richard Biener >wrote: >> >> >> >> On Thu, 14 Jan 2021, Qing Zhao wrote: >> >>> Hi, >>> More data on code size and compilation time with CPU2017: >>> Compilation time data: the numbers

  1   2   3   >