[r11-5267 Regression] FAIL: gfortran.dg/gomp/declare-target-4.f90 -O scan-tree-dump-times original "[\n\r][\n\r]f1" 1 on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

6692c400f207c68fb11b44182ae127856e8b9ad3 is the first bad commit
commit 6692c400f207c68fb11b44182ae127856e8b9ad3
Author: Martin Sebor 
Date:   Mon Nov 23 17:15:54 2020 -0700

Dump type attributes in dump_function_to_file.

caused

FAIL: gcc.dg/tree-ssa/pr23401.c scan-tree-dump-times gimple "int" 5
FAIL: gcc.dg/tree-ssa/pr27810.c scan-tree-dump-times gimple "int" 3
FAIL: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized " w?\\* " 9
FAIL: gfortran.dg/gomp/declare-target-4.f90   -O   scan-tree-dump-times 
original "__attribute__\\(\\(omp declare target 
\\(device_type\\(any\\)\\)\\)\\)[\n\r]f2" 1
FAIL: gfortran.dg/gomp/declare-target-4.f90   -O   scan-tree-dump-times 
original "__attribute__\\(\\(omp declare target 
\\(device_type\\(any\\)\\)\\)\\)[\n\r]f3" 1
FAIL: gfortran.dg/gomp/declare-target-4.f90   -O   scan-tree-dump-times 
original "__attribute__\\(\\(omp declare target 
\\(device_type\\(any\\)\\)\\)\\)[\n\r]s1" 1
FAIL: gfortran.dg/gomp/declare-target-4.f90   -O   scan-tree-dump-times 
original "__attribute__\\(\\(omp declare target 
\\(device_type\\(host\\)\\)\\)\\)[\n\r]f4" 1
FAIL: gfortran.dg/gomp/declare-target-4.f90   -O   scan-tree-dump-times 
original "__attribute__\\(\\(omp declare target 
\\(device_type\\(host\\)\\)\\)\\)[\n\r]s3" 1
FAIL: gfortran.dg/gomp/declare-target-4.f90   -O   scan-tree-dump-times 
original "__attribute__\\(\\(omp declare target 
\\(device_type\\(nohost\\)\\)\\)\\)[\n\r]f5" 1
FAIL: gfortran.dg/gomp/declare-target-4.f90   -O   scan-tree-dump-times 
original "__attribute__\\(\\(omp declare target 
\\(device_type\\(nohost\\)\\)\\)\\)[\n\r]s2" 1
FAIL: gfortran.dg/gomp/declare-target-4.f90   -O   scan-tree-dump-times 
original "[\n\r][\n\r]f1" 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-5267/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/pr23401.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/pr23401.c --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/pr23401.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/pr23401.c --target_board='unix{-m64\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/pr27810.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/pr27810.c --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/pr27810.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/pr27810.c --target_board='unix{-m64\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/slsr-8.c --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/slsr-8.c --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/slsr-8.c --target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/slsr-8.c --target_board='unix{-m64\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/declare-target-4.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/declare-target-4.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/declare-target-4.f90 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/declare-target-4.f90 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

Re: How to traverse all the local variables that declared in the current routine?

[Richard Biener via Gcc-patches]

On Tue, Nov 24, 2020 at 12:05 AM Qing Zhao via Gcc-patches
 wrote:
>
> Hi,
>
> Does gcc provide an iterator to traverse all the local variables that are 
> declared in the current routine?
>
> If not, what’s the best way to traverse the local variables?

Depends on what for.  There's the source level view you get by walking
BLOCK_VARS of the
scope tree, theres cfun->local_variables (FOR_EACH_LOCAL_DECL) and
there's SSA names
(FOR_EACH_SSA_NAME).

Richard.

>
> Thanks.
>
> Qing

Re: [24/32] module mapper

[Boris Kolpackov]

Nathan Sidwell  writes:

> These are needed as they also serve to inform the mapper of a dependency 
> edge.

Ok, that makes sense (and thanks for making it optional via a flag).

One thing that is still missing in this area is the dependency on
stdc-predef.h. In other words, we now can get everything via the
mapper as we can get with -M* except for this file.

Do you think it would be possible to report it with INCLUDE-TRANSLATE
(with the only valid response being BOOL FALSE)? There could also be
a flag to indicate that it's not really "translatable".

Re: Modules doc

[Boris Kolpackov]

Marek Polacek  writes:

> > +Only emit the module CMI, inhibiting any object file.
> 
> Maybe say here that CMI is Compiled Module Interface.

FYI, SG15 (WG21 study group on tooling) seems to have settled
on BMI ("built module interface"):

https://github.com/cplusplus/modules-ecosystem-tr/blob/master/definitions.tex

Re: [PATCH] IBM Z: Update autovec-*-quiet-uneq expectations

[Andreas Krebbel via Gcc-patches]

On 23.11.20 22:38, Ilya Leoshkevich wrote:
> Commit 229752afe315 ("VEC_COND_EXPR optimizations") has improved code
> generation: we no longer need "vx x,x,-1", which turned out to be
> superfluous.  Instead, we simply swap 0 and -1 arguments of the
> preceding "vsel".
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-11-23  Ilya Leoshkevich  
> 
>   * gcc.target/s390/zvector/autovec-double-quiet-uneq.c: Expect
>   that "vx" is not emitted.
>   * gcc.target/s390/zvector/autovec-float-quiet-uneq.c: Likewise.

Ok. Thanks!

Andreas

[PATCH v2 01/31] PR target/58901: reload: Handle SUBREG of MEM with a mode-dependent address

[Maciej W. Rozycki]

From: Matt Thomas 

Fix an ICE with the handling of RTL expressions like:

(subreg:QI (mem/c:SI (plus:SI (plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:67 i ] 
[67])
(const_int 4 [0x4]))
(reg/v/f:SI 7 %r7 [orig:59 doacross ] [59]))
(const_int 40 [0x28])) [1 MEM[(unsigned int *)doacross_63 + 40B + 
i_106 * 4]+0 S4 A32]) 0)

that causes the compilation of libgomp to fail:

during RTL pass: reload
.../libgomp/ordered.c: In function 'GOMP_doacross_wait':
.../libgomp/ordered.c:507:1: internal compiler error: in change_address_1, at 
emit-rtl.c:2275
  507 | }
  | ^
0x10a3462b change_address_1
.../gcc/emit-rtl.c:2275
0x10a353a7 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, 
int, int, poly_int<1u, long>)
.../gcc/emit-rtl.c:2409
0x10ae2993 alter_subreg(rtx_def**, bool)
.../gcc/final.c:3368
0x10ae25cf cleanup_subreg_operands(rtx_insn*)
.../gcc/final.c:3322
0x110922a3 reload(rtx_insn*, int)
.../gcc/reload1.c:1232
0x10de2bf7 do_reload
.../gcc/ira.c:5812
0x10de3377 execute
.../gcc/ira.c:5986

in a `vax-netbsdelf' build, where an attempt is made to change the mode
of the contained memory reference to the mode of the containing SUBREG.
Such RTL expressions are produced by the VAX shift and rotate patterns
(`ashift', `ashiftrt', `rotate', `rotatert') where the count operand
always has the QI mode regardless of the mode, either SI or DI, of the
datum shifted or rotated.

Such a mode change cannot work where the memory reference uses the
indexed addressing mode, where a multiplier is implied that in the VAX
ISA depends on the width of the memory access requested and therefore
changing the machine mode would change the address calculation as well.

Avoid the attempt then by forcing the reload of any SUBREGs containing
a mode-dependent memory reference, also fixing these regressions:

FAIL: gcc.c-torture/compile/pr46883.c   -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/pr46883.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/20120808-1.c   -O2  (internal compiler error)
FAIL: gcc.c-torture/execute/20120808-1.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/execute/20120808-1.c   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler 
error)
FAIL: gcc.c-torture/execute/20120808-1.c   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess 
errors)
FAIL: gcc.c-torture/execute/20120808-1.c   -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/execute/20120808-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/20120808-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (internal compiler error)
FAIL: gcc.c-torture/execute/20120808-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (test for excess errors)
FAIL: gcc.c-torture/execute/20120808-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (internal compiler error)
FAIL: gcc.c-torture/execute/20120808-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.dg/20050629-1.c (internal compiler error)
FAIL: gcc.dg/20050629-1.c (test for excess errors)
FAIL: c-c++-common/torture/pr53505.c   -Os  (internal compiler error)
FAIL: c-c++-common/torture/pr53505.c   -Os  (test for excess errors)
FAIL: gfortran.dg/coarray_failed_images_1.f08   -Os  (internal compiler error)
FAIL: gfortran.dg/coarray_stopped_images_1.f08   -Os  (internal compiler error)

With test case #0 included it causes a reload with:

(insn 15 14 16 4 (set (reg:SI 31)
(ashift:SI (const_int 1 [0x1])
(subreg:QI (reg:SI 30 [ MEM[(int *)s_8(D) + 4B + _5 * 4] ]) 0))) 
"pr58901-0.c":15:12 94 {ashlsi3}
 (expr_list:REG_DEAD (reg:SI 30 [ MEM[(int *)s_8(D) + 4B + _5 * 4] ])
(nil)))

as follows:

Reloads for insn # 15
Reload 0: reload_in (SI) = (reg:SI 30 [ MEM[(int *)s_8(D) + 4B + _5 * 4] ])
ALL_REGS, RELOAD_FOR_INPUT (opnum = 2)
reload_in_reg: (reg:SI 30 [ MEM[(int *)s_8(D) + 4B + _5 * 4] ])
reload_reg_rtx: (reg:SI 5 %r5)

resulting in:

(insn 37 14 15 4 (set (reg:SI 5 %r5)
(mem/c:SI (plus:SI (plus:SI (mult:SI (reg/v:SI 1 %r1 [orig:25 i ] [25])
(const_int 4 [0x4]))
(reg/v/f:SI 4 %r4 [orig:29 s ] [29]))
(const_int 4 [0x4])) [1 MEM[(int *)s_8(D) + 4B + _5 * 4]+0 S4 
A32])) "pr58901-0.c":15:12 12 {movsi_2}
 (nil))
(insn 15 37 16 4 (set (reg:SI 2 %r2 [31])
(ashift:SI (const_int 1 [0x1])
(reg:QI 5 %r5))) "pr58901-0.c":15:12 94 {ashlsi3}
 (nil))

and assembly like:

.L3:
movl 4(%r4)[%r1],%r5
ashl %r5,$1,%r2
xorl2 %r2,%r0
incl %r1
cmpl %r1,%r3
jneq .L3

produced for the loop, providing optimization has been enabled.  

Likewise with test case #1 the reload of:

(insn 17 16 18 4 (set (reg:SI 34)
(and:SI 

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Thomas Koenig via Gcc-patches]

Am 24.11.20 um 07:04 schrieb Maciej W. Rozycki:

I am going to give up at this point, as porting libgfortran to non-IEEE FP
is surely well beyond what I can afford to do right now.


Can you file a PR about this? Eliminating __builtin_inf and friends
sounds doable.

And does anybody know what we should return in cases where the result
exceeds the maximum representable number?

Best regards

Thomas

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:

> > > I don't know how or why __FLT_HAS_INFINITY is set for a target which
> > > does not support it, but if you get rid of that macro, that particular
> > > problem should be solved.
> > 
> >  Thanks for the hint; I didn't look into it any further not to distract 
> > myself from the scope of the project.  I have now, and the check you have 
> > quoted is obviously broken (as are all the remaining similar ones), given:
> > 
> > $ vax-netbsdelf-gcc -E -dM - < /dev/null | sort | grep _HAS_
> > #define __DBL_HAS_DENORM__ 0
> > #define __DBL_HAS_INFINITY__ 0
> > #define __DBL_HAS_QUIET_NAN__ 0
> > #define __FLT_HAS_DENORM__ 0
> > #define __FLT_HAS_INFINITY__ 0
> > #define __FLT_HAS_QUIET_NAN__ 0
> > #define __LDBL_HAS_DENORM__ 0
> > #define __LDBL_HAS_INFINITY__ 0
> > #define __LDBL_HAS_QUIET_NAN__ 0
> > $ 
> > 
> > which looks reasonable to me.  This seems straightforward to fix to me, so 
> > I'll include it along with verification I am about to schedule (assuming 
> > that this will be enough for libgfortran to actually build; obviously it 
> > hasn't been tried by anyone with such a setup for a while now, as these 
> > libgfortran checks date back to 2009).
> 
>  Well, it is still broken, owing to NetBSD failing to implement POSIX 2008 
> locale handling correctly, apparently deliberately[1], and missing 
> uselocale(3)[2] while still providing newlocale(3).  This confuses our 
> conditionals and consequently:
> 
> .../libgfortran/io/transfer.c: In function 'data_transfer_init_worker':
> .../libgfortran/io/transfer.c:3416:30: error:
> 'old_locale_lock' undeclared (first use in this function)
>  3416 |   __gthread_mutex_lock (_locale_lock);
>   |  ^~~
> 
> etc.
> 
>  We can probably work it around by downgrading to setlocale(3) for NetBSD 
> (i.e. whenever either function is missing) unless someone from the NetBSD 
> community contributes a better implementation (they seem to prefer their 
> own non-standard printf_l(3) library API).

 And now:

In file included from .../libgfortran/intrinsics/erfc_scaled.c:33:
.../libgfortran/intrinsics/erfc_scaled_inc.c:
In function 'erfc_scaled_r4':
.../libgfortran/intrinsics/erfc_scaled_inc.c:169:15: warning: target format 
does not support infinity
  169 | res = __builtin_inf ();
  |   ^
In file included from .../libgfortran/intrinsics/erfc_scaled.c:39:
.../libgfortran/intrinsics/erfc_scaled_inc.c:
In function 'erfc_scaled_r8':
.../libgfortran/intrinsics/erfc_scaled_inc.c:82:15: warning: floating constant 
exceeds range of 'double'
   82 |   xbig = 26.543, xhuge = 6.71e+7, xmax = 2.53e+307;
  |   ^~~~
.../libgfortran/intrinsics/erfc_scaled_inc.c:169:15: warning: target format 
does not support infinity
  169 | res = __builtin_inf ();
  |   ^

and:

.../libgfortran/intrinsics/c99_functions.c: In function 'tgamma':
.../libgfortran/intrinsics/c99_functions.c:1866:3: warning: floating constant 
truncated to zero [-Woverflow]
 1866 |   static const double xminin = 2.23e-308;
  |   ^~
.../libgfortran/intrinsics/c99_functions.c:1868:60: warning: target format does 
not support infinity
 1868 |   static const double xnan = __builtin_nan ("0x0"), xinf = 
__builtin_inf ();
  |
^{standard input}: Assembler messages:
{standard input}:487: Fatal error: Junk at end of expression "QNaN"
make[3]: *** [Makefile:6466: c99_functions.lo] Error 1

I am going to give up at this point, as porting libgfortran to non-IEEE FP 
is surely well beyond what I can afford to do right now.

  Maciej

Re: H8 cc0 conversion

[Jeff Law via Gcc-patches]

On 11/23/20 9:49 PM, Hans-Peter Nilsson wrote:
> On Sun, 22 Nov 2020, Jeff Law via Gcc-patches wrote:
>> This is the primary patch for cc0 removal on the H8 port.? It doesn't
>> have any of the optimization work and many patterns are simply disabled
>> at this time.? It's working well enough to not regress the testsuite.
>>
>> The H8 is similar to the m68k and other ports in that the vast majority
>> of instructions clobber the condition codes, including most of the
>> arithmetic insns that reload needs to use. While there's a special
>> adds/subs that does not modify the condition codes, they only accept
>> constant addends of 1, 2 and 4. With that in mind, this port does not
>> expose cc0 until after reload. So most patterns are defined using
>> define_insn_and_split. The splitter adds the appropriate clobbers.
> JFTR (as I'm repeating a previous note for another port): if
> you'd went for exposing cc0 *before* reload (adding a clobber to
> each pattern that clobbers, then specifying exceptions removing
> them), the amount of (required) define_insn_and_splits would
> have been zero; typically much less churn in the port.  That
> approach also has the benefit of insns not "silently" changing
> behavior at reload-time.
>
> You might think a parallel with a clobber for each insn hampers
> some rtl optimizations, but I found that to be not an issue at
> all, doing that for CRIS (at least when comparing to the cc0
> version).
I've definitely seen cases where exposing the clobber early hurts, so I
went with exposing after reload.

I also had someone else doing most of the grunt work, my son :-)

Jeff

Re: [PATCH 1/2] correct BB frequencies after loop changed

[Jiufu Guo via Gcc-patches]

Jeff Law  writes:

> On 11/18/20 12:28 AM, Richard Biener wrote:
>> On Tue, 17 Nov 2020, Jeff Law wrote:
>>
>>> Minor questions for Jan and Richi embedded below...
>>>
>>> On 10/9/20 4:12 AM, guojiufu via Gcc-patches wrote:
 When investigating the issue from 
 https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549786.html
 I find the BB COUNTs of loop seems are not accurate in some case.
 For example:

 In below figure:


COUNT:268435456  pre-header
 |
 |  ..
 |  ||
 V  v|
COUNT:805306369|
/ \  |
33%/   \ |
  / \|
 v   v   |
 COUNT:268435456  COUNT:536870911  | 
 exit-edge |   latch |
   ._.

 Those COUNTs have below equations:
 COUNT of exit-edge:268435456 = COUNT of pre-header:268435456
 COUNT of exit-edge:268435456 = COUNT of header:805306369 * 33
 COUNT of header:805306369 = COUNT of pre-header:268435456 + COUNT of 
 latch:536870911


 While after pcom:

COUNT:268435456  pre-header
 |
 |  ..
 |  ||
 V  v|
COUNT:268435456|
/ \  |
50%/   \ |
  / \|
 v   v   |
 COUNT:134217728  COUNT:134217728  | 
 exit-edge |   latch |
   ._.

 COUNT != COUNT + COUNT
 COUNT != COUNT

 In some cases, the probility of exit-edge is easy to estimate, then
 those COUNTs of other BBs in loop can be re-caculated.

 Bootstrap and regtest pass on ppc64le. Is this ok for trunk?

 Jiufu

 gcc/ChangeLog:
 2020-10-09  Jiufu Guo   

* cfgloopmanip.h (recompute_loop_frequencies): New function.
* cfgloopmanip.c (recompute_loop_frequencies): New implementation.
* tree-ssa-loop-manip.c (tree_transform_and_unroll_loop): Call
recompute_loop_frequencies.

 ---
  gcc/cfgloopmanip.c| 53 +++
  gcc/cfgloopmanip.h|  2 +-
  gcc/tree-ssa-loop-manip.c | 28 +++--
  3 files changed, 57 insertions(+), 26 deletions(-)

 diff --git a/gcc/cfgloopmanip.c b/gcc/cfgloopmanip.c
 index 73134a20e33..b0ca82a67fd 100644
 --- a/gcc/cfgloopmanip.c
 +++ b/gcc/cfgloopmanip.c
 @@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.  If not see
  #include "gimplify-me.h"
  #include "tree-ssa-loop-manip.h"
  #include "dumpfile.h"
 +#include "cfgrtl.h"
  
  static void copy_loops_to (class loop **, int,
   class loop *);
 @@ -1773,3 +1774,55 @@ loop_version (class loop *loop,
  
return nloop;
  }
 +
 +/* Recalculate the COUNTs of BBs in LOOP, if the probability of exit edge
 +   is NEW_PROB.  */
 +
 +bool
 +recompute_loop_frequencies (class loop *loop, profile_probability 
 new_prob)
 +{
 +  edge exit = single_exit (loop);
 +  if (!exit)
 +return false;
 +
 +  edge e;
 +  edge_iterator ei;
 +  edge non_exit;
 +  basic_block * bbs;
 +  profile_count exit_count = loop_preheader_edge (loop)->count ();
 +  profile_probability exit_p = exit_count.probability_in 
 (loop->header->count);
 +  profile_count base_count = loop->header->count;
 +  profile_count after_num = base_count.apply_probability (exit_p);
 +  profile_count after_den = base_count.apply_probability (new_prob);
 +
 +  /* Update BB counts in loop body.
 + COUNT = COUNT
 + COUNT = COUNT * exit_edge_probility
 + The COUNT = COUNT * old_exit_p / new_prob.  
 */
 +  bbs = get_loop_body (loop);
 +  scale_bbs_frequencies_profile_count (bbs, loop->num_nodes, after_num,
 +   after_den);
 +  free (bbs);
 +
 +  /* Update probability and count of the BB besides exit edge (maybe 
 latch).  */
 +  FOR_EACH_EDGE (e, ei, exit->src->succs)
 +if (e != exit)
 +  break;
 +  non_exit = e;
>>> Are we sure that exit->src has just two successors (will that case be
>>> canonicalized before we get here?).? If it 

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:

> > I don't know how or why __FLT_HAS_INFINITY is set for a target which
> > does not support it, but if you get rid of that macro, that particular
> > problem should be solved.
> 
>  Thanks for the hint; I didn't look into it any further not to distract 
> myself from the scope of the project.  I have now, and the check you have 
> quoted is obviously broken (as are all the remaining similar ones), given:
> 
> $ vax-netbsdelf-gcc -E -dM - < /dev/null | sort | grep _HAS_
> #define __DBL_HAS_DENORM__ 0
> #define __DBL_HAS_INFINITY__ 0
> #define __DBL_HAS_QUIET_NAN__ 0
> #define __FLT_HAS_DENORM__ 0
> #define __FLT_HAS_INFINITY__ 0
> #define __FLT_HAS_QUIET_NAN__ 0
> #define __LDBL_HAS_DENORM__ 0
> #define __LDBL_HAS_INFINITY__ 0
> #define __LDBL_HAS_QUIET_NAN__ 0
> $ 
> 
> which looks reasonable to me.  This seems straightforward to fix to me, so 
> I'll include it along with verification I am about to schedule (assuming 
> that this will be enough for libgfortran to actually build; obviously it 
> hasn't been tried by anyone with such a setup for a while now, as these 
> libgfortran checks date back to 2009).

 Well, it is still broken, owing to NetBSD failing to implement POSIX 2008 
locale handling correctly, apparently deliberately[1], and missing 
uselocale(3)[2] while still providing newlocale(3).  This confuses our 
conditionals and consequently:

.../libgfortran/io/transfer.c: In function 'data_transfer_init_worker':
.../libgfortran/io/transfer.c:3416:30: error:
'old_locale_lock' undeclared (first use in this function)
 3416 |   __gthread_mutex_lock (_locale_lock);
  |  ^~~

etc.

 We can probably work it around by downgrading to setlocale(3) for NetBSD 
(i.e. whenever either function is missing) unless someone from the NetBSD 
community contributes a better implementation (they seem to prefer their 
own non-standard printf_l(3) library API).

References:

[1] Martin Husemann, "Re: uselocale() function", 


[2] "The Open Group Base Specifications Issue 7, 2018 edition", IEEE Std 
1003.1-2017 (Revision of IEEE Std 1003.1-2008),


  Maciej

Re: H8 cc0 conversion

[Hans-Peter Nilsson]

On Sun, 22 Nov 2020, Jeff Law via Gcc-patches wrote:
> This is the primary patch for cc0 removal on the H8 port.? It doesn't
> have any of the optimization work and many patterns are simply disabled
> at this time.? It's working well enough to not regress the testsuite.
>
> The H8 is similar to the m68k and other ports in that the vast majority
> of instructions clobber the condition codes, including most of the
> arithmetic insns that reload needs to use. While there's a special
> adds/subs that does not modify the condition codes, they only accept
> constant addends of 1, 2 and 4. With that in mind, this port does not
> expose cc0 until after reload. So most patterns are defined using
> define_insn_and_split. The splitter adds the appropriate clobbers.

JFTR (as I'm repeating a previous note for another port): if
you'd went for exposing cc0 *before* reload (adding a clobber to
each pattern that clobbers, then specifying exceptions removing
them), the amount of (required) define_insn_and_splits would
have been zero; typically much less churn in the port.  That
approach also has the benefit of insns not "silently" changing
behavior at reload-time.

You might think a parallel with a clobber for each insn hampers
some rtl optimizations, but I found that to be not an issue at
all, doing that for CRIS (at least when comparing to the cc0
version).

brgds, H-P

[committed] Fix expected output after recent dump output changes

[Jeff Law via Gcc-patches]

Martin's recent changes added the return type to the dump file. 
Naturally we have tests that count "int" or pointers, which can show up
in the return type.

This patch adjusts the tests to the current output.   Pushed to the trunk.

Jeff


commit 4cd35cf3fdb70e2107f6b059f638f5bde4dae1c3
Author: Jeff Law 
Date:   Mon Nov 23 21:34:24 2020 -0700

Fix expected output after recent changes

gcc/testsuite
* gcc.dg/tree-ssa/pr23401.c: Update expected output.
* gcc.dg/tree-ssa/pr27810.c: Update expected output.
* gcc.dg/tree-ssa/slsr-8.c: Update expected output.

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr23401.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr23401.c
index fb8aebff525..a93fcaf8770 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr23401.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr23401.c
@@ -19,5 +19,5 @@ int (int i)
 
 /* We should not use extra temporaries apart from for i1 + i2.  */
 
-/* { dg-final { scan-tree-dump-times "int" 5 "gimple" } } */
+/* { dg-final { scan-tree-dump-times "int" 6 "gimple" } } */
 /* { dg-final { scan-tree-dump-times "int D\\\." 1 "gimple" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr27810.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr27810.c
index 84dfcc9ed91..5c1945bb5c1 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr27810.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr27810.c
@@ -13,5 +13,5 @@ int qqq (int a)
 /* We should not use an extra temporary for the result of the
function call.  */
 
-/* { dg-final { scan-tree-dump-times "int" 3 "gimple" } } */
+/* { dg-final { scan-tree-dump-times "int" 4 "gimple" } } */
 /* { dg-final { scan-tree-dump-times "int D\\\." 1 "gimple" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c 
b/gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c
index 585b660886b..479f40f93de 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c
@@ -23,7 +23,7 @@ f (int s, int *c, int *d)
However, this proves to be a useful test for introducing an
initializer with a cast, so we'll keep it as is.  */
 
-/* There are 4 ' * ' instances in the decls (since "int * iftmp.0;" is
-   added), 2 parms, 3 in the code.  The second one in the code may
-   be a widening multiply (for example, on AArch64).  */
-/* { dg-final { scan-tree-dump-times " w?\\* " 9 "optimized" } } */
+/* There are 5 ' * ' instances in the decls (since "int * iftmp.0;" is
+   added), 2 parms, 3 in the code, and the return value.  The second one
+   in the code may be a widening multiply (for example, on AArch64).  */
+/* { dg-final { scan-tree-dump-times " w?\\* " 10 "optimized" } } */

Re: [PATCH] dump type attributes in dump_function_to_file

[Jeff Law via Gcc-patches]

On 11/20/20 4:14 PM, Jeff Law wrote:
>
> On 11/20/20 11:12 AM, Martin Sebor via Gcc-patches wrote:
>> dump_function_to_file prints DECL_ATTRIBUTES but not TYPE_ATTRIBUTES
>> when both can be important and helpful for debugging, especially with
>> attributes that are added implicitly (such attribute access and
>> the proposed internal attribute *dealloc).  The function also prints
>> function arguments (and their types) but not its return type, again,
>> leaving out a useful detail.  The attached tweak adds both to
>> the dump.
>>
>> Martin
>>
>> gcc-dump-type-attr.diff
>>
>> gcc/ChangeLog:
>>
>>  * gcc/tree-cfg.c (dump_function_to_file): Print type attributes
>>  and return type.
>>
>> gcc/testsuite/ChangeLog:
>>  * gcc.dg/attr-access-4.c: New test.
So was this actually regression tested?  Even tests that change dump
files need to be regression tested because some of the tests scan those
dump files.

I'm seeing this on several targets:

Tests that now fail, but worked before (6 tests):

xstormy16-sim: gcc.dg/tree-ssa/pr23401.c scan-tree-dump-times gimple "int" 5
xstormy16-sim: gcc.dg/tree-ssa/pr23401.c scan-tree-dump-times gimple "int" 5
xstormy16-sim: gcc.dg/tree-ssa/pr27810.c scan-tree-dump-times gimple "int" 3
xstormy16-sim: gcc.dg/tree-ssa/pr27810.c scan-tree-dump-times gimple "int" 3
xstormy16-sim: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized " w?\\* 
" 9
xstormy16-sim: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized " w?\\* 
" 9



>From my quick reading, these tests are likely failing across the board.

jeff

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Mon, 23 Nov 2020, Thomas Koenig wrote:

> >   Well it does not:
> > 
> > In file included from .../libgfortran/generated/maxval_r4.c:26:
> > .../libgfortran/generated/maxval_r4.c: In function 'maxval_r4':
> > .../libgfortran/libgfortran.h:292:30: warning: target format does not
> > support infinity
> >292 | # define GFC_REAL_4_INFINITY __builtin_inff ()
> >|  ^~
> 
> This is guarded with
> 
> #ifdef __FLT_HAS_INFINITY__
> # define GFC_REAL_4_INFINITY __builtin_inff ()
> #endif
> 
> I don't know how or why __FLT_HAS_INFINITY is set for a target which
> does not support it, but if you get rid of that macro, that particular
> problem should be solved.

 Thanks for the hint; I didn't look into it any further not to distract 
myself from the scope of the project.  I have now, and the check you have 
quoted is obviously broken (as are all the remaining similar ones), given:

$ vax-netbsdelf-gcc -E -dM - < /dev/null | sort | grep _HAS_
#define __DBL_HAS_DENORM__ 0
#define __DBL_HAS_INFINITY__ 0
#define __DBL_HAS_QUIET_NAN__ 0
#define __FLT_HAS_DENORM__ 0
#define __FLT_HAS_INFINITY__ 0
#define __FLT_HAS_QUIET_NAN__ 0
#define __LDBL_HAS_DENORM__ 0
#define __LDBL_HAS_INFINITY__ 0
#define __LDBL_HAS_QUIET_NAN__ 0
$ 

which looks reasonable to me.  This seems straightforward to fix to me, so 
I'll include it along with verification I am about to schedule (assuming 
that this will be enough for libgfortran to actually build; obviously it 
hasn't been tried by anyone with such a setup for a while now, as these 
libgfortran checks date back to 2009).

  Maciej

Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

[Segher Boessenkool]

On Fri, Nov 13, 2020 at 09:41:28AM +0100, Richard Biener via Gcc-patches wrote:
> On Thu, Mar 12, 2020 at 1:41 AM J.W. Jagersma via Gcc-patches
>  wrote:
> > The following patch extends the generation of exception handling
> > information, so that it is possible to catch exceptions thrown from
> > volatile asm statements, when -fnon-call-exceptions is enabled.  Parts
> > of the gcc code already suggested this should be possible, but it was
> > never fully implemented.

> As you say volatile asms are already considered throwing in some pieces of
> code so this is a step towards fulfilling that promise.

But that is just wrong.  Volatile is an orthogonal concept.  There is
nothing wrong with having a non-volatile throwing asm, either, and it
can optimise better.

Can you just add some markup for throwing asm?

LLVM implements "asm goto" with outputs as a throwing insn, instead of
as a jump insn (as it should be, as it is documented!)  I suggested
doing an "asm break" (or whatever name, this is just a vaguely related
already existing keyword) for this, instead.  This has exactly the
semantics you want: all outputs are written on the normal path, and
they are either or not written when it throws.

The difference with your situation is in that case you specify all
labels the code could jump to, and in your case you don't.  Maybe
just one less colon could make the distinction?  (asm goto has four
colons, other asm has at most three).


Segher

Re: [PATCH][PR target/97642] Fix incorrect replacement of vmovdqu32 with vpblendd.

[Hongtao Liu via Gcc-patches]

On Tue, Nov 24, 2020 at 4:27 AM Jeff Law  wrote:
>
>
>
> On 11/4/20 2:19 AM, Hongtao Liu via Gcc-patches wrote:
> > Hi:
> >   When programmers explicitly use mask loaded intrinsics, don't
> > transform the instruction to vpblend{b,w,d,q} since If mem_addr points
> > to a memory region with less than whole vector size of accessible
> > memory,  the mask would prevent reading the inaccessible bytes which
> > could avoid fault.
> >
> >   Bootstrap is ok, gcc regress test for i386/x86_64 backend is ok.
> >   Ok for trunk?
> >
> > gcc/ChangeLog:
> >
> > PR target/97642
> > * config/i386/sse.md (UNSPEC_MASKLOAD): New unspec.
> > (*_load_mask): New define_insns for masked load
> > instructions.
> > (_load_mask): Changed to define_expands which
> > specifically handle memory operands.
> > (_blendm): Changed to define_insns which are same
> > as original _load_mask with adjustment of
> > operands order.
> > (*_load): New define_insn_and_split which is
> > used to optimize for masked load with all one mask.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/i386/avx512bw-vmovdqu16-1.c: Adjust testcase to
> > make sure only masked load instruction is generated.
> > * gcc.target/i386/avx512bw-vmovdqu8-1.c: Ditto.
> > * gcc.target/i386/avx512f-vmovapd-1.c: Ditto.
> > * gcc.target/i386/avx512f-vmovaps-1.c: Ditto.
> > * gcc.target/i386/avx512f-vmovdqa32-1.c: Ditto.
> > * gcc.target/i386/avx512f-vmovdqa64-1.c: Ditto.
> > * gcc.target/i386/avx512vl-vmovapd-1.c: Ditto.
> > * gcc.target/i386/avx512vl-vmovaps-1.c: Ditto.
> > * gcc.target/i386/avx512vl-vmovdqa32-1.c: Ditto.
> > * gcc.target/i386/avx512vl-vmovdqa64-1.c: Ditto.
> > * gcc.target/i386/pr97642-1.c: New test.
> > * gcc.target/i386/pr97642-2.c: New test.
> >
> >
> > 0001-Fix-incorrect-replacement-of-vmovdqu32-with-vpblendd.patch
> >
> > From 48cf0adcd55395653891888f4768b8bdc19786f2 Mon Sep 17 00:00:00 2001
> > From: liuhongt 
> > Date: Tue, 3 Nov 2020 17:26:43 +0800
> > Subject: [PATCH] Fix incorrect replacement of vmovdqu32 with vpblendd which
> >  can cause fault.
> >
> > gcc/ChangeLog:
> >
> >   PR target/97642
> >   * config/i386/sse.md (UNSPEC_MASKLOAD): New unspec.
> >   (*_load_mask): New define_insns for masked load
> >   instructions.
> >   (_load_mask): Changed to define_expands which
> >   specifically handle memory operands.
> >   (_blendm): Changed to define_insns which are same
> >   as original _load_mask with adjustment of
> >   operands order.
> >   (*_load): New define_insn_and_split which is
> >   used to optimize for masked load with all one mask.
> >
> > gcc/testsuite/ChangeLog:
> >
> >   * gcc.target/i386/avx512bw-vmovdqu16-1.c: Adjust testcase to
> >   make sure only masked load instruction is generated.
> >   * gcc.target/i386/avx512bw-vmovdqu8-1.c: Ditto.
> >   * gcc.target/i386/avx512f-vmovapd-1.c: Ditto.
> >   * gcc.target/i386/avx512f-vmovaps-1.c: Ditto.
> >   * gcc.target/i386/avx512f-vmovdqa32-1.c: Ditto.
> >   * gcc.target/i386/avx512f-vmovdqa64-1.c: Ditto.
> >   * gcc.target/i386/avx512vl-vmovapd-1.c: Ditto.
> >   * gcc.target/i386/avx512vl-vmovaps-1.c: Ditto.
> >   * gcc.target/i386/avx512vl-vmovdqa32-1.c: Ditto.
> >   * gcc.target/i386/avx512vl-vmovdqa64-1.c: Ditto.
> >   * gcc.target/i386/pr97642-1.c: New test.
> >   * gcc.target/i386/pr97642-2.c: New test.
> So in the BZ Jakub asked for the all-ones mask case to be specially
> handled to emit a normal load.  I don't see where we're handling that.
> ISTM that we'd want a test for that too.  Right?
>

all-ones mask would be simplified to a simple load but with unspec in
set_src and would be handled by the following

+(define_insn_and_split "*_load"
+  [(set (match_operand:V48_AVX512VL 0 "register_operand")
+ (unspec:V48_AVX512VL
+   [(match_operand:V48_AVX512VL 1 "memory_operand")]
+   UNSPEC_MASKLOAD))]
+  "TARGET_AVX512F"
+  "#"
+  "&& 1"
+  [(set (match_dup 0) (match_dup 1))])

and the corresponding testcase is

new file   gcc/testsuite/gcc.target/i386/pr97642-1.c
@@ -0,0 +1,23 @@
+/* PR target/97642 */
+/* { dg-do compile } */
+/* { dg-options "-mavx512vl -O2" } */
+/* { dg-final { scan-assembler-not { k[0-8] } } } */
+
+#include 
+__m128i
+foo1 (__m128i src, void const* P)
+{
+  return _mm_mask_loadu_epi32 (src, 15, P);
+}
+
+__m256i
+foo2 (__m256i src, void const* P)
+{
+  return _mm256_mask_loadu_epi32 (src, 255, P);
+}
+
+__m512i
+foo3 (__m512i src, void const* P)
+{
+  return _mm512_mask_loadu_epi32 (src, 65535 , P);
+}


> WIth that in place and tested, this is probably ready for the trunk.
>
> jeff
>
>


-- 
BR,
Hongtao

Re: Ping^3: [PATCH 0/4] rs6000: Enable variable vec_insert with IFN VEC_SET

[Xionghu Luo via Gcc-patches]

Ping^3, thanks.

https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555905.html


On 2020/11/13 10:05, Xionghu Luo via Gcc-patches wrote:

Ping^2, thanks.

On 2020/11/5 09:34, Xionghu Luo via Gcc-patches wrote:

Ping.

On 2020/10/10 16:08, Xionghu Luo wrote:

Originated from
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554240.html
with patch split and some refinement per review comments.

Patch of IFN VEC_SET for ARRAY_REF(VIEW_CONVERT_EXPR) is committed,
this patch set enables expanding IFN VEC_SET for Power9 and Power8
with specfic instruction sequences.

Xionghu Luo (4):
   rs6000: Change rs6000_expand_vector_set param
   rs6000: Support variable insert and Expand vec_insert in expander 
[PR79251]

   rs6000: Enable vec_insert for P8 with rs6000_expand_vector_set_var_p8
   rs6000: Update testcases' instruction count

  gcc/config/rs6000/rs6000-c.c  |  44 +++--
  gcc/config/rs6000/rs6000-call.c   |   2 +-
  gcc/config/rs6000/rs6000-protos.h |   3 +-
  gcc/config/rs6000/rs6000.c    | 181 +-
  gcc/config/rs6000/vector.md   |   4 +-
  .../powerpc/fold-vec-insert-char-p8.c |   8 +-
  .../powerpc/fold-vec-insert-char-p9.c |  12 +-
  .../powerpc/fold-vec-insert-double.c  |  11 +-
  .../powerpc/fold-vec-insert-float-p8.c    |   6 +-
  .../powerpc/fold-vec-insert-float-p9.c    |  10 +-
  .../powerpc/fold-vec-insert-int-p8.c  |   6 +-
  .../powerpc/fold-vec-insert-int-p9.c  |  11 +-
  .../powerpc/fold-vec-insert-longlong.c    |  10 +-
  .../powerpc/fold-vec-insert-short-p8.c    |   6 +-
  .../powerpc/fold-vec-insert-short-p9.c    |   8 +-
  .../gcc.target/powerpc/pr79251-run.c  |  28 +++
  gcc/testsuite/gcc.target/powerpc/pr79251.h    |  19 ++
  gcc/testsuite/gcc.target/powerpc/pr79251.p8.c |  17 ++
  gcc/testsuite/gcc.target/powerpc/pr79251.p9.c |  18 ++
  .../gcc.target/powerpc/vsx-builtin-7.c    |   4 +-
  20 files changed, 337 insertions(+), 71 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr79251-run.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr79251.h
  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr79251.p8.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr79251.p9.c







--
Thanks,
Xionghu

Re: [PATCH] libstdc++: Add C++2a synchronization support

[David Edelsohn via Gcc-patches]

On Mon, Nov 23, 2020 at 1:31 PM Jonathan Wakely  wrote:
>
> On 22/11/20 13:37 +, Jonathan Wakely via Libstdc++ wrote:
> >On Sun, 22 Nov 2020, 12:29 Iain Sandoe,  wrote:
> >
> >> thanks for looking at this over the weekend.
> >>
> >> Jonathan Wakely via Gcc-patches  wrote:
> >>
> >> > On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++
> >> >  wrote:
> >> >> I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
> >> >> fixes.  And a few c++ failures with similar symptoms.  I'm not certain
> >> >> that it is due to this patch, but it's the likely suspect.
> >> > Yes, it's that patch.
> >> >
> >> > This should fix most of those errors, but I haven't finished testing
> >> > it, and can't commit it now anyway.
> >> > 
> >>
> >> with r11-5235 + this patch there are still quite a few fails on Darwin -
> >> but
> >> all seem to be the same ( so maybe only problem ;) ):
> >>   “sem_timedwait was not declared in this scope”.
> >>
> >> It looks like the semaphore header is optional in SUSv3 (AFAIK that’s still
> >> the claimed edition for Darwin) - and although Darwin has the semaphore
> >> header, it doesn’t seem to have an impl. of sem_timedwait.
> >>
> >> just:
> >> int sem_trywait(sem_t *);
> >> int sem_wait(sem_t *) ;
> >>
> >
> >
> >It probably depends on the _POSIX_TIMEOUTS option which MacOS doesn't
> >support (optional in POSIX 2001, but not 2008).
>
> Hopefully this fixes it, but I haven't tested it on darwin, only
> linux, aix and solaris.

This patch fixed the problems that I saw on AIX.  Thanks for addressing it!

Thanks, David

Re: [PATCH 27/31] VAX: Make the `divmoddisi4' and `*amulsi4' comment notation consistent

[Segher Boessenkool]

On Fri, Nov 20, 2020 at 03:36:24AM +, Maciej W. Rozycki wrote:
> Use a double colon to introduce the comments like elsewhere throughout
> the VAX machine description.

It's a double semicolon, so kind of a single colon ;-)


Segher

Re: PR97849: aarch64: ICE (segfault) during GIMPLE pass: ifcvt

[Prathamesh Kulkarni via Gcc-patches]

On Wed, 18 Nov 2020 at 19:13, Richard Biener  wrote:
>
> On Wed, 18 Nov 2020, Prathamesh Kulkarni wrote:
>
> > Hi,
> > For the following test-case (slightly reduced from PR)
> > int a, b, c;
> >
> > int g() {
> >   char i = 0;
> >   for (c = 0; c <= 8; c++)
> > --i;
> >
> >   while (b) {
> > _Bool f = i <= 0;
> > a = (a == 0) ? 0 : f / a;
> >   }
> > }
> >
> > The compiler segfaults with -O1 -march=armv8.2-a+sve in ifcvt_local_dce.
> >
> > IIUC, the issue here is that tree-if-conv.c:predicate_rhs_code
> > processes the following statement:
> > iftmp.2_7 = a_lsm.10_11 != 0 ? iftmp.2_13 : 0;
> > and records  mapping.
> >
> > However RPO VN eliminates iftmp.2_13:
> > Removing dead stmt iftmp.2_13 = .COND_DIV (_29, _4, a_lsm.10_11, 0);
> >
> > and we end up replacing iftmp.2_7 with a dead ssa_name in ifcvt_local_dce:
> > FOR_EACH_VEC_ELT (redundant_ssa_names, i, name_pair)
> > replace_uses_by (name_pair->first, name_pair->second);
> >   redundant_ssa_names.release ();
> >
> > resulting in incorrect IR, and segfault down the line.
> >
> > To avoid clashing of RPO VN with redunant_ssa_names, the patch simply moves
> > ifcvt_local_dce before do_rpo_vn, which avoids the segfault.
> > Does that look OK ?
> > (Altho I guess, doing DCE after VN is better in principle)
>
> Yes, I'd say just moving
>
>   FOR_EACH_VEC_ELT (redundant_ssa_names, i, name_pair)
> replace_uses_by (name_pair->first, name_pair->second);
>   redundant_ssa_names.release ();
>
> before rpo_vn makes more sense, no?
Ah indeed, thanks for the suggestion.
Committed the attached patch after bootstrap+test on x86_64, and
cross testing on aarch64*-*-* and arm*-*-*.

Thanks,
Prathamesh
>
> OK with that change.
> Thanks,
> Richard.
>
> > Thanks,
> > Prathamesh
> >
>
> --
> Richard Biener 
> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
> Germany; GF: Felix Imend


pr97849-3.diff
Description: Binary data

Re: [PATCH 02/31] VAX: Remove `c' operand format specifier overload

[Segher Boessenkool]

On Fri, Nov 20, 2020 at 03:34:16AM +, Maciej W. Rozycki wrote:
> The `c' operand format specifier is handled directly by the middle end
> in `output_asm_insn':
> 
>%cN means require operand N to be a constant
>   and print the constant expression with no punctuation.
> 
> however it resorts to the target for constants that are not valid
> addresses:
> 
>   else if (letter == 'c')
> {
>   if (CONSTANT_ADDRESS_P (operands[opnum]))
> output_addr_const (asm_out_file, operands[opnum]);
>   else
> output_operand (operands[opnum], 'c');
> }
> 
> The VAX backend expects the fallback never to happen and overloads `c'
> with the branch condition code.  This is confusing however

There are 16 targets in trunk that overload the 'c' output modifier.
Most do it for something with condition codes (or comparisons).  This is
a well-established convention, confusing or not :-)

(I have nothing against the patch of course.)


Segher

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

[Jeff Law via Gcc-patches]

On 11/10/20 2:09 PM, Jeff Law wrote:
> On 11/10/20 1:14 PM, Jakub Jelinek via Gcc-patches wrote:
>> On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote:
>>> Eric Botcazou  wrote:
>>>
> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() 
> functions
> is rather bad, it yields bad machine code at least on i386 and AMD64. 
> Since
> GCC knows how to shift integers twice the register size these functions 
> can
> be written as one-liners.
 These functions are precisely meant to be used when GCC cannot do that.
>>> On which processor(s) is GCC unable to generate code for DWtype shifts?
>> E.g. avr-none, msp430-elf, pdp11-aout.
>> And I see recursive __cmpdi2 calls on avr-none too.
> ACK.  I'll pull those [u]cmpdi changes.  They were iffy at best, this
> confirms the concerns we both had.
I'm not seeing recursive calls.  I'm seeing ucmpdi calling cmpdi on avr
(and cmpdi is simple straightline code with no calls, so no recursion). 
msp looks OK WRT [u]cmpdi as does pdp11.

So I think unless we see something clearly wrong we should leave the
committed patch as-is.  There's the follow-up for abs and more multiply
stuff that still needs a looksie as well as subsequent independent patches.

Jeff

Re: [PATCH] use TYPE_SIZE instead of DECL_SIZE for classes (PR 97595)

[Martin Sebor via Gcc-patches]

On 11/16/20 11:54 PM, Jason Merrill wrote:

On 11/16/20 9:41 PM, Martin Sebor wrote:

The result of DECL_SIZE_UNIT doesn't always reflect the size
of data members of virtual classes.  This can lead to objects
of such types appearing smaller than they are to warnings like
-Warray-bounds or -Wstringop-overflow, causing false positives.

To avoid these false positives, the attached replaces the use
of DECL_SIZE_UNIT in component_ref_size in the middle end with
TYPE_SIZE_UNIT.


Unfortunately, that's not enough; the offset between the intermediate 
base and the virtual base could be greater than the TYPE_SIZE of the 
intermediate base:


extern "C" int printf (const char *, ...);

struct A { char ar1[24]; };
struct B: virtual A { };
struct C { char ar2[42]; };
struct D: B, C { };

int main()
{
   D d;
   printf ("size %d, offset %d\n", sizeof (B), d.ar1 - (char*)(B*));
}

Here base C is allocated between base B and its virtual base A, so the 
offset between them is 50, while the size of B is only 32.


The difference between TYPE_SIZE and DECL_SIZE could be a way to 
recognize the case of bases with virtual bases, and then either hunt 
down all the virtual bases or just use the bounds of the enclosing 
most-derived object.


An advanced analysis of classes with virtual bases is beyond what
I have cycles to tackle at this point (it seems it would also need
to be done in the C++ front end?)  It will have to wait until I have
more time or the next stage 1.

So for now, I've changed component_ref_size to fail when DECL_SIZE
isn't equal TYPE_SIZE.




+    /* DECL_SIZE may be less than TYPE_SIZE in C++ when referring
+   to the type of a virtual base class which doesn't reflect
+   the size of the virtual's members (see pr97595).  */


The problem isn't with the virtual base class itself (A), but with the 
intermediate base class subobject (B), for which DECL_SIZE doesn't 
include the size of the virtual base A, because the A base subobject is 
allocated separately.


I've also adjusted the comments above the _SIZE macros in tree.h
to more closely reflect what happens there.  My main goal isn't
to describe when they don't match with perfect accuracy, just to
point that they may be unequal and (roughly) when.

Martin
PR middle-end/97595 - bogus -Wstringop-overflow due to DECL_SIZE_UNIT underreporting field size

gcc/ChangeLog:

	PR middle-end/97595
	* tree.c (component_ref_size): Fail when DECL_SIZE != TYPE_SIZE.
	* tree.h (DECL_SIZE): Update comment.

gcc/testsuite/ChangeLog:

	PR middle-end/97595
	* g++.dg/warn/Warray-bounds-14.C: New test.
	* g++.dg/warn/Wstringop-overflow-6.C: New test.

diff --git a/gcc/testsuite/g++.dg/warn/Warray-bounds-14.C b/gcc/testsuite/g++.dg/warn/Warray-bounds-14.C
new file mode 100644
index 000..0812f833d74
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Warray-bounds-14.C
@@ -0,0 +1,25 @@
+/* PR middle-end/97595 - bogus -Wstringop-overflow due to DECL_SIZE_UNIT
+   underreporting field size
+   { dg-do compile }
+   { dg-options "-O2 -Wall" } */
+
+struct A { char a[32]; };
+struct B: virtual A { };
+struct C: B { };
+
+struct D
+{
+  B 
+  D (B&);
+};
+
+D::D (B ): b (b) { }// { dg-bogus "-Warray-bounds" }
+
+void f (void*);
+
+void g ()
+{
+  C c;
+  D d (c);
+  f ();
+}
diff --git a/gcc/testsuite/g++.dg/warn/Wstringop-overflow-6.C b/gcc/testsuite/g++.dg/warn/Wstringop-overflow-6.C
new file mode 100644
index 000..8173e601d4b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wstringop-overflow-6.C
@@ -0,0 +1,8 @@
+/* PR middle-end/97595 - bogus -Wstringop-overflow due to DECL_SIZE_UNIT
+   underreporting field size
+   { dg-do compile { target c++11 } }
+   { dg-options "-O2 -Wall -Wsystem-headers" } */
+
+#include 
+
+template void std::basic_iostream::swap (basic_iostream&);
diff --git a/gcc/tree.c b/gcc/tree.c
index d6ba55319bf..52a145dd018 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -13740,9 +13740,9 @@ component_ref_size (tree ref, special_array_member *sam /* = NULL */)
 {
   gcc_assert (TREE_CODE (ref) == COMPONENT_REF);
 
-  special_array_member arkbuf;
+  special_array_member sambuf;
   if (!sam)
-sam = 
+sam = 
   *sam = special_array_member::none;
 
   /* The object/argument referenced by the COMPONENT_REF and its type.  */
@@ -13756,7 +13756,13 @@ component_ref_size (tree ref, special_array_member *sam /* = NULL */)
 {
   tree memtype = TREE_TYPE (member);
   if (TREE_CODE (memtype) != ARRAY_TYPE)
-	return memsize;
+	/* DECL_SIZE may be less than TYPE_SIZE in C++ when referring
+	   to the type of a class with a virtual base which doesn't
+	   reflect the size of the virtual's members (see pr97595).
+	   If that's the case fail for now and implement something
+	   more robust in the future.  */
+	return (tree_int_cst_equal (memsize, TYPE_SIZE_UNIT (memtype))
+		? memsize : NULL_TREE);
 
   bool trailing = array_at_struct_end_p (ref);
   bool zero_length = integer_zerop (memsize);
diff --git a/gcc/tree.h b/gcc/tree.h

Re: [PATCH] PowerPC: PR 97791: Fix gnu attributes.

[Segher Boessenkool]

Hi!

On Thu, Nov 19, 2020 at 06:54:29PM -0500, Michael Meissner wrote:
> 1) Only set gnu attribute #4 if long double was passed.  Passing __float128
> when long double is IBM or __ibm128 when long double is IEEE no longer sets 
> the
> attribute.  This resulted in a lot of false positives, such as using 
> __float128
> and no long double support.

Sure, makes sense (and is a bug fix actually).

> 2) Do not set the gnu attribute if a mode used by long double (TF or DF) is
> used in a move.  The moves do not differentiate between the long double type
> and similar types.  Delete the three tests that tested this.

This, too.

> diff --git a/gcc/testsuite/gcc.target/powerpc/gnuattr1.c 
> b/gcc/testsuite/gcc.target/powerpc/gnuattr1.c
> deleted file mode 100644
> index cf46777849a..000
> --- a/gcc/testsuite/gcc.target/powerpc/gnuattr1.c
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -/* { dg-do compile { target { powerpc*-linux-* } } } */
> -/* { dg-require-effective-target powerpc_vsx_ok } */
> -/* { dg-options "-O2 -mvsx -mlong-double-64" } */
> -/* { dg-final { scan-assembler "gnu_attribute 4, 9" } } */
> -
> -/* Check that if we can do the long double operation without doing an 
> emulator
> -   call, such as with 64-bit long double support, that we still set the
> -   appropriate .gnu_attribute.  */
> -
> -long double a;
> -
> -void add1 (void)
> -{
> -  a++;
> -}

But this *does* use long double.  So this testcase is valid, and you
should not delete it.

Instead, it points out you have a deficiency in the code, one that used
to be hidden by how you used moves to set the attribute.

Same for the other testcases you delete.


Segher

Re: [PATCH] unshare expressions in attribute arguments

[Joseph Myers]

On Fri, 20 Nov 2020, Martin Sebor via Gcc-patches wrote:

> The VLA bounds are evaluated in function definitions so there
> must be a point where that's done.  I don't know where that
> happens but unless at that point the most significant bound
> is still associated with the param (AFAIK, it never really
> is at the tree level) it wouldn't help me.

grokdeclarator combines VLA bounds with the *expr passed in using a 
COMPOUND_EXPR.  These later get stored in arg_info->pending_sizes, and the 
evaluation happens via the add_stmt call in store_parm_decls.

-- 
Joseph S. Myers
jos...@codesourcery.com

c: Allow comparison of pointers to complete and incomplete types for C11 [PR95630]

[Joseph Myers]

As noted in bug 95630, C11 removed a restriction in C99 on comparing
pointers to compatible complete and incomplete types (this was one of
the changes in N1439, which was largely a terminological change to
make incomplete types a subset of object types rather than a different
kind of type).  Implement that change by using pedwarn_c99 with
OPT_Wpedantic for this diagnostic.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Applied to 
mainline.

gcc/c/
2020-11-23  Joseph Myers  

PR c/95630
* c-typeck.c (build_binary_op): Use pedwarn_c99 with OPT_Wpedantic
for comparisons of complete and incomplete pointers.

gcc/testsuite/
2020-11-23  Joseph Myers  

PR c/95630
* gcc.dg/c11-compare-incomplete-1.c,
gcc.dg/c11-compare-incomplete-2.c,
gcc.dg/c99-compare-incomplete-1.c,
gcc.dg/c99-compare-incomplete-2.c: New tests.

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 286f3d9cd6c..cdc491a25fd 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -12266,8 +12266,8 @@ build_binary_op (location_t location, enum tree_code 
code,
  result_type = common_pointer_type (type0, type1);
  if (!COMPLETE_TYPE_P (TREE_TYPE (type0))
  != !COMPLETE_TYPE_P (TREE_TYPE (type1)))
-   pedwarn (location, 0,
-"comparison of complete and incomplete pointers");
+   pedwarn_c99 (location, OPT_Wpedantic,
+"comparison of complete and incomplete pointers");
  else if (TREE_CODE (TREE_TYPE (type0)) == FUNCTION_TYPE)
pedwarn (location, OPT_Wpedantic, "ISO C forbids "
 "ordered comparisons of pointers to functions");
diff --git a/gcc/testsuite/gcc.dg/c11-compare-incomplete-1.c 
b/gcc/testsuite/gcc.dg/c11-compare-incomplete-1.c
new file mode 100644
index 000..b1c05cf221e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-compare-incomplete-1.c
@@ -0,0 +1,52 @@
+/* Test comparisons of pointers to complete and incomplete types are
+   accepted in C11 mode.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+int
+f (int (*p)[], int (*q)[3])
+{
+  return p < q;
+}
+
+int
+f2 (int (*p)[], int (*q)[3])
+{
+  return p <= q;
+}
+
+int
+f3 (int (*p)[], int (*q)[3])
+{
+  return p > q;
+}
+
+int
+f4 (int (*p)[], int (*q)[3])
+{
+  return p >= q;
+}
+
+int
+g (int (*p)[], int (*q)[3])
+{
+  return q < p;
+}
+
+int
+g2 (int (*p)[], int (*q)[3])
+{
+  return q <= p;
+}
+
+int
+g3 (int (*p)[], int (*q)[3])
+{
+  return q > p;
+}
+
+int
+g4 (int (*p)[], int (*q)[3])
+{
+  return q >= p;
+}
diff --git a/gcc/testsuite/gcc.dg/c11-compare-incomplete-2.c 
b/gcc/testsuite/gcc.dg/c11-compare-incomplete-2.c
new file mode 100644
index 000..8e809e87e9a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-compare-incomplete-2.c
@@ -0,0 +1,52 @@
+/* Test comparisons of pointers to complete and incomplete types are
+   diagnosed in C11 mode with -Wc99-c11-compat.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic-errors -Wc99-c11-compat" } */
+
+int
+f (int (*p)[], int (*q)[3])
+{
+  return p < q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+f2 (int (*p)[], int (*q)[3])
+{
+  return p <= q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+f3 (int (*p)[], int (*q)[3])
+{
+  return p > q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+f4 (int (*p)[], int (*q)[3])
+{
+  return p >= q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+g (int (*p)[], int (*q)[3])
+{
+  return q < p; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+g2 (int (*p)[], int (*q)[3])
+{
+  return q <= p; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+g3 (int (*p)[], int (*q)[3])
+{
+  return q > p; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+g4 (int (*p)[], int (*q)[3])
+{
+  return q >= p; /* { dg-warning "complete and incomplete" } */
+}
diff --git a/gcc/testsuite/gcc.dg/c99-compare-incomplete-1.c 
b/gcc/testsuite/gcc.dg/c99-compare-incomplete-1.c
new file mode 100644
index 000..dfafc39145e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c99-compare-incomplete-1.c
@@ -0,0 +1,52 @@
+/* Test comparisons of pointers to complete and incomplete types are
+   diagnosed in C99 mode: -pedantic.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c99 -pedantic" } */
+
+int
+f (int (*p)[], int (*q)[3])
+{
+  return p < q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+f2 (int (*p)[], int (*q)[3])
+{
+  return p <= q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+f3 (int (*p)[], int (*q)[3])
+{
+  return p > q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+f4 (int (*p)[], int (*q)[3])
+{
+  return p >= q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+g (int (*p)[], int (*q)[3])
+{
+  return q < p; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+g2 (int (*p)[], int (*q)[3])
+{
+  return q 

How to traverse all the local variables that declared in the current routine?

[Qing Zhao via Gcc-patches]

Hi, 

Does gcc provide an iterator to traverse all the local variables that are 
declared in the current routine? 

If not, what’s the best way to traverse the local variables?

Thanks.

Qing

Re: [PATCH] ipa: special pass-through op for Fortran strides

[Martin Jambor]

Hi Jeff,

On Fri, Nov 20 2020, Jeff Law wrote:
> On 6/12/20 3:25 PM, Martin Jambor wrote:
>>
[...]
>>
>> 2020-06-12  Martin Jambor  
>>
>>  * ipa-prop.h (ipa_pass_through_data): Expand comment describing
>>  operation.
>>  * ipa-prop.c (analyze_agg_content_value): Detect new special case and
>>  encode it as ASSERT_EXPR.
>>  * ipa-cp.c (values_equal_for_ipcp_p): Move before
>>  ipa_get_jf_arith_result.
>>  (ipa_get_jf_arith_result): Special case ASSERT_EXPR.
>>
>>  testsuite/
>>  * gfortran.dg/ipcp-array-2.f90: New test.
> I don't see any feedback on this (old) patch.
>
> It's not obvious from the patch, but I get the impression that the
> ASSERT_EXPR isn't actually added to the IL, but instead just gets
> stuffed into the agg_value structure.  Can you confirm one way or the
> other.  If it ends up in the IL then we need to make sure it doesn't
> escape the pass.
>
> Assuming we don't ultimately extract the info from the agg_value
> structure and add it to the IL, I don't have any significant concerns
> about this patch.  Do you want to re-test it and include it in gcc-11?
>

thank you very much for reminding me, I would have probably forgotten
about it.  I was experimenting a little with emulating this by adding
chains of operations to jump functions like ipa predicates have, but I
do not have anything ready for GCC 11 so at least for now I have
re-bootstrapped and re-tested the patch from June and committed it as
f38a33a2745.

Thanks again,

Martin


For reference, the committed patch is the following:

when Fortran functions pass array descriptors they receive as a
parameter to another function, they actually rebuild it.  Thanks to
work done mainly by Feng, IPA-CP can already handle the cases when
they pass directly the values loaded from the original descriptor.
Unfortunately, perhaps the most important one, stride, is first
checked against zero and is replaced with one in that case:

  _12 = *a_11(D).dim[0].stride;
  if (_12 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

  
// empty BB
  
  # iftmp.22_9 = PHI <_12(2), 1(3)>
   ...
   parm.6.dim[0].stride = iftmp.22_9;
   ...
   __x_MOD_foo (, b_31(D));

in the most important and hopefully common cases, the incoming value
is already 1 and we fail to propagate it.

I would therefore like to propose the following way of encoding this
situation in pass-through jump functions using using ASSERTT_EXPR
operation code meaning that if the incoming value is the same as the
"operand" in the jump function, it is passed on, otherwise the result
is unknown.  This of course captures only the single (but most
important) case but is an improvement and does not need enlarging the
jump function structure and is simple to pattern match.  Encoding that
zero needs to be changed to one would need another field and matching
it would be slightly more complicated too.

2020-06-12  Martin Jambor  

* ipa-prop.h (ipa_pass_through_data): Expand comment describing
operation.
* ipa-prop.c (analyze_agg_content_value): Detect new special case and
encode it as ASSERT_EXPR.
* ipa-cp.c (values_equal_for_ipcp_p): Move before
ipa_get_jf_arith_result.
(ipa_get_jf_arith_result): Special case ASSERT_EXPR.

testsuite/
* gfortran.dg/ipcp-array-2.f90: New test.
---
 gcc/ipa-cp.c   |  48 ---
 gcc/ipa-prop.c | 148 ++---
 gcc/ipa-prop.h |  11 +-
 gcc/testsuite/gfortran.dg/ipcp-array-2.f90 |  45 +++
 4 files changed, 179 insertions(+), 73 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/ipcp-array-2.f90

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index c3ee71e16e1..a06b4d151dd 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1304,6 +1304,26 @@ initialize_node_lattices (struct cgraph_node *node)
   }
 }
 
+/* Return true iff X and Y should be considered equal values by IPA-CP.  */
+
+static bool
+values_equal_for_ipcp_p (tree x, tree y)
+{
+  gcc_checking_assert (x != NULL_TREE && y != NULL_TREE);
+
+  if (x == y)
+return true;
+
+  if (TREE_CODE (x) == ADDR_EXPR
+  && TREE_CODE (y) == ADDR_EXPR
+  && TREE_CODE (TREE_OPERAND (x, 0)) == CONST_DECL
+  && TREE_CODE (TREE_OPERAND (y, 0)) == CONST_DECL)
+return operand_equal_p (DECL_INITIAL (TREE_OPERAND (x, 0)),
+   DECL_INITIAL (TREE_OPERAND (y, 0)), 0);
+  else
+return operand_equal_p (x, y, 0);
+}
+
 /* Return the result of a (possibly arithmetic) operation on the constant
value INPUT.  OPERAND is 2nd operand for binary operation.  RES_TYPE is
the type of the parameter to which the result is passed.  Return
@@ -1321,6 +1341,14 @@ ipa_get_jf_arith_result (enum tree_code opcode, tree 
input, tree operand,
   if (!is_gimple_ip_invariant (input))
 return NULL_TREE;
 
+  if (opcode == ASSERT_EXPR)
+{
+  if (values_equal_for_ipcp_p (input, operand))
+

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

[Jeff Law via Gcc-patches]

On 11/11/20 2:55 AM, Jakub Jelinek wrote:
> On Wed, Nov 11, 2020 at 09:33:00AM +0100, Stefan Kanthak wrote:
>> Ouch: that's but not the point here; what matters is the undefined behaviour 
>> of
>>   ((u) & 0x00ff) << 24
>>
>> 0x00ff is a signed int, so (u) & 0x00ff is signed too -- and 
>> producing
>> a negative value (or overflow) from the left-shift of a signed int, i.e.
>> shifting into (or beyond) the sign bit, is undefined behaviour!
> Only in some language dialects.
> It is caught by -fsanitize=shift.
> In C++20, if the shift count is within bounds, all signed as well as
> unsigned left shifts well defined.
> In C99/C11 there is one extra rule:
> For signed x << y, in C99/C11, the following:
>  (unsigned) x >> (uprecm1 - y)
>  if non-zero, is undefined.
> and for C++11 to C++17 another one:
>   /* For signed x << y, in C++11 and later, the following:
>  x < 0 || ((unsigned) x >> (uprecm1 - y)) > 1
>  is undefined.  */
> So indeed, 0x80 << 24 is UB in C99/C11 and C++98, unclear in C89 and
> well defined in C++11 and later.  I don't know if C2X is considering
> mandating two's complement and making it well defined like C++20 did.
>
> Guess we should fix that, though because different languages have different
> rules, GCC itself except for sanitization doesn't consider it UB and only
> treats shifts by negative value or shifts by bitsize or more UB.
Even if it's well defined by C++20, I don't think we can rely on those
semantics within libgcc2.  At best we might be able to claim C99 and we
might even be stuck at C89, regardless of how GCC treats a shift into
the sign bit.

I'll do a bit of testing here, but I'm inclined to explicitly treat all
those constants as unsigned for the sake of consistency.  Thanks Stefan
for pointing out what I missed (shift into the sign bit).

jeff

Re: [PATCH PR94274] fold phi whose incoming args are defined from binary

[Jeff Law via Gcc-patches]

On 6/11/20 6:01 AM, Zhanghaijian (A) wrote:
> Hi,
>
> This is a experimental fix for pr94274.
> For if/else structure, when the expressions is binary operation and have a 
> common subexpression, and the opcode is the same, we can
> fold the merging phi node in tree_ssa_phiopt_worker (ssa-phiopt). It can be 
> optimized to do csel first and then do binary operations.
> This can eliminate one or more instructions. And this patch is effective for 
> 500.perlbench_r in spec2017.
> Bootstrap and tested on aarch64/x86_64 Linux platform. No new regression 
> witnessed.
>
> Any suggestion?  
>
> Thanks,
> Haijian Zhang
>
> pr94274-v1.diff
>
> From 1f0f09ef3170569ef15791cf3e70de781a9a4cb0 Mon Sep 17 00:00:00 2001
> From: Haijian Zhang 
> Date: Thu, 11 Jun 2020 14:56:44 +0800
> Subject: [PATCH] fold phi whose incoming args are defined from binary
>  operations [PR94274]
>
> For if/else structure, when the expressions is binary operation and
> have a common subexpression, and the opcode is the same. We can fold
> the merging phi node in tree_ssa_phiopt_worker (ssa-phiopt). It can
> be optimized to do csel first and then do binary operations. This can
> eliminate one or more instructions.
>
> 2020-06-11  Haijian Zhang  
>
> gcc/
>
>   PR tree-optimization/94274
>   * common.opt (ftree-combine): New option.
>   * doc/invoke.texi (-ftree-combine): Document new option.
>   * opts.c (default_options_table): Enable -ftree-combine at -O1.
>   * passes.def: Add pass_adjust_alignment.
>   * tree-pass.h (make_pass_tree_combine): New.
>   * tree-ssa-phiopt.c (pass_data_tree_combine): New.
> gcc/testsuite/
>   PR tree-optimization/94274
>   * gcc.dg/tree-ssa/pr94274-1.c: New test.
>   * gcc.dg/tree-ssa/pr94274-2.c: Likewise.
>   * gcc.dg/tree-ssa/pr94274-3.c: Likewise.
I like a lot of what I see in here.   Do you have a copyright assignment
and employer disclaimer on file with the FSF?  If not, then we can't
take the submission at this time.


> ---
>  gcc/ChangeLog |  10 +
>  gcc/common.opt|   4 +
>  gcc/doc/invoke.texi   |  15 +-
>  gcc/opts.c|   1 +
>  gcc/passes.def|   1 +
>  gcc/testsuite/ChangeLog   |   7 +
>  gcc/testsuite/gcc.dg/tree-ssa/pr94274-1.c |  15 +
>  gcc/testsuite/gcc.dg/tree-ssa/pr94274-2.c |  26 ++
>  gcc/testsuite/gcc.dg/tree-ssa/pr94274-3.c |  16 +
>  gcc/tree-pass.h   |   1 +
>  gcc/tree-ssa-phiopt.c | 352 +-
>  11 files changed, 440 insertions(+), 8 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr94274-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr94274-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr94274-3.c
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index b0860738d04..c1a5bf87626 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,13 @@
> +2020-06-11  Haijian Zhang  
> +
> + PR tree-optimization/94274
> + * common.opt (ftree-combine): New option.
> + * doc/invoke.texi (-ftree-combine): Document new option.
> + * opts.c (default_options_table): Enable -ftree-combine at -O1.
> + * passes.def: Add pass_adjust_alignment.
> + * tree-pass.h (make_pass_tree_combine): New.
> + * tree-ssa-phiopt.c (pass_data_tree_combine): New.
You should reference tree-optimization/64700 as well.   While your patch
doesn't address all the issues in 64700, it's an excellent start.

> +
>  2020-06-10  Martin Sebor  
>  
>   PR middle-end/95353
> diff --git a/gcc/common.opt b/gcc/common.opt
> index df8af365d1b..f4441aa9ddd 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -2721,6 +2721,10 @@ ftree-cselim
>  Common Report Var(flag_tree_cselim) Init(2) Optimization
>  Transform condition stores into unconditional ones.
>  
> +ftree-combine
> +Common Report Var(flag_tree_combine) Optimization
> +Combine binary operations using SSA PHI nodes.
I probably would bother with a switch for this.  There's already a flag
to control phi-opt as a whole and that seems fine for this change as well.

> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr94274-1.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/pr94274-1.c
> new file mode 100644
> index 000..f883c6a3201
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr94274-1.c
> @@ -0,0 +1,15 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-combine" } */
> +
> +int foo (int cond, int a, int b, int c)
> +{
> +  int result = 0;
> +
> +  if (cond == 1)
> +result = b + a;
> +  else
> +result = a + c;
> +  return result;
> +}
You should look at comment #3 in pr64700 which I think has a couple more
test cases.diff --git a/gcc/tree-ssa-phiopt.c b/gcc/tree-ssa-phiopt.c


> index 5f283890998..9b09330c026 100644
> --- a/gcc/tree-ssa-phiopt.c
> +++ b/gcc/tree-ssa-phiopt.c
> @@ -48,7 +48,7 @@ along with GCC; see the file 

Re: [PATCH] PowerPC: PR libgcc/97543, fix 64-bit long double issues

[Segher Boessenkool]

Hi!

On Thu, Nov 19, 2020 at 06:43:02PM -0500, Michael Meissner wrote:
> One feature of the current GNU attribute implementation is if you have a 
> shared
> library (such as libgcc_s.so), the GNU attributes for the shared library is an
> inclusive OR of all of the modules within the library.  This means if any
> module uses the -mlong-double-128 option and uses long double, the GNU
> attributes for the library will indicate that it uses 128-bit IBM long
> doubles.  If you have a static library, you will get the warning only if you
> actually reference a module with the attribute set.

(You use "module" a lot, here and in the patch; just "object file" would
be clearer I think.  "Module" has a specific (and different)( meaning in
many contexts.)

> 2) I turned off GNU attributes for building the shared library or for
> building the IBM 128-bit long double support.

It's not clear to me what error disabling setting it for the static
library avoids?  Not that it *hurts* of course.  Do you have an example
for this?

Anyway, okay for trunk (and backports later).  Thanks!


Segher

Re: [PATCH, rs6000] Add non-relative jump table support on Power Linux

[Segher Boessenkool]

Hi!

Sorry this took so long.

On Thu, Oct 15, 2020 at 04:46:01PM +0800, HAO CHEN GUI wrote:
> On 29/9/2020 上午 6:46, Segher Boessenkool wrote:
> >[ Please do not insert patches into discussions ]

So, please send new patches as a new thread.  This makes it much easier
to handle.  If you want to reply to something in the old thread just do
it there, but send the new patch not as a reply.

>   * config/rs6000/rs6000.opt (mrelative-jumptables): Add
>   mrelative-jumptables.

Just "New." or "New flag." or similar?

> +/* Implement TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC.
> +   Marco relative jumpstables indicates addr_diff_vec or addr_vec.  */

The documentation says
  Return true to generate ADDR_DIF_VEC table or false to generate
  ADDR_VEC table for jumps in case of -fPIC.
but you can just leave out that last line completely.

> +  if (rs6000_relative_jumptables)
> + {
> +   if (TARGET_32BIT)
> + jump = gen_tablejumpsi_nospec (operands[0], operands[1], ccreg);
> +   else
> + jump = gen_tablejumpdi_nospec (operands[0], operands[1], ccreg);
> + }
>else
> - jump = gen_tablejumpdi_nospec (operands[0], operands[1], ccreg);
> + jump = gen_tablejump_absolute_nospec (Pmode, operands[0], operands[1],
> +   ccreg);
>emit_jump_insn (jump);

It now is
  @tablejump_nospec
so this code will become something like

  if (rs6000_relative_jumptables)
jump = gen_tablejumpsi_nospec (Pmode, operands[0], operands[1], ccreg);
  else
jump = gen_tablejump_absolute_nospec (Pmode, operands[0], operands[1],
  ccreg);
  emit_jump_insn (jump);


Okay for trunk with those changes.  Thank you!


Segher

Re: [PATCH] Objective-C++ : Allow prefix attrs on linkage specs.

[Jason Merrill via Gcc-patches]

On Mon, Nov 23, 2020 at 8:52 AM Iain Sandoe  wrote:

> Jason Merrill  wrote:
>
> > On 11/7/20 10:11 AM, Iain Sandoe wrote:
>
> >> +  warning_at (token1->location, OPT_Wattributes, "attributes
> are"
> >> +  " only permitted in this position for
> Objective-C++,"
> >> +  " ignored");
> >
> > It would be nice for the warning to suggest where to move the
> attribute,
> > rather than just say that this location is bad.
>
> f.C:
>
> __attribute__(())
> extern "C" int foo (void);
>
> ===
>
> So, I looked at two possibles.
>
> 1/ trying to use a fixit hint - but this seems a little lacking in
> information to me.
>
> f.C:2:1: warning: attributes are only permitted in this position for
> Objective-C++ (ignored for C++) [-Wattributes]
>  2 | __attribute__(())
>| ^
>  3 | extern "C" int foo (void);
>|__attribute__
>
> (NOTE: ‘__attribute__' starting indent is below ‘int’ for a fixed spacing
> font)
>
> 2/ adding an inform:
>
> f.C:2:1: warning: attributes are only permitted in this position for
> Objective-C++ (ignored for C++) [-Wattributes]
>  2 | __attribute__(())
>| ^
> f.C:3:12: note: for C++, attributes may be added here
>  3 | extern "C" int foo (void);
>|^~~
>
> (NOTE: likewise,   ^~~ starting indent is below ‘int’ for a fixed spacing
> font)
>
> ===
>
> I’m inclined to think that the second is more useful,
> but have patches for both,
> which (or something else) do you prefer?
>

I agree that the second is preferable, thanks.  But let's not underline all
of "int" there, just the caret is sufficient.  I'd also drop the mention of
Obj-C++.

Jason

Re: *ping* [patch, fortran] Correct fndecls for some library functions

[Thomas Koenig via Gcc-patches]

Hi Iain,


Is there some testcase that can be used to see a progression from
applying this patch?


I haven't been able to find anything.  Previously, everything was
passed as ". r r r r r r" and so on; there were also too many
arguments for functions like findloc.  Since "r " is the most
conservative thing you can do, I suppose it didn't lead to wrong code,
at least.

Best regards

Thomas

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Thomas Koenig via Gcc-patches]

Am 23.11.20 um 22:51 schrieb Maciej W. Rozycki:

/* Define to 1 if you have the  header file. */
#undef HAVE_IEEEFP_H

So perhaps it does do the "right thing" if you do not have this header file on
your VAX operating system.

  Well it does not:

In file included from .../libgfortran/generated/maxval_r4.c:26:
.../libgfortran/generated/maxval_r4.c: In function 'maxval_r4':
.../libgfortran/libgfortran.h:292:30: warning: target format does not support 
infinity
   292 | # define GFC_REAL_4_INFINITY __builtin_inff ()
   |  ^~


This is guarded with

#ifdef __FLT_HAS_INFINITY__
# define GFC_REAL_4_INFINITY __builtin_inff ()
#endif

I don't know how or why __FLT_HAS_INFINITY is set for a target which
does not support it, but if you get rid of that macro, that particular
problem should be solved.

Best regards

Thomas

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Sat, 21 Nov 2020, Toon Moene wrote:

> > 2. libgfortran -- oddly enough for Fortran a piece requires IEEE 754
> > floating-point arithmetic (possibly a porting problem too).
> 
> gcc/libgfortran/config.h.in does have:
> 
> /* Define to 1 if you have the  header file. */
> #undef HAVE_IEEEFP_H
> 
> So perhaps it does do the "right thing" if you do not have this header file on
> your VAX operating system.

 Well it does not:

In file included from .../libgfortran/generated/maxval_r4.c:26:
.../libgfortran/generated/maxval_r4.c: In function 'maxval_r4':
.../libgfortran/libgfortran.h:292:30: warning: target format does not support 
infinity
  292 | # define GFC_REAL_4_INFINITY __builtin_inff ()
  |  ^~
.../libgfortran/generated/maxval_r4.c:149:19:
note: in expansion of macro 'GFC_REAL_4_INFINITY'
  149 | result = -GFC_REAL_4_INFINITY;
  |   ^~~
.../libgfortran/generated/maxval_r4.c: In function 'mmaxval_r4':
.../libgfortran/libgfortran.h:292:30: warning: target format does not support 
infinity
  292 | # define GFC_REAL_4_INFINITY __builtin_inff ()
  |  ^~
.../libgfortran/generated/maxval_r4.c:363:19:
note: in expansion of macro 'GFC_REAL_4_INFINITY'
  363 | result = -GFC_REAL_4_INFINITY;
  |   ^~~
{standard input}: Assembler messages:
{standard input}:204: Fatal error: Can't relocate expression
make[3]: *** [Makefile:3358: maxval_r4.lo] Error 1

with the offending assembly instruction at 204 being:

movf $0f+QNaN,%r2

and the `QNaN' part of the operand being what GAS complains about (of 
course it is a problem too that GCC lets the infinity intrinsics through 
with a mere warning and rubbish emitted rather than bailing out right 
away, but they are not supposed to be requested in the first place as the 
notion of infinity is specific to IEEE 754 FP and the VAX FP format used 
here does not support such an FP datum).

 The absence of IEEE 754 FP is correctly recognised by the configuration 
script:

checking for ieeefp.h... no
[...]
configure: FPU dependent file will be fpu-generic.h
configure: Support for IEEE modules: no

> The Fortran Standard allows an implementation *not* to have IEEE floating
> point support ...

 Given how long before IEEE 754 Fortran was invented I would be rather 
surprised if it was the other way round, which is why I have suspected, as 
I have noted in the piece quoted above, a problem with the VAX/NetBSD port 
of libgfortran.

  Maciej

[PATCH] IBM Z: Update autovec-*-quiet-uneq expectations

[Ilya Leoshkevich via Gcc-patches]

Commit 229752afe315 ("VEC_COND_EXPR optimizations") has improved code
generation: we no longer need "vx x,x,-1", which turned out to be
superfluous.  Instead, we simply swap 0 and -1 arguments of the
preceding "vsel".

gcc/testsuite/ChangeLog:

2020-11-23  Ilya Leoshkevich  

* gcc.target/s390/zvector/autovec-double-quiet-uneq.c: Expect
that "vx" is not emitted.
* gcc.target/s390/zvector/autovec-float-quiet-uneq.c: Likewise.
---
 .../gcc.target/s390/zvector/autovec-double-quiet-uneq.c  | 5 -
 .../gcc.target/s390/zvector/autovec-float-quiet-uneq.c   | 5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/s390/zvector/autovec-double-quiet-uneq.c 
b/gcc/testsuite/gcc.target/s390/zvector/autovec-double-quiet-uneq.c
index 3d6da30beac..7c9b20fd2e0 100644
--- a/gcc/testsuite/gcc.target/s390/zvector/autovec-double-quiet-uneq.c
+++ b/gcc/testsuite/gcc.target/s390/zvector/autovec-double-quiet-uneq.c
@@ -5,6 +5,9 @@
 
 AUTOVEC_DOUBLE (QUIET_UNEQ);
 
+/* { dg-final { scan-assembler {\n\tvzero\t} } } */
+/* { dg-final { scan-assembler {\n\tvgmg\t} } } */
 /* { dg-final { scan-assembler-times {\n\tvfchdb\t} 2 } } */
 /* { dg-final { scan-assembler {\n\tvo\t} } } */
-/* { dg-final { scan-assembler {\n\tvx\t} } } */
+/* { dg-final { scan-assembler {\n\tvsel\t} } } */
+/* { dg-final { scan-assembler-not {\n\tvx\t} } } */
diff --git a/gcc/testsuite/gcc.target/s390/zvector/autovec-float-quiet-uneq.c 
b/gcc/testsuite/gcc.target/s390/zvector/autovec-float-quiet-uneq.c
index 1df53a99bc8..5ab9337880d 100644
--- a/gcc/testsuite/gcc.target/s390/zvector/autovec-float-quiet-uneq.c
+++ b/gcc/testsuite/gcc.target/s390/zvector/autovec-float-quiet-uneq.c
@@ -5,6 +5,9 @@
 
 AUTOVEC_FLOAT (QUIET_UNEQ);
 
+/* { dg-final { scan-assembler {\n\tvzero\t} } } */
+/* { dg-final { scan-assembler {\n\tvgmf\t} } } */
 /* { dg-final { scan-assembler-times {\n\tvfchsb\t} 2 } } */
 /* { dg-final { scan-assembler {\n\tvo\t} } } */
-/* { dg-final { scan-assembler {\n\tvx\t} } } */
+/* { dg-final { scan-assembler {\n\tvsel\t} } } */
+/* { dg-final { scan-assembler-not {\n\tvx\t} } } */
-- 
2.25.4

Re: [PATCH] warn for integer overflow in allocation calls (PR 96838)

[Martin Sebor via Gcc-patches]

On 11/21/20 6:26 AM, Andrew MacLeod wrote:

On 11/21/20 12:07 AM, Jeff Law wrote:


On 11/9/20 9:00 AM, Martin Sebor wrote:

Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554000.html

Jeff, I don't expect to have the cycles to reimplement this patch
using the Ranger APIs before stage 1 closes.  I'm open to giving
it a try in stage 3 if it's still in scope for GCC 11.  Otherwise,
is this patch okay to commit?

So all we're going to get from the ranger is ranges of operands, right?
Meaning that we still need to either roll our own evaluator
(eval_size_vflow) or overload range_for_stmt with our own, which likely
looks like eval_size_vflow anyway, right?

My hope was to avoid the roll our own evaluator, but that doesn't look
like it's in the cards in the reasonably near future.


Is there a PR open showing what exactly you are looking for?
I'm using open PRs to track enhancement requests, and they will all feed 
back into the development roadmap  I am working on.


Not that I know of.  The background is upthread, in particular in
Aldy's response here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554242.html

I like the suggestion and if/when I have the time I'd like to give
it a try.  Until then, I think the patch is useful on its own so
I'll go with it for now.

Longer term, I do hope we can revisit the idea of computing either
mathematically correct ranges alongside those required by the language
semantics, or tracking signed overflow or unsigned wraparound.  E.g.,
in:

  void* f (int n)
  {
if (n < INT_MAX / 3)
  n = INT_MAX / 3;

n *= sizeof (int);
// n is [(INT_MAX / 3) * 4, INF] mathematically
// undefined due to overflow in C
// but [INT_MIN, INT_MAX] according to VRP

return malloc (n);
  }

and in

  void* g (unsigned n)
  {
if (n < UINT_MAX / 3)
  n = UINT_MAX / 3;

n *= sizeof (int);
// n is [(UINT_MAX / 3) * 4, INF] mathematically
// but [0, UINT_MAX] in C

return malloc (n);
  }

In neither case is the overflow (or wraparound) easy to detect
without the Ranger's help.

Martin


If my summary of the current state is correct, then I'd suggest we go
with the patch as-is.  If we want to override eval_size_vflow in the
future, we can still do that.  And if we want to replace the call to
determine_value_range with a ranger API, that seems like a fairly
straightforward change to make in gcc-12.



Jeff

Re: *ping* [patch, fortran] Correct fndecls for some library functions

[Iain Sandoe via Gcc-patches]

Hi Thomas.

Thomas Koenig via Fortran  wrote:




this patch makes sure that we pass the correct fn decls for
some of our library functions. cshift and others still remain
to be implemented.
This is a step in our voyage to stop lying to the middle end :-)
Regression-tested. OK for trunk?


Ping?

(I am not 100% sure this mail ever made it to the mailing list,
but it is in the archive at

https://gcc.gnu.org/pipermail/fortran/2020-November/055303.html

).


Very much in favour of accuracy to the middle end (and ultimately
lowering of calls).

Is there some testcase that can be used to see a progression from
applying this patch?

Iain

Re: [PATCH 3/3] PowerPC: Require IBM long double for conversion test.

[Segher Boessenkool]

On Sat, Nov 21, 2020 at 12:39:53AM -0500, Michael Meissner wrote:
> The test c-c++-common/dfp/convert-bfp-11.c explicit expects long double to use
> the IBM 128-bit extended double format.  In particular, some of the tests
> expect an infinity to be created if decimal values that are converted that are
> too large for IBM extended double.  However, the numbers do fit in the range
> for IEEE 128-bit format, since it has a larger exponent than the IBM 128-bit
> format.  The test fails because an infinity is not generated.

> 2020-11-21  Michael Meissner  
> 
>   * c-c++-common/dfp/convert-bfp-11.c: Require IBM 128-bit long
>   double.

Okay for trunk (and backports later).  Thanks!


Segher

[PATCH] PR fortran/85796 - Floating point exception with implied do

[Harald Anlauf]

The patch below is based on a previous version by Steve.
The present version fixes an additional copy error.

Needless to say that it (still!) regtests cleanly on x86_64-pc-linux-gnu.

OK for master?  As it appears safe, OK for backport to at least 10-branch?

Thanks,
Harald


PR fortran/85796 - Floating point exception with implied do

Catch invalid step=0 in implied do loop within data statements.

gcc/fortran/ChangeLog:

PR fortran/85796
* resolve.c (traverse_data_list): Fix copy errors; catch
step=0 in implied do loop.

gcc/testsuite/ChangeLog:

PR fortran/85796
* gfortran.dg/pr85796.f90: New test.

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 1641eb6ca10..b6d21ad1bac 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -16327,7 +16327,7 @@ traverse_data_list (gfc_data_variable *var, locus *where)
   || end->expr_type != EXPR_CONSTANT)
 {
   gfc_error ("end of implied-do loop at %L could not be "
-		 "simplified to a constant value", >where);
+		 "simplified to a constant value", >where);
   retval = false;
   goto cleanup;
 }
@@ -16335,7 +16335,14 @@ traverse_data_list (gfc_data_variable *var, locus *where)
   || step->expr_type != EXPR_CONSTANT)
 {
   gfc_error ("step of implied-do loop at %L could not be "
-		 "simplified to a constant value", >where);
+		 "simplified to a constant value", >where);
+  retval = false;
+  goto cleanup;
+}
+  if (mpz_cmp_si (step->value.integer, 0) == 0)
+{
+  gfc_error ("step of implied-do loop at %L shall not be zero",
+		 >where);
   retval = false;
   goto cleanup;
 }
diff --git a/gcc/testsuite/gfortran.dg/pr85796.f90 b/gcc/testsuite/gfortran.dg/pr85796.f90
new file mode 100644
index 000..78683787fbb
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr85796.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/85796 - Floating point exception with implied do in data statement
+
+program p
+  implicit none
+  integer :: i, j, x(2,2)
+  data ((x(i,j),i=1,2,j-1),j=1,2) /3*789/ ! { dg-error "step of implied-do loop" }
+end

Re: [06/32] cpp macros

[Jeff Law via Gcc-patches]

On 11/3/20 2:14 PM, Nathan Sidwell wrote:
>
> Header units can provide macros to an importer.  For efficiency that
> is done lazily.  When we import a header unit we mark the identifers
> it defines as significant.  It's only when we need the macro
> definition (including in #ifdef &| defined (X) processing) that we
> resolve the macro.  We already had lazy (builtin) macros.  This
> extends it to deferred macros.  Each deferred macro has an index the
> resolver can use.   on an LP64 host that index does not inlarge the
> node structure.
>
> As a macro can be undefined by this mechanism, the users of this
> deferred interface must be prepared to handle 'not a macro after all'
>
>
>
>
> 06-cpp-macro.diff
>
>
OK with the usual ChangeLog note.
jeff

Re: PING: Re: [PATCH] Add analyzer plugin support and CPython GIL example

[Jeff Law via Gcc-patches]

On 11/10/20 2:51 PM, David Malcolm via Gcc-patches wrote:
> I'd like to ping this patch:
>   https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556214.html
> Are the non-analyzer parts OK for master?
Just looking for an ACK on the analyzer_init notification bits in the
generic parts of the compiler?  If so, yea, that's fine.  Sorry for the
delay.

jeff

Re: [PATCH] cache compute_objsize results in strlen/sprintf (PR 97373)

[Jeff Law via Gcc-patches]

On 11/4/20 5:58 PM, Martin Sebor via Gcc-patches wrote:
> To determine the target of a pointer expression and the offset into
> it, the increasingly widely used compute_objsize function traverses
> the IL following the DEF statements of pointer variables, aggregating
> offsets from POINTER_PLUS assignments along the way.  It does that
> for many statements that involve pointers, including calls to
> built-in functions and (so far only) accesses to char arrays.  When
> a function has many such statements with pointers to the same objects
> but with different offsets, the traversal ends up visiting the same
> pointer assignments repeatedly and unnecessarily.
>
> To avoid this repeated traversal, the attached patch adds the ability
> to cache results obtained in prior calls to the function.  The cache
> is optional and only used when enabled.
>
> To exercise the cache I have enabled it for the strlen pass (which
> is probably the heaviest compute_objsize user).  That happens to
> resolve PR 97373 which tracks the pass' failure to detect sprintf
> overflowing allocated buffers at a non-constant offset.  I thought
> about making this a separate patch but the sprintf/strlen changes
> are completely mechanical so it didn't seem worth the effort.
>
> In the benchmarking I've done the cache isn't a huge win there but
> it does have a measurable difference in the project I'm wrapping up
> where most pointer assignments need to be examined.  The space used
> for the cache is negligible on average: fewer than 20 entries per
> Glibc function and about 6 for GCC.  The worst case in Glibc is
> 6 thousand entries and 10k in GCC.  Since the entries are sizable
> (216 bytes each) the worst case memory consumption can be reduced
> by adding a level of indirection.  A further savings can be obtained
> by replacing some of the offset_int members of the entries with
> HOST_WIDE_INT.
>
> The efficiency benefits of the cache should increase further as more
> of the access checking code is integrated into the same pass.  This
> should eventually include the checking currently done in the built-in
> expanders.
>
> Tested on x86_64-linux, along with Glibc and Binutils/GDB.
>
> Martin
>
> PS The patch add the new pointer_query class (loosely modeled on
> range_query) to builtins.{h,c}.  This should be only temporary,
> until the access checking code is moved into a file (and ultimately
> a pass) of its own.
>
> gcc-97373.diff
>
> PR middle-end/97373 - missing warning on sprintf into allocated destination
>
> gcc/ChangeLog:
>
>   PR middle-end/97373
>   * builtins.c (compute_objsize): Rename...
>   (compute_objsize_r): to this.  Change order and types of arguments.
>   Use new argument.  Adjust calls to self.
>   (access_ref::get_ref): New member function.
>   (pointer_query::pointer_query): New member function.
>   (pointer_query::get_ref): Same.
>   (pointer_query::put_ref): Same.
>   (handle_min_max_size): Change order and types of arguments.
>   (maybe_emit_free_warning): Add a test.
>   * builtins.h (class pointer_query): New class.
>   (compute_objsize): Declare an overload.
>   * gimple-ssa-sprintf.c (get_destination_size):
>   (handle_printf_call):
>   * tree-ssa-strlen.c (adjust_last_stmt): Add an argument and use it.
>   (maybe_warn_overflow): Same.
>   (handle_builtin_strcpy): Same.
>   (maybe_diag_stxncpy_trunc): Same.
>   (handle_builtin_memcpy): Change argument type.  Adjust calls.
>   (handle_builtin_strcat): Same.
>   (handle_builtin_memset): Same.
>   (handle_store): Same.
>   (strlen_check_and_optimize_call): Same.
>   (check_and_optimize_stmt): Same.
>   (strlen_dom_walker): Add new data members.
>   (strlen_dom_walker::before_dom_children): Use new member.
>   (printf_strlen_execute): Dump cache performance counters.
>   * tree-ssa-strlen.h (maybe_diag_stxncpy_trunc): Add argument.
>   (handle_printf_call): Change argument type.
>
> gcc/testsuite/ChangeLog:
>
>   PR middle-end/97373
>   * gcc.dg/warn-strnlen-no-nul.c:
>   * g++.dg/warn/Wmismatched-new-delete-2.C: New test.
>   * gcc.dg/tree-ssa/builtin-sprintf-warn-25.c: New test.
I'm going to hesitatingly ACK this. 

The reason I saw hesitatingly is because I suspect that we're going to
see more cases where caching would be useful and I'd like to have a
general way to do that.  We've already got a ton of caching code in
Ranger and I fully expect more as we continue to write analysis code
that wants to walk backwards.  I don't want to see multiple
implementations of simple caching code.

Additionally, if you're doing so many queries in a subsequent patch that
caching is needed, then that may be an indication that you're doing too
much work.  I can't really evaluate that yet as I haven't looked at the
subsequent patch where this becomes a significant issue.

So expect pushback if further cache implementations are introduced.

Jeff

Re: test: Update cases for vect_partial_vectors_usage_1

[Richard Sandiford via Gcc-patches]

"Kewen.Lin"  writes:
> Hi,
>
> I adjusted some vectorization test cases for vect_partial_vectors_usage_1
> before, but as exposed in the recent testings, some of them need to be
> adjusted again.  The reason is that the commit r11-3393 improved the
> epilogue loop handling of partial vectors and we won't use partial vectors
> to vectorize a single iteration scalar loop now.
>
> The affected test cases have only one single iteration in their epilogues
> separately, so we shouldn't expect the vectorization to happen on the
> epilogues any more.
>
> Tested with explicit --param=vect-partial-vector-usage=1 and default
> enablement.
>
> Is it ok for trunk?
>
> BR,
> Kewen
> -
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.dg/vect/slp-perm-1.c: Adjust for partial vectors.
>   * gcc.dg/vect/slp-perm-5.c: Likewise.
>   * gcc.dg/vect/slp-perm-6.c: Likewise.
>   * gcc.dg/vect/slp-perm-7.c: Likewise.

OK, thanks.

> diff --git a/gcc/testsuite/gcc.dg/vect/slp-perm-1.c 
> b/gcc/testsuite/gcc.dg/vect/slp-perm-1.c
> index 4128cca024c..ca7803ec1a9 100644
> --- a/gcc/testsuite/gcc.dg/vect/slp-perm-1.c
> +++ b/gcc/testsuite/gcc.dg/vect/slp-perm-1.c
> @@ -80,9 +80,7 @@ int main (int argc, const char* argv[])
>  }
>  
>  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect"  { target 
> vect_perm } } } */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" 
> { target { vect_perm3_int && { {! vect_load_lanes } && {! 
> vect_partial_vectors_usage_1 } } } } } } */
> -/* The epilogues are vectorized using partial vectors.  */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" 
> { target { vect_perm3_int && { {! vect_load_lanes } && 
> vect_partial_vectors_usage_1 } } } } } */
> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" 
> { target { vect_perm3_int && {! vect_load_lanes } } } } } */
>  /* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 0 "vect" 
> { target vect_load_lanes } } } */
>  /* { dg-final { scan-tree-dump "Built SLP cancelled: can use 
> load/store-lanes" "vect" { target { vect_perm3_int && vect_load_lanes } } } } 
> */
>  /* { dg-final { scan-tree-dump "LOAD_LANES" "vect" { target vect_load_lanes 
> } } } */
> diff --git a/gcc/testsuite/gcc.dg/vect/slp-perm-5.c 
> b/gcc/testsuite/gcc.dg/vect/slp-perm-5.c
> index b137821ec39..b86a3dc8756 100644
> --- a/gcc/testsuite/gcc.dg/vect/slp-perm-5.c
> +++ b/gcc/testsuite/gcc.dg/vect/slp-perm-5.c
> @@ -104,9 +104,7 @@ int main (int argc, const char* argv[])
>  }
>  
>  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect"  { target 
> vect_perm } } } */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" 
> { target { vect_perm3_int && { {! vect_load_lanes } && {! 
> vect_partial_vectors_usage_1 } } } } } } */
> -/* The epilogues are vectorized using partial vectors.  */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "vect" 
> { target { vect_perm3_int && { {! vect_load_lanes } && 
> vect_partial_vectors_usage_1 } } } } } */
> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" 
> { target { vect_perm3_int && { ! vect_load_lanes } } } } } */
>  /* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 0 "vect" 
> { target vect_load_lanes } } } */
>  /* { dg-final { scan-tree-dump "Built SLP cancelled: can use 
> load/store-lanes" "vect" { target { vect_perm3_int && vect_load_lanes } } } } 
> */
>  /* { dg-final { scan-tree-dump "LOAD_LANES" "vect" { target vect_load_lanes 
> } } } */
> diff --git a/gcc/testsuite/gcc.dg/vect/slp-perm-6.c 
> b/gcc/testsuite/gcc.dg/vect/slp-perm-6.c
> index 5f121b52ffb..bec1544650a 100644
> --- a/gcc/testsuite/gcc.dg/vect/slp-perm-6.c
> +++ b/gcc/testsuite/gcc.dg/vect/slp-perm-6.c
> @@ -103,10 +103,7 @@ int main (int argc, const char* argv[])
>  }
>  
>  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect"  { target 
> vect_perm } } } */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" 
> { target { vect_perm3_int && { {! vect_load_lanes } && {! 
> vect_partial_vectors_usage_1 } } } } } } */
> -/* The epilogues are vectorized using partial vectors.  */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "vect" 
> { target { vect_perm3_int && { {! vect_load_lanes } && 
> vect_partial_vectors_usage_1 } } } } } */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" 
> { target { vect_perm3_int && vect_load_lanes } } } } */
> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" 
> { target vect_perm3_int } } } */
>  /* { dg-final { scan-tree-dump "Built SLP cancelled: can use 
> load/store-lanes" "vect" { target { vect_perm3_int && vect_load_lanes } xfail 
> *-*-* } } } */
>  /* { dg-final { scan-tree-dump "LOAD_LANES" "vect" { target vect_load_lanes 
> xfail vect_perm3_int } } } */
>  /* { dg-final { 

Re: [PATCH 2/3] PowerPC: require IBM long double for pr70117.

[Segher Boessenkool]

Hi!

On Sat, Nov 21, 2020 at 12:37:10AM -0500, Michael Meissner wrote:
> Since the test is explicitly checking for IBM extended double, do not try to
> run it when long double is IEEE 128-bit.

Before your change, it would explicitly use __ibm128 if that is not the
same as long double.

You need a better explanation / justification for the patch.

What goes wrong without the patch?  Is that to be expected?  Etc.

You get less coverage than before after this patch (it will now only run
on systems that have double-double as long double).


Segher

Re: [ Preprocessor ] [ Common ] Feature: Macros for identifying the wide and narrow execution string literal encoding

[JeanHeyd Meneide via Gcc-patches]

Dear Jeff,

On Mon, Nov 23, 2020 at 3:02 PM Jeff Law  wrote:
>
> You use a getter function to retrieve the value of ret.to, which is
> fine.  Is there a specific reason why you're not using a setter function
> to save the value?

 I did this because I have access to ret.to in the libcpp
functions! Outside, the structure of that type is unknown and only a
pointer, so it needs the getter function.

Sincerely,
JeanHeyd

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Fri, 20 Nov 2020, Anders Magnusson wrote:

> >   Then there is a fix for the PDP11 backend addressing an issue I found in
> > the handling of floating-point comparisons.  Unlike all the other changes
> > this one has not been regression-tested, not even built as I have no idea
> > how to prepare a development environment for a PDP11 target (also none of
> > my VAX pieces is old enough to support PDP11 machine code execution).
> You could use simh /w 2.11BSD, or if you want to test it on real hardware I
> have a 11/83 where you could test?

 This promises a lot of fun, but regrettably I think I cannot afford the 
time required to get this set up right now.  And getting at a piece of 
hardware, real or simulated, is the least of the problem here.  Getting a 
proper cross-compilation environment set up is, as Paul's recent response 
also indicates.  And to verify this change it is all that is needed really 
(though running full testing never hurts).

 Running testing across the Internet, while supported by DejaGNU, even (or 
maybe especially) if all the security issues around it have been sorted is 
going to be terribly slow.  And having peeked at the PDP-11 compatibility 
chapter of the VAX 032 spec I note that it does not actually include FPU 
emulation, so it would have to be a real PDP-11 piece anyway.

 Anyway once the patches have been merged, which given all the approvals 
from Jeff I think is going to take until verification completes by the end 
of this week, I need to move on.

 First I need to figure out why an attempt to use a DEFPA FDDI network 
interface with my brand new POWER9 system makes the system firmware spew a 
flood of warning messages on the main console (there's the BMC console as 
well) and the interface fails to initialise and work; the MAC address is 
retrieved as all-zeros.  I only brought the system up enough to complete 
this effort and I need to complete the rest while I'm onsite (owing to the 
pandemic).

 NB as a precaution to anyone considering to use POWER9 for software 
development: I have learnt the hard way with this very VAX/GCC effort of 
one embarassing shortcoming of the architecture when it comes to this kind 
of use.  It only implements a lone single hardware watchpoint, and then a 
security-impared one, which therefore has to be force-enabled (with Linux 
anyway) before it can be used (cf. Documentation/powerpc/dawr-power9.rst 
in Linux sources).  Consequently I had to take extra care not to have more 
then one watchpoint set at any given time or GDB would resort to using 
software watchpoints, painfully slow.

 I used to think watchpoints are for granted nowadays and before getting 
this system I didn't even think such a silly shortcoming would be possible 
in 2020 with a performance chip where the cost of a couple watchpoints is 
nothing in terms of silicon.  I mean Intel x86 has had *four* of them as 
standard since 1985(!) in every single even most crippled implementation, 
and myself I have used this feature since 1991.  And even embedded chips 
such as MIPS ones usually have at least two these days.

 Based on my quick research this shortcoming has now been corrected with 
POWER10, but I find the 35 years required to get on par with x86 a bit 
disappointing, and of course I won't be able to make use of it anyway.

 Second I need to find a new day job.

  Maciej

Re: [PATCH 7/X] libsanitizer: Add tests

[Richard Sandiford via Gcc-patches]

Matthew Malcomson  writes:
> new file mode 100644
> index 
> ..a6a11866823ae8ba9c20b79ac068e84aa73e053d
> --- /dev/null
> +++ b/gcc/testsuite/lib/hwasan-dg.exp
> @@ -0,0 +1,121 @@
> +# Copyright (C) 2012-2019 Free Software Foundation, Inc.

2012-2020

> +
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with GCC; see the file COPYING3.  If not see
> +# .
> +
> +# Return 1 if compilation with -fsanitize=hwaddress is error-free for trivial
> +# code, 0 otherwise.
> +
> +load_lib asan-dg.exp

The “Return 1” comment is now misplaced.  However…

> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 
> ceee78c26a9379f908659ae3d594bca104227d04..18b8c5a60a089fcac7bf2a41adcc373f995fca0f
>  100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -10633,6 +10633,30 @@ proc check_effective_target_movdir { } {
>  } "-mmovdiri -mmovdir64b" ]
>  }
>  
> +# Return 1 if compilation with -fsanitize=address is error-free for trivial
> +# code, 0 otherwise.
> +
> +proc check_effective_target_fsanitize_address {} {
> +if ![check_no_compiler_messages fsanitize_address executable {
> + int main (void) { return 0; }
> +}] {
> + return 0;
> +}
> +
> +# asan doesn't work if there's a ulimit on virtual memory.
> +if ![is_remote target] {
> + if [catch {exec sh -c "ulimit -v"} ulimit_v] {
> + # failed to get ulimit
> + } elseif [regexp {^[0-9]+$} $ulimit_v] {
> + # ulimit -v gave a numeric limit
> + warning "skipping asan tests due to ulimit -v"
> + return 0;
> + }
> +}
> +
> +return 1;
> +}
> +

Looking at this again, I realise I was wrong to say that the
effective_target routines should be here.  I guess this function was in
asan-dg.exp because it doesn't add any flags to ensure that the address
sanitiser is used.  Instead it relies on the harness to add the flags
first.

So could you put this back but add:

#
# NOTE: This function should only be used between calls to asan_init
# and asan_finish.  It is therefore defined here rather than in
# target-supports.exp.

Similarly for the hwasan routines, but with hwasan_init and hwasan_finish.

Sorry for the runaround.

OK with that change, no need for another review round.

Thanks,
Richard

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

[Segher Boessenkool]

Hi!

On Sat, Nov 21, 2020 at 12:33:52AM -0500, Michael Meissner wrote:
> +# See if the target is a powerpc with the long double format that uses the 
> IBM
> +# extended double format.

"Return 1 if the target is PowerPC, and long double is IBM extended double."

> @@ -7939,6 +7992,9 @@ proc is-effective-target { arg } {
> "power10_hw" { set selected [check_power10_hw_available] }
> "ppc_float128_sw" { set selected [check_ppc_float128_sw_available] }
> "ppc_float128_hw" { set selected [check_ppc_float128_hw_available] }
> +   "ppc_long_double_ibm" { set selected [check_ppc_long_double_ibm] }
> +   "ppc_long_double_ieee" { set selected [check_ppc_long_double_ieee] }
> +   "ppc_long_double_64bit" { set selected [check_ppc_long_double_64bit] }
> "ppc_recip_hw"   { set selected [check_ppc_recip_hw_available] }
> "ppc_cpu_supports_hw" { set selected 
> [check_ppc_cpu_supports_hw_available] }
> "ppc_mma_hw" { set selected [check_ppc_mma_hw_available] }

Why this?  It just defines aliases to the exact same name?


Segher

Re: [PATCH][PR target/97642] Fix incorrect replacement of vmovdqu32 with vpblendd.

[Jeff Law via Gcc-patches]

On 11/4/20 2:19 AM, Hongtao Liu via Gcc-patches wrote:
> Hi:
>   When programmers explicitly use mask loaded intrinsics, don't
> transform the instruction to vpblend{b,w,d,q} since If mem_addr points
> to a memory region with less than whole vector size of accessible
> memory,  the mask would prevent reading the inaccessible bytes which
> could avoid fault.
>
>   Bootstrap is ok, gcc regress test for i386/x86_64 backend is ok.
>   Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/97642
> * config/i386/sse.md (UNSPEC_MASKLOAD): New unspec.
> (*_load_mask): New define_insns for masked load
> instructions.
> (_load_mask): Changed to define_expands which
> specifically handle memory operands.
> (_blendm): Changed to define_insns which are same
> as original _load_mask with adjustment of
> operands order.
> (*_load): New define_insn_and_split which is
> used to optimize for masked load with all one mask.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/avx512bw-vmovdqu16-1.c: Adjust testcase to
> make sure only masked load instruction is generated.
> * gcc.target/i386/avx512bw-vmovdqu8-1.c: Ditto.
> * gcc.target/i386/avx512f-vmovapd-1.c: Ditto.
> * gcc.target/i386/avx512f-vmovaps-1.c: Ditto.
> * gcc.target/i386/avx512f-vmovdqa32-1.c: Ditto.
> * gcc.target/i386/avx512f-vmovdqa64-1.c: Ditto.
> * gcc.target/i386/avx512vl-vmovapd-1.c: Ditto.
> * gcc.target/i386/avx512vl-vmovaps-1.c: Ditto.
> * gcc.target/i386/avx512vl-vmovdqa32-1.c: Ditto.
> * gcc.target/i386/avx512vl-vmovdqa64-1.c: Ditto.
> * gcc.target/i386/pr97642-1.c: New test.
> * gcc.target/i386/pr97642-2.c: New test.
>
>
> 0001-Fix-incorrect-replacement-of-vmovdqu32-with-vpblendd.patch
>
> From 48cf0adcd55395653891888f4768b8bdc19786f2 Mon Sep 17 00:00:00 2001
> From: liuhongt 
> Date: Tue, 3 Nov 2020 17:26:43 +0800
> Subject: [PATCH] Fix incorrect replacement of vmovdqu32 with vpblendd which
>  can cause fault.
>
> gcc/ChangeLog:
>
>   PR target/97642
>   * config/i386/sse.md (UNSPEC_MASKLOAD): New unspec.
>   (*_load_mask): New define_insns for masked load
>   instructions.
>   (_load_mask): Changed to define_expands which
>   specifically handle memory operands.
>   (_blendm): Changed to define_insns which are same
>   as original _load_mask with adjustment of
>   operands order.
>   (*_load): New define_insn_and_split which is
>   used to optimize for masked load with all one mask.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/i386/avx512bw-vmovdqu16-1.c: Adjust testcase to
>   make sure only masked load instruction is generated.
>   * gcc.target/i386/avx512bw-vmovdqu8-1.c: Ditto.
>   * gcc.target/i386/avx512f-vmovapd-1.c: Ditto.
>   * gcc.target/i386/avx512f-vmovaps-1.c: Ditto.
>   * gcc.target/i386/avx512f-vmovdqa32-1.c: Ditto.
>   * gcc.target/i386/avx512f-vmovdqa64-1.c: Ditto.
>   * gcc.target/i386/avx512vl-vmovapd-1.c: Ditto.
>   * gcc.target/i386/avx512vl-vmovaps-1.c: Ditto.
>   * gcc.target/i386/avx512vl-vmovdqa32-1.c: Ditto.
>   * gcc.target/i386/avx512vl-vmovdqa64-1.c: Ditto.
>   * gcc.target/i386/pr97642-1.c: New test.
>   * gcc.target/i386/pr97642-2.c: New test.
So in the BZ Jakub asked for the all-ones mask case to be specially
handled to emit a normal load.  I don't see where we're handling that. 
ISTM that we'd want a test for that too.  Right?

WIth that in place and tested, this is probably ready for the trunk.

jeff

Re: [C PATCH] Do not drop qualifiers for _Atomic in typeof

[Joseph Myers]

On Mon, 23 Nov 2020, Uecker, Martin wrote:

> Joseph,
> 
> here is the patch to not drop qualifiers for _Atomic in
> typeof. I am not sure whether this is appropriate in
> stage3, but I wanted to leave it here for you to comment
> and so that it does not lost.
> 
> First, I noticed that the change to drop qualifiers
> in lvalue conversion also implies that __auto_type now
> always uses the non-qualified type. I think this is more
> correct, and also what other compilers and C++'s auto do.
> The first change here in c-parser would remove the now
> redundant code to drop qualifiers for _Atomic types.
> 
> The second change would remove the code to drop qualifiers
> for _Atomic types for typeof. I would then use the
> comma operator for stdatomic to remove all qualifiers.
> Here, the question is whether this may have same
> unintended side effects.

This is OK, with references to bugs 65455 and 92935 as I think it fixes 
those.

Any change to qualifiers for typeof risks breaking something relying on 
the details of when the result is or is not qualified, but given that in 
previous GCC versions that was poorly defined and inconsistent, making 
these changes to make it more consistent seems reasonable.

It is probably still the case that _Typeof as proposed for ISO C would 
need special handling of function and function pointer types for the same 
reason as _Generic has such handling (_Noreturn not being part of the 
function type as defined by ISO C).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Update: [PATCH 5/X] libsanitizer: mid-end: Introduce stack variable handling for HWASAN

[Richard Sandiford via Gcc-patches]

Sorry for the earlier OK, was replying to the wrong message…

Matthew Malcomson  writes:
> @@ -1216,6 +1255,24 @@ expand_stack_vars (bool (*pred) (size_t), class 
> stack_vars_data *data)
>   {
> offset = alloc_stack_frame_space (stack_vars[i].size, alignb);
> base_align = crtl->max_used_stack_slot_alignment;
> +
> +   if (hwasan_sanitize_stack_p ())
> + {
> +   /* Align again since the point of this alignment is to handle
> +  the "end" of the object (i.e. smallest address after the
> +  stack object).  For FRAME_GROWS_DOWNWARD that requires
> +  aligning the stack before allocating, but for a frame that
> +  grows upwards that requires aligning the stack after
> +  allocation.
> +
> +  Use `frame_offset` to record the offset value rather than
> +  offset since the `frame_offset` describes the extent

What I meant here was to quote “offset”, i.e.:

 Use `frame_offset` to record the offset value rather than
 `offset` since `frame_offset` describes the extent

Without the quoting, “the offset value rather than offset” was quite
hard to parse.

OK with that change, thanks.

Richard

> +  allocated for this particular variable while `offset`
> +  describes the address that this variable starts at.  */
> +   align_frame_offset (HWASAN_TAG_GRANULE_SIZE);
> +   hwasan_record_stack_var (virtual_stack_vars_rtx, base,
> +hwasan_orig_offset, frame_offset);
> + }
>   }
>   }
>else

Re: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.

[Segher Boessenkool]

On Mon, Nov 23, 2020 at 08:10:49PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 23, 2020 at 12:59:29PM -0600, Segher Boessenkool wrote:
> > On Sat, Nov 21, 2020 at 12:27:30AM -0500, Michael Meissner wrote:
> > > On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote:
> > > > Sure -- I am suggesting to always define __IBM128_MAX__ and the like,
> > > > which then can be used to define LDBL_MAX, but also can be used
> > > > directly.
> > > 
> > > I have posted patches for this as a new set of patches.  Rather than 
> > > trying to
> > > create IBM 128-bit long double min/max/etc. defines, I just marked the 
> > > test as
> > > needing IBM 128-bit long double.
> > > 
> > > I did look into providing defines for these.  Unfortunately the function 
> > > that
> > > creates these (builtin_define_float_constants) is static.  And the caller 
> > > of
> > > that function (c_cpp_builtins) does not have a target hook or other 
> > > method to
> > > provide for these defines for MD specific floating point types.
> > 
> > So create the defines from somewhere in the backend, instead?  This
> > isn't rocket science.
> > 
> > You can even leave the existing LDBL defines alone if you just override
> > them later.
> 
> The current defines are quite complex code, because defining them is very
> expensive and we don't want to pay that price at every compilation start
> when most of the compilations never use those macros.
> So they are magic deferred macros.

Ah, so defining later will not work, or it will be quite fragile at
least.  So that won't fly :-/

We can provide IBM128 etc. macros for this just fine of course, but
using that for the LDBL is hard then, so perhaps we should not do that
second step, certainly not in stage > 1.

Thanks,


Segher

Re: [PATCH 4/X] libsanitizer: options: Add hwasan flags and argument parsing

[Richard Sandiford via Gcc-patches]

Matthew Malcomson  writes:
> Hi there,
>
> I was just doing some double-checks and noticed I'd placed the
> documentation in the wrong section of tm.texi.  The `MEMTAG` hooks were
> documented in the `Register Classes` section, so I've now moved it to
> the `Misc` section.
>
> That's the only change, Ok for trunk?

OK, thanks.

Richard

[committed] Adjust rtx_costs for h8300

[Jeff Law via Gcc-patches]

So the primary purpose of this patch is to make it easier to write tests
for removal of useless test/compare insns on the H8.



In simplest terms the costing model in the H8 port tends to encourage
changing something like

  x = y + 4;
  if (x == 0)

into

  x = y + 4;
  if (y == -4)

This is a marginal de-optimization on the H8.  So fixing it makes the
code ever-so-slightly better in isolation.   Fixing this also improves
redundant test/compare elimination and makes writing tests for redundant
test/compare elimination far easier.



   gcc/
    * config/h8300/h8300.c (h8300_rtx_costs): Handle the various
    comparison rtx codes too.



Committed to the trunk.

Jeff
diff --git a/gcc/config/h8300/h8300.c b/gcc/config/h8300/h8300.c
index 89cd793277a..31f7805f057 100644
--- a/gcc/config/h8300/h8300.c
+++ b/gcc/config/h8300/h8300.c
@@ -1205,6 +1205,16 @@ h8300_rtx_costs (rtx x, machine_mode mode 
ATTRIBUTE_UNUSED, int outer_code,
   return true;
 
 case COMPARE:
+case NE:
+case EQ:
+case GE:
+case GT:
+case LE:
+case LT:
+case GEU:
+case GTU:
+case LEU:
+case LTU:
   if (XEXP (x, 1) == const0_rtx)
*total = 0;
   return false;

Re: Update: [PATCH 5/X] libsanitizer: mid-end: Introduce stack variable handling for HWASAN

[Richard Sandiford via Gcc-patches]

Matthew Malcomson  writes:
> Hi there,
>
> I was just doing some double-checks and noticed I'd placed the
> documentation in the wrong section of tm.texi.  The `MEMTAG` hooks were
> documented in the `Register Classes` section, so I've now moved it to
> the `Misc` section.
>
> That's the only change, Ok for trunk?

OK, thanks.

Richard

[C PATCH] Do not drop qualifiers for _Atomic in typeof

[Uecker, Martin]

Joseph,

here is the patch to not drop qualifiers for _Atomic in
typeof. I am not sure whether this is appropriate in
stage3, but I wanted to leave it here for you to comment
and so that it does not lost.

First, I noticed that the change to drop qualifiers
in lvalue conversion also implies that __auto_type now
always uses the non-qualified type. I think this is more
correct, and also what other compilers and C++'s auto do.
The first change here in c-parser would remove the now
redundant code to drop qualifiers for _Atomic types.

The second change would remove the code to drop qualifiers
for _Atomic types for typeof. I would then use the
comma operator for stdatomic to remove all qualifiers.
Here, the question is whether this may have same
unintended side effects.

--Martin



diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 7540a15d65d..72dbd2e00c0 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -2224,10 +2224,6 @@ c_parser_declaration_or_fndef (c_parser *parser, bool 
fndef_ok,
      " initializer");
      init = convert_lvalue_to_rvalue (init_loc, init, true, true);
      tree init_type = TREE_TYPE (init.value);
-     /* As with typeof, remove all qualifiers from atomic types.  
*/
-     if (init_type != error_mark_node && TYPE_ATOMIC (init_type))
-   init_type
-     = c_build_qualified_type (init_type, TYPE_UNQUALIFIED);
      bool vm_type = variably_modified_type_p (init_type,
       NULL_TREE);
      if (vm_type)
@@ -3743,11 +3739,6 @@ c_parser_typeof_specifier (c_parser *parser)
   if (was_vm)
    ret.expr = c_fully_fold (expr.value, false, _const_operands);
   pop_maybe_used (was_vm);
-  /* For use in macros such as those in , remove all
-    qualifiers from atomic types.  (const can be an issue for more macros
-    using typeof than just the  ones.)  */
-  if (ret.spec != error_mark_node && TYPE_ATOMIC (ret.spec))
-   ret.spec = c_build_qualified_type (ret.spec, TYPE_UNQUALIFIED);
 }
   parens.skip_until_found_close (parser);
   return ret;
diff --git a/gcc/ginclude/stdatomic.h b/gcc/ginclude/stdatomic.h
index b9681640fe1..7c2e08a2c41 100644
--- a/gcc/ginclude/stdatomic.h
+++ b/gcc/ginclude/stdatomic.h
@@ -107,7 +107,7 @@ extern void atomic_signal_fence (memory_order);
 #define ATOMIC_POINTER_LOCK_FREE   __GCC_ATOMIC_POINTER_LOCK_FREE
 
 
-/* Note that these macros require __typeof__ and __auto_type to remove
+/* Note that these macros require __auto_type to remove
_Atomic qualifiers (and const qualifiers, if those are valid on
macro operands).

@@ -122,7 +122,7 @@ extern void atomic_signal_fence (memory_order);
   __extension__
\
   ({   \
 __auto_type __atomic_store_ptr = (PTR);\
-__typeof__ (*__atomic_store_ptr) __atomic_store_tmp = (VAL);   \
+__typeof__ ((void)0, *__atomic_store_ptr) __atomic_store_tmp = (VAL);  
\
 __atomic_store (__atomic_store_ptr, &__atomic_store_tmp, (MO));\
   })
 
@@ -134,7 +134,7 @@ extern void atomic_signal_fence (memory_order);
   __extension__
\
   ({   \
 __auto_type __atomic_load_ptr = (PTR); \
-__typeof__ (*__atomic_load_ptr) __atomic_load_tmp; \
+__typeof__ ((void)0, *__atomic_load_ptr) __atomic_load_tmp;
\
 __atomic_load (__atomic_load_ptr, &__atomic_load_tmp, (MO));   \
 __atomic_load_tmp; \
   })
@@ -146,8 +146,8 @@ extern void atomic_signal_fence (memory_order);
   __extension__
\
   ({   \
 __auto_type __atomic_exchange_ptr = (PTR); \
-__typeof__ (*__atomic_exchange_ptr) __atomic_exchange_val = (VAL); \
-__typeof__ (*__atomic_exchange_ptr) __atomic_exchange_tmp; \
+__typeof__ ((void)0, *__atomic_exchange_ptr) __atomic_exchange_val = 
(VAL);\
+__typeof__ ((void)0, *__atomic_exchange_ptr) __atomic_exchange_tmp;
\
 __atomic_exchange (__atomic_exchange_ptr, &__atomic_exchange_val,  \
       &__atomic_exchange_tmp, (MO));   \
 __atomic_exchange_tmp; \
@@ -161,7 +161,7 @@ extern void atomic_signal_fence (memory_order);
   __extension__
\
   ({   \
 __auto_type 

Re: [ Preprocessor ] [ Common ] Feature: Macros for identifying the wide and narrow execution string literal encoding

[Jeff Law via Gcc-patches]

On 10/9/20 6:39 AM, JeanHeyd Meneide via Gcc-patches wrote:
> Hello,
>
>> Typo:  comple-time
>>
>>> 2020-10-08  JeanHeyd "ThePhD" Meneide  
>>>
>>>* gcc/c-family/c-cppbuiltin.c: Add predefined macro
>>> definitions for charsets
>> I think you should put the macro names in braces after the filename and drop 
>> the trailing "for charsets".
>  Can do!
>
>>>* gcc/doc/cpp.texi: Document new predefined macro.
>>>* gcc/testsuite/c-c++-common/cpp/wide-narrow-predef-macros.c (new):
>> I think you should drop "(new)" above.
>> thanks,
>  I saw that in previous changelogs, but I can change it! Fixed up
> the typos, too.
>
> Sincerely,
> JeanHeyd
>
> 2020-10-09  JeanHeyd "ThePhD" Meneide  
>
> * gcc/c-family/c-cppbuiltin.c: Add predefined
>   {__GNUC_EXECUTION_CHARSET_NAME} and
>   {__GNUC_WIDE_EXECUTION_CHARSET_NAME} macros
> * gcc/doc/cpp.texi: Document above new predefined macros
> * gcc/testsuite/c-c++-common/cpp/wide-narrow-predef-macros.c:
>   New test for macro definitions to always exist and be strings
> * libcpp/include/cpplib.h: Add functions declarations for
>   retrieving charset names
> * libcpp/directives.c: Add function definitions to retrieve charset
>   names
> * libcpp/internal.h: Add to/from name preservations
>
> encoding_names.patch.txt
>

[ ... ]
> diff --git a/libcpp/charset.c b/libcpp/charset.c
> index 28b81c9c864..3e5578b1390 100644
> --- a/libcpp/charset.c
> +++ b/libcpp/charset.c
> @@ -638,6 +638,9 @@ init_iconv_desc (cpp_reader *pfile, const char *to, const 
> char *from)
>char *pair;
>size_t i;
>  
> +  ret.to = to;
> +  ret.from = from;
> +
AFAICT ret.from is never used.  Is there a reason why you're saving it?


You use a getter function to retrieve the value of ret.to, which is
fine.  Is there a specific reason why you're not using a setter function
to save the value?

Otherwise I think this is basically ready to be included.

jeff

[PATCH 1,2] Darwin : Update libtool and dependencies for Darwin20 [PR97865]

[Iain Sandoe]

Hi

This fixes a blocker for x86_64 darwin20 (a.k.a macOS 11)
It is needed on all open branches too.

(probably this comes under my Dariwn hat - but since it involves
 regenerating all the configure scripts… I’d welcome another pair
 of eyes)

tested on:
darwin8-darwin20, powerpc, i686, x86_64, arm64(aarch64).
aix (cfarm gcc119), aarch64 (cfarm gcc115), powerpc64 (BE) - (cfarm gcc110)
powerpc64 (LE) - (cfarm gcc135), sparc solaris 2.11 (gcc211)
x86_64-linux-gnu (cfarm gcc123)

OK for master?

OK for backports?

thanks
iain

N.B. I am attaching the second patch which is the uninteresting regenerated  
files.


=

The change in major version (and the increment from Darwin19 to 20)
caused libtool tests to fail which resulted in incorrect build settings
for shared libraries.

We take this opportunity to sort out the shared undefined symbols state
rather than propagating the current unsound behaviour into a new rev.

This change means that we default to the case that missing symbols are
considered an error, and if one wants to allow this intentionally, the
confiuration for that case should be set appropriately.

We use intentional missing symbols to emulate the ELF behaviour when
we have a weak undefined extern.

So, three existing cases need undefined dynamic lookup:
 libitm, where there is already a configuration mechanism to add the
 flags.
 libsanitizer, likewise
 libcc1, where we add simple configuration to add the flags for Darwin.

libcc1/ChangeLog:

PR target/97865
* Makefile.am: Add dynamic_lookup to LD flags for Darwin.
* configure.ac: Test for Darwin host and set a flag.

libitm/ChangeLog:

PR target/97865
* configure.tgt: Add dynamic_lookup to XLDFLAGS for Darwin.

libsanitizer/ChangeLog:

PR target/97865
* configure.tgt: Add dynamic_lookup to EXTRA_CXXFLAGS for
Darwin.

ChangeLog:

PR target/97865
* libtool.m4: Update handling of Darwin platform link flags
for Darwin20.


---
 libcc1/Makefile.am |  3 +++
 libcc1/configure.ac|  6 ++
 libitm/configure.tgt   |  9 -
 libsanitizer/configure.tgt |  1 +
 libtool.m4 | 32 +---
 5 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/libcc1/Makefile.am b/libcc1/Makefile.am
index ab6f839ecae..173b84f9cdb 100644
--- a/libcc1/Makefile.am
+++ b/libcc1/Makefile.am
@@ -25,6 +25,9 @@ CPPFLAGS_FOR_C_FAMILY = -I $(srcdir)/../gcc/c-family \
 CPPFLAGS_FOR_C = $(CPPFLAGS_FOR_C_FAMILY) -I $(srcdir)/../gcc/c
 CPPFLAGS_FOR_CXX = $(CPPFLAGS_FOR_C_FAMILY) -I $(srcdir)/../gcc/cp
 AM_CXXFLAGS = $(WARN_FLAGS) $(WERROR) $(visibility) $(CET_HOST_FLAGS)
+if DARWIN_DYNAMIC_LOOKUP
+AM_CXXFLAGS += -Wl,-undefined,dynamic_lookup
+endif
 override CXXFLAGS := $(filter-out -fsanitize=address,$(CXXFLAGS))
 override LDFLAGS := $(filter-out -fsanitize=address,$(LDFLAGS))
 # Can be simplified when libiberty becomes a normal convenience library.
diff --git a/libcc1/configure.ac b/libcc1/configure.ac
index 8d3b8d14748..262e0a61e6f 100644
--- a/libcc1/configure.ac
+++ b/libcc1/configure.ac
@@ -104,6 +104,12 @@ AC_CACHE_CHECK([for socket libraries],  
libcc1_cv_lib_sockets,

 ])
 LIBS="$LIBS $libcc1_cv_lib_sockets"

+case "$host" in
+  *-*-darwin*) darwin_dynamic_lookup=yes ;;
+  *) darwin_dynamic_lookup= ;;
+esac
+AM_CONDITIONAL(DARWIN_DYNAMIC_LOOKUP, test $darwin_dynamic_lookup = yes)
+
 # If any of these functions are missing, simply don't bother building
 # this plugin.
 GCC_ENABLE_PLUGINS
diff --git a/libitm/configure.tgt b/libitm/configure.tgt
index 04109160e91..d1beb5c9ec8 100644
--- a/libitm/configure.tgt
+++ b/libitm/configure.tgt
@@ -43,6 +43,7 @@ if test "$gcc_cv_have_tls" = yes ; then
 *-*-linux*)
XCFLAGS="${XCFLAGS} -ftls-model=initial-exec"
;;
+
   esac
 fi

@@ -144,10 +145,16 @@ case "${target}" in
   *-*-gnu* | *-*-k*bsd*-gnu \
   | *-*-netbsd* | *-*-freebsd* | *-*-openbsd* \
   | *-*-solaris2* | *-*-sysv4* | *-*-hpux11* \
-  | *-*-darwin* | *-*-aix* | *-*-dragonfly*)
+  | *-*-aix* | *-*-dragonfly*)
# POSIX system.  The OS is supported.
;;

+  *-*-darwin*)
+   # The OS is supported, but we need dynamic lookup to support undefined
+   # weak symbols at link-time.
+   XLDFLAGS="${XLDFLAGS} -Wl,-undefined,dynamic_lookup"
+   ;;
+
   *)   # Non-POSIX, or embedded system
UNSUPPORTED=1
;;
diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index ef9150209c4..f73d410dedf 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -64,6 +64,7 @@ case "${target}" in
;;
   x86_64-*-darwin2* | x86_64-*-darwin1[2-9]* | i?86-*-darwin1[2-9]*)
TSAN_SUPPORTED=no
+   EXTRA_CXXFLAGS+="-Wl,-undefined,dynamic_lookup"
;;
   x86_64-*-solaris2.11* | i?86-*-solaris2.11*)
;;
diff --git a/libtool.m4 b/libtool.m4
index e194e899fcf..9b14b9470df 100644
--- a/libtool.m4
+++ b/libtool.m4
@@ 

Re: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.

[Jakub Jelinek via Gcc-patches]

On Mon, Nov 23, 2020 at 12:59:29PM -0600, Segher Boessenkool wrote:
> On Sat, Nov 21, 2020 at 12:27:30AM -0500, Michael Meissner wrote:
> > On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote:
> > > Sure -- I am suggesting to always define __IBM128_MAX__ and the like,
> > > which then can be used to define LDBL_MAX, but also can be used
> > > directly.
> > 
> > I have posted patches for this as a new set of patches.  Rather than trying 
> > to
> > create IBM 128-bit long double min/max/etc. defines, I just marked the test 
> > as
> > needing IBM 128-bit long double.
> > 
> > I did look into providing defines for these.  Unfortunately the function 
> > that
> > creates these (builtin_define_float_constants) is static.  And the caller of
> > that function (c_cpp_builtins) does not have a target hook or other method 
> > to
> > provide for these defines for MD specific floating point types.
> 
> So create the defines from somewhere in the backend, instead?  This
> isn't rocket science.
> 
> You can even leave the existing LDBL defines alone if you just override
> them later.

The current defines are quite complex code, because defining them is very
expensive and we don't want to pay that price at every compilation start
when most of the compilations never use those macros.
So they are magic deferred macros.

Jakub

Re: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.

[Segher Boessenkool]

On Sat, Nov 21, 2020 at 12:27:30AM -0500, Michael Meissner wrote:
> On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote:
> > Sure -- I am suggesting to always define __IBM128_MAX__ and the like,
> > which then can be used to define LDBL_MAX, but also can be used
> > directly.
> 
> I have posted patches for this as a new set of patches.  Rather than trying to
> create IBM 128-bit long double min/max/etc. defines, I just marked the test as
> needing IBM 128-bit long double.
> 
> I did look into providing defines for these.  Unfortunately the function that
> creates these (builtin_define_float_constants) is static.  And the caller of
> that function (c_cpp_builtins) does not have a target hook or other method to
> provide for these defines for MD specific floating point types.

So create the defines from somewhere in the backend, instead?  This
isn't rocket science.

You can even leave the existing LDBL defines alone if you just override
them later.

And there is nothing against adding new hooks or whatever!


Segher

Re: [PATCH] unshare expressions in attribute arguments

[Martin Sebor via Gcc-patches]

On 11/23/20 11:21 AM, Jakub Jelinek wrote:

On Mon, Nov 23, 2020 at 11:08:13AM -0700, Martin Sebor wrote:

I don't think it would be significant complication, on the other side you
avoid wasting compile time memory on that (GC one, which means it will be
wasted until GC collection if there is one ever).  Plus all the issues from
having the same information in multiple different places.


So just to make sure I understand correctly (and answer the question
I asked): unsharing the expression as in the proposed patch won't
cause any correctness issues.  You just find rewriting the code to
use the existing SAVE_EXPRs instead preferable for the reasons above.
Please correct me if I misunderstood something.


I admit I haven't looked into detail what exactly you are doing
with those expressions.
If they ever result in code generation rather than just warnings, then if
they lack SAVE_EXPRs by the time you unshare, it would be a wrong-code
(evaluating the expression multiple times).
If they are just compared (lexicographically?), it can work, I guess a
question is if foo () in two expressions is really equal, but I guess it
would mean just one invocation of the same function and so can be considered
equal.  Another thing is that one expression can call something and the
other something else and just the user will know they will in that case do
the same thing.  A warning (but not error) is fine in that case though.


Nontrivial expressions (anything but a straight PARM_DECL which is
mapped to a positional argument) are only used in lexicographical
comparisons to check for equivalence.  They're not used for codegen
decisions.

Examples can certainly be contrived where relying on equivalence is
not reliable and results in warnings for safe code.  There are even
very simple cases where this can happen that are clearly correct
(e.g., pr97548).  Some of the former are probably unavoidable (such
as the one you described) but I'd like to try to deal with at least
the basic ones.

Martin

testsuite: Adjust pruning

[Nathan Sidwell]

Here is the patch to adjust the include-stack pruning messages to also
strip out c++ modules.  The ICE regexp was a little too strict such
that if someone overrides the bug-reporting URL it doesn't trigger.
May as well relax it too.

gcc/testsuite/
* lib/prune.exp (prune_gcc_output): Adjust include stack pruning
for modules.
(print_ices): Relax regexp.

pushing to trunk

nathan
--
Nathan Sidwell
diff --git c/gcc/testsuite/lib/prune.exp w/gcc/testsuite/lib/prune.exp
index 190367c44e0..5d051b99def 100644
--- c/gcc/testsuite/lib/prune.exp
+++ w/gcc/testsuite/lib/prune.exp
@@ -48,7 +48,11 @@ proc prune_gcc_output { text } {
 regsub -all "(^|\n)\[^\n\]*: re(compiling|linking)\[^\n\]*" $text "" text
 regsub -all "(^|\n)Please submit.*instructions\[^\n\]*" $text "" text
 regsub -all "(^|\n)\[0-9\]\[0-9\]* errors\." $text "" text
-regsub -all "(^|\n)(In file included|\[ \]+from)\[^\n\]*" $text "" text
+
+# Diagnostic inclusion stack
+regsub -all "(^|\n)(In file)?\[ \]+included from \[^\n\]*" $text "" text
+regsub -all "(^|\n)\[ \]+from \[^\n\]*" $text "" text
+regsub -all "(^|\n)(In|of) module( \[^\n \]*,)? imported at \[^\n\]*" $text "" text
 
 # Ignore informational notes.
 regsub -all "(^|\n)\[^\n\]*: note: \[^\n\]*" $text "" text
@@ -128,8 +133,8 @@ proc prune_file_path { text } {
 # footnote.
 
 proc prune_ices { text } {
-  regsub -all "(^|\n)\[^\n\]*: internal compiler error:.*for instructions\[^\n\]*" $text "" text
-  regsub -all "(^|\n|')*Internal compiler error:.*for instructions\[^\n\]*" $text "" text
+  regsub -all "(^|\n)\[^\n\]*: internal compiler error:.*\nSee \[^\n\]*" $text "" text
+  regsub -all "(^|\n|')*Internal compiler error:.*\nSee \[^\n\]*" $text "" text
   return $text
 }
 

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 22/11/20 22:13 +0100, Stephan Bergmann wrote:

On 20/11/2020 23:44, Thomas Rodgers wrote:

Tested x86_64-pc-linux-gnu, committed.


Clang complains:


$ cat test.cc
#include 

$ clang++ --gcc-toolchain=~/gcc/trunk/inst -std=c++20 -fsyntax-only test.cc
In file included from test.cc:1:
In file included from 
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/semaphore:36:
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/semaphore_base.h:145:22:
 error: no viable conversion from 'std::chrono::system_clock::time_point' (aka 
'time_point>>') 
to 'const std::__platform_semaphore::__clock_t' (aka 'const std::chrono::system_clock')
   const __clock_t __s_entry = __clock_t::now();
   ^   
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/chrono:1101:12: 
note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 
'std::chrono::system_clock::time_point' (aka 'time_point>>') to 'const std::chrono::system_clock &' for 
1st argument
   struct system_clock
  ^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/chrono:1101:12: note: 
candidate constructor (the implicit move constructor) not viable: no known conversion from 
'std::chrono::system_clock::time_point' (aka 'time_point>>') to 'std::chrono::system_clock &&' for 1st argument
1 error generated.


which


diff --git a/libstdc++-v3/include/bits/semaphore_base.h 
b/libstdc++-v3/include/bits/semaphore_base.h
index 78a0b6ba26e..f25c9fdb325 100644
--- a/libstdc++-v3/include/bits/semaphore_base.h
+++ b/libstdc++-v3/include/bits/semaphore_base.h
@@ -142,7 +142,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   else
 {
   const typename _Clock::time_point __c_entry = _Clock::now();
-   const __clock_t __s_entry = __clock_t::now();
+   const __clock_t::time_point __s_entry = __clock_t::now();
   const auto __delta = __atime - __c_entry;
   const auto __s_atime = __s_entry + __delta;
   if (_M_try_acquire_until_impl(__s_atime))
~


would fix.


I just used 'auto'` instead.

Committed, thanks.

The fact this didn't error with GCC suggests we're missing some tests.


commit 1ccee0fbfa8e528b3671dfbf4dad5b6f67755e4c
Author: Jonathan Wakely 
Date:   Mon Nov 23 18:16:44 2020

libstdc++: Fix variable declared with wrong type

libstdc++-v3/ChangeLog:

* include/bits/semaphore_base.h
(__platform_semaphore::_M_try_acquire_until): Fix type of
variable.

diff --git a/libstdc++-v3/include/bits/semaphore_base.h b/libstdc++-v3/include/bits/semaphore_base.h
index 0692f95f24f2..56333bbbfef7 100644
--- a/libstdc++-v3/include/bits/semaphore_base.h
+++ b/libstdc++-v3/include/bits/semaphore_base.h
@@ -141,7 +141,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	else
 	  {
 	const typename _Clock::time_point __c_entry = _Clock::now();
-	const __clock_t __s_entry = __clock_t::now();
+	const auto __s_entry = __clock_t::now();
 	const auto __delta = __atime - __c_entry;
 	const auto __s_atime = __s_entry + __delta;
 	if (_M_try_acquire_until_impl(__s_atime))

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 22/11/20 22:41 +0100, Stephan Bergmann wrote:

On 20/11/2020 23:44, Thomas Rodgers wrote:

Tested x86_64-pc-linux-gnu, committed.


...and there are multiple definition complaints from the linker 
because of two missing "include":



index 7b2682a577e..23ab2018ca8 100644
--- a/libstdc++-v3/include/bits/atomic_wait.h
+++ b/libstdc++-v3/include/bits/atomic_wait.h
@@ -223,7 +223,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  { _M_w._M_do_wait(_M_version); }
};
-void
+inline void
__thread_relax() noexcept
{
#if defined __i386__ || defined __x86_64__
@@ -233,7 +233,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#endif
}
-void
+inline void
__thread_yield() noexcept
   {
#if defined _GLIBCXX_USE_SCHED_YIELD


Committed, thanks.


commit 0986d3bc621b12c3d0367bf7bd25927c7fbfc552
Author: Stephan Bergmann 
Date:   Mon Nov 23 18:14:44 2020

libstdc++: Fix linker errors due to missing 'inline' keywords

libstdc++-v3/ChangeLog:

* include/bits/atomic_wait.h (__thread_relax, __thread_yield):
Add 'inline'.

diff --git a/libstdc++-v3/include/bits/atomic_wait.h b/libstdc++-v3/include/bits/atomic_wait.h
index a40cff124d7d..cd756f68de6d 100644
--- a/libstdc++-v3/include/bits/atomic_wait.h
+++ b/libstdc++-v3/include/bits/atomic_wait.h
@@ -224,7 +224,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { _M_w._M_do_wait(_M_version); }
 };
 
-void
+inline void
 __thread_relax() noexcept
 {
 #if defined __i386__ || defined __x86_64__
@@ -234,9 +234,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
 }
 
-void
+inline void
 __thread_yield() noexcept
-   {
+{
 #if defined _GLIBCXX_USE_SCHED_YIELD
  __gthread_yield();
 #endif

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 23/11/20 18:31 +, Jonathan Wakely wrote:

On 22/11/20 13:37 +, Jonathan Wakely via Libstdc++ wrote:

On Sun, 22 Nov 2020, 12:29 Iain Sandoe,  wrote:


thanks for looking at this over the weekend.

Jonathan Wakely via Gcc-patches  wrote:


On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++
 wrote:

I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
fixes.  And a few c++ failures with similar symptoms.  I'm not certain
that it is due to this patch, but it's the likely suspect.

Yes, it's that patch.

This should fix most of those errors, but I haven't finished testing
it, and can't commit it now anyway.



with r11-5235 + this patch there are still quite a few fails on Darwin -
but
all seem to be the same ( so maybe only problem ;) ):
 “sem_timedwait was not declared in this scope”.

It looks like the semaphore header is optional in SUSv3 (AFAIK that’s still
the claimed edition for Darwin) - and although Darwin has the semaphore
header, it doesn’t seem to have an impl. of sem_timedwait.

just:
int sem_trywait(sem_t *);
int sem_wait(sem_t *) ;




It probably depends on the _POSIX_TIMEOUTS option which MacOS doesn't
support (optional in POSIX 2001, but not 2008).


Hopefully this fixes it, but I haven't tested it on darwin, only
linux, aix and solaris.

Committed.


With the patch this time ...


commit 92b47a321e14f98c524f6e67e7ecabad5afa7886
Author: Jonathan Wakely 
Date:   Mon Nov 23 17:17:09 2020

libstdc++: Add configure checks for semaphores

This moves the checks for POSIX semaphores to configure time. As well as
requiring  and SEM_VALUE_MAX, we also require the
sem_timedwait function. That was only optional in POSIX 2001 (and is
absent on Darwin).

libstdc++-v3/ChangeLog:

* acinclude.m4 (GLIBCXX_CHECK_GTHREADS): Check for
* config.h.in: Regenerate.
* configure: Regenerate.
* include/bits/semaphore_base.h (_GLIBCXX_HAVE_POSIX_SEMAPHORE):
Check autoconf macro instead of defining it here.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 486347b34d94..a4a0bb840181 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -4089,6 +4089,43 @@ AC_DEFUN([GLIBCXX_CHECK_GTHREADS], [
 fi
   fi
 
+  AC_CHECK_HEADER(semaphore.h, [
+AC_MSG_CHECKING([for POSIX Semaphores and sem_timedwait])
+AC_TRY_COMPILE([
+	#include 
+	#include 
+	#include 
+  ],
+  [
+	#if !defined _POSIX_TIMEOUTS || _POSIX_TIMEOUTS <= 0
+	# error "POSIX Timeouts option not supported"
+	#elif !defined _POSIX_SEMAPHORES || _POSIX_SEMAPHORES <= 0
+	# error "POSIX Semaphores option not supported"
+	#else
+	#if defined SEM_VALUE_MAX
+	constexpr int sem_value_max = SEM_VALUE_MAX;
+	#elif defined _POSIX_SEM_VALUE_MAX
+	constexpr int sem_value_max = _POSIX_SEM_VALUE_MAX;
+	#else
+	# error "SEM_VALUE_MAX not available"
+	#endif
+	sem_t sem;
+	sem_init(, 0, sem_value_max);
+	struct timespec ts = { 0 };
+	sem_timedwait(, );
+	#endif
+  ],
+  [ac_have_posix_semaphore=yes],
+  [ac_have_posix_semaphore=no])],
+  [ac_have_posix_semaphore=no])
+
+  if test $ac_have_posix_semaphore = yes ; then
+AC_DEFINE(_GLIBCXX_HAVE_POSIX_SEMAPHORE,
+	  1,
+	  [Define to 1 if POSIX Semaphores with sem_timedwait are available in .])
+  fi
+  AC_MSG_RESULT([$ac_have_posix_semaphore])
+
   CXXFLAGS="$ac_save_CXXFLAGS"
   AC_LANG_RESTORE
 ])
diff --git a/libstdc++-v3/include/bits/semaphore_base.h b/libstdc++-v3/include/bits/semaphore_base.h
index 5e29d3783fe1..0692f95f24f2 100644
--- a/libstdc++-v3/include/bits/semaphore_base.h
+++ b/libstdc++-v3/include/bits/semaphore_base.h
@@ -39,11 +39,9 @@
 
 #include 
 
-#if __has_include()
+#ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
+# include 
 # include 
-# if defined SEM_VALUE_MAX || _POSIX_SEM_VALUE_MAX
-#  define _GLIBCXX_HAVE_POSIX_SEMAPHORE 1
-# endif
 #endif
 
 #include 

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 22/11/20 13:37 +, Jonathan Wakely via Libstdc++ wrote:

On Sun, 22 Nov 2020, 12:29 Iain Sandoe,  wrote:


thanks for looking at this over the weekend.

Jonathan Wakely via Gcc-patches  wrote:

> On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++
>  wrote:
>> I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
>> fixes.  And a few c++ failures with similar symptoms.  I'm not certain
>> that it is due to this patch, but it's the likely suspect.
> Yes, it's that patch.
>
> This should fix most of those errors, but I haven't finished testing
> it, and can't commit it now anyway.
> 

with r11-5235 + this patch there are still quite a few fails on Darwin -
but
all seem to be the same ( so maybe only problem ;) ):
  “sem_timedwait was not declared in this scope”.

It looks like the semaphore header is optional in SUSv3 (AFAIK that’s still
the claimed edition for Darwin) - and although Darwin has the semaphore
header, it doesn’t seem to have an impl. of sem_timedwait.

just:
int sem_trywait(sem_t *);
int sem_wait(sem_t *) ;




It probably depends on the _POSIX_TIMEOUTS option which MacOS doesn't
support (optional in POSIX 2001, but not 2008).


Hopefully this fixes it, but I haven't tested it on darwin, only
linux, aix and solaris.

Committed.

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 22/11/20 01:27 +, Jonathan Wakely via Libstdc++ wrote:

On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++
 wrote:


I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
fixes.  And a few c++ failures with similar symptoms.  I'm not certain
that it is due to this patch, but it's the likely suspect.

Yes, it's that patch.

This should fix most of those errors, but I haven't finished testing
it, and can't commit it now anyway.


I've committed this now.

Tested powerpc64le-linux and (lightly) on powerpc-aix and
sparc-solaris.


commit 183ae52b226898cc34aa51d4153cf0c006212a8a
Author: Jonathan Wakely 
Date:   Sun Nov 22 01:00:46 2020

libstdc++: make atomic waiting depend on gthreads or futexes

libstdc++-v3/ChangeLog:

* include/bits/atomic_wait.h: Do not define anything unless
gthreads or futexes are available.
* include/bits/atomic_timed_wait.h: Likewise.
* include/bits/semaphore_base.h: Likewise.
* include/std/semaphore: Likewise.
* include/bits/atomic_base.h (atomic_flag::wait)
(atomic_flag::notify_one, atomic_flag::notify_all)
(__atomic_base::wait, __atomic_base::notify_one)
(__atomic_base::notify_all, __atomic_base::wait)
(__atomic_base::notify_one, __atomic_base::notify_all)
(__atomic_impl::wait, __atomic_impl::notify_one)
(__atomic_impl::notify_all, __atomic_float::wait)
(__atomic_float::notify_one, __atomic_float::notify_all)
(__atomic_ref::wait, __atomic_ref::notify_one)
(__atomic_ref::notify_all): Only define if gthreads or futexes
are available.
* include/std/atomic (atomic::wait, atomic::notify_one)
(atomic::notify_all): Likewise.
* include/std/version (__cpp_lib_semaphore): Define
conditionally.

diff --git a/libstdc++-v3/include/bits/atomic_base.h b/libstdc++-v3/include/bits/atomic_base.h
index 7de02f169977..d7db8612889e 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -230,6 +230,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return __v == __GCC_ATOMIC_TEST_AND_SET_TRUEVAL;
 }
 
+#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX
 _GLIBCXX_ALWAYS_INLINE void
 wait(bool __old,
 	memory_order __m = memory_order_seq_cst) const noexcept
@@ -252,6 +253,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { std::__atomic_notify(&_M_i, true); }
 
 // TODO add const volatile overload
+#endif // GTHREADS || LINUX_FUTEX
 #endif // C++20
 
 _GLIBCXX_ALWAYS_INLINE void
@@ -603,6 +605,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
 #if __cplusplus > 201703L
+#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX
   _GLIBCXX_ALWAYS_INLINE void
   wait(__int_type __old,
 	  memory_order __m = memory_order_seq_cst) const noexcept
@@ -625,6 +628,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { std::__atomic_notify(&_M_i, true); }
 
   // TODO add const volatile overload
+#endif // GTHREADS || LINUX_FUTEX
 #endif // C++2a
 
   _GLIBCXX_ALWAYS_INLINE __int_type
@@ -897,6 +901,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
 #if __cplusplus > 201703L
+#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX
   _GLIBCXX_ALWAYS_INLINE void
   wait(__pointer_type __old,
 	   memory_order __m = memory_order_seq_cst) noexcept
@@ -919,6 +924,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { std::__atomic_notify(&_M_p, true); }
 
   // TODO add const volatile overload
+#endif // GTHREADS || LINUX_FUTEX
 #endif // C++2a
 
   _GLIBCXX_ALWAYS_INLINE __pointer_type
@@ -1010,6 +1016,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
 #if __cplusplus > 201703L
+#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX
 template
   _GLIBCXX_ALWAYS_INLINE void
   wait(const _Tp* __ptr, _Val<_Tp> __old,
@@ -1034,6 +1041,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { std::__atomic_notify(__ptr, true); }
 
   // TODO add const volatile overload
+#endif // GTHREADS || LINUX_FUTEX
 #endif // C++2a
 
 template
@@ -1289,6 +1297,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
    __cmpexch_failure_order(__order));
   }
 
+#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX
   _GLIBCXX_ALWAYS_INLINE void
   wait(_Fp __old, memory_order __m = memory_order_seq_cst) const noexcept
   { __atomic_impl::wait(&_M_fp, __old, __m); }
@@ -1306,6 +1315,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { __atomic_impl::notify_all(&_M_fp); }
 
   // TODO add const volatile overload
+#endif // GTHREADS || LINUX_FUTEX
 
   value_type
   fetch_add(value_type __i,
@@ -1444,6 +1454,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
    __cmpexch_failure_order(__order));
   }
 
+#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX
   _GLIBCXX_ALWAYS_INLINE void
   wait(_Tp __old, 

Re: [PATCH] unshare expressions in attribute arguments

[Jakub Jelinek via Gcc-patches]

On Mon, Nov 23, 2020 at 11:08:13AM -0700, Martin Sebor wrote:
> > I don't think it would be significant complication, on the other side you
> > avoid wasting compile time memory on that (GC one, which means it will be
> > wasted until GC collection if there is one ever).  Plus all the issues from
> > having the same information in multiple different places.
> 
> So just to make sure I understand correctly (and answer the question
> I asked): unsharing the expression as in the proposed patch won't
> cause any correctness issues.  You just find rewriting the code to
> use the existing SAVE_EXPRs instead preferable for the reasons above.
> Please correct me if I misunderstood something.

I admit I haven't looked into detail what exactly you are doing
with those expressions.
If they ever result in code generation rather than just warnings, then if
they lack SAVE_EXPRs by the time you unshare, it would be a wrong-code
(evaluating the expression multiple times).
If they are just compared (lexicographically?), it can work, I guess a
question is if foo () in two expressions is really equal, but I guess it
would mean just one invocation of the same function and so can be considered
equal.  Another thing is that one expression can call something and the
other something else and just the user will know they will in that case do
the same thing.  A warning (but not error) is fine in that case though.

Jakub

Re: [PATCH 7/X] libsanitizer: Add tests

[Matthew Malcomson via Gcc-patches]

Hello,

Update of the hwasan tests attached.

Ok for trunk?

(NOTE on the state of the entire patch series:
  Currently re-testing everything from scratch to ensure I didn't get tripped up
  from old state carried around.
  Also looking into PR 97941 on hwasan.  As yet don't understand what's going
  on there and having difficulty reproducing.)




Adding hwasan tests.

Only interesting thing here is that we have to make sure the tagging mechanism
is deterministic to avoid flaky tests.

gcc/testsuite/ChangeLog:

* c-c++-common/ubsan/sanitize-recover-7.c: Update error message format.
* lib/asan-dg.exp (check_effective_target_fsanitize_address): Move to
target-supports.exp.
(asan_link_flags): Implement as a helper function asan_link_flags_1
which asan_link_flags and hwasan_link_flags use.
(asan_link_flags_1): Parametrised version of asan_link_flags.
* lib/target-supports.exp (check_effective_target_fsanitize_address):
Move from asan-dg.exp.
(check_effective_target_fsanitize_hwaddress,
check_effective_target_hwaddress_exec): New.
* c-c++-common/hwasan/aligned-alloc.c: New test.
* c-c++-common/hwasan/alloca-array-accessible.c: New test.
* c-c++-common/hwasan/alloca-base-init.c: New test.
* c-c++-common/hwasan/alloca-gets-different-tag.c: New test.
* c-c++-common/hwasan/alloca-outside-caught.c: New test.
* c-c++-common/hwasan/arguments-1.c: New test.
* c-c++-common/hwasan/arguments-2.c: New test.
* c-c++-common/hwasan/arguments-3.c: New test.
* c-c++-common/hwasan/arguments.c: New test.
* c-c++-common/hwasan/asan-pr63316.c: New test.
* c-c++-common/hwasan/asan-pr70541.c: New test.
* c-c++-common/hwasan/asan-pr78106.c: New test.
* c-c++-common/hwasan/asan-pr79944.c: New test.
* c-c++-common/hwasan/asan-rlimit-mmap-test-1.c: New test.
* c-c++-common/hwasan/bitfield-1.c: New test.
* c-c++-common/hwasan/bitfield-2.c: New test.
* c-c++-common/hwasan/builtin-special-handling.c: New test.
* c-c++-common/hwasan/check-interface.c: New test.
* c-c++-common/hwasan/halt_on_error-1.c: New test.
* c-c++-common/hwasan/handles-poly_int-marked-vars.c: New test.
* c-c++-common/hwasan/heap-overflow.c: New test.
* c-c++-common/hwasan/hwasan-poison-optimisation.c: New test.
* c-c++-common/hwasan/hwasan-thread-access-parent.c: New test.
* c-c++-common/hwasan/hwasan-thread-basic-failure.c: New test.
* c-c++-common/hwasan/hwasan-thread-clears-stack.c: New test.
* c-c++-common/hwasan/hwasan-thread-success.c: New test.
* c-c++-common/hwasan/kernel-defaults.c: New test.
* c-c++-common/hwasan/large-aligned-0.c: New test.
* c-c++-common/hwasan/large-aligned-1.c: New test.
* c-c++-common/hwasan/large-aligned-untagging-0.c: New test.
* c-c++-common/hwasan/large-aligned-untagging-1.c: New test.
* c-c++-common/hwasan/large-aligned-untagging-2.c: New test.
* c-c++-common/hwasan/large-aligned-untagging-3.c: New test.
* c-c++-common/hwasan/large-aligned-untagging-4.c: New test.
* c-c++-common/hwasan/large-aligned-untagging-5.c: New test.
* c-c++-common/hwasan/large-aligned-untagging-6.c: New test.
* c-c++-common/hwasan/large-aligned-untagging-7.c: New test.
* c-c++-common/hwasan/macro-definition.c: New test.
* c-c++-common/hwasan/no-sanitize-attribute.c: New test.
* c-c++-common/hwasan/param-instrument-mem-intrinsics.c: New test.
* c-c++-common/hwasan/param-instrument-reads-and-writes.c: New test.
* c-c++-common/hwasan/param-instrument-reads.c: New test.
* c-c++-common/hwasan/param-instrument-writes.c: New test.
* c-c++-common/hwasan/random-frame-tag.c: New test.
* c-c++-common/hwasan/sanity-check-pure-c.c: New test.
* c-c++-common/hwasan/setjmp-longjmp-0.c: New test.
* c-c++-common/hwasan/setjmp-longjmp-1.c: New test.
* c-c++-common/hwasan/stack-tagging-basic-0.c: New test.
* c-c++-common/hwasan/stack-tagging-basic-1.c: New test.
* c-c++-common/hwasan/stack-tagging-disable.c: New test.
* c-c++-common/hwasan/unprotected-allocas-0.c: New test.
* c-c++-common/hwasan/unprotected-allocas-1.c: New test.
* c-c++-common/hwasan/use-after-free.c: New test.
* c-c++-common/hwasan/vararray-outside-caught.c: New test.
* c-c++-common/hwasan/vararray-stack-restore-correct.c: New test.
* c-c++-common/hwasan/very-large-objects.c: New test.
* g++.dg/hwasan/hwasan.exp: New test.
* g++.dg/hwasan/rvo-handled.C: New test.
* gcc.dg/hwasan/hwasan.exp: New test.
* gcc.dg/hwasan/nested-functions-0.c: New test.
* gcc.dg/hwasan/nested-functions-1.c: New test.
* 

Re: [PATCH] unshare expressions in attribute arguments

[Martin Sebor via Gcc-patches]

On 11/23/20 10:30 AM, Jakub Jelinek wrote:

On Mon, Nov 23, 2020 at 10:03:44AM -0700, Martin Sebor wrote:

If the most significant bound is lost, why don't you save in the attribute
early only the most significant bound before it is lost


The other bounds are a part of the type so saving them in the attribute
isn't essential.  I save all of them because it simplifies their lookup.
With only the most significant bound in the attribute argument, looking
up the other bounds (e.g., when checking function redeclarations for
mismatches) will, in addition to doing what's done for the most
significant bound, involve scanning the declarations' argument lists,
extracting the bounds from the SAVE_EXPRs, before comparing them.
As an example, in

   void f (int A[m][n]);

the attribute has the chain (VAR_DECL(m), VAR_DECL(n)) as arguments
and comparing them with another declaration of f is as simple as
traversing the chain and comparing each node value.

With the change you suggest, the attribute will only have VAR_DECL(m)
and the least significant bound will have to be extracted from A[m]'s
type's size which is:

   MULT (NOP (bitsizetype, NOP (sizetype, SAVE (VAR (n, 32)

It's possible to do but not without some additional complexity and
cost.


I don't think it would be significant complication, on the other side you
avoid wasting compile time memory on that (GC one, which means it will be
wasted until GC collection if there is one ever).  Plus all the issues from
having the same information in multiple different places.


So just to make sure I understand correctly (and answer the question
I asked): unsharing the expression as in the proposed patch won't
cause any correctness issues.  You just find rewriting the code to
use the existing SAVE_EXPRs instead preferable for the reasons above.
Please correct me if I misunderstood something.

Thanks
Martin

Re: [PATCH] config.sub, config.guess : Import upstream 2020-11-07.

[Jeff Law via Gcc-patches]

On 11/23/20 9:35 AM, Iain Sandoe wrote:
> Hello,
>
> The current config.guess/sub version do not support the recently
> released Darwin platforms; current upstream does.
>
> 
>
> This imports from:
>
> sha1 77632d92f25e26b95c64afd3700d51bd03587613
> Date:   2020-11-07 04:46:23 +
>
> ChangeLog:
>
>     * config.guess: Import latest upstream.
>     * config.sub: Import latest upstream.
>
> ==
>
> tested on:
>
> darwin8-darwin20, powerpc, i686, x86_64, arm64(aarch64).
>
> aix (cfarm gcc119)
>
> aarch64 (cfarm gcc115)
>
> powerpc64 (BE) - (cfarm gcc110)
>
> powerpc64 (LE) - (cfarm gcc135)
>
> sparc solaris 2.11 (thanks to Rainer)
>
> x86_64-linux-gnu (cfarm gcc123)
>
> OK for master?
Yes.  Importing from upstream should always be OK with the possible
exception of just before a release to avoid instability.

jeff

Re: [PATCH] unshare expressions in attribute arguments

[Jakub Jelinek via Gcc-patches]

On Mon, Nov 23, 2020 at 10:03:44AM -0700, Martin Sebor wrote:
> > If the most significant bound is lost, why don't you save in the attribute
> > early only the most significant bound before it is lost
> 
> The other bounds are a part of the type so saving them in the attribute
> isn't essential.  I save all of them because it simplifies their lookup.
> With only the most significant bound in the attribute argument, looking
> up the other bounds (e.g., when checking function redeclarations for
> mismatches) will, in addition to doing what's done for the most
> significant bound, involve scanning the declarations' argument lists,
> extracting the bounds from the SAVE_EXPRs, before comparing them.
> As an example, in
> 
>   void f (int A[m][n]);
> 
> the attribute has the chain (VAR_DECL(m), VAR_DECL(n)) as arguments
> and comparing them with another declaration of f is as simple as
> traversing the chain and comparing each node value.
> 
> With the change you suggest, the attribute will only have VAR_DECL(m)
> and the least significant bound will have to be extracted from A[m]'s
> type's size which is:
> 
>   MULT (NOP (bitsizetype, NOP (sizetype, SAVE (VAR (n, 32)
> 
> It's possible to do but not without some additional complexity and
> cost.

I don't think it would be significant complication, on the other side you
avoid wasting compile time memory on that (GC one, which means it will be
wasted until GC collection if there is one ever).  Plus all the issues from
having the same information in multiple different places.

Jakub

Re: [PATCH] unshare expressions in attribute arguments

[Martin Sebor via Gcc-patches]

On 11/21/20 1:01 AM, Jakub Jelinek wrote:

On Fri, Nov 20, 2020 at 03:44:01PM -0700, Martin Sebor via Gcc-patches wrote:

So that likely means you are doing it too early.


The bounds are added to attribute "arg spec" for each param in
push_parm_decl.  I think that's both as early and (except maybe
in function definitions) as late as can be.  After that point,
the association between a VLA parameter and its most significant
bound is lost.


If the most significant bound is lost, why don't you save in the attribute
early only the most significant bound before it is lost


The other bounds are a part of the type so saving them in the attribute
isn't essential.  I save all of them because it simplifies their lookup.
With only the most significant bound in the attribute argument, looking
up the other bounds (e.g., when checking function redeclarations for
mismatches) will, in addition to doing what's done for the most
significant bound, involve scanning the declarations' argument lists,
extracting the bounds from the SAVE_EXPRs, before comparing them.
As an example, in

  void f (int A[m][n]);

the attribute has the chain (VAR_DECL(m), VAR_DECL(n)) as arguments
and comparing them with another declaration of f is as simple as
traversing the chain and comparing each node value.

With the change you suggest, the attribute will only have VAR_DECL(m)
and the least significant bound will have to be extracted from A[m]'s
type's size which is:

  MULT (NOP (bitsizetype, NOP (sizetype, SAVE (VAR (n, 32)

It's possible to do but not without some additional complexity and
cost.


and for the other
bounds just refer to the SAVE_EXPRs in the FUNCTION_TYPE's TYPE_ARG_TYPES
ARRAY_TYPEs?  And for function definitions, even the outermost bounds
aren't really lost, the FE for
int bar ();
int baz ();

int
foo (int n, int x[bar () + 4][baz () + 2])
{
   return sizeof (x[0]);
}
emits all the side-effects, though not sure if it creates a SAVE_EXPR for
that.  But for the definitions you really want to use the same SAVE_EXPR
as the function evaluates.


It does create a SAVE_EXPR.  I found the code in grokdeclarator.
The SAVE_EXPR is available to callers so I can use it instead.

I'm still not sure I understand why using the SAVE_EXPR of the bound
in the attribute argument where it isn't evaluated is preferable to
saving the unshared bound as the argument instead.  Can you explain
the problem with doing that?

Thanks
Martin

Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

[J.W. Jagersma via Gcc-patches]

On 2020-11-23 09:20, Richard Biener wrote:
> On Sun, Nov 22, 2020 at 5:38 PM J.W. Jagersma  wrote:
>>
>> On 2020-11-21 12:27, J.W. Jagersma wrote:
>>> ...
>>> Another idea I had is to introduce a new operand modifier, eg. '-', which
>>> would signify that the output *must* be considered clobbered on exception,
>>> and it would be an error if a copy is not possible.  Then the meaning of '+'
>>> can be extended to say that the output must be valid regardless of whether 
>>> an
>>> exception occured or not.  Modifier '=' would mean the same as '+' with the
>>> additional implication that it is okay to eliminate earlier assignments, so
>>> that its value on the EH edge would be undefined.
>>
>> I've been working on implementing this, but I ran into an issue:
>>
>> First of all, in the first version of this patch I had to make sure that
>> debug stmts were inserted across the fallthrough edge, so that they don't
>> appear at the end a basic block.  I was surprised to find that this is no
>> longer necessary.
>>
>> Next I discovered that the following test case fails (returns -1):
>>
>> int f ()
>> {
>>   int i = 0;
>>   try { asm ("mov %0, 1; ud2" : "+r" (i)); }
>>   catch (...) { }
>>   return i - 1;
>> }
>>
>> And this does succeed with a memory operand.
>>
>> It seems that something changed in the past few months, and now asm register
>> outputs are already being assigned via a temporary variable, somewhere.  Does
>> anyone know where that might be?
> 
> It's likely out-of SSA / RTL expansion inserting a bogus copy or doing
> coalescing on the EH edge.  Semantics of throwing asm stmts need to be
> honored there.
> 
> Richard.

I believe the issue is caused by commit e3b3b59 which adds support for outputs
from asm goto (CC-ing the author of that patch).  I don't yet see how to
reconcile this with the idea to add a new constraint modifier.

Also, that patch has another problem:
asm goto ("# %0 %1 %2" : "+r" (i) ::: jmp);
Prints two registers and a label offset, which is somewhat unexpected.

And then:
asm goto ("# %l[jmp]" : "+r" (i) ::: jmp);
Produces an error: '%l' operand isn't a label.

So label operands are numbered after the in-out operand is split, but %l is
evaluated before the split.  The examples given in extend.texi can never work.

[PATCH] config.sub, config.guess : Import upstream 2020-11-07.

[Iain Sandoe]

Hello,

The current config.guess/sub version do not support the recently released  
Darwin platforms; current upstream does.




This imports from:

sha1 77632d92f25e26b95c64afd3700d51bd03587613
Date:   2020-11-07 04:46:23 +

ChangeLog:

* config.guess: Import latest upstream.
* config.sub: Import latest upstream.

==

tested on:

darwin8-darwin20, powerpc, i686, x86_64, arm64(aarch64).

aix (cfarm gcc119)

aarch64 (cfarm gcc115)

powerpc64 (BE) - (cfarm gcc110)

powerpc64 (LE) - (cfarm gcc135)

sparc solaris 2.11 (thanks to Rainer)

x86_64-linux-gnu (cfarm gcc123)

OK for master?
thanks
Iain



0001-config.sub-config.guess-Import-upstream-2020-11-07.patch
Description: Binary data

Re: Add -std=c2x, -std=gnu2x, -Wc11-c2x-compat, C2X _Static_assert support

[Joseph Myers]

On Mon, 23 Nov 2020, Martin Liška wrote:

> On 10/18/18 1:59 AM, Joseph Myers wrote:
> > -   || strcmp (language_string, "GNU C17") == 0)
> > +   || strcmp (language_string, "GNU C17") == 0
> > +   || strcmp (language_string, "GNU C2X"))
> 
> Hello Joseph.
> 
> Shouldn't this hunk be '|| strcmp (language_string, "GNU C2X") == 0' ?

Yes.

(There is a question of at what point we decide to assume that C2X will be 
published on the schedule approved by ISO processes and change references 
to refer to C23 and add all the corresponding option names referring to 
C23.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Go patch committed: Change name mangling convention

[Ian Lance Taylor via Gcc-patches]

On Sun, Nov 22, 2020 at 11:00 AM Rainer Orth
 wrote:
>
> > This patch to the Go frontend and libgo changes the name mangling
> > convention.  The previous convention (which was actually the second
> > one) turned out to be ambiguous when the path to a package contained a
> > dot; this is a common case, as many package paths are of the form
> > "github.com/name/package".  The previous convention also did not
> > support package paths that start with a digit, which is less common
> > but does occur (https://golang.org/issue/41862).
> >
> > This patch rewrites and somewhat simplifies the naming convention.
> > Now dot is used only as a separator character and for special names.
> > Actual name mangling, for representing Unicode characters and other
> > non-ASCII alphanumerics, is now done with an underscore.  This has the
> > advantage of being simpler, in that it avoids the overloading that the
> > previous convention applied to dot.  It has the disadvantage that
> > mangled symbol names look somewhat like valid Go names, since valid Go
> > names can of course contain underscore.  Still, it seems like the best
> > choice.
> >
> > This patch increments the libgo major version number, since many
> > symbol names have changed.
> >
> > Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> > to mainline.
>
> this patch broke Solaris bootstrap: linking in gotools fails with
>
> Undefined   first referenced
>  symbol in file
> log_1syslog.syslog__c   
> ../i386-pc-solaris2.11/libgo/.libs/libgo.so
> ld: fatal: symbol referencing errors
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:829: buildid] Error 1
>
> The following patch fixed this for me:

Thanks.  Committed to mainline.

Ian

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 21/11/20 17:39 +, Jonathan Wakely wrote:

On 21/11/20 17:04 +, Jonathan Wakely wrote:

On 21/11/20 16:16 +0100, Andreas Schwab wrote:

In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
  from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
  from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
  from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
  from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:
 In member function 'void std::atomic_flag::wait(bool, std::memory_order) 
const':
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 error: no matching function for call to '__atomic_wait(const __atomic_flag_data_type*, 
bool&, std::atomic_flag::wait(bool, std::memory_order) const::)'
In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:41,
  from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
  from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
  from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
  from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
  from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note: candidate: 'template void 
std::__atomic_wait(const _Tp*, _Tp, _Pred)'
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note:   template argument deduction/substitution failed:
In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
  from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
  from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
  from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
  from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 note:   deduced conflicting types for parameter '_Tp' ('unsigned char' and 
'bool')


I'm testing this.


I'm committing this instead, it's the same but also disables
29_atomics/atomic/wait_notify/generic.cc on non-linux targets.

Tested sparc-solaris2.11 and powerpc64le-linux.

There are still some timeouts on linux:

FAIL: 30_threads/latch/3.cc execution test
FAIL: 30_threads/semaphore/try_acquire_for.cc execution test



Here's another small fix.

Tested powerpc64le-linux, pushed to trunk.



commit fd62daea40e09c1e6d599a6171db6b298d6c362e
Author: Jonathan Wakely 
Date:   Mon Nov 23 15:46:24 2020

libstdc++: Link tests to libatomic as required [PR 97948]

libstdc++-v3/ChangeLog:

PR libstdc++/97948
* testsuite/29_atomics/atomic_float/wait_notify.cc: Add options
for libatomic.
* testsuite/29_atomics/atomic_integral/wait_notify.cc: Likewise.
* testsuite/29_atomics/atomic_ref/wait_notify.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_float/wait_notify.cc b/libstdc++-v3/testsuite/29_atomics/atomic_float/wait_notify.cc
index 27d9b601c2f4..8f9e4a39a21f 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_float/wait_notify.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_float/wait_notify.cc
@@ -2,6 +2,7 @@
 // { dg-do run { target c++2a } }
 // { dg-require-gthreads "" }
 // { dg-additional-options "-pthread" { target pthread } }
+// { dg-add-options libatomic }
 // { dg-skip-if "broken" { ! *-*-*linux } }
 
 // Copyright (C) 2020 Free Software Foundation, Inc.
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_integral/wait_notify.cc b/libstdc++-v3/testsuite/29_atomics/atomic_integral/wait_notify.cc
index 6e9ee7dbf93f..abf2bfdbee96 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_integral/wait_notify.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_integral/wait_notify.cc
@@ -2,6 +2,7 @@
 // { dg-do run { target c++2a } }
 // { dg-require-effective-target pthread }
 // { dg-require-gthreads "" }
+// { dg-add-options libatomic }
 
 // Copyright (C) 2020 Free Software Foundation, Inc.
 //
diff --git 

[PATCH][RFC] tree-optimization/97832 - handle associatable chains in SLP discovery

[Richard Biener]

This makes SLP discovery handle associatable (including mixed
plus/minus) chains better by swapping operands across the whole
chain.

While it works it still is a prototype only.  I need to consider
the compile-time complexity by reworking how many "permutes" we
allow during SLP discovery (like a comment suggests probably
capping the actual work, aka the number of vect_build_slp_tree
calls rather than the number of permutes).  There's also some
cleanup to be done.

And the biggest question is what to do for BB vectorization
(for permute handling in general) - we don't have a good
SLP discovery "failure mode" since there's always the possibility
to build a node from scalars.  That means if we're unlucky and
do not end in all loads or constants in the SLP leafs we will
end up need to cost one SLP build variant against another which
means we can't really "stop" when we found a match.  We could
still see matching better than not matching (we can still have
some fatal matches) but as said, I don't have a good idea here.

Bootstrapped and tested on x86_64-unknown-linux-gnu, I've also
built SPEC CPU 2017 (but did not yet benchmark anything).

So at this point looking for conceptual comments, maybe also
great implementation ideas I missed ;)

Even though this fixes a recently reported bug it does feel
like stage1 material.

Thanks,
Richard.

2020-11-18  Richard Biener  

PR tree-optimization/97832
* tree-vectorizer.h (_slp_tree::failed): New.
* tree-vect-slp.c (_slp_tree::_slp_tree): Initialize
failed member.
(_slp_tree::~_slp_tree): Free failed.
(vect_build_slp_tree): Retain failed nodes and record
matches in them, copying that back out when running
into a cached fail.  Dump start and end of discovery.
(dt_sort_cmp): New.
(vect_build_slp_tree_2): Handle associatable chains
together doing more aggressive operand swapping.

* gcc.dg/vect/pr97832-1.c: New testcase.
* gcc.dg/vect/pr97832-2.c: Likewise.
* gcc.dg/vect/pr97832-3.c: Likewise.
---
 gcc/testsuite/gcc.dg/vect/pr97832-1.c |  17 +
 gcc/testsuite/gcc.dg/vect/pr97832-2.c |  29 ++
 gcc/testsuite/gcc.dg/vect/pr97832-3.c |  50 +++
 gcc/testsuite/gcc.dg/vect/slp-50.c|  20 ++
 gcc/tree-vect-slp.c   | 472 +-
 gcc/tree-vectorizer.h |   5 +
 6 files changed, 587 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr97832-1.c
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr97832-2.c
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr97832-3.c
 create mode 100644 gcc/testsuite/gcc.dg/vect/slp-50.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr97832-1.c 
b/gcc/testsuite/gcc.dg/vect/pr97832-1.c
new file mode 100644
index 000..063fc7bd717
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr97832-1.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-Ofast" } */
+/* { dg-require-effective-target vect_double } */
+
+double a[1024], b[1024], c[1024];
+
+void foo()
+{
+  for (int i = 0; i < 256; ++i)
+{
+  a[2*i] = a[2*i] + b[2*i] - c[2*i];
+  a[2*i+1] = a[2*i+1] - b[2*i+1] - c[2*i+1];
+}
+}
+
+/* { dg-final { scan-tree-dump "vectorizing stmts using SLP" "vect" } } */
+/* { dg-final { scan-tree-dump "Loop contains only SLP stmts" "vect" } } */
diff --git a/gcc/testsuite/gcc.dg/vect/pr97832-2.c 
b/gcc/testsuite/gcc.dg/vect/pr97832-2.c
new file mode 100644
index 000..4f0578120ee
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr97832-2.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-Ofast" } */
+/* { dg-require-effective-target vect_double } */
+
+void foo1x1(double* restrict y, const double* restrict x, int clen)
+{
+  int xi = clen & 2;
+  double f_re = x[0+xi+0];
+  double f_im = x[4+xi+0];
+  int clen2 = (clen+xi) * 2;
+#pragma GCC unroll 0
+  for (int c = 0; c < clen2; c += 8) {
+// y[c] = y[c] - x[c]*conj(f);
+#pragma GCC unroll 4
+for (int k = 0; k < 4; ++k) {
+  double x_re = x[c+0+k];
+  double x_im = x[c+4+k];
+  double y_re = y[c+0+k];
+  double y_im = y[c+4+k];
+  y_re = y_re - x_re * f_re - x_im * f_im;;
+  y_im = y_im + x_re * f_im - x_im * f_re;
+  y[c+0+k] = y_re;
+  y[c+4+k] = y_im;
+}
+  }
+}
+
+/* { dg-final { scan-tree-dump "vectorizing stmts using SLP" "vect" } } */
+/* { dg-final { scan-tree-dump "Loop contains only SLP stmts" "vect" } } */
diff --git a/gcc/testsuite/gcc.dg/vect/pr97832-3.c 
b/gcc/testsuite/gcc.dg/vect/pr97832-3.c
new file mode 100644
index 000..ad1225ddbaa
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr97832-3.c
@@ -0,0 +1,50 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-Ofast" } */
+/* { dg-require-effective-target vect_double } */
+
+void foo(double* restrict y, const double* restrict x0, const double* restrict 
x1, int clen)
+{
+  int xi = clen & 2;
+  double f00_re = x0[0+xi+0];
+  double f10_re = x1[0+xi+0];
+  

Do not leak memory in ipa-prop

[Jan Hubicka]

Hi,
this patch adds missing gcc_free on agg.items and descriptors and makes
allocations precise.  This saves about 316MB WPAing Firefox

Honza

Bootstrapped/regtested x86_64-linux, comitted.

* ipa-prop.c (build_agg_jump_func_from_list,
ipa_read_jump_function): Reserve agg.items precisely.
* ipa-prop.h (ipa_node_params::~ipa_node_params): Release descriptors
(ipa_edge_args::~ipa_edge_args): Release agg.items.
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 7a5fa59ecec..904a8f7d18b 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -1682,7 +1682,7 @@ build_agg_jump_func_from_list (struct 
ipa_known_agg_contents_list *list,
   int value_count, HOST_WIDE_INT arg_offset,
   struct ipa_jump_func *jfunc)
 {
-  vec_alloc (jfunc->agg.items, value_count);
+  vec_safe_reserve (jfunc->agg.items, value_count, true);
   for (; list; list = list->next)
 {
   struct ipa_agg_jf_item item;
@@ -4745,7 +4745,10 @@ ipa_read_jump_function (class lto_input_block *ib,
 
   count = streamer_read_uhwi (ib);
   if (prevails)
-vec_alloc (jump_func->agg.items, count);
+{
+  jump_func->agg.items = NULL;
+  vec_safe_reserve (jump_func->agg.items, count, true);
+}
   if (count)
 {
   struct bitpack_d bp = streamer_read_bitpack (ib);
diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
index 77e92b04bba..56e80559cf4 100644
--- a/gcc/ipa-prop.h
+++ b/gcc/ipa-prop.h
@@ -620,6 +620,7 @@ inline
 ipa_node_params::~ipa_node_params ()
 {
   free (lattices);
+  vec_free (descriptors);
   known_csts.release ();
   known_contexts.release ();
 }
@@ -895,6 +896,10 @@ class GTY((for_user)) ipa_edge_args
   /* Destructor.  */
   ~ipa_edge_args ()
 {
+  unsigned int i;
+  ipa_jump_func *jf;
+  FOR_EACH_VEC_SAFE_ELT (jump_functions, i, jf)
+   vec_free (jf->agg.items);
   vec_free (jump_functions);
   vec_free (polymorphic_call_contexts);
 }

Re: [PATCH] middle-end: Support complex Addition

[Richard Biener]

On Mon, 23 Nov 2020, Tamar Christina wrote:

> Hi All,
> 
> This patch adds support for
> 
>   * Complex Addition with rotation of 90 and 270.
> 
>   Addition with rotation of the second argument around the Argand plane.
> Supported rotations are 90 and 180.
> 
> c = a + (b * I) and c = a + (b * I * I * I)
> 
> For the full code I have pushed a branch at 
> refs/users/tnfchris/heads/complex-numbers.
> 
> As a side note, I still needed to set
> 
> STMT_SLP_TYPE (call_stmt_info) = pure_slp;
> 
> as the new hybrid detection code only runs for loop aware SLP.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues, but
> sorting out the testcases as TCL is processed before the CPP..
> 
> Ok for master?

So I failed to apply this patch (and after manual fixup build).
I went ahead and checked out the branch, patching the tree with
x86 support for cadd90 with -msse3 or -mavx2 using the attached
patch.

For

double c[1024], b[1024], a[1024];

void foo ()
{
  for (int i = 0; i < 512; ++i)
{
  c[2*i] = a[2*i] - b[2*i+1];
  c[2*i+1] = a[2*i+1] + b[2*i];
}
}

I then see

t.c:5:21: note:Analyzing SLP tree 0x39c0010 for patterns
t.c:5:21: note:Found COMPLEX_ADD_ROT90 pattern in SLP tree
t.c:5:21: note:Target supports COMPLEX_ADD_ROT90 vectorization with 
mode vector(2) double
t.c:5:21: note:Pattern matched SLP tree
t.c:5:21: note:node 0x39c0010 (max_nunits=2, refcnt=2)
t.c:5:21: note:op template: c[_1] = _5;
t.c:5:21: note: stmt 0 c[_1] = _5;
t.c:5:21: note: stmt 1 c[_3] = _8;
t.c:5:21: note: children 0x39c0080
t.c:5:21: note:node 0x39c0080 (max_nunits=2, refcnt=2)
t.c:5:21: note:op template: slp_patt_29 = .COMPLEX_ADD_ROT90 (_5, _5);
t.c:5:21: note: stmt 0 _5 = _2 - _4;
t.c:5:21: note: stmt 1 _8 = _6 + _7;
t.c:5:21: note: lane permutation { 0[0] 1[1] }
t.c:5:21: note: children 0x39c00f0 0x39c02b0
t.c:5:21: note:node 0x39c00f0 (max_nunits=2, refcnt=2)
t.c:5:21: note:op template: _2 = a[_1];
t.c:5:21: note: stmt 0 _2 = a[_1];
t.c:5:21: note: stmt 1 _6 = a[_3];
t.c:5:21: note: load permutation { 0 1 }
t.c:5:21: note:node 0x39c02b0 (max_nunits=1, refcnt=1)
t.c:5:21: note:op: VEC_PERM_EXPR
t.c:5:21: note: { }
t.c:5:21: note: lane permutation { 0[1] 0[0] }
t.c:5:21: note: children 0x39c0160
t.c:5:21: note:node 0x39c0160 (max_nunits=2, refcnt=2)
t.c:5:21: note:op template: _4 = b[_3];
t.c:5:21: note: stmt 0 _4 = b[_3];
t.c:5:21: note: stmt 1 _7 = b[_1];
t.c:5:21: note: load permutation { 1 0 }

I'm confused about the lane permutation in the .COMPLEX_ADD_ROT90
node (I guess this permutation is simply ignored by code-generation).
Should it not be there?  

Otherwise the outcome is now as expected.  Permute optimization
later produces

t.c:5:21: note:   node 0x39c0080 (max_nunits=2, refcnt=1)
t.c:5:21: note:   op template: slp_patt_29 = .COMPLEX_ADD_ROT90 (_5, _5);
t.c:5:21: note: stmt 0 _5 = _2 - _4;
t.c:5:21: note: stmt 1 _8 = _6 + _7;
t.c:5:21: note: lane permutation { 0[0] 1[1] }
t.c:5:21: note: children 0x39c00f0 0x39c02b0
...
t.c:5:21: note:   node 0x39c02b0 (max_nunits=1, refcnt=1)
t.c:5:21: note:   op: VEC_PERM_EXPR
t.c:5:21: note: { }
t.c:5:21: note: lane permutation { 0[0] 0[1] }
t.c:5:21: note: children 0x39c0160
t.c:5:21: note:   node 0x39c0160 (max_nunits=2, refcnt=1)
t.c:5:21: note:   op template: _4 = b[_3];
t.c:5:21: note: stmt 0 _7 = b[_1];
t.c:5:21: note: stmt 1 _4 = b[_3];

where the noop permute is correctly costed (and thus is just a
cosmetic annoyance):

0x3a13870 a[_1] 1 times vector_load costs 12 in body
0x3a13870 b[_1] 1 times vector_load costs 12 in body
0x3a13870  0 times vec_perm costs 0 in body
0x3a13870 .COMPLEX_ADD_ROT90 (_5, _5) 1 times vector_stmt costs 12 in body
0x3a13870 _5 1 times vector_store costs 12 in body

Code generated is also superior (-msse3):

.L2:
movapd  a(%rax), %xmm0
addsubpdb(%rax), %xmm0
addq$16, %rax
movaps  %xmm0, c-16(%rax)
cmpq$8192, %rax
jne .L2

compared to GCC 10 where we have an extra permute

.L2:
movapd  b(%rax), %xmm0
movapd  a(%rax), %xmm1
addq$16, %rax
shufpd  $1, %xmm0, %xmm0
addsubpd%xmm0, %xmm1
movaps  %xmm1, c-16(%rax)
cmpq$8192, %rax
jne .L2

which of course makes me wonder whether I have done the x86
support correctly.  Ah, I have not.  The x86 instructions
do not embed the even/odd lane swap, they just do the mixed
sign operation.  So for those we'd need additional optabs
and patterns then.

So I see the branch contains only the complex add so I'm
going through the changes there:

 /* Create an SLP node for SCALAR_STMTS.  */
 
-static slp_tree
+slp_tree
 vect_create_new_slp_node (slp_tree node,
  

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Paul Koning via Gcc-patches]

> On Nov 19, 2020, at 10:38 PM, Maciej W. Rozycki  wrote:
> 
> Hi,
> 
> [Paul, there's a PDP11 piece for you further down here and then 29/31.]
> 
> ...
> 
> Then there is a fix for the PDP11 backend addressing an issue I found in 
> the handling of floating-point comparisons.  Unlike all the other changes 
> this one has not been regression-tested, not even built as I have no idea 
> how to prepare a development environment for a PDP11 target (also none of 
> my VAX pieces is old enough to support PDP11 machine code execution).

I agree this is a correct change, interesting that it was missed before.  You'd 
expect some ICE issues from that mistake.  Perhaps there were and I didn't 
realize the cause; the PDP11 test run is not yet fully clean.

I've hacked together a primitive newlib based "bare metal" execution test setup 
that uses SIMH, but it's not a particularly clean setup.  And it hasn't been 
posted, I hope to be able to do that at some point.

Thanks for the fix.

paul

Diagnostic for module importation

[Nathan Sidwell]

This tweaks the 'included from ...' printing to deal with imports in
the 'include' path.  One new thing is that there can now be two
'include' names on a single line.  For example 'in module X, included
at Y'.  This reads better than placing them on different lines.

gcc/
* diagnostic.c (diagnostic_report_current_module): Adjust for C++
module importation.

pushing to trunk

--
Nathan Sidwell
diff --git i/gcc/diagnostic.c w/gcc/diagnostic.c
index 1b6c9845892..fe509d88e6d 100644
--- i/gcc/diagnostic.c
+++ w/gcc/diagnostic.c
@@ -689,12 +689,13 @@ diagnostic_report_current_module (diagnostic_context *context, location_t where)
   set_last_module (context, map);
   if (! MAIN_FILE_P (map))
 	{
-	  bool first = true;
+	  bool first = true, need_inc = true, was_module = MAP_MODULE_P (map);
 	  expanded_location s = {};
 	  do
 	{
 	  where = linemap_included_from (map);
 	  map = linemap_included_from_linemap (line_table, map);
+	  bool is_module = MAP_MODULE_P (map);
 	  s.file = LINEMAP_FILE (map);
 	  s.line = SOURCE_LINE (map, where);
 	  int col = -1;
@@ -706,14 +707,24 @@ diagnostic_report_current_module (diagnostic_context *context, location_t where)
 	  const char *line_col = maybe_line_and_column (s.line, col);
 	  static const char *const msgs[] =
 		{
-		 N_("In file included from"),
+		 NULL,
 		 N_(" from"),
+		 N_("In file included from"),	/* 2 */
+		 N_("included from"),
+		 N_("In module"),		/* 4 */
+		 N_("of module"),
+		 N_("In module imported at"),	/* 6 */
+		 N_("imported at"),
 		};
-	  unsigned index = !first;
+
+	  unsigned index = (was_module ? 6 : is_module ? 4
+: need_inc ? 2 : 0) + !first;
+
 	  pp_verbatim (context->printer, "%s%s %r%s%s%R",
-			   first ? "" : ",\n", _(msgs[index]),
+			   first ? "" : was_module ? ", " : ",\n",
+			   _(msgs[index]),
 			   "locus", s.file, line_col);
-	  first = false;
+	  first = false, need_inc = was_module, was_module = is_module;
 	}
 	  while (! MAIN_FILE_P (map));
 	  pp_verbatim (context->printer, ":");

c++: Add empty module.cc

[Nathan Sidwell]

This adds an empty module.cc file, along with make rules to build it.

gcc/cp/
* module.cc: New dummy file.
* Make-lang.in: Add rules to build module.o

pushing to trunk
--
Nathan Sidwell
diff --git c/gcc/cp/Make-lang.in w/gcc/cp/Make-lang.in
index 6be4678776b..de64d592a0d 100644
--- c/gcc/cp/Make-lang.in
+++ w/gcc/cp/Make-lang.in
@@ -54,6 +54,9 @@ c++.serial: c++
 
 CFLAGS-cp/g++spec.o += $(DRIVER_DEFINES)
 
+CFLAGS-cp/module.o += -DHOST_MACHINE=\"$(host)\" \
+	-DTARGET_MACHINE=\"$(target)\"
+
 # Create the compiler driver for g++.
 GXX_OBJS = $(GCC_OBJS) cp/g++spec.o
 xg++$(exeext): $(GXX_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a $(LIBDEPS)
@@ -81,7 +84,7 @@ CXX_AND_OBJCXX_OBJS = \
 	cp/error.o cp/except.o cp/expr.o \
 	cp/friend.o cp/init.o \
 	cp/lambda.o cp/lex.o cp/logic.o \
-	cp/mangle.o cp/method.o \
+	cp/mangle.o cp/method.o cp/module.o \
 	cp/name-lookup.o cp/optimize.o \
 	cp/parser.o cp/pt.o cp/ptree.o \
 	cp/rtti.o \
diff --git c/gcc/cp/module.cc w/gcc/cp/module.cc
new file mode 100644
index 000..596061b3c49
--- /dev/null
+++ w/gcc/cp/module.cc
@@ -0,0 +1,21 @@
+/* C++ modules.  Experimental!
+   Copyright (C) 2017-2020 Free Software Foundation, Inc.
+   Written by Nathan Sidwell  while at FaceBook
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/* This file intentionally left empty.  */

Re: [C PATCH] Drop qualifiers during lvalue conversion

[Uecker, Martin]

Am Montag, den 23.11.2020, 14:55 +0100 schrieb Christophe Lyon:
> Hi,
> 
> 
> On Thu, 19 Nov 2020 at 07:34, Uecker, Martin
>  wrote:
> > 
> > 
> > Here is another version of the patch. The
> > only difference is the additional the check
> > using 'tree_ssa_useless_type_conversion'.
> > 
> > 
> > Best,
> > Martin
> > 
> > 
> > 
> > 
> > C: Drop qualifiers during lvalue conversion. PR97702
> > 
> > 2020-11-XX  Martin Uecker  
> > 
> > gcc/
> > * gcc/gimplify.c (gimplify_modify_expr_rhs): Optimizie
> > NOP_EXPRs that contain compound literals.
> > 
> > gcc/c/
> > * c-typeck.c (convert_lvalue_to_rvalue): Drop
> > qualifiers.
> > 
> > gcc/testsuite/
> > * gcc.dg/cond-constqual-1.c: Adapt test.
> > * gcc.dg/lvalue-11.c: New test.
> > * gcc.dg/pr60195.c: Add warning.
> > 
> > 
> > 
> 
> This patch causes a regression on arm:
> FAIL: gcc.dg/fixed-point/struct-union.c (test for excess errors)
> Excess errors:
> /gcc/testsuite/gcc.dg/fixed-point/struct-union.c:60:8: warning: value
> computed is not used [-Wunused-value]
> /gcc/testsuite/gcc.dg/fixed-point/struct-union.c:61:9: warning: value
> computed is not used [-Wunused-value]
> 
> The test in question lines 60-61 are:
>   /* Test assignment to volatile structure members.  */
>   sv.f = 0.06r;
>   sv.lf = 0.07lr;
> 
> so it seems these assignments are now illegally removed.
> 
> Can you check?

Must be some kind of strange interaction with _Fract.
I am not yet sure why this happens...

Best,
Martin


> Thanks,
> 
> Christophe
>
> > 
> > diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
> > index 413109c916c..286f3d9cd6c 100644
> > --- a/gcc/c/c-typeck.c
> > +++ b/gcc/c/c-typeck.c
> > @@ -2080,6 +2080,9 @@ convert_lvalue_to_rvalue (location_t loc,
> > struct c_expr exp,
> >  exp = default_function_array_conversion (loc, exp);
> >if (!VOID_TYPE_P (TREE_TYPE (exp.value)))
> >  exp.value = require_complete_type (loc, exp.value);
> > +  if (convert_p && !error_operand_p (exp.value)
> > +  && (TREE_CODE (TREE_TYPE (exp.value)) != ARRAY_TYPE))
> > +exp.value = convert (build_qualified_type (TREE_TYPE
> > (exp.value), TYPE_UNQUALIFIED),
> > exp.value);
> >if (really_atomic_lvalue (exp.value))
> >  {
> >vec *params;
> > diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> > index 2566ec7f0af..fd0b5202b45 100644
> > --- a/gcc/gimplify.c
> > +++ b/gcc/gimplify.c
> > @@ -5518,6 +5518,19 @@ gimplify_modify_expr_rhs (tree *expr_p, tree
> > *from_p, tree *to_p,
> > return GS_OK;
> >   }
> > 
> > +   case NOP_EXPR:
> > + /* Pull out compound literal expressions from a NOP_EXPR.
> > +Those are created in the C FE to drop qualifiers
> > during
> > +lvalue conversion.  */
> > + if ((TREE_CODE (TREE_OPERAND (*from_p, 0)) ==
> > COMPOUND_LITERAL_EXPR)
> > + && tree_ssa_useless_type_conversion (*from_p))
> > +   {
> > + *from_p = TREE_OPERAND (*from_p, 0);
> > + ret = GS_OK;
> > + changed = true;
> > +   }
> > + break;
> > +
> > case COMPOUND_LITERAL_EXPR:
> >   {
> > tree complit = TREE_OPERAND (*expr_p, 1);
> > diff --git a/gcc/testsuite/gcc.dg/cond-constqual-1.c
> > b/gcc/testsuite/gcc.dg/cond-constqual-1.c
> > index 3354c7214a4..b5a09cb0038 100644
> > --- a/gcc/testsuite/gcc.dg/cond-constqual-1.c
> > +++ b/gcc/testsuite/gcc.dg/cond-constqual-1.c
> > @@ -11,5 +11,5 @@ test (void)
> >__typeof__ (1 ? foo (0) : 0) texpr;
> >__typeof__ (1 ? i : 0) texpr2;
> >texpr = 0;  /* { dg-bogus "read-only variable" "conditional
> > expression with call to const
> > function" } */
> > -  texpr2 = 0; /* { dg-error "read-only variable" "conditional
> > expression with const variable" } */
> > +  texpr2 = 0; /* { dg-bogus "read-only variable" "conditional
> > expression with const variable" } */
> >  }
> > diff --git a/gcc/testsuite/gcc.dg/lvalue-11.c
> > b/gcc/testsuite/gcc.dg/lvalue-11.c
> > new file mode 100644
> > index 000..45a97d86890
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/lvalue-11.c
> > @@ -0,0 +1,46 @@
> > +/* test that lvalue conversions drops qualifiers, Bug 97702 */
> > +/* { dg-do compile } */
> > +/* { dg-options "" } */
> > +
> > +
> > +void f(void)
> > +{
> > + const int j;
> > + typeof((0,j)) i10; i10 = j;;
> > + typeof(+j) i11; i11 = j;;
> > + typeof(-j) i12; i12 = j;;
> > + typeof(1?j:0) i13; i13 = j;;
> > + typeof((int)j) i14; i14 = j;;
> > + typeof((const int)j) i15; i15 = j;;
> > +}
> > +
> > +void g(void)
> > +{
> > + volatile int j;
> > + typeof((0,j)) i21; i21 = j;;
> > + typeof(+j) i22; i22 = j;;
> > + typeof(-j) i23; i23 = j;;
> > + typeof(1?j:0) i24; i24 = j;;
> > + typeof((int)j) i25; i25 = j;;
> > + typeof((volatile int)j) i26; i26 = j;;
> > +}
> > +
> > +void h(void)
> > +{
> > + _Atomic int j;
> > + typeof((0,j)) i32; i32 = j;;
> > + typeof(+j) i33; i33 = 

Re: [PATCH] gcov: Add __gcov_info_to_gdca()

[Martin Liška]

On 11/23/20 3:50 PM, Sebastian Huber wrote:

On 23/11/2020 15:49, Martin Liška wrote:


On 11/23/20 3:35 PM, Sebastian Huber wrote:

If I have to wait for next stage 1, I can also try to refactor write_one_data() 
after your patch which removes the buffering.


Yes, please build your patches on top of the file buffering removal.

Ok.



This would avoid some duplicated code, however, it would require some changes 
in existing code. Is it allowed to remove external (hidden?) symbols from 
libgcov?


Which functions do you mean?

Refactoring write_one_data() to use hooks requires that

gcov_write_counter()

gcov_write_tag_length()

gcov_write_summary()


I bet these 3 can be actually moved to gcov-io.h, these functions are very 
small.
So yes, it should be doable.

Martin



move from gcc/gcov-io.c to libgcc/libgcov-buffer.c. They can be made static. I 
am not sure if the external symbols can be removed

/* In libgcov we need these functions to be extern, so prefix them with
     __gcov.  In libgcov they must also be hidden so that the instance in
     the executable is not also used in a DSO.  */
#define gcov_write_tag_length __gcov_write_tag_length
#define gcov_write_counter __gcov_write_counter
#define gcov_write_summary __gcov_write_summary

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

[Martin Liška]

On 11/23/20 2:02 PM, Martin Liška wrote:

May I apply the patch after it finishes regression tests and bootstrap?


It survives testing.

There's the second part which adds -frecord-gcc-switches-format.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Thanks,
Martin
>From b6c135ff7709df10e8bc3d6fab9d7987ed263fa2 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 23 Nov 2020 14:10:38 +0100
Subject: [PATCH] Change semantics of -frecord-gcc-switches and add
 -frecord-gcc-switches-format.

gcc/ChangeLog:

	* common.opt: Document new options -frecord-gcc-switches-format
	and -frecord-gcc-switches-file.
	* doc/invoke.texi: Document the new options.
	* dwarf2out.c (dwarf2out_early_finish): Respect
	flag_record_gcc_switches_format.
	* flag-types.h (enum record_gcc_switches_format): New.
	* gcc.c (save_driver_cmdline): Save command line to a temporary
	file.
	(driver::main): Call set_commandline.
	(driver::set_commandline): New.
	* gcc.h (set_commandline): New.
	* opts.c (get_driver_command_line): New.
	* opts.h (get_driver_command_line): New.
	* toplev.c (init_asm_output): Use new function get_producer_string.
	(process_options): Respect flag_record_gcc_switches_format
	option.

Co-Authored-By: Egeyar Bagcioglu  
---
 gcc/common.opt  | 19 ++-
 gcc/doc/invoke.texi | 23 ++-
 gcc/dwarf2out.c | 17 -
 gcc/flag-types.h|  7 +++
 gcc/gcc.c   | 37 -
 gcc/gcc.h   |  1 +
 gcc/opts.c  | 31 +++
 gcc/opts.h  |  2 ++
 gcc/toplev.c| 29 ++---
 9 files changed, 151 insertions(+), 15 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index ca8a2690799..3492e14cb1e 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2322,9 +2322,26 @@ Common Joined RejectNegative Var(common_deferred_options) Defer
 ; records information in the assembler output file as comments, so
 ; they never reach the object file.
 frecord-gcc-switches
-Common Report Var(flag_record_gcc_switches)
+Common Driver Report Var(flag_record_gcc_switches)
 Record gcc command line switches in the object file.
 
+Enum
+Name(record_gcc_switches_format) Type(enum record_gcc_switches_format)
+
+EnumValue
+Enum(record_gcc_switches_format) String(processed) Value(RECORD_GCC_SWITCHES_PROCESSED)
+
+EnumValue
+Enum(record_gcc_switches_format) String(driver) Value(RECORD_GCC_SWITCHES_DRIVER)
+
+frecord-gcc-switches-format=
+Common Report Joined RejectNegative Var(flag_record_gcc_switches_format) Enum(record_gcc_switches_format) Init(RECORD_GCC_SWITCHES_PROCESSED)
+-frecord-gcc-switches-format=[processed|driver]	Format of recorded gcc command line switches.
+
+frecord-gcc-switches-file=
+Common Report Joined RejectNegative Var(flag_record_gcc_switches_file) Undocumented
+Path to file that contains driver command line options.
+
 freg-struct-return
 Common Report Var(flag_pcc_struct_return,0) Optimization
 Return small aggregates in registers.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 26372a2435a..d7e43c84ffc 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -642,7 +642,7 @@ Objective-C and Objective-C++ Dialects}.
 -finhibit-size-directive  -fcommon  -fno-ident @gol
 -fpcc-struct-return  -fpic  -fPIC  -fpie  -fPIE  -fno-plt @gol
 -fno-jump-tables -fno-bit-tests @gol
--frecord-gcc-switches @gol
+-frecord-gcc-switches -frecord-gcc-switches-format @gol
 -freg-struct-return  -fshort-enums  -fshort-wchar @gol
 -fverbose-asm  -fpack-struct[=@var{n}]  @gol
 -fleading-underscore  -ftls-model=@var{model} @gol
@@ -16022,6 +16022,27 @@ comments, so it never reaches the object file.
 See also @option{-grecord-gcc-switches} for another
 way of storing compiler options into the object file.
 
+@item -frecord-gcc-switches-format=@var{format}
+@opindex frecord-gcc-switches-format
+This switch controls the output format of options that record
+the command line.  The affected options are @option{-frecord-gcc-switches},
+@option{-grecord-gcc-switches} and @option{-fverbose-asm}.
+
+The @var{format} argument should be one of the following:
+
+@table @samp
+
+@item processed
+
+Options are printed after processing by the compiler driver.
+It is the default option value.
+
+@item driver
+
+Options are printed as provided to the compiler driver.
+
+@end table
+
 @item -fpic
 @opindex fpic
 @cindex global offset table
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 82303751fce..c584bb1a7c5 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -32036,13 +32036,20 @@ dwarf2out_early_finish (const char *filename)
  header compilation, so always fill it with empty string initially
  and overwrite only here.  */
   dw_attr_node *producer = get_AT (comp_unit_die (), DW_AT_producer);
+  producer_string = concat (lang_hooks.name, " ", version_string, NULL);
 
   if (dwarf_record_gcc_switches)
-producer_string = gen_producer_string 

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 21/11/20 16:36 -0800, H.J. Lu wrote:

On Sat, Nov 21, 2020 at 9:40 AM Jonathan Wakely via Gcc-patches
 wrote:


On 21/11/20 17:04 +, Jonathan Wakely wrote:
>On 21/11/20 16:16 +0100, Andreas Schwab wrote:
>>In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
>>from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
>>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:
 In member function 'void std::atomic_flag::wait(bool, std::memory_order) const':
>>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 error: no matching function for call to '__atomic_wait(const __atomic_flag_data_type*, 
bool&, std::atomic_flag::wait(bool, std::memory_order) const::)'
>>In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:41,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
>>from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
>>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note: candidate: 'template void std::__atomic_wait(const 
_Tp*, _Tp, _Pred)'
>>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note:   template argument deduction/substitution failed:
>>In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
>>from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
>>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 note:   deduced conflicting types for parameter '_Tp' ('unsigned char' and 'bool')
>
>I'm testing this.

I'm committing this instead, it's the same but also disables
29_atomics/atomic/wait_notify/generic.cc on non-linux targets.

Tested sparc-solaris2.11 and powerpc64le-linux.

There are still some timeouts on linux:

FAIL: 30_threads/latch/3.cc execution test
FAIL: 30_threads/semaphore/try_acquire_for.cc execution test



I opened:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936


Thanks.

Re: [PATCH] gcov: Add __gcov_info_to_gdca()

[Sebastian Huber]

On 23/11/2020 15:49, Martin Liška wrote:


On 11/23/20 3:35 PM, Sebastian Huber wrote:
If I have to wait for next stage 1, I can also try to refactor 
write_one_data() after your patch which removes the buffering.


Yes, please build your patches on top of the file buffering removal.

Ok.


This would avoid some duplicated code, however, it would require some 
changes in existing code. Is it allowed to remove external (hidden?) 
symbols from libgcov?


Which functions do you mean?

Refactoring write_one_data() to use hooks requires that

gcov_write_counter()

gcov_write_tag_length()

gcov_write_summary()

move from gcc/gcov-io.c to libgcc/libgcov-buffer.c. They can be made 
static. I am not sure if the external symbols can be removed


/* In libgcov we need these functions to be extern, so prefix them with
    __gcov.  In libgcov they must also be hidden so that the instance in
    the executable is not also used in a DSO.  */
#define gcov_write_tag_length __gcov_write_tag_length
#define gcov_write_counter __gcov_write_counter
#define gcov_write_summary __gcov_write_summary

--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier: 
https://embedded-brains.de/datenschutzerklaerung/

[Patch] OpenMP: C/C++ parse 'omp allocate'

[Tobias Burnus]

Given that (at least for C/C++) there is some initial support for
OpenMP 5.0's allocators, it is likely that users will try it.
Also the release notes state: "the allocator routines of OpenMP 5.0,
including initial|allocate|  clause support in C/C++."

The latter does not include the omp allocate directive, still,
it can be expected that users will try:

  #pragma omp allocate(...)

And that will fail at runtime. I think that's undesirable,
even if - like any unknown directive - -Wunknown-pragmas
(-Wall) warns about it.

Thoughts? OK?

Tobias

PS: I have not tried to implement restrictions or additions
like 'allocate(a[5])', which is currently rejected. I also
did not check whether there are differences between the clause
([partially] implemented) and the directive (this patch).

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
OpenMP: C/C++ parse 'omp allocate'

gcc/c-family/ChangeLog:

	* c-pragma.c (omp_pragmas): Add 'allocate'.
	* c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_ALLOCATE.

gcc/c/ChangeLog:

	* c-parser.c (c_parser_omp_allocate): New.
	(c_parser_omp_construct): Call it.

gcc/cp/ChangeLog:

	* parser.c (cp_parser_omp_allocate): New.
	(cp_parser_omp_construct, cp_parser_pragma): Call it.

gcc/testsuite/ChangeLog:

	* c-c++-common/gomp/allocate-5.c: New test.

 gcc/c-family/c-pragma.c  |  1 +
 gcc/c-family/c-pragma.h  |  1 +
 gcc/c/c-parser.c | 52 
 gcc/cp/parser.c  | 43 ++-
 gcc/testsuite/c-c++-common/gomp/allocate-5.c | 41 ++
 5 files changed, 137 insertions(+), 1 deletion(-)

diff --git a/gcc/c-family/c-pragma.c b/gcc/c-family/c-pragma.c
index d68985ca277..e80dcd7c0a1 100644
--- a/gcc/c-family/c-pragma.c
+++ b/gcc/c-family/c-pragma.c
@@ -1309,6 +1309,7 @@ static const struct omp_pragma_def oacc_pragmas[] = {
   { "wait", PRAGMA_OACC_WAIT }
 };
 static const struct omp_pragma_def omp_pragmas[] = {
+  { "allocate", PRAGMA_OMP_ALLOCATE },
   { "atomic", PRAGMA_OMP_ATOMIC },
   { "barrier", PRAGMA_OMP_BARRIER },
   { "cancel", PRAGMA_OMP_CANCEL },
diff --git a/gcc/c-family/c-pragma.h b/gcc/c-family/c-pragma.h
index 5a493fe5175..e0e4da6b6b3 100644
--- a/gcc/c-family/c-pragma.h
+++ b/gcc/c-family/c-pragma.h
@@ -42,6 +42,7 @@ enum pragma_kind {
   PRAGMA_OACC_UPDATE,
   PRAGMA_OACC_WAIT,
 
+  PRAGMA_OMP_ALLOCATE,
   PRAGMA_OMP_ATOMIC,
   PRAGMA_OMP_BARRIER,
   PRAGMA_OMP_CANCEL,
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 7540a15d65d..fddd5c3c8c6 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -17255,6 +17255,55 @@ c_parser_oacc_wait (location_t loc, c_parser *parser, char *p_name)
   return stmt;
 }
 
+/* OpenMP 5.0:
+   # pragma omp allocate (list)  [allocator(allocator)]  */
+
+static void
+c_parser_omp_allocate (location_t loc, c_parser *parser)
+{
+  tree allocator = NULL_TREE;
+  tree nl = c_parser_omp_var_list_parens (parser, OMP_CLAUSE_ALLOCATE, NULL_TREE);
+  if (c_parser_next_token_is (parser, CPP_NAME))
+{
+  matching_parens parens;
+  const char *p = IDENTIFIER_POINTER (c_parser_peek_token (parser)->value);
+  c_parser_consume_token (parser);
+  if (strcmp ("allocator", p) != 0)
+	error_at (c_parser_peek_token (parser)->location,
+		  "expected %");
+  else if (parens.require_open (parser))
+	{
+	  location_t expr_loc = c_parser_peek_token (parser)->location;
+	  c_expr expr = c_parser_expr_no_commas (parser, NULL);
+	  expr = convert_lvalue_to_rvalue (expr_loc, expr, false, true);
+	  allocator = expr.value;
+	  allocator = c_fully_fold (allocator, false, NULL);
+	  tree orig_type
+	= expr.original_type ? expr.original_type : TREE_TYPE (allocator);
+	  orig_type = TYPE_MAIN_VARIANT (orig_type);
+	  if (!INTEGRAL_TYPE_P (TREE_TYPE (allocator))
+	  || TREE_CODE (orig_type) != ENUMERAL_TYPE
+	  || TYPE_NAME (orig_type)
+		 != get_identifier ("omp_allocator_handle_t"))
+	{
+	  error_at (expr_loc, "% clause allocator expression "
+"has type %qT rather than "
+"%",
+TREE_TYPE (allocator));
+	  allocator = NULL_TREE;
+	}
+	  parens.skip_until_found_close (parser);
+	}
+}
+  c_parser_skip_to_pragma_eol (parser);
+
+  if (allocator)
+for (tree c = nl; c != NULL_TREE; c = OMP_CLAUSE_CHAIN (c))
+  OMP_CLAUSE_ALLOCATE_ALLOCATOR (c) = allocator;
+
+  sorry_at (loc, "%<#pragma omp allocate%> not yet supported");
+}
+
 /* OpenMP 2.5:
# pragma omp atomic new-line
  expression-stmt
@@ -21542,6 +21591,9 @@ c_parser_omp_construct (c_parser *parser, bool *if_p)
   strcpy (p_name, "#pragma wait");
   stmt = c_parser_oacc_wait (loc, parser, p_name);
   break;
+case PRAGMA_OMP_ALLOCATE:
+  c_parser_omp_allocate (loc, parser);
+  return;
 case PRAGMA_OMP_ATOMIC:
   

Re: [PATCH] gcov: Add __gcov_info_to_gdca()

[Martin Liška]

On 11/23/20 3:35 PM, Sebastian Huber wrote:

If I have to wait for next stage 1, I can also try to refactor write_one_data() 
after your patch which removes the buffering.


Yes, please build your patches on top of the file buffering removal.


This would avoid some duplicated code, however, it would require some changes 
in existing code. Is it allowed to remove external (hidden?) symbols from 
libgcov?


Which functions do you mean?

Martin

[committed] MSP430: Remove target-specific handling of the "persistent" attribute

[Jozef Lawrynowicz]

The "persistent" attribute is now handled generically, and does not
need specific support in the MSP430 back end.

Successfully built and regtested C/C++ testsuites for msp430-elf.

Committed as obvious.
>From 77ee207e17d02e4aec502c6aedd9b0ba36a08de3 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Mon, 23 Nov 2020 14:24:43 +
Subject: [PATCH] MSP430: Remove target-specific handling of the "persistent"
 attribute

The "persistent" attribute is now handled generically, and does not
need specific support in the MSP430 back end.

gcc/ChangeLog:

* config/msp430/msp430.c (msp430_section_attr): Don't warn for "lower"
attribute used with "noinit" or "persistent" attributes.
(msp430_persist_attr): Remove.
(attr_lower_exclusions): Remove ATTR_PERSIST exclusion.
(attr_upper_exclusions): Likewise.
(attr_either_exclusions): Likewise.
(attr_persist_exclusions): Remove.
(msp430_attribute_table): Remove ATTR_PERSIST handling.
(msp430_handle_generic_attribute): Remove ATTR_PERSIST section conflict
handling.
(TARGET_ASM_INIT_SECTIONS): Remove.
(msp430_init_sections): Remove.
(msp430_select_section): Use default_elf_select_section for decls with
the "persistent" attribute.
(msp430_section_type_flags): Remove ".persistent" section handling.
* doc/extend.texi (MSP430 Variable Attributes): Remove "noinit" and
"persistent" documentation.

gcc/testsuite/ChangeLog:

* g++.target/msp430/data-attributes.C: Remove expected warnings for
"lower" attribute conflicts.
Adjust expected wording for "persistent" attribute misuse.
* gcc.target/msp430/data-attributes-2.c: Likewise.
* gcc.target/msp430/pr78818-auto-warn.c: Likewise.
---
 gcc/config/msp430/msp430.c| 114 +++---
 gcc/doc/extend.texi   |  17 ---
 .../g++.target/msp430/data-attributes.C   |  19 +--
 .../gcc.target/msp430/data-attributes-2.c |  14 +--
 .../gcc.target/msp430/pr78818-auto-warn.c |   4 +-
 5 files changed, 36 insertions(+), 132 deletions(-)

diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 51f49edffa8..db3a9ff5330 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -1968,15 +1968,18 @@ msp430_section_attr (tree * node,
 
   const char * message = NULL;
 
-  /* The "noinit" and "section" attributes are handled generically, so we
- cannot set up additional target-specific attribute exclusions using the
- existing mechanism.  */
-  if (has_attr (ATTR_NOINIT, *node))
+  /* The "noinit", "persistent", and "section" attributes are handled
+ generically, so we cannot set up additional target-specific attribute
+ exclusions using the existing mechanism.  */
+  if (has_attr (ATTR_NOINIT, *node) && !TREE_NAME_EQ (name, "lower"))
 message = G_("ignoring attribute %qE because it conflicts with "
 "attribute %");
   else if (has_attr ("section", *node) && !TREE_NAME_EQ (name, "lower"))
 message = G_("ignoring attribute %qE because it conflicts with "
 "attribute %");
+  else if (has_attr (ATTR_PERSIST, *node) && !TREE_NAME_EQ (name, "lower"))
+message = G_("ignoring attribute %qE because it conflicts with "
+"attribute %");
   /* It does not make sense to use upper/lower/either attributes without
  -mlarge.
  Without -mlarge, "lower" is the default and only region, so is redundant.
@@ -1997,56 +2000,6 @@ msp430_section_attr (tree * node,
   return NULL_TREE;
 }
 
-static tree
-msp430_persist_attr (tree *node,
- tree   name,
- tree   args,
- intflags ATTRIBUTE_UNUSED,
- bool * no_add_attrs ATTRIBUTE_UNUSED)
-{
-  const char * message = NULL;
-
-  gcc_assert (DECL_P (* node));
-  gcc_assert (args == NULL);
-  gcc_assert (TREE_NAME_EQ (name, ATTR_PERSIST));
-
-  /* Check for the section attribute separately from DECL_SECTION_NAME so
- we can provide a clearer warning.  */
-  if (has_attr ("section", *node))
-message = G_("ignoring attribute %qE because it conflicts with "
-"attribute %");
-  /* Check that it's possible for the variable to have a section.  */
-  else if ((TREE_STATIC (*node) || DECL_EXTERNAL (*node) || in_lto_p)
-  && (DECL_SECTION_NAME (*node)))
-message = G_("%qE attribute cannot be applied to variables with specific "
-"sections");
-  else if (has_attr (ATTR_NOINIT, *node))
-message = G_("ignoring attribute %qE because it conflicts with "
-"attribute %");
-  else if (TREE_CODE (*node) != VAR_DECL)
-message = G_("%qE attribute only applies to variables");
-  else if (!TREE_STATIC (*node) && !TREE_PUBLIC (*node)
-  && !DECL_EXTERNAL (*node))
-message = G_("%qE attribute has no effect on automatic variables");
-  else if (DECL_COMMON 

Re: [PATCH v2] tree-ssa-threadbackward.c (profitable_jump_thread_path): Do not allow __builtin_constant_p () before IPA.

[Ilya Leoshkevich via Gcc-patches]

On Fri, 2020-11-20 at 12:14 -0700, Jeff Law wrote:
> 
> On 6/30/20 12:46 PM, Ilya Leoshkevich wrote:
> > v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.html
> > 
> > This is the implementation of Jakub's suggestion: allow
> > __builtin_constant_p () after IPA, but fold it into 0.  Smoke test
> > passed on s390x-redhat-linux, full regtest and bootstrap are
> > running on
> > x86_64-redhat-linux.
> > 
> > ---
> > 
> > Linux Kernel (specifically, drivers/leds/trigger/ledtrig-cpu.c)
> > build
> > with GCC 10 fails on s390 with "impossible constraint".
> > 
> > The problem is that jump threading makes __builtin_constant_p ()
> > lie
> > when it splits a path containing a non-constant expression in a way
> > that on each of the resulting paths this expression is constant.
> > 
> > Fix by disallowing __builtin_constant_p () on threading paths
> > before
> > IPA and fold it into 0 after IPA.
> > 
> > gcc/ChangeLog:
> > 
> > 2020-06-30  Ilya Leoshkevich  
> > 
> > * tree-ssa-threadbackward.c (thread_jumps::m_allow_bcp_p): New
> > member.
> > (thread_jumps::profitable_jump_thread_path): Do not allow
> > __builtin_constant_p () on threading paths unless m_allow_bcp_p
> > is set.
> > (thread_jumps::find_jump_threads_backwards): Set m_allow_bcp_p.
> > (pass_thread_jumps::execute): Allow __builtin_constant_p () on
> > threading paths after IPA.
> > (pass_early_thread_jumps::execute): Do not allow
> > __builtin_constant_p () on threading paths before IPA.
> > * tree-ssa-threadupdate.c (duplicate_thread_path): Fold
> > __builtin_constant_p () on threading paths into 0.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > 2020-06-30  Ilya Leoshkevich  
> > 
> > * gcc.target/s390/builtin-constant-p-threading.c: New test.
> So I'm finally getting back to this.  Thanks for your patience.
> 
> It's a nasty little problem, and I suspect there's actually some
> deeper
> issues here.  While I'd like to claim its a bad use of b_c_p, I don't
> think I can reasonably make that argument.
> 
> So what we have is a b_c_p at the start of an if-else chain. 
> Subsequent
> tests on the "true" arm of the the b_c_p test may throw us off the
> constant path (because the constants are out of range).  Once all the
> tests are passed (it's constant and the constant is in range) the
> true
> arm's terminal block has a special asm that requires a constant
> argument.   In the case where we get to the terminal block on the
> true
> arm, the argument to the b_c_p is used as the constant argument to
> the
> special asm.
> 
> At first glace jump threading seems to be doing the right thing. 
> Except
> that we end up with two paths to that terminal block with the special
> asm, one for each of the two constant arguments to the b_c_p call. 
> Naturally since that same value is used in the asm, we have to
> introduce
> a PHI to select between them at the head of the terminal block.   Now
> the argument in the asm is no longer constant and boom we fail.
> 
> I briefly pondered if we should only throttle when the argument to
> the
> b_c_p is not used elsewhere.  But I think that just hides the problem
> and with a little work I could probably extend the testcase to still
> fail in that scenario.
> 
> I also briefly pondered if we should isolate the terminal block as
> well
> (essentially creating one for each unique PHI argument).  We'd likely
> only need to do that when there's an ASM in the terminal block, but
> that
> likely just papers over the problem as well since the ASM could be in
> a
> successor of the terminal block.
> 
> I haven't thought real deeply about it, but I wouldn't be surprised
> if
> there's other passes that can trigger similar problems.  Aggressive
> cross-jumping would be the most obvious, but some of the
> hosting/sinking
> of operations past PHIs would seem potentially problematical as well.
> 
> Jakub suggestion might be the best one in this space.   I don't have
> anything better right now.  The deeper questions about other passes
> setting up similar scenarios can probably be punted, I'd expect
> threading to be far and above the most common way for this to happen
> and
> I'd be comfortable faulting in investigation of other cases if/when
> they
> happen.
> 
> So I retract my initial objections.  Let's go with the V2 patch.
> 
> 
> jeff

Hi Jeff,

Thanks for having another look!

I did x86_64 builds of SPEC and vmlinux, and it seems that in practice
v2 does not have any benefit over v1.

What do you think about going with the v1, which is less complex?

Best regards,
Ilya

Re: [PATCH] gcov: Add __gcov_info_to_gdca()

[Sebastian Huber]

Hello Martin,

On 23/11/2020 15:30, Martin Liška wrote:
+/* Convert the gcov info to a gcda data stream.  This function does 
not support
+   whole program statistics and top counters.  It is intended for 
free-standing
+   environments which do not support the C library file I/O. For the 
data

+   format, see also write_one_data().  */
+
+void
+__gcov_info_to_gcda (const struct gcov_info *gi_ptr,
+ void (*filename) (const char *, void *),
+ void (*dump) (const void *, unsigned, void *),
+ void *arg)


Hello.

I would prefer a better names for the hooks. What about something like
open_filename_hook and write_data_hook?


+{
+  (*filename) (gi_ptr->filename, arg);
+  gcov_unsigned_t word = GCOV_DATA_MAGIC;
+  (*dump) (, sizeof (word), arg);


And I would add a new macro like
#define GCOV_WRITE_DATA(data) (*write_data_hook) (, sizeof 
(DATA), arg


What do you think?

sounds good.


Note that we already entered a code freeze before the patch was sent 
to the mailing list.
That means we can install it in the next stage1. 
If I have to wait for next stage 1, I can also try to refactor 
write_one_data() after your patch which removes the buffering. This 
would avoid some duplicated code, however, it would require some changes 
in existing code. Is it allowed to remove external (hidden?) symbols 
from libgcov?


--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier: 
https://embedded-brains.de/datenschutzerklaerung/

Re: [PATCH] gcov: Add __gcov_info_to_gdca()

[Martin Liška]

On 11/17/20 10:57 AM, Sebastian Huber wrote:

This is a proposal to get the gcda data for a gcda info in a free-standing
environment.  It is intended to be used with the -fprofile-info-section option.
A crude test program which doesn't use a linker script is:

   #include 
   #include 

   extern const struct gcov_info *my_info;

   static void
   filename(const char *f, void *arg)
   {
 printf("filename: %s\n", f);
   }

   static void
   dump(const void *d, unsigned n, void *arg)
   {
 const unsigned char *c;
 unsigned i;

 c = d;

 for (i = 0; i < n; ++i) {
printf("%02x", c[i]);
 }
   }

   int main()
   {
 __asm__ volatile (".set my_info, .LPBX2");
 __gcov_info_to_gcda(my_info, filename, dump, NULL);
 return 0;
   }

gcc/

* doc/invoke.texi (fprofile-info-section): Mention
__gcov_info_to_gdca().

libgcc/

Makefile.in (LIBGCOV_DRIVER): Add _gcov_info_to_gcda.
gcov.h (gcov_info): Declare.
(__gcov_info_to_gdca): Likewise.
libgcov-driver.c (gcov_are_all_counters_zero): New.
(write_one_data): Use gcov_are_all_counters_zero().
(gcov_fn_info_to_gcda): New.
(__gcov_info_to_gcda): Likewise.
---
  gcc/doc/invoke.texi |  73 
  libgcc/Makefile.in  |   2 +-
  libgcc/gcov.h   |  15 +
  libgcc/libgcov-driver.c | 120 
  4 files changed, 188 insertions(+), 22 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3510a54c6c4..09cb4922f5e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -14248,17 +14248,17 @@ To optimize the program based on the collected 
profile information, use
  Register the profile information in the specified section instead of using a
  constructor/destructor.  The section name is @var{name} if it is specified,
  otherwise the section name defaults to @code{.gcov_info}.  A pointer to the
-profile information generated by @option{-fprofile-arcs} or
-@option{-ftest-coverage} is placed in the specified section for each
-translation unit.  This option disables the profile information registration
-through a constructor and it disables the profile information processing
-through a destructor.  This option is not intended to be used in hosted
-environments such as GNU/Linux.  It targets systems with limited resources
-which do not support constructors and destructors.  The linker could collect
-the input sections in a continuous memory block and define start and end
-symbols.  The runtime support could dump the profiling information registered
-in this linker set during program termination to a serial line for example.  A
-GNU linker script example which defines a linker output section follows:
+profile information generated by @option{-fprofile-arcs} is placed in the
+specified section for each translation unit.  This option disables the profile
+information registration through a constructor and it disables the profile
+information processing through a destructor.  This option is not intended to be
+used in hosted environments such as GNU/Linux.  It targets free-standing
+environments (for example embedded systems) with limited resources which do not
+support constructors/destructors or the C library file I/O.
+
+The linker could collect the input sections in a continuous memory block and
+define start and end symbols.  A GNU linker script example which defines a
+linker output section follows:
  
  @smallexample

.gcov_info  :
@@ -14269,6 +14269,57 @@ GNU linker script example which defines a linker 
output section follows:
@}
  @end smallexample
  
+The program could dump the profiling information registered in this linker set

+for example like this:
+
+@smallexample
+#include 
+#include 
+
+extern const struct gcov_info *__gcov_info_start[];
+extern const struct gcov_info *__gcov_info_end[];
+
+static void
+filename (const char *f, void *arg)
+@{
+  puts (f);
+@}
+
+static void
+dump (const void *d, unsigned n, void *arg)
+@{
+  const unsigned char *c = d;
+
+  for (unsigned i = 0; i < n; ++i)
+printf ("%02x", c[i]);
+@}
+
+static void
+dump_gcov_info (void)
+@{
+  const struct gcov_info **info = __gcov_info_start;
+  const struct gcov_info **end = __gcov_info_end;
+
+  /* Obfuscate variable to prevent compiler optimizations.  */
+  __asm__ ("" : "+r" (end));
+
+  while (info != end)
+  @{
+void *arg = NULL;
+__gcov_info_to_gcda (*info, filename, dump, arg);
+putchar ('\n');
+++info;
+  @}
+@}
+
+int
+main()
+@{
+  dump_gcov_info();
+  return 0;
+@}
+@end smallexample
+
  @item -fprofile-note=@var{path}
  @opindex fprofile-note
  
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in

index d6075d32bd4..c22413d768c 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -908,7 +908,7 @@ LIBGCOV_INTERFACE = _gcov_dump _gcov_fork   
\
_gcov_execl _gcov_execlp\
   

Re: [PATCH] gcov: Add __gcov_info_to_gdca()

[Martin Liška]

On 11/23/20 1:25 PM, Sebastian Huber wrote:

On 20/11/2020 17:14, Sebastian Huber wrote:


On 20/11/2020 16:25, Martin Liška wrote:


Apart from these 2 hooks, I bet you will also need gcov_position and gcov_seek 
functions,
can be seen in my sent patch.

For what do I need them?



I prefer the way with the 2 extra hooks.
Can you please prepare a patch where the newly added functions 
__gcov_info_to_gcda and __gcov_fn_info_to_gcda
will be used in libgcov (with the hooks equal to fopen and fwrite? 


I am not really sure what I should do. Do you mean that write_one_data() should 
be rewritten to use __gcov_info_to_gcda() with hooks that use 
gcov_write_unsigned()?

The write_one_data() also has a const struct gcov_summary *prg_p pointer. What should 
an external user provide for this pointer? For example _ptr->summary?

The write_one_data() has this code

  if (fn_buffer && fn_buffer->fn_ix == f_ix)
    {
  /* Buffered data from another program.  */
  buffered = 1;
  gfi_ptr = _buffer->info;
  length = GCOV_TAG_FUNCTION_LENGTH;
    }

which uses a global variable

/* buffer for the fn_data from another program.  */
static struct gcov_fn_buffer *fn_buffer;

For this handling we would need a new hook to do this:

  if (buffered)
    fn_buffer = free_fn_data (gi_ptr, fn_buffer, GCOV_COUNTERS);

I don't know for what we need seek and position hooks.


Refactoring write_one_data() to use hooks requires that

gcov_write_counter()

gcov_write_tag_length()

gcov_write_summary()

move from gcc/gcov-io.c to libgcc/libgcov-buffer.c. They can be made static. I 
am not sure if the external symbols can be removed

/* In libgcov we need these functions to be extern, so prefix them with
    __gcov.  In libgcov they must also be hidden so that the instance in
    the executable is not also used in a DSO.  */
#define gcov_write_tag_length __gcov_write_tag_length
#define gcov_write_counter __gcov_write_counter
#define gcov_write_summary __gcov_write_summary

without breaking anything? What is the performance impact if only 
gcov_write_unsigned() is used by libgcc/libgcov-driver.c?



All right. It seems that your original patch would be a simpler approach,
I'll comment the patch in a moment.

Thanks,
Martin

Re: [PATCH] middle-end, c++: Treat shifts by negative as undefined [PR96929]

[Richard Biener]

On Mon, 23 Nov 2020, Jakub Jelinek wrote:

> Hi!
> 
> The PR38359 change made the -1 >> x to -1 optimization less useful by
> requiring that the x must be non-negative.
> Shifts by negative amount are UB, but we for historic reasons had in some
> (but not all) places some hack to treat shifts by negative value as the
> other direction shifts by the negated amount.
> 
> The following patch just removes that special handling, instead we punt on
> optimizing those (and ideally path isolation should catch that up and turn
> those into __builtin_unreachable, perhaps with __builtin_warning next to
> it).  Folding the shifts in some places as if they were rotates and in other
> as if they were saturating just leads to inconsistencies.
> 
> For C++ constexpr diagnostics and -fpermissive, I've added code to pretend
> fold-const.c has not changed, without -fpermissive it will be an error
> anyway and I think it is better not to change all the diagnostics.
> 
> During x86_64-linux and i686-linux bootstrap/regtest, my statistics
> gathering patch noted 185 unique -m32/-m64 x TU x function_name x shift_kind
> x fold-const/tree-ssa-ccp cases.  I have investigated the
> 64 ../../gcc/config/i386/i386.c x86_output_aligned_bss LSHIFT_EXPR 
> wide_int_bitop
> 64 ../../gcc/config/i386/i386-expand.c emit_memmov LSHIFT_EXPR wide_int_bitop
> 64 ../../gcc/config/i386/i386-expand.c ix86_expand_carry_flag_compare 
> LSHIFT_EXPR wide_int_bitop
> 64 ../../gcc/expmed.c expand_divmod LSHIFT_EXPR wide_int_bitop
> 64 ../../gcc/lra-lives.c process_bb_lives LSHIFT_EXPR wide_int_bitop
> 64 ../../gcc/rtlanal.c nonzero_bits1 LSHIFT_EXPR wide_int_bitop
> 64 ../../gcc/varasm.c optimize_constant_pool.isra LSHIFT_EXPR wide_int_bitop
> cases and all of them are either during jump threading (dom) or during PRE.
> For jump threading, the most common case is 1 << floor_log2 (whatever) where
> floor_log2 is return HOST_BITS_PER_WIDE_INT - 1 - clz_hwi (x);
> and clz_hwi is if (x == 0) return HOST_BITS_PER_WIDE_INT; return 
> __builtin_clz* (x);
> and so has range [-1, 63] and a comparison against == 0 which makes the
> threader think it might be nice to jump thread the case leading to 1 << -1.
> I think it is better to keep the 1 << -1 s in the IL for this and let path
> isolation turn that into __builtin_unreachable () if the user wishes so.
> 
> Earlier version of this patch has been bootstrapped/regtested on
> x86_64-linux and i686-linux, is this one ok for trunk if it passes the same
> testing?

Yes.

Thanks,
Richard.

> 2020-11-23  Jakub Jelinek  
> 
>   PR tree-optimization/96929
>   * fold-const.c (wide_int_binop) :
>   Return false on negative second argument rather than trying to handle
>   it as shift in the other direction.
>   * tree-ssa-ccp.c (bit_value_binop)case RSHIFT_EXPR>: Punt on negative shift count rather than trying
>   to handle it as shift in the other direction.
>   * match.pd (-1 >> x to -1): Remove tree_expr_nonnegative_p check.
> 
>   * constexpr.c (cxx_eval_binary_expression): For shifts by constant
>   with MSB set, emulate older wide_int_binop behavior to preserve
>   diagnostics and -fpermissive behavior.
> 
>   * gcc.dg/tree-ssa/pr96929.c: New test.
> 
> --- gcc/fold-const.c.jj   2020-11-20 12:26:16.921936188 +0100
> +++ gcc/fold-const.c  2020-11-23 12:42:13.784315448 +0100
> @@ -992,26 +992,19 @@ wide_int_binop (wide_int ,
>res = wi::bit_and (arg1, arg2);
>break;
>  
> -case RSHIFT_EXPR:
>  case LSHIFT_EXPR:
>if (wi::neg_p (arg2))
> - {
> -   tmp = -arg2;
> -   if (code == RSHIFT_EXPR)
> - code = LSHIFT_EXPR;
> -   else
> - code = RSHIFT_EXPR;
> - }
> -  else
> -tmp = arg2;
> + return false;
> +  res = wi::lshift (arg1, arg2);
> +  break;
>  
> -  if (code == RSHIFT_EXPR)
> - /* It's unclear from the C standard whether shifts can overflow.
> -The following code ignores overflow; perhaps a C standard
> -interpretation ruling is needed.  */
> - res = wi::rshift (arg1, tmp, sign);
> -  else
> - res = wi::lshift (arg1, tmp);
> +case RSHIFT_EXPR:
> +  if (wi::neg_p (arg2))
> + return false;
> +  /* It's unclear from the C standard whether shifts can overflow.
> +  The following code ignores overflow; perhaps a C standard
> +  interpretation ruling is needed.  */
> +  res = wi::rshift (arg1, arg2, sign);
>break;
>  
>  case RROTATE_EXPR:
> --- gcc/tree-ssa-ccp.c.jj 2020-11-20 12:26:16.946935910 +0100
> +++ gcc/tree-ssa-ccp.c2020-11-23 12:42:13.785315436 +0100
> @@ -1432,13 +1432,7 @@ bit_value_binop (enum tree_code code, si
> else
>   {
> if (wi::neg_p (shift))
> - {
> -   shift = -shift;
> -   if (code == RSHIFT_EXPR)
> - code = LSHIFT_EXPR;
> -   else
> - code = RSHIFT_EXPR;
> -