[PATCH] widening_mul: Fix a > ~b to .ADD_OVERFLOW optimization [PR98256]

[Jakub Jelinek via Gcc-patches]

Hi!

Unfortunately, my latest tree-ssa-math-opts.c patch broke the following
testcase.  The problem is that the code is adding .ADD_OVERFLOW or
.SUB_OVERFLOW before or after the stmt on which the function has been
called, which is normally a addition or subtraction that has all the
operands.
But in the a > ~b optimization that stmt is the ~b stmt and the other
comparison operand might be defined only after that ~b stmt, so we can't
insert the .ADD_OVERFLOW next to ~b that we want to delete, but need to
insert it before the a > temp comparison that uses it; and in that case
when removing the BIT_NOT_EXPR stmt we need to ensure the caller doesn't do
gsi_next because gsi_remove already points the iterator to the next stmt.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-12-13  Jakub Jelinek  

PR tree-optimization/98256
* tree-ssa-math-opts.c (match_uaddsub_overflow): For BIT_NOT_EXPR,
only handle a single use, and insert .ADD_OVERFLOW before the
comparison rather than after the BIT_NOT_EXPR.  Return true iff
it is BIT_NOT_EXPR and it has been removed.
(math_opts_dom_walker::after_dom_children) :
If match_uaddsub_overflow returned true, continue instead of break.

* gcc.c-torture/compile/pr98256.c: New test.

--- gcc/tree-ssa-math-opts.c.jj 2020-12-12 14:48:40.195306781 +0100
+++ gcc/tree-ssa-math-opts.c2020-12-12 22:42:24.474396562 +0100
@@ -3598,6 +3598,7 @@ match_uaddsub_overflow (gimple_stmt_iter
   gimple *use_stmt;
   gimple *add_stmt = NULL;
   bool add_first = false;
+  gimple *cond_stmt = NULL;
 
   gcc_checking_assert (code == PLUS_EXPR
   || code == MINUS_EXPR
@@ -3628,8 +3629,9 @@ match_uaddsub_overflow (gimple_stmt_iter
return false;
  if (rhs2 == NULL)
rhs2 = other;
- else if (rhs2 != other)
+ else
return false;
+ cond_stmt = use_stmt;
}
  ovf_use_seen = true;
}
@@ -3818,6 +3820,9 @@ match_uaddsub_overflow (gimple_stmt_iter
}
 }
 
+  if (code == BIT_NOT_EXPR)
+*gsi = gsi_for_stmt (cond_stmt);
+
   tree ctype = build_complex_type (type);
   gcall *g = gimple_build_call_internal (code != MINUS_EXPR
 ? IFN_ADD_OVERFLOW : IFN_SUB_OVERFLOW,
@@ -3843,7 +3848,10 @@ match_uaddsub_overflow (gimple_stmt_iter
   tree ovf = make_ssa_name (type);
   g2 = gimple_build_assign (ovf, IMAGPART_EXPR,
build1 (IMAGPART_EXPR, type, ctmp));
-  gsi_insert_after (gsi, g2, GSI_NEW_STMT);
+  if (code != BIT_NOT_EXPR)
+gsi_insert_after (gsi, g2, GSI_NEW_STMT);
+  else
+gsi_insert_before (gsi, g2, GSI_SAME_STMT);
 
   FOR_EACH_IMM_USE_STMT (use_stmt, iter, lhs)
 {
@@ -3908,11 +3916,12 @@ match_uaddsub_overflow (gimple_stmt_iter
 }
   else if (code == BIT_NOT_EXPR)
 {
-  gimple_stmt_iterator gsi2 = gsi_for_stmt (stmt);
-  gsi_remove (&gsi2, true);
+  *gsi = gsi_for_stmt (stmt);
+  gsi_remove (gsi, true);
   release_ssa_name (lhs);
+  return true;
 }
-  return true;
+  return false;
 }
 
 /* Return true if target has support for divmod.  */
@@ -4238,7 +4247,8 @@ math_opts_dom_walker::after_dom_children
  break;
 
case BIT_NOT_EXPR:
- match_uaddsub_overflow (&gsi, stmt, code);
+ if (match_uaddsub_overflow (&gsi, stmt, code))
+   continue;
  break;
 
case TRUNC_MOD_EXPR:
--- gcc/testsuite/gcc.c-torture/compile/pr98256.c.jj2020-12-12 
22:44:34.037940761 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr98256.c   2020-12-12 
22:35:54.452778912 +0100
@@ -0,0 +1,9 @@
+/* PR tree-optimization/98256 */
+
+unsigned a, b;
+
+int
+foo (void)
+{
+  return !!(~a / b);
+}

Jakub

[patch, fortran, committed] Improved parse dump for coarrays

[Thomas Koenig via Gcc-patches]

Hello world,

I have just committed as obvious and simple (and as no-user-impact)
an improvement to the tree dump, plus the ability to call
debug(array_reference) in the debugger. The revision is
r11-5967.

The dump for a coarray assignment now looks like

  ASSIGN main:a(FULL)[THIS_IMAGE] 4.2000e1
  ASSIGN main:b()[2] 2.1000e1
  ASSIGN main:c()[*] 1.0500e1

for

  a = 42
  b[2] = 21
  c[*] = 10.5

Previously, the coarray dumps weren't displayed, which had
led to some confusion on my part :-)

Best regards

Thomas

Show coarrays on parse tree dump, implement debug for array references.

gcc/fortran/ChangeLog:

* dump-parse-tree.c (show_array_ref): Also show coarrays.
(debug): Implement for array reference.

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

[Iain Sandoe via Gcc-patches]

Thomas Koenig via Fortran  wrote:


Hello world,

I have struggled with debugging the GENERIC generated by the
Fortran front end because it is only possible to look at the
code via -fdump-tree-original, but it is not possible to
inspect the values; additionally, the D.3456 form makes it
hard to read which variable is which.

This patch adds a flag which gives all variables generated by
Fortran a name and makes them visible to debuggers. As an
example, compiler-generated variables now look like this
(for a "Hello, world" program):

 {
   struct __st_parameter_dt dt_parm:0;

   dt_parm:0.common.filename = &"hello.f90"[1]{lb: 1 sz: 1};
   dt_parm:0.common.line = 2;
   dt_parm:0.common.flags = 128;
   dt_parm:0.common.unit = 6;
   _gfortran_st_write (&dt_parm:0);
   _gfortran_transfer_character_write (&dt_parm:0, &"Hello, world"[1]{lb: 1 sz: 
1}, 12);
   _gfortran_st_write_done (&dt_parm:0);
 }

Note the colon in the variable name, which I chose because it is
not in the user's namespace, and gdb does not choke on it.


If it’s part of a symbol used by the rest of the toolchain (assembler, linker
debugger) then it’s also important to note that some OS/tool pairs might
be more constrained than the one you’ve tested.  In particular, some
assemblers will not accept all characters in an  identifier.


In order to inspect the variables, you usually have to step
a bit through the generated assembly code, but you can then
print the values, manipulate them etc (and sometimes also hit
an internal error in gdb).



--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -73,6 +73,40 @@ gfc_advance_chain (tree t, int n)
   return t;



+  /* We want debug info for it.  */
+  DECL_IGNORED_P (t) = 0;
+  /* It should not be nameless.  */
+  DECL_NAMELESS (t) = 0;




 tree
@@ -80,6 +114,9 @@ gfc_create_var_np (tree type, const char *prefix)
 {
   tree t;

+  if (flag_debug_aux_vars)
+return create_var_debug_raw (type, prefix);
+
   t = create_tmp_var_raw (type, prefix);



You could take advantage of the understanding of assembler identifier rules
built into create_var_debug_raw()

.. perhaps (totally untested)….

if (flag_debug_aux_vars)
  prefix = prefix ? prefix :  “gfc”;

t = create_tmp_var_raw (type, prefix);
if (flag_debug_aux_vars)
  {
 /* We want debug info for it.  */
DECL_IGNORED_P (t) = false;
/* It should not be nameless.  */
DECL_NAMELESS (t) = false;
  }

 return t;


… or doens’t this approach work for some reason?
cheers
Iain

[C PATCH] Drop qualifiers of assignment expressions [PR 97981]

[Uecker, Martin]

Here is a patch to drop qualifiers in assignment expressions.

-- Martin



C: Drop qualifiers of assignment expressions. [PR98047]

ISO C17 6.5.15.1 specifies that the result is the
type the LHS would have after lvalue conversion.


2020-12-12  Martin Uecker  

gcc/c/
 PR c/98047
 * c-typeck.c (build_modify_expr): Drop qualifiers.  

gcc/testsuite/
 PR c/98047
 * gcc.dg/qual-assign-7.c.c: New test.


diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 138af073925..d8b2ca12766 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -6276,16 +6276,9 @@ build_modify_expr (location_t location, tree lhs, tree 
lhs_origtype,
    "enum conversion in assignment is invalid in C++");
 }
 
-  /* If the lhs is atomic, remove that qualifier.  */
-  if (is_atomic_op)
-{
-  lhstype = build_qualified_type (lhstype, 
-     (TYPE_QUALS (lhstype)
-      & ~TYPE_QUAL_ATOMIC));
-  olhstype = build_qualified_type (olhstype, 
-      (TYPE_QUALS (lhstype)
-   & ~TYPE_QUAL_ATOMIC));
-}
+  /* Remove qualifiers.  */
+  lhstype = build_qualified_type (lhstype, TYPE_UNQUALIFIED);
+  olhstype = build_qualified_type (olhstype, TYPE_UNQUALIFIED);
 
   /* Convert new value to destination type.  Fold it first, then
  restore any excess precision information, for the sake of
diff --git a/gcc/testsuite/gcc.dg/qual-assign-7.c 
b/gcc/testsuite/gcc.dg/qual-assign-7.c
new file mode 100644
index 000..3e064e82f5f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/qual-assign-7.c
@@ -0,0 +1,18 @@
+/* test that assignment drops qualifiers, Bug 98047 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+
+volatile int jv;
+extern int j;
+extern typeof(jv = 1) j;
+
+_Atomic int ja;
+extern typeof(ja = 1) j;
+
+int * __restrict pa;
+extern int *p;
+extern typeof(pa = 0) p;
+
+
+

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

[Thomas Koenig via Gcc-patches]

Hi Iain,


If it’s part of a symbol used by the rest of the toolchain (assembler, 
linker

debugger) then it’s also important to note that some OS/tool pairs might
be more constrained than the one you’ve tested.  In particular, some
assemblers will not accept all characters in an  identifier.


That is, of course, true.  What I have works for the usual Linux
toolchain.  Since I do not have access to other systems where
I can compile gcc (see the recent *BSD desaster when I tried this),
the most I could do is to make the character configurable - use
: by default, use something else if specified.



You could take advantage of the understanding of assembler identifier rules
built into create_var_debug_raw()

.. perhaps (totally untested)….

if (flag_debug_aux_vars)
   prefix = prefix ? prefix :  “gfc”;

t = create_tmp_var_raw (type, prefix);
if (flag_debug_aux_vars)
   {
  /* We want debug info for it.  */
     DECL_IGNORED_P (t) = false;
     /* It should not be nameless.  */
     DECL_NAMELESS (t) = false;
   }

  return t;


… or doens’t this approach work for some reason?


This doesn't work for gdb because gdb searches for
a variable called "S" when trying to access "S.0".
I also tried out @ as a separation character; that
is also interpreted by gdb in a special way.

And I wanted to avoid anything in the namespace of
Fortran identifiers, even with options, so _ and $ were
out.

Do you have any other suggestions?

Best regards

Thomas

Re: rs6000: Update the processor defaults for FreeBSD

[Segher Boessenkool]

On Sun, Dec 13, 2020 at 01:10:58AM +0100, Gerald Pfeifer wrote:
> Piotr is the one spending most times on ensuring FreeBSD ports work
> fine on POWER, so personally I'm happy to follow his recommendation
> on such matters.

I have a question though:

> -/* Until now the 970 is the only Processor where FreeBSD 64-bit runs on.  */
>  #undef  PROCESSOR_DEFAULT
> -#define PROCESSOR_DEFAULT PROCESSOR_POWER4
> +#define PROCESSOR_DEFAULT PROCESSOR_PPC7450
>  #undef  PROCESSOR_DEFAULT64
> -#define PROCESSOR_DEFAULT64 PROCESSOR_POWER4
> +#define PROCESSOR_DEFAULT64 PROCESSOR_POWER8

Is this wise?  Binaries won't run on many BE systems anymore with
this.  (Linux still uses Power4 by default for BE, as well).

In either case: yes, whatever you guys decide here is fine.  Also for
all backports you want.  Thanks!


Segher

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

[Iain Sandoe via Gcc-patches]

Hi Thomas,

Thomas Koenig  wrote:

If it’s part of a symbol used by the rest of the toolchain (assembler,  
linker

debugger) then it’s also important to note that some OS/tool pairs might
be more constrained than the one you’ve tested.  In particular, some
assemblers will not accept all characters in an  identifier.


That is, of course, true.  What I have works for the usual Linux
toolchain.  Since I do not have access to other systems where
I can compile gcc (see the recent *BSD desaster when I tried this),
the most I could do is to make the character configurable - use
: by default, use something else if specified.


yes a configure option is a possible way around a conflict.

You could take advantage of the understanding of assembler identifier  
rules

built into create_var_debug_raw()
.. perhaps (totally untested)….
if (flag_debug_aux_vars)
  prefix = prefix ? prefix :  “gfc”;
t = create_tmp_var_raw (type, prefix);
if (flag_debug_aux_vars)
  {
 /* We want debug info for it.  */
DECL_IGNORED_P (t) = false;
/* It should not be nameless.  */
DECL_NAMELESS (t) = false;
  }
 return t;
… or doens’t this approach work for some reason?


This doesn't work for gdb because gdb searches for
a variable called "S" when trying to access "S.0".
I also tried out @ as a separation character; that
is also interpreted by gdb in a special way.


and there are other debug consumers in common use - at
least lldb.


And I wanted to avoid anything in the namespace of
Fortran identifiers, even with options, so _ and $ were
out.

Do you have any other suggestions?


At the moment none other than the obvious..
.. test the current proposal on a wider range of systems - I expect
someone would volunteer to test on Darwin (Dominique or me)
.. you could use the cfarm for AIX, Solaris and others (I mention
AIX, Solaris and Darwin as three known to use non-GNU
assemblers and linkers).

Iain

Re: rs6000: Update the processor defaults for FreeBSD

[Piotr Kubaj via Gcc-patches]

Hello,

this is only default tuning (-mtune, not -mcpu). Linux also does similarly in 
linux64.h:
 74 #undef  PROCESSOR_DEFAULT
 75 #define PROCESSOR_DEFAULT PROCESSOR_POWER7
 76 #undef  PROCESSOR_DEFAULT64
 77 #define PROCESSOR_DEFAULT64 PROCESSOR_POWER8

Although there is hard to explain (for me) setting to tune for POWER7 on 
32-bits. POWER7 is 64-bit and it should be more reasonable to optimize for the 
last 32-bit machines that still may be in use (so G4).

That said, on the 64-bit front, we will just match the Linux setting.

On 20-12-13 08:23:53, Segher Boessenkool wrote:
> On Sun, Dec 13, 2020 at 01:10:58AM +0100, Gerald Pfeifer wrote:
> > Piotr is the one spending most times on ensuring FreeBSD ports work
> > fine on POWER, so personally I'm happy to follow his recommendation
> > on such matters.
> 
> I have a question though:
> 
> > -/* Until now the 970 is the only Processor where FreeBSD 64-bit runs on.  
> > */
> >  #undef  PROCESSOR_DEFAULT
> > -#define PROCESSOR_DEFAULT PROCESSOR_POWER4
> > +#define PROCESSOR_DEFAULT PROCESSOR_PPC7450
> >  #undef  PROCESSOR_DEFAULT64
> > -#define PROCESSOR_DEFAULT64 PROCESSOR_POWER4
> > +#define PROCESSOR_DEFAULT64 PROCESSOR_POWER8
> 
> Is this wise?  Binaries won't run on many BE systems anymore with
> this.  (Linux still uses Power4 by default for BE, as well).
> 
> In either case: yes, whatever you guys decide here is fine.  Also for
> all backports you want.  Thanks!
> 
> 
> Segher


signature.asc
Description: PGP signature

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

[Thomas Koenig via Gcc-patches]

Hi Iain,


yes a configure option is a possible way around a conflict.


I was thinking more along making it a run-time option.

This is an option which will only be used by a developer,
who should know what the source code contains and what
the tool chain supports (and who can try out an underscore
if nothing else works).

So, something along the lines of -fdebug-aux-vars=: would be
equivalent to -fdebug-aux-vars, -fdebug-aux-vars=_ should work
on any system, with the (small) risk of colliding with user code.

How does that sound?

Best regards

Thomas

[PATCH] Fix _GLIBCXX_DEBUG tests

[François Dumont via Gcc-patches]

Some tests are XPASS because array assertions have been disabled for a 
good reason in C++11.


I wonder if the respective non-constexpr _GLIBCXX_ASSERTION checks 
shouldn't target C++14 too. At the moment they are failing as expected 
but because of an Undefined Behavior no ?


The other test is failing because of some cleanup in headers which makes 
 include necessary.


    libstdc++: Fix several _GLIBCXX_DEBUG tests

    libstdc++-v3/ChangeLog:

    * testsuite/23_containers/array/debug/back2_neg.cc: target 
c++14 because assertion

    for constexpr is disabled in C++11.
    * testsuite/23_containers/array/debug/front2_neg.cc: Likewise.
    * 
testsuite/23_containers/array/debug/square_brackets_operator2_neg.cc: 
Likewise.
    * 
testsuite/23_containers/vector/debug/multithreaded_swap.cc: Include 

    for shared_ptr.

Ok to commit ?

François

diff --git a/libstdc++-v3/testsuite/23_containers/array/debug/back2_neg.cc b/libstdc++-v3/testsuite/23_containers/array/debug/back2_neg.cc
index b14a3ec8c04..0066c671c42 100644
--- a/libstdc++-v3/testsuite/23_containers/array/debug/back2_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/array/debug/back2_neg.cc
@@ -16,7 +16,7 @@
 // .
 //
 // { dg-options "-D_GLIBCXX_ASSERTIONS" }
-// { dg-do run { target c++11 xfail *-*-* } }
+// { dg-do run { target c++14 xfail *-*-* } }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/23_containers/array/debug/front2_neg.cc b/libstdc++-v3/testsuite/23_containers/array/debug/front2_neg.cc
index e099e6eb46b..a6118cfce3a 100644
--- a/libstdc++-v3/testsuite/23_containers/array/debug/front2_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/array/debug/front2_neg.cc
@@ -16,7 +16,7 @@
 // .
 //
 // { dg-options "-D_GLIBCXX_ASSERTIONS" }
-// { dg-do run { target c++11 xfail *-*-* } }
+// { dg-do run { target c++14 xfail *-*-* } }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/23_containers/array/debug/square_brackets_operator2_neg.cc b/libstdc++-v3/testsuite/23_containers/array/debug/square_brackets_operator2_neg.cc
index 4e93c8a7d68..efb28d715e9 100644
--- a/libstdc++-v3/testsuite/23_containers/array/debug/square_brackets_operator2_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/array/debug/square_brackets_operator2_neg.cc
@@ -16,7 +16,7 @@
 // .
 //
 // { dg-options "-D_GLIBCXX_ASSERTIONS" }
-// { dg-do run { target c++11 xfail *-*-* } }
+// { dg-do run { target c++14 xfail *-*-* } }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/23_containers/vector/debug/multithreaded_swap.cc b/libstdc++-v3/testsuite/23_containers/vector/debug/multithreaded_swap.cc
index 0d795147644..a0050ec764c 100644
--- a/libstdc++-v3/testsuite/23_containers/vector/debug/multithreaded_swap.cc
+++ b/libstdc++-v3/testsuite/23_containers/vector/debug/multithreaded_swap.cc
@@ -26,6 +26,7 @@
 // mode as it requires acquiring 2 locks at the same time.
 
 #include 
+#include 
 #include 
 #include 
 #include 

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

[Iain Sandoe via Gcc-patches]

Thomas Koenig via Fortran  wrote:


yes a configure option is a possible way around a conflict.


I was thinking more along making it a run-time option.

This is an option which will only be used by a developer,
who should know what the source code contains and what
the tool chain supports (and who can try out an underscore
if nothing else works).


I guess the hard thing is for the developer to know that (s)he wants
the option and what to do when a conflict occurs.


So, something along the lines of -fdebug-aux-vars=: would be
equivalent to -fdebug-aux-vars, -fdebug-aux-vars=_ should work
on any system, with the (small) risk of colliding with user code.


naming is ever hard - although I suppose, if this is very infrequent in
use, having a long name isn’t so terrible

maybe:

-fdebug-aux-vars-with-separator=x

and

-fdebug-aux-vars
as an alias to '-fdebug-aux-vars-with-separator=:'

(so that, unless one needs something different, the shorter version is
 available).

FAOD, this is ‘thinking aloud’ about what might make it easier to
understand; your version is equivalent other than the names.


How does that sound?


A reasonable compromise (at this point I will defer to those folks
who are actually likely to use the facility).

cheers
Iain

Re: rs6000: Update the processor defaults for FreeBSD

[Segher Boessenkool]

Hi!

On Sun, Dec 13, 2020 at 03:34:57PM +0100, Piotr Kubaj wrote:
> this is only default tuning (-mtune, not -mcpu).

It is both, actually (-mcpu= implies -mtune=)

> Linux also does similarly in linux64.h:
>  74 #undef  PROCESSOR_DEFAULT
>  75 #define PROCESSOR_DEFAULT PROCESSOR_POWER7
>  76 #undef  PROCESSOR_DEFAULT64
>  77 #define PROCESSOR_DEFAULT64 PROCESSOR_POWER8

Yes, but we still default to power4 on BE Linux (and power8 on LE).  I
get lost in the macro maze here, not sure how that works :-)

> Although there is hard to explain (for me) setting to tune for POWER7 on 
> 32-bits. POWER7 is 64-bit and it should be more reasonable to optimize for 
> the last 32-bit machines that still may be in use (so G4).

7450 has very different optimisation than 970.  Power7 and 970 have
largely similar pipelines.

> That said, on the 64-bit front, we will just match the Linux setting.

Compile a very simple test and look at the .machine in the generated .s?
Does that do what you want?


Segher

Re: [PATCH] Fix up testcase.

[Jeff Law via Gcc-patches]

On 12/9/20 3:24 AM, Hongtao Liu via Gcc-patches wrote:
> On Wed, Dec 9, 2020 at 5:22 PM Prathamesh Kulkarni via Gcc-patches
>  wrote:
>> On Wed, 9 Dec 2020 at 00:29, sunil.k.pandey  wrote:
>>> On Linux/x86_64,
>>>
>>> 3a6e3ad38a17a03ee0139b49a0946e7b9ded1eb1 is the first bad commit
>>> commit 3a6e3ad38a17a03ee0139b49a0946e7b9ded1eb1
>>> Author: Prathamesh Kulkarni 
>>> Date:   Tue Dec 8 14:30:04 2020 +0530
>>>
>>> gimple-isel: Fold x CMP y ? -1 : 0 to x CMP y [PR97872]
>>>
>>> caused
>>>
>>> FAIL: gcc.target/i386/pr78102.c scan-assembler-times pcmpeqq 3
>> Hi,
>> This is a known issue with the patch, and discussed here:
>> https://gcc.gnu.org/pipermail/gcc/2020-December/234438.html
>> I guess Hongtao will check in a fix for that soon.
>>
> According to https://uops.info/table.html,
> both pcmpeqq and pcmpeqd use only port 1, so i think there's no
> performance difference between
>
> vpcmpeqq %xmm1, %xmm0, %xmm0
> vpxor %xmm1, %xmm1, %xmm1
> vpcmpeqq %xmm1, %xmm0, %xmm0
>
> and
>
> vpcmpeqq %xmm1, %xmm0, %xmm0
> vpcmpeqd %xmm1, %xmm1, %xmm1
> vpandn %xmm1, %xmm0, %xmm0
>
> So fix up testcase as below.
>
> gcc/testsuite
>
> * gcc.target/i386/i386/pr78102.c: Adjust testcase.
OK
jeff

Re: [PATCH] Limit perf data buffer during feature checking

[Jeff Law via Gcc-patches]

On 12/9/20 5:45 AM, Ilya Leoshkevich via Gcc-patches wrote:
> Bootstrapped and regtested on x86_64-redhat-linux.  Ok for master?
>
> Commit 2ead1ab91123 ("Limit perf data buffer during profiling") added
> -m8 to perf invocations during running tests, but the same problem
> exists for checking whether perf is working in the first place.
>
> gcc/testsuite/ChangeLog:
>
> 2020-12-08  Ilya Leoshkevich  
>
>   * lib/target-supports.exp(check_profiling_available): Limit
>   perf data buffer.
OK
jeff

Re: [PATCH] varasm, v2: Reject soft frame or arg pointer registers for register vars [PR92469]

[Jeff Law via Gcc-patches]

On 12/10/20 8:11 AM, Jakub Jelinek wrote:
> On Thu, Dec 10, 2020 at 12:00:17PM +0100, Jakub Jelinek wrote:
>> So, would it be better to check for one of FRAME_POINTER_REGNUM,
>> ARG_POINTER_REGNUM or RETURN_ADDRESS_POINTER_REGNUM if they
>> are mentioned in (from part of pairs in) ELIMINABLE_REGS?
> In patch form now:
>
> 2020-12-10  Jakub Jelinek  
>
>   PR target/92469
>   * varasm.c (eliminable_regno_p): New function.
>   (make_decl_rtl): Reject asm vars for frame and argp
>   if they are different from hard frame pointer.
>
>   * gcc.target/i386/pr92469.c: New test.
>   * gcc.target/i386/pr79804.c: Adjust expected diagnostics.
>   * gcc.target/i386/pr88178.c: Expect an error.
OK
jeff

Re: [PATCH] VAX: Fix lower bound adjustment with `casesi'

[Jeff Law via Gcc-patches]

On 12/10/20 4:20 AM, Maciej W. Rozycki wrote:
> Fix an issue with the `casesi' expander using `GEN_INT' to produce the 
> constant rtx for lower bound adjustment.  This generates a VOIDmode 
> value which may overflow the SImode range required for the operand to 
> stay within to satisfy `general_operand', resulting in an ICE like:
>
> .../gcc/testsuite/gcc.c-torture/compile/pr46934.c: In function 'caller':
> .../gcc/testsuite/gcc.c-torture/compile/pr46934.c:17:1: error: unrecognizable 
> insn:
> (insn 5 2 6 2 (set (reg:SI 25)
> (plus:SI (mem/c:SI (reg/f:SI 17 virtual-incoming-args) [1 reg_type+0 
> S4 A32])
> (const_int 2147483648 [0x8000]))) -1
>  (nil))
> during RTL pass: vregs
> .../gcc/testsuite/gcc.c-torture/compile/pr46934.c:17:1: internal compiler 
> error: in extract_insn, at recog.c:2315
> 0x110d4673 _fatal_insn(char const*, rtx_def const*, char const*, int, char 
> const*)
>   .../gcc/rtl-error.c:108
> 0x110d46eb _fatal_insn_not_found(rtx_def const*, char const*, int, char 
> const*)
>   .../gcc/rtl-error.c:116
> 0x1106578b extract_insn(rtx_insn*)
>   .../gcc/recog.c:2315
> 0x10b63f73 instantiate_virtual_regs_in_insn
>   .../gcc/function.c:1609
> 0x10b65b2f instantiate_virtual_regs
>   .../gcc/function.c:1979
> 0x10b65ca7 execute
>   .../gcc/function.c:2028
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> compiler exited with status 1
> FAIL: gcc.c-torture/compile/pr46934.c   -O0  (internal compiler error)
>
> Use `gen_int_mode' to produce the rtx instead, requesting a SImode value 
> so that the constant gets correctly truncated:
>
> @@ -199,7 +199,7 @@ caller (unsigned int reg_type)
>
>  (insn 5 4 6 (set (reg:SI 25)
>  (plus:SI (mem/c:SI (reg/f:SI 17 virtual-incoming-args) [1 reg_type+0 
> S4 A32])
> -(const_int 2147483648 [0x8000]))) -1
> +(const_int -2147483648 [0x8000]))) -1
>   (nil))
>
>  (jump_insn 6 5 7 (set (pc)
>
> removing these test suite failures:
>
> FAIL: gcc.c-torture/compile/pr46934.c   -O0  (internal compiler error)
> FAIL: gcc.c-torture/compile/pr46934.c   -O0  (test for excess errors)
>
> with the `vax-netbsdelf' target.
>
>   gcc/
>   * config/vax/vax.md (casesi): Use `gen_int_mode' rather than
>   `GEN_INT' for the immediate used for lower bound adjustment.
OK
jeff

Re: [PATCH 1/3] VAX: Remove unused register allocation from QMATH DImode add/sub handler

[Jeff Law via Gcc-patches]

On 12/11/20 1:47 PM, Maciej W. Rozycki wrote:
> An allocation is made for a temporary register, however it is unneeded, 
> as actually explained in the comment preceding the conditional block in 
> question, and consequently never used, so remove it.  The `temp' rtx is 
> already used elsewhere in the function, which is possibly why this dead 
> assignment has not been warned about.
>
>   gcc/
>   * config/vax/vax.c (vax_expand_addsub_di_operands): Remove 
>   unused register allocation.
OK
jeff

PING^1: V3 [PATCH 0/2] Switch to a new section if the SECTION_RETAIN bit doesn't match

[H.J. Lu via Gcc-patches]

On Tue, Dec 8, 2020 at 4:51 AM H.J. Lu  wrote:
>
> When SECTION_RETAIN is used, definitions marked with used attribute and
> unmarked definitions are placed in a section with the same name.  Instead
> of issue an error:
>
> [hjl@gnu-cfl-2 gcc]$ /usr/gcc-11.0.0-x32/bin/gcc -S c.c 
> -fdiagnostics-plain-output
> c.c:2:49: error: ‘foo1’ causes a section type conflict with ‘foo2’
> c.c:1:54: note: ‘foo2’ was declared here
> [hjl@gnu-cfl-2 gcc]$
>
> the first patch switches to a new section if the SECTION_RETAIN bit
> doesn't match.  The second optional patch issues a warning:
>
> [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S c.c
> c.c:2:49: warning: ‘foo1’ without ‘used’ attribute and ‘foo2’ with ‘used’ 
> attribute are placed in a section with the same name [-Wattributes]
> 2 | const int __attribute__((section(".data.foo"))) foo1 = 1;
>   | ^~~~
> c.c:1:54: note: ‘foo2’ was declared here
> 1 | const int __attribute__((used,section(".data.foo"))) foo2 = 2;
>   |
> [hjl@gnu-cfl-2 gcc]$
>
> Changes from V2:
>
> 1. Add (new_section->common.flags & SECTION_NAMED) check since
> SHF_GNU_RETAIN section must be named.
> 2. Move c-c++-common/attr-used-9.c to the fist patch since there are
> no new warnings.
> 3. Check new warnings only for R_flag_in_section target.
>
> H.J. Lu (2):
>   Switch to a new section if the SECTION_RETAIN bit doesn't match
>   Warn used and not used symbols in section with the same name
>
>  gcc/output.h |  2 +-
>  gcc/testsuite/c-c++-common/attr-used-5.c | 27 ++
>  gcc/testsuite/c-c++-common/attr-used-6.c | 27 ++
>  gcc/testsuite/c-c++-common/attr-used-7.c |  9 +
>  gcc/testsuite/c-c++-common/attr-used-8.c |  9 +
>  gcc/testsuite/c-c++-common/attr-used-9.c | 28 +++
>  gcc/varasm.c | 46 +---
>  7 files changed, 143 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/c-c++-common/attr-used-5.c
>  create mode 100644 gcc/testsuite/c-c++-common/attr-used-6.c
>  create mode 100644 gcc/testsuite/c-c++-common/attr-used-7.c
>  create mode 100644 gcc/testsuite/c-c++-common/attr-used-8.c
>  create mode 100644 gcc/testsuite/c-c++-common/attr-used-9.c
>

PING.

-- 
H.J.

Re: [PATCH 2/3] VAX: Handle constant 0 with QMATH DImode add/sub

[Jeff Law via Gcc-patches]

On 12/11/20 1:48 PM, Maciej W. Rozycki wrote:
> Handle constant 0 passed to the QMATH DImode add/sub handler such as 
> with:
>
> #2  0x11d409b0 in gen_adddi3 (operand0=0x75c0a128,
> operand1=0x75c60480, operand2=0x75c60470)
> at .../gcc/config/vax/vax.md:755
> 755 "vax_expand_addsub_di_operands (operands, PLUS); DONE;")
> (gdb) pr operand0
> (reg:DI 31)
> (gdb) pr operand1
> (const_int 0 [0])
> (gdb) pr operand2
> (const_int -1 [0x])
> (gdb) 
>
> causing an assertion in `vax_expand_addsub_di_operands':
>
>   gcc_assert (operands[1] != const0_rtx || code == MINUS);
>
> to trigger:
>
> during RTL pass: expand
> .../gcc/testsuite/gcc.c-torture/compile/sync-1.c: In function 
> 'test_op_ignore':
> .../gcc/testsuite/gcc.c-torture/compile/sync-1.c:33:10: internal compiler 
> error: in vax_expand_addsub_di_operands, at config/vax/vax.c:2080
> 0x11815003 vax_expand_addsub_di_operands(rtx_def**, rtx_code)
>   .../gcc/config/vax/vax.c:2080
> 0x11d409af gen_adddi3(rtx_def*, rtx_def*, rtx_def*)
>   .../gcc/config/vax/vax.md:755
> 0x10ea2763 rtx_insn* insn_gen_fn::operator() rtx_def*>(rtx_def*, rtx_def*, rtx_def*) const
>   .../gcc/recog.h:304
> 0x10f7fc8f maybe_gen_insn(insn_code, unsigned int, expand_operand*)
>   .../gcc/optabs.c:7402
> 0x10f67f8b expand_binop_directly
>   .../gcc/optabs.c:1122
> 0x10f684cf expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, 
> rtx_def*, int, optab_methods)
>   .../gcc/optabs.c:1209
> 0x10f6fb4f expand_unop(machine_mode, optab_tag, rtx_def*, rtx_def*, int)
>   .../gcc/optabs.c:3013
> 0x10f6c493 expand_simple_unop(machine_mode, rtx_code, rtx_def*, rtx_def*, int)
>   .../gcc/optabs.c:2200
> 0x10f7e2f3 expand_atomic_fetch_op(rtx_def*, rtx_def*, rtx_def*, rtx_code, 
> memmodel, bool)
>   .../gcc/optabs.c:7021
> 0x107f7523 expand_builtin_sync_operation
>   .../gcc/builtins.c:7605
> 0x107ff547 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
>   .../gcc/builtins.c:9430
> 0x10acda63 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
> expand_modifier, rtx_def**, bool)
>   .../gcc/expr.c:11249
> 0x10abeb9f expand_expr_real(tree_node*, rtx_def*, machine_mode, 
> expand_modifier, rtx_def**, bool)
>   .../gcc/expr.c:8486
> 0x1085606b expand_expr
>   .../gcc/expr.h:282
> 0x1086157f expand_call_stmt
>   .../gcc/cfgexpand.c:2709
> 0x10865ab7 expand_gimple_stmt_1
>   .../gcc/cfgexpand.c:3713
> 0x108662fb expand_gimple_stmt
>   .../gcc/cfgexpand.c:3877
> 0x10870387 expand_gimple_basic_block
>   .../gcc/cfgexpand.c:5918
> 0x10872b6b execute
>   .../gcc/cfgexpand.c:6602
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> compiler exited with status 1
> FAIL: gcc.c-torture/compile/sync-1.c   -O0  (internal compiler error)
>
> causing numerous failures in regression testing.
>
> While requesting an addition operation to be produced for the constant 
> operands of 0 and -1 may seem silly, technically there is nothing wrong 
> with it, and non-QMATH code (as with the `-mno-qmath' option) has no 
> issues with that, so neither should QMATH code.  This operation will 
> normally be folded in later passes anyway.
>
> Observe then, that adding or subtracting constant 0 amounts to a move 
> (and we even have a machine instruction available to do that with a 
> single operation) so handle the case explicitly, swapping the addends if 
> so required, removing the assertion failure and along with that 70 test 
> suite failures like:
>
> FAIL: gcc.c-torture/compile/sync-1.c   -O0  (internal compiler error)
> FAIL: gcc.c-torture/compile/sync-1.c   -O0  fetch_and_nand (test for 
> warnings, line )
> FAIL: gcc.c-torture/compile/sync-1.c   -O0  nand_and_fetch (test for 
> warnings, line )
> FAIL: gcc.c-torture/compile/sync-1.c   -O0  (test for excess errors)
> FAIL: gcc.c-torture/compile/sync-2.c   -O0  (internal compiler error)
> FAIL: gcc.c-torture/compile/sync-2.c   -O0   (test for warnings, line )
> FAIL: gcc.c-torture/compile/sync-2.c   -O0  (test for excess errors)
> FAIL: gcc.c-torture/compile/sync-3.c   -O0  (internal compiler error)
> FAIL: gcc.c-torture/compile/sync-3.c   -O0   (test for warnings, line )
> FAIL: gcc.c-torture/compile/sync-3.c   -O0  (test for excess errors)
>
> and similarly across all the other optimization levels and compilation 
> options covered.
>
>   gcc/
>   * config/vax/vax.c (vax_expand_addsub_di_operands): Handle the 
>   addition or subtraction of 0.
OK, though I would have generally expected something to catch this earlier.

jeff

Re: [PATCH 3/3] VAX: Handle subtracting from self with QMATH DImode add/sub

[Jeff Law via Gcc-patches]

On 12/11/20 1:48 PM, Maciej W. Rozycki wrote:
> Remove an assertion the failure of which has not been actually observed, 
> but which appears clearly dangerous, for when the QMATH DImode add/sub 
> handler is invoked with the subtrahend and the minuend both the same.
> Instead handle the operation by emitting a move of constant 0 to the 
> output operand.  Adjust the relevant inline comment accordingly.
>
>   gcc/
>   * config/vax/vax.c (vax_expand_addsub_di_operands): Handle equal
>   input operands with subtraction.
OK
jeff

[C PATCH] Avoid incorrect warning for volatile in compound expressions [PR 98260]

[Uecker, Martin]

Here is a patch that fixes an incorrect warning for volatile
that appeared with the lvalue change. 


-- Martin

C: Avoid incorrect warning for volatile in compound expressions [PR98260]

2020-12-12  Martin Uecker  

gcc/c/
 PR c/98260
 * c-parser.c (c_parser_expression): Look into
 nop expression when marking expressions as read.  

gcc/testsuite/
 PR c/98260
 * gcc.dg/unused-9.c: New test.


diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 87ee8f47806..1388a60c495 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -10615,8 +10615,14 @@ c_parser_expression (c_parser *parser)
   c_parser_consume_token (parser);
   expr_loc = c_parser_peek_token (parser)->location;
   lhsval = expr.value;
-  while (TREE_CODE (lhsval) == COMPOUND_EXPR)
-   lhsval = TREE_OPERAND (lhsval, 1);
+  while (TREE_CODE (lhsval) == COMPOUND_EXPR
+    || TREE_CODE (lhsval) == NOP_EXPR)
+   {
+     if (TREE_CODE (lhsval) == COMPOUND_EXPR)
+   lhsval = TREE_OPERAND (lhsval, 1);
+     else
+   lhsval = TREE_OPERAND (lhsval, 0);
+   }
   if (DECL_P (lhsval) || handled_component_p (lhsval))
    mark_exp_read (lhsval);
   next = c_parser_expr_no_commas (parser, NULL);
diff --git a/gcc/testsuite/gcc.dg/unused-9.c b/gcc/testsuite/gcc.dg/unused-9.c
new file mode 100644
index 000..b32f7ef6c03
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/unused-9.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-Wunused" } */
+
+
+void g(void)
+{
+  int i = 0;
+  volatile int x;
+  (x, i++);/* { dg-bogus "set but not used" } */
+}
+
+

Re: [PATCH 1/2] VAX: Check the correct operand for constant 0 push operation

[Jeff Law via Gcc-patches]

On 12/12/20 5:05 AM, Maciej W. Rozycki wrote:
> Check the output operand for representing pushing a value onto the stack 
> rather than the constant 0 input in determining whether to use the PUSHL 
> or the CLRL instruction for a SImode move.  The latter actually works by 
> means of using the predecrement addressing mode with the SP register and 
> the machine code produced even takes the same number of bytes, however 
> at least with some VAX implementations it incurs a performance penalty.  
> Besides, we don't want to check the wrong operand anyway and have code 
> that works by chance only.
>
> Add a test case covering push operations; for operands different from 
> constant zero there is actually a code size advantage for using PUSHL 
> rather than the equivalent MOVL instruction.
>
>   gcc/
>   * config/vax/vax.c (vax_output_int_move): Check the correct 
>   operand for constant 0 push operation.
>
>   gcc/testsuite/
>   * gcc.target/vax/push.c: New test.

OK
jeff

Re: [PATCH 2/2] VAX: Unify push operation selection

[Jeff Law via Gcc-patches]

On 12/12/20 5:05 AM, Maciej W. Rozycki wrote:
> Avoid the possibility of code discrepancies like one fixed with the 
> previous change and improve the structure of code by selecting between 
> push and non-push operations in a single place in `vax_output_int_move'.
>
> The PUSHAB/MOVAB address moves are never actually produced from this 
> code as the SImode invocation of this function is guarded with the 
> `nonsymbolic_operand' predicate, but let's not mess up with this code 
> too much on this occasion and keep the piece in place.
>
>   * config/vax/vax.c (vax_output_int_move): Unify push operation 
>   selection.
OK
Jeff

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[Jeff Law via Gcc-patches]

On 12/12/20 11:33 AM, abebeos wrote:
>
>
> On Sat, 12 Dec 2020 at 01:15, Segher Boessenkool
> mailto:seg...@kernel.crashing.org>> wrote:
>
> On Fri, Dec 11, 2020 at 11:20:01PM +0200, abebeos wrote:
> > Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool <
> > seg...@kernel.crashing.org >
> έγραψε:
> > > > Ok, to speed things up, is it ok if I simply pick the patch
> that I've
> > > > attached to the issue:
> > > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c21
> 
> > >
> > > I see no patch attached there?  Just a link to github.
> >
> > sorry, it's on top of the issue.
> >
> > direct link:
> >
> https://gcc.gnu.org/bugzilla/attachment.cgi?bugid=92729&action=viewall
> 
>
> Ah, you linked to comment 21, so I only looked in that comment :-)
>
> > > I'd ask the original author, but it seems he's busy with other
> work, so to
> > > > avoid delays...
> > >
> > > Please try to ask him first?  That is always nice,
> >
> > contacted days ago both authors via email (naturally closing
> with "feel
> > free to  ignore if you're busy"), pip replied, saa not. Though
> both are on
> > the cc of the issue, too.
>
> Let's hope he replies soon after you post it.  
>
>
> Here it is:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561718.html
> 
>
> My understanding is that patches are neutral (no signature, no names),
> so if saaadhu signs it off and commits it, all will be fine (legal and
> ethics).
The FSF has very specific requirements for copyright assignments.  The
author needs a copyright assignment on file with the FSF and the FSF may
also require their author's employer to sign an employer disclaimer
before the contributions can be accepted.

Jeff

Re: [PATCH] sanitizer: do not ICE for pointer cmp/sub

[Jeff Law via Gcc-patches]

On 12/10/20 1:31 AM, Martin Liška wrote:
> Hello.
>
> In C FE we have troubles to instrument top-level pointer comparison
> (and subtraction):
>
> /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/asan/pr98204.c:5:1:
> internal compiler error: in pointer_diff, at c/c-typeck.c:3954
>     5 | static long i=((char*)&(v.c)-(char*)&v);
>       | ^~
>
> and
>
>  gcc
> /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/asan/pr98204.c
> -c -fsanitize=address,pointer-compare
> /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/asan/pr98204.c:6:16:
> error: initializer element is not constant
>     6 | static long i2=((char*)&(v.c)<(char*)&v);
>       |                ^
>
> The patch fixes that by not instrumenting that when current_function_decl
> is NULL_TREE.
>
> On the contrary, C++ is fine with that and does the emission in ctor:
>
> $ +
> /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/asan/pr98204.c
> -c -fsanitize=address,pointer-compare,pointer-subtract
> -fdump-tree-gimple=/dev/stdout
> ...
> void __static_initialization_and_destruction_0 (int __initialize_p,
> int __priority)
> {
>   if (__initialize_p == 1) goto ; else goto ;
>   :
>   __builtin___asan_before_dynamic_init
> ("/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/asan/pr98204.c");
>   if (__priority == 65535) goto ; else goto ;
>   :
>   __builtin___sanitizer_ptr_sub (&v.c, &v);
>   i = 0;
>   __builtin___sanitizer_ptr_cmp (&v.c, &v);
>
> Are we able to do something similar for C FE, or are we fine with the
> suggested patch?
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/c/ChangeLog:
>
>     PR sanitizer/98204
>     * c-typeck.c (pointer_diff): Do not emit a top-level
>     sanitization.
>     (build_binary_op): Likewise.
>
> gcc/testsuite/ChangeLog:
>
>     PR sanitizer/98204
>     * c-c++-common/asan/pr98204.c: New test.
It would be better if we had consistency across C and C++ for this.  But
to make this work for C wouldn't we have to change the static
initialization to a runtime initialization?  Which in turn means we'd
need to set up some kind of ctor?  WHich in turn means that we'd bring
the whole issue of static ctor initialization order to C?  Ew.

I'd be real tempted to just live with the inconsistency and go with your
patch.

jeff

Re: introduce overridable clear_cache emitter

[Jeff Law via Gcc-patches]

On 12/10/20 3:58 AM, Alexandre Oliva wrote:
> On Dec  3, 2020, Alexandre Oliva  wrote:
>
>> +local_define_builtin ("__builtin___clear_cache", ftype,
>> +  BUILT_IN_CLEAR_CACHE,
>> +  "__builtin___clear_cache",
>> +  ECF_NOTHROW);
> Ugh, so that somehow worked for aarch64-linux-gnu-gfortran, but the
> aarch64-elf Ada compiler started issuing calls to an undefined
> __builtin___clear_cache symbol.
>
> The second string actual passed to local_define_builtin binds to formal
> libname, which explains at least the new problem.  I've so far
> restrained my curiosity as to why it wasn't a problem on
> aarch64-linux-gnu-gfortran.  I'm checking it in as obvious, so far
> lightly tested on x86_64-linux-gnu and -x-aarch64-elf.
>
>
> drop __builtin_ from __clear_cache libname
>
> From: Alexandre Oliva 
>
> I made a cut&pasto in my previous patch for tree.c, causing platforms
> that have CLEAR_INSN_CACHE defined, and none of the internal
> __clear_cache expansion overriders, to issue calls to symbols named
> __builtin___clear_cache rather than __clear_cache, on languages other
> than those in the C family.  Oops.
>
> This patch removes __builtin_ from the string used as the libname for
> __buuiltin___clear_cache.
>
>
> for  gcc/ChangeLog
>
>   * tree.c (build_common_builtin_nodes): Drop __builtin_ from
>   __clear_cache libname.
OK
jeff

Re: [committed] Fix non-unique testnames

[Jeff Law via Gcc-patches]

On 12/7/20 9:19 AM, Martin Sebor wrote:
> On 12/4/20 3:17 PM, Jeff Law via Gcc-patches wrote:
>>
>>
>> On 12/4/20 2:55 PM, Mike Stump wrote:
>>> On Nov 30, 2020, at 8:00 AM, Jeff Law via Gcc-patches
>>>  wrote:
 This patch fixes a handful of tests with non-unique names which
 confuse
 the living hell out of compare_tests, particularly if one of two tests
 [x]fail while the other is [x]pass which compare_tests will flag as a
 regression each and every run.
>>> Thanks.  The other way to fix the issue is to fix the tools so that
>>> they never fail.  :-)
>> Yes, but either way tests should be unique.
>
> I know I introduced some (or even most) of these and I still have
> to change the strings and make them unique.  What bothers me is
> that it's yet another unnecessary hoop for us to jump through.
> It's not documented anywhere that these things need to be unique,
> there's no tooling to detect when they're not, and it gets missed
> in code reviews.  Why not instead change the test harness to do
> this for us?
A change to fix the test harness would certainly be appreciated.  I'm a
much bigger fan of having tools catch this kind of thing than hoping a
reviewer remembers to look for it.

jeff

Re: [PATCH] widening_mul: Fix a > ~b to .ADD_OVERFLOW optimization [PR98256]

[Richard Biener]

On December 13, 2020 12:02:48 PM GMT+01:00, Jakub Jelinek  
wrote:
>Hi!
>
>Unfortunately, my latest tree-ssa-math-opts.c patch broke the following
>testcase.  The problem is that the code is adding .ADD_OVERFLOW or
>.SUB_OVERFLOW before or after the stmt on which the function has been
>called, which is normally a addition or subtraction that has all the
>operands.
>But in the a > ~b optimization that stmt is the ~b stmt and the other
>comparison operand might be defined only after that ~b stmt, so we
>can't
>insert the .ADD_OVERFLOW next to ~b that we want to delete, but need to
>insert it before the a > temp comparison that uses it; and in that case
>when removing the BIT_NOT_EXPR stmt we need to ensure the caller
>doesn't do
>gsi_next because gsi_remove already points the iterator to the next
>stmt.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok. 

Richard. 

>2020-12-13  Jakub Jelinek  
>
>   PR tree-optimization/98256
>   * tree-ssa-math-opts.c (match_uaddsub_overflow): For BIT_NOT_EXPR,
>   only handle a single use, and insert .ADD_OVERFLOW before the
>   comparison rather than after the BIT_NOT_EXPR.  Return true iff
>   it is BIT_NOT_EXPR and it has been removed.
>   (math_opts_dom_walker::after_dom_children) :
>   If match_uaddsub_overflow returned true, continue instead of break.
>
>   * gcc.c-torture/compile/pr98256.c: New test.
>
>--- gcc/tree-ssa-math-opts.c.jj2020-12-12 14:48:40.195306781 +0100
>+++ gcc/tree-ssa-math-opts.c   2020-12-12 22:42:24.474396562 +0100
>@@ -3598,6 +3598,7 @@ match_uaddsub_overflow (gimple_stmt_iter
>   gimple *use_stmt;
>   gimple *add_stmt = NULL;
>   bool add_first = false;
>+  gimple *cond_stmt = NULL;
> 
>   gcc_checking_assert (code == PLUS_EXPR
>  || code == MINUS_EXPR
>@@ -3628,8 +3629,9 @@ match_uaddsub_overflow (gimple_stmt_iter
>   return false;
> if (rhs2 == NULL)
>   rhs2 = other;
>-else if (rhs2 != other)
>+else
>   return false;
>+cond_stmt = use_stmt;
>   }
> ovf_use_seen = true;
>   }
>@@ -3818,6 +3820,9 @@ match_uaddsub_overflow (gimple_stmt_iter
>   }
> }
> 
>+  if (code == BIT_NOT_EXPR)
>+*gsi = gsi_for_stmt (cond_stmt);
>+
>   tree ctype = build_complex_type (type);
>   gcall *g = gimple_build_call_internal (code != MINUS_EXPR
>? IFN_ADD_OVERFLOW : IFN_SUB_OVERFLOW,
>@@ -3843,7 +3848,10 @@ match_uaddsub_overflow (gimple_stmt_iter
>   tree ovf = make_ssa_name (type);
>   g2 = gimple_build_assign (ovf, IMAGPART_EXPR,
>   build1 (IMAGPART_EXPR, type, ctmp));
>-  gsi_insert_after (gsi, g2, GSI_NEW_STMT);
>+  if (code != BIT_NOT_EXPR)
>+gsi_insert_after (gsi, g2, GSI_NEW_STMT);
>+  else
>+gsi_insert_before (gsi, g2, GSI_SAME_STMT);
> 
>   FOR_EACH_IMM_USE_STMT (use_stmt, iter, lhs)
> {
>@@ -3908,11 +3916,12 @@ match_uaddsub_overflow (gimple_stmt_iter
> }
>   else if (code == BIT_NOT_EXPR)
> {
>-  gimple_stmt_iterator gsi2 = gsi_for_stmt (stmt);
>-  gsi_remove (&gsi2, true);
>+  *gsi = gsi_for_stmt (stmt);
>+  gsi_remove (gsi, true);
>   release_ssa_name (lhs);
>+  return true;
> }
>-  return true;
>+  return false;
> }
> 
> /* Return true if target has support for divmod.  */
>@@ -4238,7 +4247,8 @@ math_opts_dom_walker::after_dom_children
> break;
> 
>   case BIT_NOT_EXPR:
>-match_uaddsub_overflow (&gsi, stmt, code);
>+if (match_uaddsub_overflow (&gsi, stmt, code))
>+  continue;
> break;
> 
>   case TRUNC_MOD_EXPR:
>--- gcc/testsuite/gcc.c-torture/compile/pr98256.c.jj   2020-12-12
>22:44:34.037940761 +0100
>+++ gcc/testsuite/gcc.c-torture/compile/pr98256.c  2020-12-12
>22:35:54.452778912 +0100
>@@ -0,0 +1,9 @@
>+/* PR tree-optimization/98256 */
>+
>+unsigned a, b;
>+
>+int
>+foo (void)
>+{
>+  return !!(~a / b);
>+}
>
>   Jakub

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[Segher Boessenkool]

On Sun, Dec 13, 2020 at 09:49:25AM -0700, Jeff Law wrote:
> On 12/12/20 11:33 AM, abebeos wrote:
> > Here it is:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561718.html
> > 
> >
> > My understanding is that patches are neutral (no signature, no names),
> > so if saaadhu signs it off and commits it, all will be fine (legal and
> > ethics).

We do not do sign-offs.  You need to have a copyright assignment before
you can commit anything, so it would be superfluous.

> The FSF has very specific requirements for copyright assignments.  The
> author needs a copyright assignment on file with the FSF and the FSF may
> also require their author's employer to sign an employer disclaimer
> before the contributions can be accepted.

Senthil already has write-after-approval, and he has committed many
patches to avr/ already.


Segher

Re: [PATCH] correct -Wmismatched-new-delete (PR 98160, 98166)

[Jeff Law via Gcc-patches]

On 12/8/20 1:46 PM, Martin Sebor wrote:
> PR 98160 reports an ICE in pretty printer code called from the newly
> added -Wmismatched-new-delete.  The ICE is just a simple oversight,
> but much more interesting is the warning issued for the test case.
> It highlights an issue I didn't consider in the initial implementation:
> that inlining one of a pair of allocation/deallocation functions but
> not the other might lead to false positives when the inlined function
> calls another allocator that the deallocator isn't associated with.
>
> In addition, tests for the changes exposed the overly simplistic
> nature of the detection of calls to mismatched forms of operator
> new and delete which fails to consider member operators, also
> resulting in false positives.
>
> Finally, in a comment on the initial implementation Jonathan notes
> that the -Wmismatched-new-delete warning should trigger not only
> in user code but also in libstdc++ functions inlined into user code.
> I thought I had done that but as it turns out, the "standard code
> sequence" I put in place isn't sufficient to make this work.
>
> The attached changes avoid the false positives a) by ignoring (with
> a warning) the new form of the malloc attribute on inline functions,
> and disabling the inlining of others by implicitly adding attribute
> noinline to their declaration, and b) by making more robust
> the detection of mismatched operators new and delete.  Furthermore,
> the patch also arranges for the warning to trigger even for inlined
> calls to functions defined in system headers.
>
> To make review a little (marginally) easier the change are two files:
> 1) gcc-98166-1.diff: introduces valid_new_delete_pair_p and
> tree_inlined_location.
> 2) gcc-98166-2.diff: adjusts the atrribute/warning implementation .
>
> Tested on x86_64-linux.
>
> Martin
>
> gcc-98166-1.diff
>
> Introduce an overload of valid_new_delete_pair_p and tree_inlined_location.
>
> gcc/ChangeLog:
>
>   * tree-ssa-dce.c (valid_new_delete_pair_p): Factor code out into
>   valid_new_delete_pair_p in tree.c.
>   * tree.c (tree_inlined_location): Define new function.
>   (valid_new_delete_pair_p): Define.
>   * tree.h (tree_inlined_location): Declare.
>   (valid_new_delete_pair_p): Declare.
OK


>
> gcc-98166-2.diff
>
> Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++/57111, 
> PR middle-end/98160).
>
> Resolves:
> PR middle-end/98166 - bogus -Wmismatched-dealloc on user-defined allocator 
> and inlining
> PR c++/57111 - 57111 - Generalize -Wfree-nonheap-object to delete
> PR middle-end/98160 - ICE in default_tree_printer at gcc/tree-diagnostic.c:270
>
> gcc/ChangeLog:
>
>   PR middle-end/98166
>   PR c++/57111
>   PR middle-end/98160
>   * builtins.c (call_dealloc_p): Remove unused function.
>   (new_delete_mismatch_p): Call valid_new_delete_pair_p and rework.
>   (matching_alloc_calls_p): Handle built-in deallocation functions.
>   (warn_dealloc_offset): Corrct the handling of user-defined operators
>   delete.
>   (maybe_emit_free_warning): Avoid assuming expression is a decl.
>   Simplify.
>   * doc/extend.texi (attribute malloc): Update.
>
> gcc/c-family/ChangeLog:
>
>   PR middle-end/98166
>   PR c++/57111
>   PR middle-end/98160
>   * c-attribs.c (handle_malloc_attribute): Implicitly add attribute
>   noinline to functions not declared inline and warn on those.
>
> libstdc++-v3/ChangeLog:
>   * testsuite/ext/vstring/requirements/exception/basic.cc: Suppress
>   a false positive warning.
>   * 
> testsuite/ext/vstring/requirements/exception/propagation_consistent.cc:
> Same.
>
> gcc/testsuite/ChangeLog:
>
>   PR middle-end/98166
>   PR c++/57111
>   PR middle-end/98160
>   * g++.dg/warn/Wmismatched-dealloc-2.C: Adjust test of expected warning.
>   * g++.dg/warn/Wmismatched-new-delete.C: Same.
>   * gcc.dg/Wmismatched-dealloc.c: Same.
>   * c-c++-common/Wfree-nonheap-object-2.c: New test.
>   * c-c++-common/Wfree-nonheap-object-3.c: New test.
>   * c-c++-common/Wfree-nonheap-object.c: New test.
>   * c-c++-common/Wmismatched-dealloc.c: New test.
>   * g++.dg/warn/Wfree-nonheap-object-3.C: New test.
>   * g++.dg/warn/Wfree-nonheap-object-4.C: New test.
>   * g++.dg/warn/Wmismatched-new-delete-2.C: New test.
OK, but there's a follow-up as noted below:


>
>  
> diff --git a/gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C 
> b/gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C
> index 7ecc99a325c..3aea02fa63d 100644
> --- a/gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C
> +++ b/gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C
Please fix the non-unique testnames in this file.  This can be done as a
separate follow-up patch as they're pre-existing.

diff --git a/gcc/testsuite/g++.dg/warn/Wmismatched-new-delete.C
b/gcc/testsuite/g++.dg/warn/Wmismatched-new-delete.C
> index ed1090be5c5..fc07149995

Re: [PATCH] doc: Remove -mcet

[Jeff Law via Gcc-patches]

On 12/6/20 8:09 AM, H.J. Lu via Gcc-patches wrote:
> -mcet was removed by
>
> commit 231baae28ef7ff784683fa5a80df119da2b9a99b
> Author: H.J. Lu 
> Date:   Tue Apr 24 16:56:04 2018 +
>
> x86/CET: Remove the -mcet command-lint option
>
>   PR target/98162
>   * doc/extend.texi: Remove -mcet.
OK
jeff

Re: [19/23] rtlanal: Add some new helper classes

[Jeff Law via Gcc-patches]

On 11/13/20 1:20 AM, Richard Sandiford via Gcc-patches wrote:
> This patch adds some classes for gathering the list of registers
> and memory that are read and written by an instruction, along
> with various properties about the accesses.  In some ways it's
> similar to the information that DF collects for registers,
> but extended to memory.  The main reason for using it instead
> of DF is that it can analyse tentative changes to instructions
> before they've been committed.
>
> The classes also collect general information about the instruction,
> since it's cheap to do and helps to avoid multiple walks of the same
> RTL pattern.
>
> I've tried to optimise the code quite a bit, since with later patches
> it becomes relatively performance-sensitive.  See the discussion in
> the comments for the trade-offs involved.
>
> I put the declarations in a new rtlanal.h header file since it
> seemed a bit excessive to put so much new inline stuff in rtl.h.
>
> gcc/
>   * rtlanal.h: New file.
>   (MEM_REGNO): New constant.
>   (rtx_obj_flags): New namespace.
>   (rtx_obj_reference, rtx_properties): New classes.
>   (growing_rtx_properties, vec_rtx_properties_base): Likewise.
>   (vec_rtx_properties): New alias.
>   * rtlanal.c: Include it.
>   (rtx_properties::try_to_add_reg): New function.
>   (rtx_properties::try_to_add_dest): Likewise.
>   (rtx_properties::try_to_add_src): Likewise.
>   (rtx_properties::try_to_add_pattern): Likewise.
>   (rtx_properties::try_to_add_insn): Likewise.
>   (vec_rtx_properties_base::grow): Likewise.
One might argue at least some of these should become first class
properties of insns but then we have the joy of keeping them up-to-date
as transformations are made.  It also reminds me a bit of the old
var_ann stuff we had in the tree SSA implementation. 

OK. 

jeff

Re: [PATCH] PR target/98152: Checking python is available before using

[Jeff Law via Gcc-patches]

On 12/5/20 11:12 PM, Kito Cheng wrote:
> We'll try to canonicalize the arch string for --with-arch,
> and the script is written in python, however it will turns out
> GCC require python to build for RISC-V port, it's not expect as
> the GCC requirement.
>
> So this patch is made this as optional, detect python and only use it
> when it available, it won't break any functionality with out doing
> canonicalization, just might build one more redundant multi-lib.
>
> gcc/ChangeLog:
>
>   * config.gcc (riscv*-*-*): Checking python, python3 or python2
>   is available, and skip doing with_arch canonicalize if no python
>   available.
OK. 
jeff

Re: [PATCH] add g_nonstandard_bool attribute for GIMPLE FE use

[Jeff Law via Gcc-patches]

On 12/11/20 2:02 AM, Richard Biener wrote:
> This adds __attribute__((g_nonstandard_bool(precision))) to be able
> to construct nonstandard boolean types which for the included testcase
> is needed to simulate Ada and LTO interaction (Ada uses a 8 bit
> precision boolean_type_node).  This will also be useful for vector
> unit testcases where we need to produce vector types with
> non-standard boolean type components.
>
> --
>
> Joseph, is using attributes a good enough way to extend the set of C
> types for use of the GIMPLE FE?  I chose to add a g_ prefix to
> note use by the GIMPLE FE but since we can mix C and GIMPLE FE
> functions in one TU those of course can leak into C functions
> (and eventually lead to ICEs/issues there) - but the attribute is
> simply ignored when not compiling with -fgimple.
>
> I figured there's no documentation about GIMPLE FE "extensions",
> I'll see to write something as followup (there's a small section
> in sourcebuild.texi and the -fgimple docs itself).  I chose to
> not document this attribute in the place we document attributes
> supposed to be used in production.
>
> OK for trunk?
>
> I'll push the actual vectorizer fix for PR95582 separately, this
> patch is only "needed" to add a testcase for the PR.
>
> Thanks,
> Richard.
>
> 2020-12-11  Richard Biener  
>
>   PR tree-optimization/95582
> gcc/c-family/
>   * c-attribs.c (c_common_attribute_table): Add entry for
>   g_nonstandard_bool.
>   (handle_g_nonstandard_bool_attribute): New.
>
> gcc/testsuite/
>   * gcc.dg/pr95582.c: New testcase.
Looks reasonable to me -- the only place we might consider documenting
this would be in sourcebuild.texi as you mentioned since other
developers might want to do something similar.  I don't think we need
user level docs for this.

jeff

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Fri, 11 Dec 2020 at 20:32, Jeff Law  wrote:

>
>
> On 12/9/20 6:12 AM, abebeos via Gcc-patches wrote:
> > Essence:
> >
> > I need a confirmation that the testsuite setup as presented in:
> >
> > https://github.com/abebeos/avr-gnu
> >
> > works fine.
> >
> > The problem with the avr target is that the testsuite cannot be run
> easily,
> > mainly because of the need for a special simulated-target setup, which
> does
> > not work for avr as documented. This led developers to a dead-end with
> > their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is not
> > dropped from gcc11).
> >
> > I integrated a toolchain/testsetup to be able to run the gcc testsuite
> > against a simulated avr target.
> >
> > I then used this toolchain to test 2 different existent
> > non-cc0-avr-backends (from pipcet and saaadhu, both github).
> >
> > The result is that saaadhu's backend seems to be working 100%. It has
> > identical testsuite results with the existing (but deprecated)
> cc0-backend,
> > which means that it can be used "as-is" for inclusion in gcc11.
> >
> > Please note that I did this work in context of a bounty @ bountysouce,
> more
> > information within the issue:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
> I haven't looked at the github repo.  But I do have a couple comments here.
>
> First, the author of the changes (pipcet and saaadhu) need to have
> copyright assignments on file with the FSF.  Otherwise we can not use
> their work at all.
>
> Second, the work needs to be submitted for inclusion.  I don't recall
> seeing an official submission from either of them to gcc-patches.
>
> I'm definitely curious about the testing setup and whether or not it can
> be replicated into our Jenkins setup.


Where can I find this Jenkins setup?

It is my understanding there is
> no newlib support for avr so I'm curious what you're using for a basic
> runtime library.
>
> jeff
>
>

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

[Thomas Koenig via Gcc-patches]

Hi Iain,


I guess the hard thing is for the developer to know that (s)he wants
the option and what to do when a conflict occurs.


Actually, I just hit on a much simpler solution.

We translate all symbols to lower case (except for those
with BIND(C), which do not matter in this context).  So,
prefixing everything with GFC_ (upper case) should work on
any toolchain that can handle C, which is all we care about.

So, here is a patch which implements this method. The tree
dump now looks like this:

struct __st_parameter_dt GFC_dt_parm_0;

GFC_dt_parm_0.common.filename = &"hello.f90"[1]{lb: 1 sz: 1};
GFC_dt_parm_0.common.line = 2;
GFC_dt_parm_0.common.flags = 128;
GFC_dt_parm_0.common.unit = 6;
_gfortran_st_write (&GFC_dt_parm_0);
_gfortran_transfer_character_write (&GFC_dt_parm_0, &"Hello, 
world"[1]{lb: 1 sz: 1}, 12);

_gfortran_st_write_done (&GFC_dt_parm_0);

So, thanks for raising your concerns, I like this much better now :-)

Regression-tested. Also tested with "make dvi" and "make pdf".
If there are no other comments, I'd like to commit this as having
no user impact and kind of obvious (now :-) tomorrow or so.

Best regards

Thomas
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 8bdc8a6b038..0386818a93d 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -160,7 +160,7 @@ and warnings}.
 @item Debugging Options
 @xref{Debugging Options,,Options for debugging your program or GNU Fortran}.
 @gccoptlist{-fbacktrace -fdump-fortran-optimized -fdump-fortran-original @gol
--fdump-fortran-global -fdump-parse-tree -ffpe-trap=@var{list} @gol
+-fdebug-aux-vars -fdump-fortran-global -fdump-parse-tree -ffpe-trap=@var{list} @gol
 -ffpe-summary=@var{list}
 }
 
@@ -1219,6 +1219,15 @@ change between releases. This option may also generate internal
 compiler errors for features which have only recently been added. This
 option is deprecated; use @code{-fdump-fortran-original} instead.
 
+@item -fdebug-aux-vars
+@opindex @code{fdebug-aux-vars}
+Renames internal variables created by the gfortran front end and makes
+them accessible to a debugger.  The name of the internal variables then
+start with @code{GFC_}. This option is useful for debugging the
+compiler's code generation together with @code{-fdump-tree-original} and
+enabling debugging of the executable program by using @code{-g} or
+@code{-ggdb3}.
+
 @item -fdump-fortran-global
 @opindex @code{fdump-fortran-global}
 Output a list of the global identifiers after translating into
diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index 96ed208cb85..57b0264458e 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -452,6 +452,10 @@ fd-lines-as-comments
 Fortran RejectNegative
 Treat lines with 'D' in column one as comments.
 
+fdebug-aux-vars
+Fortran Var(flag_debug_aux_vars)
+Issue debug information for compiler-generated auxiliary variables.
+
 fdec
 Fortran Var(flag_dec)
 Enable all DEC language extensions.
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index 025abe38985..0219115812a 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -73,6 +73,42 @@ gfc_advance_chain (tree t, int n)
   return t;
 }
 
+static int num_var;
+
+#define MAX_PREFIX_LEN 20
+
+static tree
+create_var_debug_raw (tree type, const char *prefix)
+{
+  /* Space for "GFC_" + prefix + "_" + 10-digit-number + \0.  */
+  char name_buf[4 + MAX_PREFIX_LEN + 1 + 10 + 1];
+  tree t;
+
+  if (prefix != NULL)
+{
+  gcc_assert (strlen (prefix) <= MAX_PREFIX_LEN);
+  snprintf (name_buf, sizeof (name_buf), "GFC_%s_%d", prefix, num_var++);
+}
+  else
+snprintf (name_buf, sizeof (name_buf), "GFC_%d", num_var++);
+
+  t = build_decl (input_location, VAR_DECL, get_identifier (name_buf), type);
+
+  /* We want debug info for it.  */
+  DECL_IGNORED_P (t) = 0;
+  /* It should not be nameless.  */
+  DECL_NAMELESS (t) = 0;
+
+  /* Make the variable writable.  */
+  TREE_READONLY (t) = 0;
+
+  DECL_EXTERNAL (t) = 0;
+  TREE_STATIC (t) = 0;
+  TREE_USED (t) = 1;
+
+  return t;
+}
+
 /* Creates a variable declaration with a given TYPE.  */
 
 tree
@@ -80,6 +116,9 @@ gfc_create_var_np (tree type, const char *prefix)
 {
   tree t;
 
+  if (flag_debug_aux_vars)
+return create_var_debug_raw (type, prefix);
+
   t = create_tmp_var_raw (type, prefix);
 
   /* No warnings for anonymous variables.  */

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[Georg-Johann Lay]

On Fri, 11 Dec 2020 at 20:32, Jeff Law  wrote:

I'm definitely curious about the testing setup and whether or not it can
be replicated into our Jenkins setup.


Hi, Jeff.

The gcc testsuite setup is described in the readme of avrtest:

https://sourceforge.net/p/winavr/code/HEAD/tree/trunk/avrtest/

SourceForge changed code URLs some time ago, thus some links
in the GCC page are outdated and lead to nowhere...

The repo above should be the most recent one, at least it's the place
I am using to commit.


HTH, Johann

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

[Iain Sandoe via Gcc-patches]

Hi Thomas,

Thomas Koenig via Fortran  wrote:


I guess the hard thing is for the developer to know that (s)he wants
the option and what to do when a conflict occurs.


Actually, I just hit on a much simpler solution.


:) .. I’m all in favour of simplicity.


We translate all symbols to lower case (except for those
with BIND(C), which do not matter in this context).  So,
prefixing everything with GFC_ (upper case) should work on
any toolchain that can handle C, which is all we care about.


For bonus points you can prefix with _GFC_ which puts the symbols
in the implementation’s namespace (at least for C-Family purposes)
and therefore means that a clash with a user’s symbols is the user’s
problem …


So, here is a patch which implements this method. The tree
dump now looks like this:

   struct __st_parameter_dt GFC_dt_parm_0;

   GFC_dt_parm_0.common.filename = &"hello.f90"[1]{lb: 1 sz: 1};
   GFC_dt_parm_0.common.line = 2;
   GFC_dt_parm_0.common.flags = 128;
   GFC_dt_parm_0.common.unit = 6;
   _gfortran_st_write (&GFC_dt_parm_0);
   _gfortran_transfer_character_write (&GFC_dt_parm_0, &"Hello, world"[1]{lb: 1 
sz: 1}, 12);
   _gfortran_st_write_done (&GFC_dt_parm_0);

So, thanks for raising your concerns, I like this much better now :-)

Regression-tested. Also tested with "make dvi" and "make pdf".
If there are no other comments, I'd like to commit this as having
no user impact and kind of obvious (now :-) tomorrow or so.

Best regards

Thomas

Re: [PATCH 2/3] VAX: Handle constant 0 with QMATH DImode add/sub

[Maciej W. Rozycki]

On Sun, 13 Dec 2020, Jeff Law wrote:

> > gcc/
> > * config/vax/vax.c (vax_expand_addsub_di_operands): Handle the 
> > addition or subtraction of 0.
> OK, though I would have generally expected something to catch this earlier.

 Doesn't it matter that this pattern is produced in the context of atomic 
intrinsics?

 It is also not invalid even if silly and the !QMATH VAX implementation 
(the older one, presumably) lets it through just fine.  Last but not least 
the operation does not make it to assembly output; I could perhaps trace 
it through the RTL passes, but so far I have decided it doesn't really 
matter which specific pass makes it disappear.

 Either way thanks for your review, I have pushed this and the remaining 
five changes.

  Maciej

Re: [PATCH] avr: cc0 to mode_cc conversion

[abebeos via Gcc-patches]

On Sun, 13 Dec 2020 at 20:51, Georg-Johann Lay  wrote:

> > (I really tried to follow this
> https://gcc.gnu.org/contribute.html#patches,
> > but my stomach)
> >
> > Hi there all!
> >
> > The attached patch contains a new avr-backend, stripped from cc0.
> >
> > The author is gcc maintainer Snethil Kumar Selvaraj (saaadhu),
>
> Hi, AFAIK Senthil has write-after-approval state.  The only avr
> maintainer, at least according to MAINTAINERS, is still Denis, cf.
>
>
> http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=MAINTAINERS;h=32f8a2b72923b791f9687d6a2d555a1780535078;hb=HEAD#l59
>
> I allowed me CCing them.
>
> > the source can be found here:
> >
> > https://github.com/saaadhu/gcc-avr-cc0/tree/avr-cc0-squashed
> >
> > The gcc/g++ testsuites show zero regressions, tested with:
> >
> > https://github.com/abebeos/avr-gnu
> >
> > and confirmed with another testsetup, see:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561489.html
> >
> > Some more background information within:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561668.html
> >
> > and
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
> >
> > (i have this dark feeling that I did the patch submission wrong...
> pressing
> > Send anyways!)
>

(hey, "between us": where did my real-name came from in your email? I
choosed to appear here with an alias "abebeos" - not that it's difficult to
find my real name, but still, it's my choice...)


>
> Sometimes it's more convenient to have a .diff text file, but I don't
> see anything wrong with your submission.


ok

And what it really nice to
> have hunks defined for "(define_" or "^(define_") in your git diff
> setup.  That way it's easier to track in which entity of the machine
> description a change is located.  Just like when you have a change
> in the middle of a long C function, and the diff chunk spells out
> the C function in which it is located.
>

ok

> diff --git a/gcc/config/avr/avr-dimode.md b/gcc/config/avr/avr-dimode.md
>
[...] - (review)

Thank you for taking the time to review.

The author (currently not available) assessed the work as "semi working":

The (lets say) integrator (me), assessed the work as "good enough" - given
status of the gcc10 avr-backend this should be the prioriity (saving it
from extinction).

Possibly all details should be ignored for now, thus it can be merged.

My process/decision (given circumstances) is to "not touch even whitespace"
in the 0-regression-patch.

So, what remains for me now is to produce a tiny document for the
bounty-backers, and just hope that the folks here finds peace&wisdom to do
the right thing.

Over

a
n
d

Out!

.

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Nikhil Benesch via Gcc-patches]

On 12/10/20 4:44 PM, Rainer Orth wrote:

I'm attaching the -save-temps output, so you can work on the real data
rather than trying to figure things out from the Illumos repos.


Thanks, that was helpful. I also have successfully acquired access to
gcc211, so I should be self sufficient moving forward. Thanks again for
the pointer to the compile farm.

I believe the attached patch will fix the issue. There are a few parts
to the fix:

  * Typedefs whose name matches the underlying struct tag, as in

typedef struct FILE {} FILE;

are suppressed, so that we output the interesting "struct FILE {}"

definition and not the useless "typedef FILE FILE" definition.

  * Rewriting of _in6_addr to [16]byte is applied to all type
definitions, rather than to an enumerated subset. This follows the
approach used for timeval/timespec.

The old approach could not handle cases like:

type _mld2mar struct { addr _in6_addr /* ... */}
type _mld2mar_t _mld2mar

The old approach would filter out type _mld2mar but understandably

was not smart enough to filter out mld2mar_t, resulting in a
reference to non-existent type _mld2mar.

  * Handling of _timestruc_t when it is just an alias for timespec.

  * Inclusion of stdio.h to avoid an incomplete definition of the type
__FILE.

There are a few more hurdles before this patch is ready for commit. The
changes to godump.c deserve new test cases. And the changes to the
mk[r]sysinfo.sh scripts will need to go upstream first. Hopefully I'll
get to that soon. I wanted to send along what I had in the meantime.

Nikhil
diff --git a/gcc/godump.c b/gcc/godump.c
index 033b2c5..c3f4b7b 100644
--- a/gcc/godump.c
+++ b/gcc/godump.c
@@ -1155,15 +1155,25 @@ go_output_typedef (class godump_container *container, 
tree decl)
 {
   void **slot;
   const char *type;
+  tree original_type;
 
   type = IDENTIFIER_POINTER (DECL_NAME (decl));
+  original_type = DECL_ORIGINAL_TYPE (decl);
+
+  /* Suppress typedefs where the type name matches the underlying
+struct/union/enum tag. This way we'll emit the struct definition
+instead of an invalid recursive type.  */
+  if (TYPE_IDENTIFIER (original_type) != NULL
+ && IDENTIFIER_POINTER (TYPE_IDENTIFIER (original_type)) == type)
+   return;
+
   /* If type defined already, skip.  */
   slot = htab_find_slot (container->type_hash, type, INSERT);
   if (*slot != NULL)
return;
   *slot = CONST_CAST (void *, (const void *) type);
 
-  if (!go_format_type (container, DECL_ORIGINAL_TYPE (decl), true, false,
+  if (!go_format_type (container, original_type, true, false,
   NULL, false))
{
  fprintf (go_dump_file, "// ");
@@ -1174,7 +1184,8 @@ go_output_typedef (class godump_container *container, 
tree decl)
   IDENTIFIER_POINTER (DECL_NAME (decl)));
   go_output_type (container);
 
-  if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (decl)))
+  if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (decl))
+ || TREE_CODE (TREE_TYPE (decl)) == ENUMERAL_TYPE)
{
  HOST_WIDE_INT size = int_size_in_bytes (TREE_TYPE (decl));
 
@@ -1187,7 +1198,9 @@ go_output_typedef (class godump_container *container, 
tree decl)
 
   container->decls_seen.add (decl);
 }
-  else if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (decl)))
+  else if ((RECORD_OR_UNION_TYPE_P (TREE_TYPE (decl))
+   || TREE_CODE (TREE_TYPE (decl)) == ENUMERAL_TYPE)
+  && TYPE_NAME (TREE_TYPE (decl)) != NULL)
 {
void **slot;
const char *type;
diff --git a/libgo/mkrsysinfo.sh b/libgo/mkrsysinfo.sh
index c28f0e5..29ca1ab 100755
--- a/libgo/mkrsysinfo.sh
+++ b/libgo/mkrsysinfo.sh
@@ -24,11 +24,16 @@ grep -v '^// ' gen-sysinfo.go | \
   grep -v '^type _timespec ' | \
   grep -v '^type _epoll_' | \
   grep -v '^type _*locale[_ ]' | \
-  grep -v 'in6_addr' | \
+  grep -v '^type _in6_addr' | \
   grep -v 'sockaddr_in6' | \
   sed -e 's/\([^a-zA-Z0-9_]\)_timeval\([^a-zA-Z0-9_]\)/\1timeval\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_timeval$/\1timeval/g' \
   -e 's/\([^a-zA-Z0-9_]\)_timespec_t\([^a-zA-Z0-9_]\)/\1timespec\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_timespec_t$/\1timespec_t/g' \
   -e 's/\([^a-zA-Z0-9_]\)_timespec\([^a-zA-Z0-9_]\)/\1timespec\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_timespec$/\1timespec/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_in6_addr\([^a-zA-Z0-9_]\)/\1[16]byte\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_in6_addr$/\1[16]byte/g' \
 >> ${OUT}
 
 # The C long type, needed because that is the type that ptrace returns.
@@ -44,16 +49,6 @@ else
   exit 1
 fi
 
-# On AIX, the _arpcom struct, is filtered by the above grep sequence, as it as
-# a field of type _in6_addr, but other types depend on _arpcom, so we need to
-# put it back.
-grep '^type _arpcom ' gen-sysinfo.go | \
-  sed -e 's/_in6_addr/[16]byte/' >> ${OUT}
-
-# Same on Solaris for _mld_hdr_t.
-grep '^ty

Re: [PATCH] Fix _GLIBCXX_DEBUG tests

[Jonathan Wakely via Gcc-patches]

On 13/12/20 15:52 +0100, François Dumont via Libstdc++ wrote:
Some tests are XPASS because array assertions have been disabled for a 
good reason in C++11.


I wonder if the respective non-constexpr _GLIBCXX_ASSERTION checks 
shouldn't target C++14 too. At the moment they are failing as expected 
but because of an Undefined Behavior no ?


Hmm, maybe my "fix" for the bug was too hasty, and I should have done
this instead:

--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -684,7 +684,7 @@ namespace std
 
 #undef _GLIBCXX_HAS_BUILTIN
 
-#if _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED

+#if _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED && __cplusplus >= 201402L
 # define __glibcxx_assert_1(_Condition)\
 if (__builtin_is_constant_evaluated()) \
  { \

That would allow us to keep the std::array runtime assertions for
C++11, and only disable them in constexpr contexts.


The other test is failing because of some cleanup in headers which 
makes  include necessary.


    libstdc++: Fix several _GLIBCXX_DEBUG tests

    libstdc++-v3/ChangeLog:

            * testsuite/23_containers/array/debug/back2_neg.cc: target 
c++14 because assertion

            for constexpr is disabled in C++11.
            * testsuite/23_containers/array/debug/front2_neg.cc: 
Likewise.
            * 
testsuite/23_containers/array/debug/square_brackets_operator2_neg.cc: 
Likewise.
            * 
testsuite/23_containers/vector/debug/multithreaded_swap.cc: Include 


            for shared_ptr.

Ok to commit ?


Yes, thanks.

[PATCH] PR fortran/95372 - ICE in find_array_section, at fortran/expr.c:1687

[Harald Anlauf via Gcc-patches]

ICE on valid code.

Original patch by Steve, slightly adjusted and regtested on x86_64-pc-linux-gnu.

OK for master?  Backports?  Should be safe everywhere, as it replaces an assert
by an if condition.

Thanks,
Harald


PR fortran/95372 - ICE in find_array_section, at fortran/expr.c:1687

Fix handling of array references in array constructors.

gcc/fortran/ChangeLog:

PR fortran/95372
* expr.c (find_array_section): Replace assert into a conditional
construct.

gcc/testsuite/ChangeLog:

PR fortran/95372
* gfortran.dg/pr95372.f90: New test.

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index ae9b0a79474..4b0ca453968 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -1684,9 +1684,11 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
 	}

   cons = gfc_constructor_lookup (base, limit);
-  gcc_assert (cons);
-  gfc_constructor_append_expr (&expr->value.constructor,
-   gfc_copy_expr (cons->expr), NULL);
+  if (cons)
+	gfc_constructor_append_expr (&expr->value.constructor,
+ gfc_copy_expr (cons->expr), NULL);
+  else
+	t = false;
 }

   mpz_clear (ptr);
diff --git a/gcc/testsuite/gfortran.dg/pr95372.f90 b/gcc/testsuite/gfortran.dg/pr95372.f90
new file mode 100644
index 000..bedd2117c25
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr95372.f90
@@ -0,0 +1,14 @@
+! PR fortran/95372 - ICE in find_array_section, at fortran/expr.c:1687
+
+program p
+  type t
+ integer :: a = 1
+  end type t
+  type(t), parameter :: x(3) = t()
+  type(t):: u(3) = t()
+  type(t):: y(1), v(1)
+  y = [x(2:2)]
+  v = [u(2:2)]
+  if (any (y% a /= 1)) stop 1
+  if (any (v% a /= 1)) stop 2
+end

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Nikhil Benesch via Gcc-patches]

On 12/13/20 4:55 PM, Nikhil Benesch wrote:

There are a few more hurdles before this patch is ready for commit. The
changes to godump.c deserve new test cases. [...]


Updated patch attached, as promised, and is ready for review.

gcc/:
* godump.c (go_output_typedef): Suppress typedefs whose name
matches the tag of the underlying struct, union, or enum.
Output declarations for enums that do not appear in typedefs.
gcc/testsuite:
* gcc.misc-tests/godump-1.c: Add test cases.

I don't have write access, so whoever reviews, please commit if approved.

Nikhil
diff --git a/gcc/godump.c b/gcc/godump.c
index 033b2c59f3c..ff3a4a9c52c 100644
--- a/gcc/godump.c
+++ b/gcc/godump.c
@@ -1155,15 +1155,25 @@ go_output_typedef (class godump_container *container, 
tree decl)
 {
   void **slot;
   const char *type;
+  tree original_type;

   type = IDENTIFIER_POINTER (DECL_NAME (decl));
+  original_type = DECL_ORIGINAL_TYPE (decl);
+
+  /* Suppress typedefs where the type name matches the underlying
+struct/union/enum tag. This way we'll emit the struct definition
+instead of an invalid recursive type.  */
+  if (TYPE_IDENTIFIER (original_type) != NULL
+ && IDENTIFIER_POINTER (TYPE_IDENTIFIER (original_type)) == type)
+   return;
+
   /* If type defined already, skip.  */
   slot = htab_find_slot (container->type_hash, type, INSERT);
   if (*slot != NULL)
return;
   *slot = CONST_CAST (void *, (const void *) type);

-  if (!go_format_type (container, DECL_ORIGINAL_TYPE (decl), true, false,
+  if (!go_format_type (container, original_type, true, false,
   NULL, false))
{
  fprintf (go_dump_file, "// ");
@@ -1187,7 +1197,9 @@ go_output_typedef (class godump_container *container, 
tree decl)

   container->decls_seen.add (decl);
 }
-  else if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (decl)))
+  else if ((RECORD_OR_UNION_TYPE_P (TREE_TYPE (decl))
+   || TREE_CODE (TREE_TYPE (decl)) == ENUMERAL_TYPE)
+  && TYPE_NAME (TREE_TYPE (decl)) != NULL)
 {
void **slot;
const char *type;
diff --git a/gcc/testsuite/gcc.misc-tests/godump-1.c 
b/gcc/testsuite/gcc.misc-tests/godump-1.c
index 96c25863374..d37ab0b5af4 100644
--- a/gcc/testsuite/gcc.misc-tests/godump-1.c
+++ b/gcc/testsuite/gcc.misc-tests/godump-1.c
@@ -396,6 +396,15 @@ typedef enum { ET1, ET2 } et_t;
 /* { dg-final { scan-file godump-1.out "(?n)^const _ET1 = 0$" } } */
 /* { dg-final { scan-file godump-1.out "(?n)^const _ET2 = 1$" } } */

+typedef enum e_t_idem_v1 { ETIV1 } e_t_idem_v1;
+/* { dg-final { scan-file godump-1.out "(?n)^type _e_t_idem_v1 u?int\[0-9\]*$" 
} } */
+/* { dg-final { scan-file godump-1.out "(?n)^const _ETIV1 = 0$" } } */
+
+typedef enum e_t_idem_v2 e_t_idem_v2;
+enum e_t_idem_v2 { ETIV2 };
+/* { dg-final { scan-file godump-1.out "(?n)^type _e_t_idem_v2 u?int\[0-9\]*$" 
} } */
+/* { dg-final { scan-file godump-1.out "(?n)^const _ETIV2 = 0$" } } */
+
 enum { ETV1, ETV2 } et_v1;
 /* { dg-final { scan-file godump-1.out "(?n)^var _et_v1 u?int\[0-9\]*$" } } */
 /* { dg-final { scan-file godump-1.out "(?n)^const _ETV1 = 0$" } } */
@@ -477,6 +486,13 @@ struct s_fwd v_fwd;
 struct s_fwd { };
 /* { dg-final { scan-file godump-1.out "(?n)^type _s_fwd struct \{ \}$" } } */

+typedef struct s_t_idem_v1 {} s_t_idem_v1;
+/* { dg-final { scan-file godump-1.out "(?n)^type _s_t_idem_v1 struct \{ \}$" 
} } */
+
+typedef struct s_t_idem_v2 s_t_idem_v2;
+struct s_t_idem_v2 { };
+/* { dg-final { scan-file godump-1.out "(?n)^type _s_t_idem_v2 struct \{ \}$" 
} } */
+
 /*** nested structs ***/
 typedef struct { struct { uint8_t ca[3]; } s; uint32_t i; } tsn;
 /* { dg-final { scan-file godump-1.out "(?n)^type _tsn struct \{ s struct \{ 
ca \\\[2\\+1\\\]uint8; \}; i uint32; \}$" } } */
@@ -756,6 +772,13 @@ typedef union { } tue;
 union { } ue;
 /* { dg-final { scan-file godump-1.out "(?n)^var _ue struct \{ \}$" } } */

+typedef union u_t_idem_v1 { } u_t_idem_v1;
+/* { dg-final { scan-file godump-1.out "(?n)^type _u_t_idem_v1 struct \{ \}$" 
} } */
+
+typedef union u_t_idem_v2 u_t_idem_v2;
+union u_t_idem_v2 { };
+/* { dg-final { scan-file godump-1.out "(?n)^type _u_t_idem_v2 struct \{ \}$" 
} } */
+
 typedef union { uint8_t c; uint64_t l; } tu1;
 /* { dg-final { scan-file godump-1.out "(?n)^type _tu1 struct \{ c uint8; 
Godump_0_pad \\\[.\\\]byte; Godump_1_align \\\[0\\\]u?int64; \}$" } } */

Re: [PATCH] add g_nonstandard_bool attribute for GIMPLE FE use

[Martin Sebor via Gcc-patches]

On 12/11/20 2:02 AM, Richard Biener wrote:

This adds __attribute__((g_nonstandard_bool(precision))) to be able
to construct nonstandard boolean types which for the included testcase
is needed to simulate Ada and LTO interaction (Ada uses a 8 bit
precision boolean_type_node).  This will also be useful for vector
unit testcases where we need to produce vector types with
non-standard boolean type components.

--

Joseph, is using attributes a good enough way to extend the set of C
types for use of the GIMPLE FE?  I chose to add a g_ prefix to
note use by the GIMPLE FE but since we can mix C and GIMPLE FE
functions in one TU those of course can leak into C functions
(and eventually lead to ICEs/issues there) - but the attribute is
simply ignored when not compiling with -fgimple.

I figured there's no documentation about GIMPLE FE "extensions",
I'll see to write something as followup (there's a small section
in sourcebuild.texi and the -fgimple docs itself).  I chose to
not document this attribute in the place we document attributes
supposed to be used in production.

OK for trunk?


"nonstandard" isn't a very descriptive name.  The leading g_ prefix
also looks a little too terse (is that supposed to stand dor GIMPLE?).
I would suggest choosing a better name, say, bool_precision.  Since
there's also a build_nonstandard_integer_type, if extending
the attribute to integers supported by the function could be similarly
useful then simply "precision" might be sufficient.

Martin



I'll push the actual vectorizer fix for PR95582 separately, this
patch is only "needed" to add a testcase for the PR.

Thanks,
Richard.

2020-12-11  Richard Biener  

PR tree-optimization/95582
gcc/c-family/
* c-attribs.c (c_common_attribute_table): Add entry for
g_nonstandard_bool.
(handle_g_nonstandard_bool_attribute): New.

gcc/testsuite/
* gcc.dg/pr95582.c: New testcase.
---
  gcc/c-family/c-attribs.c   | 41 ++
  gcc/testsuite/gcc.dg/pr95582.c | 19 
  2 files changed, 60 insertions(+)
  create mode 100644 gcc/testsuite/gcc.dg/pr95582.c

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index f7dad7a91d7..be3009865b1 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -161,6 +161,8 @@ static tree handle_copy_attribute (tree *, tree, tree, int, 
bool *);
  static tree handle_nsobject_attribute (tree *, tree, tree, int, bool *);
  static tree handle_objc_root_class_attribute (tree *, tree, tree, int, bool 
*);
  static tree handle_objc_nullability_attribute (tree *, tree, tree, int, bool 
*);
+static tree handle_g_nonstandard_bool_attribute (tree *, tree, tree, int,
+bool *);
  
  /* Helper to define attribute exclusions.  */

  #define ATTR_EXCL(name, function, type, variable) \
@@ -274,6 +276,8 @@ const struct attribute_spec c_common_attribute_table[] =
  {
/* { name, min_len, max_len, decl_req, type_req, fn_type_req,
 affects_type_identity, handler, exclude } */
+  { "g_nonstandard_bool", 1, 1, false, true, false, true,
+ handle_g_nonstandard_bool_attribute, NULL },
{ "packed", 0, 0, false, false, false, false,
  handle_packed_attribute,
  attr_aligned_exclusions },
@@ -894,6 +898,43 @@ validate_attr_arg (tree node[2], tree name, tree newarg)
  
  /* Attribute handlers common to C front ends.  */
  
+/* Handle a "g_nonstandard_bool" attribute; arguments as in

+   struct attribute_spec.handler.  */
+
+static tree
+handle_g_nonstandard_bool_attribute (tree *node, tree name, tree args,
+int ARG_UNUSED (flags), bool *no_add_attrs)
+{
+  *no_add_attrs = true;
+  if (!flag_gimple)
+{
+  warning (OPT_Wattributes, "%qE attribute ignored", name);
+  return NULL_TREE;
+}
+
+  if (!TYPE_P (*node) || TREE_CODE (*node) != BOOLEAN_TYPE)
+{
+  warning (OPT_Wattributes, "%qE attribute only supported on "
+  "boolean types", name);
+  return NULL_TREE;
+}
+
+  unsigned HOST_WIDE_INT prec = HOST_WIDE_INT_M1U;
+  if (tree_fits_uhwi_p (TREE_VALUE (args)))
+prec = tree_to_uhwi (TREE_VALUE (args));
+  if (prec > MAX_FIXED_MODE_SIZE)
+{
+  warning (OPT_Wattributes, "%qE attribute with unsupported boolean "
+  "precision", name);
+  return NULL_TREE;
+}
+
+  tree new_type = build_nonstandard_boolean_type (prec);
+  *node = lang_hooks.types.reconstruct_complex_type (*node, new_type);
+
+  return NULL_TREE;
+}
+
  /* Handle a "packed" attribute; arguments as in
 struct attribute_spec.handler.  */
  
diff --git a/gcc/testsuite/gcc.dg/pr95582.c b/gcc/testsuite/gcc.dg/pr95582.c

new file mode 100644
index 000..cba3354557b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr95582.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-fgimple -O3" 

Re: [C PATCH] Avoid incorrect warning for volatile in compound expressions [PR 98260]

[Martin Sebor via Gcc-patches]

On 12/13/20 9:12 AM, Uecker, Martin wrote:

Here is a patch that fixes an incorrect warning for volatile
that appeared with the lvalue change.


It's helpful to mention the bug id in the first line of the regression
tests committed with the fix.  (No need to repost the patch just with
that change.)

Martin




-- Martin

C: Avoid incorrect warning for volatile in compound expressions [PR98260]
 
2020-12-12  Martin Uecker  
 
gcc/c/

  PR c/98260
  * c-parser.c (c_parser_expression): Look into
  nop expression when marking expressions as read.

gcc/testsuite/
  PR c/98260
  * gcc.dg/unused-9.c: New test.


diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 87ee8f47806..1388a60c495 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -10615,8 +10615,14 @@ c_parser_expression (c_parser *parser)
    c_parser_consume_token (parser);
    expr_loc = c_parser_peek_token (parser)->location;
    lhsval = expr.value;
-  while (TREE_CODE (lhsval) == COMPOUND_EXPR)
-   lhsval = TREE_OPERAND (lhsval, 1);
+  while (TREE_CODE (lhsval) == COMPOUND_EXPR
+    || TREE_CODE (lhsval) == NOP_EXPR)
+   {
+     if (TREE_CODE (lhsval) == COMPOUND_EXPR)
+   lhsval = TREE_OPERAND (lhsval, 1);
+     else
+   lhsval = TREE_OPERAND (lhsval, 0);
+   }
    if (DECL_P (lhsval) || handled_component_p (lhsval))
    mark_exp_read (lhsval);
    next = c_parser_expr_no_commas (parser, NULL);
diff --git a/gcc/testsuite/gcc.dg/unused-9.c b/gcc/testsuite/gcc.dg/unused-9.c
new file mode 100644
index 000..b32f7ef6c03
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/unused-9.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-Wunused" } */
+
+
+void g(void)
+{
+  int i = 0;
+  volatile int x;
+  (x, i++);/* { dg-bogus "set but not used" } */
+}
+
+

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Thu, 10 Dec 2020 at 15:57, abebeos 
wrote:

>
>
> Στις Πέμ, 10 Δεκ 2020 στις 7:42 π.μ., ο/η Dimitar Dimitrov <
> dimi...@dinux.eu> έγραψε:
>
>> On сряда, 9 декември 2020 г. 15:12:49 EET abebeos via Gcc-patches wrote:
>> > Essence:
>> >
>> > I need a confirmation that the testsuite setup as presented in:
>> >
>> > https://github.com/abebeos/avr-gnu
>> >
>> > works fine.
>> >
>> > The problem with the avr target is that the testsuite cannot be run
>> easily,
>> > mainly because of the need for a special simulated-target setup, which
>> does
>> > not work for avr as documented. This led developers to a dead-end with
>> > their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is
>> not
>> > dropped from gcc11).
>> >
>> > I integrated a toolchain/testsetup to be able to run the gcc testsuite
>> > against a simulated avr target.
>> >
>> > I then used this toolchain to test 2 different existent
>> > non-cc0-avr-backends (from pipcet and saaadhu, both github).
>> >
>> > The result is that saaadhu's backend seems to be working 100%. It has
>> > identical testsuite results with the existing (but deprecated)
>> cc0-backend,
>> > which means that it can be used "as-is" for inclusion in gcc11.
>> >
>> > Please note that I did this work in context of a bounty @ bountysouce,
>> more
>> > information within the issue:
>> >
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
>> Hi,
>>
>> I tested the trees you have given with my own AVR test setup [1]. I
>> confirm
>> your results:
>>   - saaadhu's tree does not introduce any regressions.
>>
>
> ok
>
>   - pipcet's tree has 142 gcc and 299 g++ regressions (although many of
>> them
>> are duplicates, e.g. same test case with different optimization
>> levels).
>>
>> It's a bit awkward to copy gcc/config/avr into a mainline tree
>
>
> Possibly a matter of preference, but when I'm insecure, I prefer low-level
> ops (e.g. filesystem).
>
>
>> Looking at their github history, both authors made some small changes in
>> other areas.
>
>
> saaadhu has one change, already in upstream:
> https://github.com/saaadhu/gcc-avr-cc0/issues/1
>
> I don't remember why choose to ignored the 2 changes (outside
> gcc/config/avr) of pipcet's.
>
> I'll repeat the test-run later with the two files recreated.
>

3 files are changed outside config/avr.

testresults are the same on my side (applying / not applying the 3
additional patches).


>
> I would have prefered to cherry-pick or apply patches.
>>
> [...]
>

I added the patches:

https://github.com/abebeos/avr-gnu/tree/master/patches

 (see comment in cp-avr-*  : "#TD: nonsense script, use a direct git
> checkout")
>
> https://github.com/dinuxbg/gnupru/blob/master/testing/buildbot-avr.sh
>>
>
> Nice one, this is kind of what I was asking for within
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c11
>
> before going on to integrate an own one.
>
> But the main thing is anyways:
>
> " - saaadhu's tree does not introduce any regressions"
>
>
>
>
>

Re: [PATCH] Fix _GLIBCXX_DEBUG tests

[François Dumont via Gcc-patches]

On 13/12/20 11:17 pm, Jonathan Wakely wrote:

On 13/12/20 15:52 +0100, François Dumont via Libstdc++ wrote:
Some tests are XPASS because array assertions have been disabled for 
a good reason in C++11.


I wonder if the respective non-constexpr _GLIBCXX_ASSERTION checks 
shouldn't target C++14 too. At the moment they are failing as 
expected but because of an Undefined Behavior no ?


Hmm, maybe my "fix" for the bug was too hasty, and I should have done
this instead:

--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -684,7 +684,7 @@ namespace std

 #undef _GLIBCXX_HAS_BUILTIN

-#if _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED
+#if _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED && __cplusplus >= 
201402L

 # define __glibcxx_assert_1(_Condition)    \
 if (__builtin_is_constant_evaluated()) \
  { \

That would allow us to keep the std::array runtime assertions for
C++11, and only disable them in constexpr contexts.


I already tried to restore this check in C++11 runtime without success 
but I didn't try this approach.


I'll have a try but C++11 forces constexpr to be just a return statement 
so I fear that it won't appreciate the additional assertion.





The other test is failing because of some cleanup in headers which 
makes  include necessary.


    libstdc++: Fix several _GLIBCXX_DEBUG tests

    libstdc++-v3/ChangeLog:

            * 
testsuite/23_containers/array/debug/back2_neg.cc: target c++14 
because assertion

            for constexpr is disabled in C++11.
            * 
testsuite/23_containers/array/debug/front2_neg.cc: Likewise.
            * 
testsuite/23_containers/array/debug/square_brackets_operator2_neg.cc: 
Likewise.
            * 
testsuite/23_containers/vector/debug/multithreaded_swap.cc: Include 


            for shared_ptr.

Ok to commit ?


Yes, thanks.

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Ian Lance Taylor via Gcc-patches]

On Sun, Dec 13, 2020 at 3:30 PM Nikhil Benesch  wrote:
>
> On 12/13/20 4:55 PM, Nikhil Benesch wrote:
> > There are a few more hurdles before this patch is ready for commit. The
> > changes to godump.c deserve new test cases. [...]
>
> Updated patch attached, as promised, and is ready for review.
>
> gcc/:
> * godump.c (go_output_typedef): Suppress typedefs whose name
> matches the tag of the underlying struct, union, or enum.
> Output declarations for enums that do not appear in typedefs.
> gcc/testsuite:
> * gcc.misc-tests/godump-1.c: Add test cases.
>
> I don't have write access, so whoever reviews, please commit if approved.

Thanks.  Committed.

Ian