[PATCH] c++: Distinguish btw. alignof and __alignof__ in cp_tree_equal [PR97273]

cp_tree_equal currently considers alignof the same as __alignof__, but these operators are semantically different ever since r8-7957. In the testcase below, this causes the second static_assert to fail on targets where alignof(double) != __alignof__(double) because the specialization cache (which

Re: [PATCH v2] builtins: rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

Please excuse a comment from the gallery: On Mon, 28 Sep 2020, will schmidt via Gcc-patches wrote: > On Fri, 2020-09-04 at 12:52 -0300, Raoni Fassina Firmino via Gcc-patches > wrote: > > 2020-08-13 Raoni Fassina Firmino > > > > gcc/ChangeLog: > > * config/rs6000/rs6000.md

Re: [PATCH] libstdc++: Diagnose visitors with different return types [PR95904]

On Sat, 3 Oct 2020 at 01:14, Jonathan Wakely wrote: > OK for trunk with those leading spaces switched to tab. The patch is borked, doesn't pass tests, fixing...

RE: This is my patch for fstream to fix the performance issue on Windows.

In general yes. Of course 64k would be the optimal value for buffer size for both windows and linux. However, I think iostream is an old thing. Setting it as optimal value might create compatibility issues. Yes. This patch is good. Sent from

Re: [PATCH] options: Save and restore opts_set for Optimization and Target options

On Sun, Oct 04, 2020 at 09:13:29AM +0200, Andreas Schwab wrote: > This breaks ia64: > > In file included from ./tm.h:23, > from ../../gcc/gencheck.c:23: > ./options.h:7816:40: error: ISO C++ forbids zero-size array 'explicit_mask' > [-Werror=pedantic] > 7816 | unsigned

Re: [PATCH] PR fortran/97272 - Wrong answer from MAXLOC with character arg

Hi FX, > While this is fresh in your memory, could I suggest you have a look at this > FINDLOC issue, which seems possibly related: > https://gcc.gnu.org/pipermail/fortran/2020-September/055016.html > and further messages from Thomas Koenig? I briefly checked this, but the issue with FINDLOC

Re: [r11-3641 Regression] FAIL: gcc.dg/torture/pta-ptrarith-1.c -Os scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}" on Linux/x86_64 (-m32 -march=cascadelake)

> > > > > > A number of people routinely send emails similar to these to this > > > list to point out regressions on their targets. I find both kinds > > > of emails very useful and don't mind the additional traffic. > > > > > > What would be an improvement is sending just one email for all > > >

Re: [r11-3641 Regression] FAIL: gcc.dg/torture/pta-ptrarith-1.c -Os scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}" on Linux/x86_64 (-m32 -march=cascadelake)

On Sun, Oct 4, 2020 at 10:41 AM H.J. Lu via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > On Sun, Oct 4, 2020 at 10:33 AM Martin Sebor wrote: > > > > On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote: > > > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool > > > wrote: > > >> > > >> On Sat,

Re: [r11-3641 Regression] FAIL: gcc.dg/torture/pta-ptrarith-1.c -Os scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}" on Linux/x86_64 (-m32 -march=cascadelake)

On Sun, Oct 4, 2020 at 10:33 AM Martin Sebor wrote: > > On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote: > > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool > > wrote: > >> > >> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches > >> wrote: > >>> On Linux/x86_64, >

Re: [r11-3641 Regression] FAIL: gcc.dg/torture/pta-ptrarith-1.c -Os scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}" on Linux/x86_64 (-m32 -march=cascadelake)

On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote: On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool wrote: On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote: On Linux/x86_64, c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit commit

Re: [r11-3641 Regression] FAIL: gcc.dg/torture/pta-ptrarith-1.c -Os scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}" on Linux/x86_64 (-m32 -march=cascadelake)

On Sun, Oct 4, 2020 at 10:03 AM Iain Sandoe wrote: > > H.J. Lu via Gcc-patches wrote: > > > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool > > wrote: > >> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches > >> wrote: > >>> On Linux/x86_64, > >>> > >>>

Re: [r11-3641 Regression] FAIL: gcc.dg/torture/pta-ptrarith-1.c -Os scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}" on Linux/x86_64 (-m32 -march=cascadelake)

H.J. Lu via Gcc-patches wrote: On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool wrote: On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote: On Linux/x86_64, c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit commit

Re: [r11-3641 Regression] FAIL: gcc.dg/torture/pta-ptrarith-1.c -Os scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}" on Linux/x86_64 (-m32 -march=cascadelake)

On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool wrote: > > On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches > wrote: > > On Linux/x86_64, > > > > c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit > > commit c34db4b6f8a5d80367c709309f9b00cb32630054 > >

Re: [PATCH] calls.c:can_implement_as_sibling_call_p REG_PARM_STACK_SPACE check

Hi Segher, On Fri, Oct 02, 2020 at 01:50:24PM -0500, Segher Boessenkool wrote: > On Fri, Oct 02, 2020 at 04:41:05PM +0930, Alan Modra wrote: > > This moves an #ifdef block of code from calls.c to > > targetm.function_ok_for_sibcall. Only two targets, x86 and rs6000, > > define

Re: [PATCH] PR fortran/97272 - Wrong answer from MAXLOC with character arg

Hello Harald, Slightly rewritten version of the patch, with the removal of the KIND argument from the argument list factored out: OK for master. I think it is also OK for backport as far as you want to. Best regards Thomas

Re: [PATCH] Fortran : ICE in gfc_validate_kind PR96099

Hi Mark, This is a follow up to PR95586 which fixed only the ICE that occurred when using derived types in an implicit statement.  The ICE occurred because an attempt was made to determine kind for types that do not have kinds. This patch ensures that kind is only determined for types that

Re: [Patch, fortran] PR/97045 A wrong column is selected when addressing individual elements of unlimited polymorphic dummy argument

Hi Paul, Regtests on FC31/x86_64 - OK for master? OK. You're quite right that trans-* is chock full of special-case handling (which I also found out, again, working together with Nicolas on the shared memory coarrays). Cleaning that up would be a worthwile job, although probably quite big

Re: [PATCH] PR fortran/97272 - Wrong answer from MAXLOC with character arg

Hi FX, While this is fresh in your memory, could I suggest you have a look at this FINDLOC issue, which seems possibly related: https://gcc.gnu.org/pipermail/fortran/2020-September/055016.html and further messages from Thomas Koenig? I am actually working on this again, having returned from

Re: [PATCH] PR fortran/97272 - Wrong answer from MAXLOC with character arg

Hi Harald, While this is fresh in your memory, could I suggest you have a look at this FINDLOC issue, which seems possibly related: https://gcc.gnu.org/pipermail/fortran/2020-September/055016.html and further messages from Thomas Koenig? Thanks, FX

Re: [PATCH] options: Save and restore opts_set for Optimization and Target options

cl_target_option' 7812 | struct GTY(()) cl_target_option |^~~~ $ diff -u gcc-2020100[34]/Build/gcc/options.h --- gcc-20201003/Build/gcc/options.h2020-10-03 04:50:58.0 +0200 +++ gcc-20201004/Build/gcc/options.h2020-10-04 04:25:18.0 +0200