[PATCH] Fix _Pragma GCC diagnostic in macro expansions

[Bernd Edlinger]

Hi,

currently _Pragma("GCC diagnostic ...") does not properly
work in macro expansions.

Consider the following code:

#define B _Pragma("GCC diagnostic push") \
  _Pragma("GCC diagnostic ignored \"-Wattributes\"")
#define E _Pragma("GCC diagnostic pop")

#define X() B int __attribute((unknown_attr)) x; E /* { dg-bogus "attribute 
directive ignored" } */

void test1(void)
{
X()  /* { dg-bogus "in expansion of macro" } */
}


Warnings happen in C++ despite the _Pragma, while C happens to suppress the 
warnings
more or less by accident.

This is connected to the fact that GCC uses the location of the closing 
parenthesis of the
function-like macro expansion in the _Pragma, while the rest of the locations 
are relative
to the macro expansion point, which is the letter X in this case.

This patch changes the location of builtin macros and _Pragma to use the macro 
expansion
point instead of the closing parenthesis.

A few test cases had to be adjusted, most changes were necessary because the 
__LINE__
location moved to the macro expansion point, which looks like a straight 
improvement.

In pr61817-2.c the location of __LINE__ depends on -ftrack-macro-expansion,
when enabled the location of the macro argument is the spelling location, while 
all other
locations change to the macro expansion point.

The C++ pagma plugin.c is also affected by the change, because the 
input_location is now
the spelling location of _Pragma in DO_PRAGMA and has to be converted to the 
expansion
point of the macro to get the expected result.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.libcpp:
2018-07-04  Bernd Edlinger  

* macro.c (enter_macro_context): Change the location info for builtin
macros from location of the closing parenthesis to location of the macro
expansion point.

testsuite:
2018-07-04  Bernd Edlinger  

* c-c++-common/cpp/diagnostic-pragma-2.c: New test.
* c-c++-common/pr69558.c: Remove xfail.
* gcc.dg/cpp/builtin-macro-1.c: Adjust test expectations.
* gcc.dg/pr61817-1.c: Likewise.
* gcc.dg/pr61817-2.c: Likewise.
* g++.dg/plugin/pragma_plugin.c: Warn at expansion_point_location.
Index: gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-2.c
===
--- gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-2.c	(revision 0)
+++ gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-2.c	(working copy)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+
+#define B _Pragma("GCC diagnostic push") \
+	  _Pragma("GCC diagnostic ignored \"-Wattributes\"")
+#define E _Pragma("GCC diagnostic pop")
+
+#define X() B int __attribute((unknown_attr)) x; E /* { dg-bogus "attribute directive ignored" } */
+#define Y   B int __attribute((unknown_attr)) y; E /* { dg-bogus "attribute directive ignored" } */
+
+void test1(void)
+{
+X()  /* { dg-bogus "in expansion of macro" } */
+Y/* { dg-bogus "in expansion of macro" } */
+}
Index: gcc/testsuite/c-c++-common/pr69558.c
===
--- gcc/testsuite/c-c++-common/pr69558.c	(revision 262287)
+++ gcc/testsuite/c-c++-common/pr69558.c	(working copy)
@@ -11,9 +11,9 @@
   _Pragma ("GCC diagnostic pop")
 #define C(x) \
   A \
-  static inline void bar (void) { x (); } /* { dg-bogus "in definition of|deprecated" "" { xfail { c++ } } } */ \
+  static inline void bar (void) { x (); } /* { dg-bogus "in definition of|deprecated" "" } */ \
   B
 
-__attribute__((deprecated)) void foo (void); /* { dg-bogus "declared here" "" { xfail { c++ } } } */
+__attribute__((deprecated)) void foo (void); /* { dg-bogus "declared here" "" } */
 
 C (foo) /* { dg-bogus "is deprecated" } */
Index: gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c
===
--- gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c	(revision 262287)
+++ gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c	(working copy)
@@ -1,8 +1,8 @@
 /* Origin PR preprocessor/64803
 
This test ensures that the value the __LINE__ macro expands to is
-   constant and corresponds to the line of the closing parenthesis of
-   the top-most function-like macro expansion it's part of.
+   constant and corresponds to the line of the macro expansion point
+   the function-like macro expansion it's part of.
 
{ dg-do run }
{ do-options -no-integrated-cpp }  */
@@ -19,8 +19,8 @@
   M(a
 );
 
-  assert(L20 == 20);		/* 20 is the line number of the
-   closing parenthesis of the
+  assert(L19 == 19);		/* 19 is the line number of the
+   macro expansion point of the
    invocation of the M macro.  Please
    adjust i

[PING] [PATCH] Fix _Pragma GCC diagnostic in macro expansions

[Bernd Edlinger]

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00197.html

On 07/04/18 12:53, Bernd Edlinger wrote:
> Hi,
> 
> currently _Pragma("GCC diagnostic ...") does not properly
> work in macro expansions.
> 
> Consider the following code:
> 
> #define B _Pragma("GCC diagnostic push") \
> _Pragma("GCC diagnostic ignored \"-Wattributes\"")
> #define E _Pragma("GCC diagnostic pop")
> 
> #define X() B int __attribute((unknown_attr)) x; E /* { dg-bogus "attribute 
> directive ignored" } */
> 
> void test1(void)
> {
>  X()  /* { dg-bogus "in expansion of macro" } */
> }
> 
> 
> Warnings happen in C++ despite the _Pragma, while C happens to suppress the 
> warnings
> more or less by accident.
> 
> This is connected to the fact that GCC uses the location of the closing 
> parenthesis of the
> function-like macro expansion in the _Pragma, while the rest of the locations 
> are relative
> to the macro expansion point, which is the letter X in this case.
> 
> This patch changes the location of builtin macros and _Pragma to use the 
> macro expansion
> point instead of the closing parenthesis.
> 
> A few test cases had to be adjusted, most changes were necessary because the 
> __LINE__
> location moved to the macro expansion point, which looks like a straight 
> improvement.
> 
> In pr61817-2.c the location of __LINE__ depends on -ftrack-macro-expansion,
> when enabled the location of the macro argument is the spelling location, 
> while all other
> locations change to the macro expansion point.
> 
> The C++ pagma plugin.c is also affected by the change, because the 
> input_location is now
> the spelling location of _Pragma in DO_PRAGMA and has to be converted to the 
> expansion
> point of the macro to get the expected result.
> 
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 

[PATCH] Fix middle-end/86528

[Bernd Edlinger]

Hi,

this fixes PR middle-end/86528.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
gcc:
2018-07-04  Bernd Edlinger  

	PR middle-end/86528
	* builtins.c (check_access): Bail out if range[0] is no INTEGER_CST.
	* expr.c (string_constant): Fix the element size of ARRAY_TYPE.

testsuite:
2018-07-04  Bernd Edlinger  

	PR middle-end/86528
	* gcc.c-torture/execute/pr86528.c: New test.
	* gcc.dg/Wrestrict-10.c (test_arr_strcat_2): Fix typo.

--- /dev/null	2018-07-02 16:09:41.095282291 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr86528.c	2018-07-16 14:32:24.555426245 +0200
@@ -0,0 +1,20 @@
+/* PR middle-end/86528 */
+
+void __attribute__((noinline, noclone))
+test(char *data, __SIZE_TYPE__ len)
+{
+static char const appended[] = "/./";
+char *buf = __builtin_alloca (len + sizeof appended);
+__builtin_memcpy (buf, data, len);
+__builtin_strcpy (buf + len, &appended[data[len - 1] == '/']);
+if (__builtin_strcmp(buf, "test1234/./"))
+__builtin_abort();
+}
+
+int
+main()
+{
+   char *arg = "test1234/";
+   test(arg, __builtin_strlen(arg));
+   return 0;
+}
--- gcc/testsuite/gcc.dg/Wrestrict-10.c.jj	2018-05-16 04:30:38.0 +0200
+++ gcc/testsuite/gcc.dg/Wrestrict-10.c	2018-07-16 16:06:13.250852255 +0200
@@ -39,8 +39,7 @@ test_arr_strcat_1 (void)
 void __attribute__ ((noclone, noinline))
 test_arr_strcat_2 (void)
 {
-  /* This probably deserves a warning.  */
-  strcpy (b.a, &b.a[i]);
+  strcat (b.a, &b.a[i]);/* { dg-warning "\\\[-Wrestrict" } */
 }
 
 void __attribute__ ((noclone, noinline))
--- gcc/builtins.c.jj	2018-07-13 16:10:45.0 +0200
+++ gcc/builtins.c	2018-07-16 12:48:18.880896706 +0200
@@ -3192,6 +3192,10 @@ check_access (tree exp, tree, tree, tree
   if (dstwrite)
 get_size_range (dstwrite, range);
 
+  /* This can happen at -O0.  */
+  if (range[0] && TREE_CODE (range[0]) != INTEGER_CST)
+return false;
+
   tree func = get_callee_fndecl (exp);
 
   /* First check the number of bytes to be written against the maximum
--- gcc/expr.c.jj	2018-07-09 22:33:48.0 +0200
+++ gcc/expr.c	2018-07-16 13:18:03.433353514 +0200
@@ -11341,7 +11341,9 @@ string_constant (tree arg, tree *ptr_off
   tree offset = wide_int_to_tree (sizetype, base_off);
   if (varidx)
 {
-  if (tree eltsize = TYPE_SIZE_UNIT (TREE_TYPE (array)))
+  if (TREE_CODE (TREE_TYPE (array)) != ARRAY_TYPE)
+	return NULL_TREE;
+  if (tree eltsize = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (array
 	{
 	  /* Add the scaled variable index to the constant offset.  */
 	  tree eltoff = fold_build2 (MULT_EXPR, TREE_TYPE (offset),

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Bernd Edlinger]

  if (TREE_CODE (idx) != INTEGER_CST
  && TREE_CODE (argtype) == POINTER_TYPE)
{
  /* From a pointer (but not array) argument extract the variable
 index to prevent get_addr_base_and_unit_offset() from failing
 due to it.  Use it later to compute the non-constant offset
 into the string and return it to the caller.  */
  varidx = idx;
  ref = TREE_OPERAND (arg, 0);

  tree type = TREE_TYPE (arg);
  if (TREE_CODE (type) == ARRAY_TYPE
  && TREE_CODE (type) != INTEGER_TYPE)
return NULL_TREE;
}

the condition TREE_CODE(type) == ARRAY_TYPE
&& TREE_CODE (type) != INTEGER_TYPE looks funny.
Check for ARRAY_TYPE should imply != INTEGER_TYPE.

  else if (DECL_P (arg))
{
  array = arg;
  chartype = TREE_TYPE (arg);
}

chartype is only used in the if (varidx) block, but that is always zero
in this case.

  while (TREE_CODE (chartype) == ARRAY_TYPE
 || TREE_CODE (chartype) == POINTER_TYPE)
chartype = TREE_TYPE (chartype);

you multiply sizeof(chartype) with varidx but you should probably
use the type of the  TREE_OPERAND (arg, 0); above instead.

this is not in the patch, but I dont like it at all, because it compares the
size of a single initializer against the full size of the array.  But it should
be the innermost enclosing array:

  tree array_size = DECL_SIZE_UNIT (array);
  if (!array_size || TREE_CODE (array_size) != INTEGER_CST)
return NULL_TREE;

  /* Avoid returning a string that doesn't fit in the array
 it is stored in, like
 const char a[4] = "abcde";
 but do handle those that fit even if they have excess
 initializers, such as in
 const char a[4] = "abc\000\000";
 The excess elements contribute to TREE_STRING_LENGTH()
 but not to strlen().  */
  unsigned HOST_WIDE_INT length
= strnlen (TREE_STRING_POINTER (init), TREE_STRING_LENGTH (init));
  if (compare_tree_int (array_size, length + 1) < 0)
return NULL_TREE;

consider the following test case:
$ cat part.c
const char a[2][3][8] = { { "a", "bb", "ccc"},
  { "", "e", "ff" } };

int main ()
{
  int n = __builtin_strlen (&a[0][1][0]);

  if (n == 30)
__builtin_abort ();
}

11413 if (!init || TREE_CODE (init) != STRING_CST)
(gdb) call debug(init)
"bb"
(gdb) n
11416 tree array_size = DECL_SIZE_UNIT (array);
(gdb) n
11417 if (!array_size || TREE_CODE (array_size) != INTEGER_CST)
(gdb) call debug(array_size)
48
(gdb) n
11429   = strnlen (TREE_STRING_POINTER (init), TREE_STRING_LENGTH (init));
(gdb) n
11430 if (compare_tree_int (array_size, length + 1) < 0)
(gdb) n
11433 *ptr_offset = offset;
(gdb) 




Bernd.

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Bernd Edlinger]

> @@ -633,12 +642,17 @@ c_strlen (tree src, int only_value)
>   return ssize_int (0);
>  
>/* We don't know the starting offset, but we do know that the string
> -  has no internal zero bytes.  We can assume that the offset falls
> -  within the bounds of the string; otherwise, the programmer deserves
> -  what he gets.  Subtract the offset from the length of the string,
> -  and return that.  This would perhaps not be valid if we were dealing
> -  with named arrays in addition to literal string constants.  */
> -  return size_diffop_loc (loc, size_int (maxelts * eltsize), byteoff);
> +  has no internal zero bytes.  If the offset falls within the bounds
> +  of the string subtract the offset from the length of the string,
> +  and return that.  Otherwise the length is zero.  Take care to
> +  use SAVE_EXPR in case the OFFSET has side-effects.  */
> +  tree offsave = TREE_SIDE_EFFECTS (byteoff) ? save_expr (byteoff) : 
> byteoff;
> +  offsave = fold_convert (ssizetype, offsave);
> +  tree condexp = fold_build2_loc (loc, LE_EXPR, boolean_type_node, 
> offsave,
> +   build_int_cst (ssizetype, len * eltsize));
> +  tree lenexp = size_diffop_loc (loc, ssize_int (strelts * eltsize), 
> offsave);
> +  return fold_build3_loc (loc, COND_EXPR, ssizetype, condexp, lenexp,
> +   build_zero_cst (ssizetype));


This computes the number of bytes.
c_strlen is supposed to return number of (wide) characters:

/* Compute the length of a null-terminated character string or wide
character string handling character sizes of 1, 2, and 4 bytes.
TREE_STRING_LENGTH is not the right way because it evaluates to
the size of the character array in bytes (as opposed to characters)
and because it can contain a zero byte in the middle.


> @@ -11343,16 +11356,15 @@ string_constant (tree arg, tree *ptr_offset)
>  {
>if (TREE_CODE (TREE_TYPE (array)) != ARRAY_TYPE)
>   return NULL_TREE;
> -  if (tree eltsize = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (array
> - {
> -   /* Add the scaled variable index to the constant offset.  */
> -   tree eltoff = fold_build2 (MULT_EXPR, TREE_TYPE (offset),
> -  fold_convert (sizetype, varidx),
> -  eltsize);
> -   offset = fold_build2 (PLUS_EXPR, TREE_TYPE (offset), offset, eltoff);
> - }
> -  else
> - return NULL_TREE;
> +
> +  while (TREE_CODE (chartype) != INTEGER_TYPE)
> + chartype = TREE_TYPE (chartype);
> +
> +  /* Set the non-constant offset to the non-constant index scaled
> +  by the size of the character type.  */
> +  offset = fold_build2 (MULT_EXPR, TREE_TYPE (offset),
> + fold_convert (sizetype, varidx),
> + TYPE_SIZE_UNIT (chartype));

here you fix the computation for wide character strings,
but I see no test cases with wide character stings.

But down here you use a non-wide character function on a
wide character string:

   /* Avoid returning a string that doesn't fit in the array
  it is stored in, like
  const char a[4] = "abcde";
  but do handle those that fit even if they have excess
  initializers, such as in
  const char a[4] = "abc\000\000";
  The excess elements contribute to TREE_STRING_LENGTH()
  but not to strlen().  */
   unsigned HOST_WIDE_INT length
 = strnlen (TREE_STRING_POINTER (init), TREE_STRING_LENGTH (init));


Actually I begin to wonder, if all this wide character stuff is
really so common that we have to optimize it.
Same for the strlen(&a[0][i]), does this happen really so often that
it is a worth the risk?


Bernd.

[PATCH, obvious?] Some minor nits in string folding functions

[Bernd Edlinger]

Hi,


this fixes a few minor nits, which I spotted while
looking at the string folding functions:

string_constant: Remove impossible check: TREE_CODE (arg)
can't be COMPONENT_REF and MEM_REF at the same time.

c_strlen: maxelts is (signed) HOST_WIDE_INT, therefore
use tree_to_shwi.

c_getstr: tree_to_uhwi needs to be protected by
tree_fits_uhwi_p.

BTW: c_getstr uses string_constant which appears to be
able to extract wide char string initializers, but c_getstr
does not seem to be prepared for wide char strings:

   else if (string[string_length - 1] != '\0')
 {
   /* Support only properly NUL-terminated strings but handle
  consecutive strings within the same array, such as the six
  substrings in "1\0002\0003".  */
   return NULL;
 }


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
2018-07-19  Bernd Edlinger  

	* builtins.c (c_strlen): Use tree_to_shwi.
	* expr.c (string_constant): Remove impossible check.
	* fold-const.c (c_getstr): Use tree_fits_uhwi_p.

Index: gcc/builtins.c
===
--- gcc/builtins.c	(revision 262861)
+++ gcc/builtins.c	(working copy)
@@ -610,7 +610,7 @@ c_strlen (tree src, int only_value)
   tree type = TREE_TYPE (src);
   if (tree size = TYPE_SIZE_UNIT (type))
 if (tree_fits_shwi_p (size))
-  maxelts = tree_to_uhwi (size);
+  maxelts = tree_to_shwi (size);
 
   maxelts = maxelts / eltsize - 1;
 
Index: gcc/expr.c
===
--- gcc/expr.c	(revision 262861)
+++ gcc/expr.c	(working copy)
@@ -11371,11 +11371,6 @@ string_constant (tree arg, tree *ptr_offset)
 return NULL_TREE;
   if (TREE_CODE (init) == CONSTRUCTOR)
 {
-  if (TREE_CODE (arg) != ARRAY_REF
-	  && TREE_CODE (arg) == COMPONENT_REF
-	  && TREE_CODE (arg) == MEM_REF)
-	return NULL_TREE;
-
   /* Convert the 64-bit constant offset to a wider type to avoid
 	 overflow.  */
   offset_int wioff;
Index: gcc/fold-const.c
===
--- gcc/fold-const.c	(revision 262861)
+++ gcc/fold-const.c	(working copy)
@@ -14613,7 +14613,7 @@ c_getstr (tree src, unsigned HOST_WIDE_INT *strlen
   unsigned HOST_WIDE_INT string_size = string_length;
   tree type = TREE_TYPE (src);
   if (tree size = TYPE_SIZE_UNIT (type))
-if (tree_fits_shwi_p (size))
+if (tree_fits_uhwi_p (size))
   string_size = tree_to_uhwi (size);
 
   if (strlen)

Re: [PATCH, obvious?] Some minor nits in string folding functions

[Bernd Edlinger]

On 07/19/18 20:11, Jeff Law wrote:
> On 07/19/2018 12:04 PM, Bernd Edlinger wrote:
>> Hi,
>>
>>
>> this fixes a few minor nits, which I spotted while
>> looking at the string folding functions:
>>
>> string_constant: Remove impossible check: TREE_CODE (arg)
>> can't be COMPONENT_REF and MEM_REF at the same time.
> Shouldn't they all be != tests?  Though clearly this code isn't being
> tested by anything.
> 

I think a COMPONENT_REF would be possible for strlen(&a.b).
It looks like that removing this check will be the best option.
Unless Martin has a different idea of course.

> 
>>
>> c_strlen: maxelts is (signed) HOST_WIDE_INT, therefore
>> use tree_to_shwi.
> One could argue maxelts should be unsigned.
> 

I would agree, but a few lines later I see:

   /* Offset from the beginning of the string in elements.  */
   HOST_WIDE_INT eltoff;

   /* We have a known offset into the string.  Start searching there for
  a null character if we can represent it as a single HOST_WIDE_INT.  */
   if (byteoff == 0)
 eltoff = 0;
   else if (! tree_fits_shwi_p (byteoff))
 eltoff = -1;
   else
 eltoff = tree_to_shwi (byteoff) / eltsize;

   /* If the offset is known to be out of bounds, warn, and call strlen at
  runtime.  */
   if (eltoff < 0 || eltoff > maxelts)
 {

This would be doing signed/unsigned comparisons then.
Maybe that is the reason why ?

>>
>> c_getstr: tree_to_uhwi needs to be protected by
>> tree_fits_uhwi_p.
> Looks correct to me.
> 
> 
>>
>> BTW: c_getstr uses string_constant which appears to be
>> able to extract wide char string initializers, but c_getstr
>> does not seem to be prepared for wide char strings:
>>
>> else if (string[string_length - 1] != '\0')
>>   {
>> /* Support only properly NUL-terminated strings but handle
>>consecutive strings within the same array, such as the six
>>substrings in "1\0002\0003".  */
>> return NULL;
>>   }
> Seems like a goof to me.
> 

Well, maybe this could be a gcc_assert instead.  Normal strings should always
be zero-terminated, even wide character strings.
Anyways probably for another time.


Bernd.

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Bernd Edlinger]

On 07/19/18 22:03, Martin Sebor wrote:
> On 07/19/2018 07:23 AM, Bernd Edlinger wrote:
>>> @@ -633,12 +642,17 @@ c_strlen (tree src, int only_value)
>>>  return ssize_int (0);
>>>
>>>    /* We don't know the starting offset, but we do know that the string
>>> - has no internal zero bytes.  We can assume that the offset falls
>>> - within the bounds of the string; otherwise, the programmer deserves
>>> - what he gets.  Subtract the offset from the length of the string,
>>> - and return that.  This would perhaps not be valid if we were dealing
>>> - with named arrays in addition to literal string constants.  */
>>> -  return size_diffop_loc (loc, size_int (maxelts * eltsize), byteoff);
>>> + has no internal zero bytes.  If the offset falls within the bounds
>>> + of the string subtract the offset from the length of the string,
>>> + and return that.  Otherwise the length is zero.  Take care to
>>> + use SAVE_EXPR in case the OFFSET has side-effects.  */
>>> +  tree offsave = TREE_SIDE_EFFECTS (byteoff) ? save_expr (byteoff) : 
>>> byteoff;
>>> +  offsave = fold_convert (ssizetype, offsave);
>>> +  tree condexp = fold_build2_loc (loc, LE_EXPR, boolean_type_node, 
>>> offsave,
>>> +  build_int_cst (ssizetype, len * eltsize));
>>> +  tree lenexp = size_diffop_loc (loc, ssize_int (strelts * eltsize), 
>>> offsave);
>>> +  return fold_build3_loc (loc, COND_EXPR, ssizetype, condexp, lenexp,
>>> +  build_zero_cst (ssizetype));
>>
>>
>> This computes the number of bytes.
>> c_strlen is supposed to return number of (wide) characters:
> 
> You're right.  I guess that must mean the function isn't used
> for wide character strings.  The original code also computes
> a byte offset and so does the new expression.  I have no
> problem changing it, but if feels like a change that should
> be made independently of this bug fix.
> 
>>
>> /* Compute the length of a null-terminated character string or wide
>>     character string handling character sizes of 1, 2, and 4 bytes.
>>     TREE_STRING_LENGTH is not the right way because it evaluates to
>>     the size of the character array in bytes (as opposed to characters)
>>     and because it can contain a zero byte in the middle.
>>
>>
>>> @@ -11343,16 +11356,15 @@ string_constant (tree arg, tree *ptr_offset)
>>>  {
>>>    if (TREE_CODE (TREE_TYPE (array)) != ARRAY_TYPE)
>>>  return NULL_TREE;
>>> -  if (tree eltsize = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (array
>>> -    {
>>> -  /* Add the scaled variable index to the constant offset.  */
>>> -  tree eltoff = fold_build2 (MULT_EXPR, TREE_TYPE (offset),
>>> - fold_convert (sizetype, varidx),
>>> - eltsize);
>>> -  offset = fold_build2 (PLUS_EXPR, TREE_TYPE (offset), offset, eltoff);
>>> -    }
>>> -  else
>>> -    return NULL_TREE;
>>> +
>>> +  while (TREE_CODE (chartype) != INTEGER_TYPE)
>>> +    chartype = TREE_TYPE (chartype);
>>> +
>>> +  /* Set the non-constant offset to the non-constant index scaled
>>> + by the size of the character type.  */
>>> +  offset = fold_build2 (MULT_EXPR, TREE_TYPE (offset),
>>> +    fold_convert (sizetype, varidx),
>>> +    TYPE_SIZE_UNIT (chartype));
>>
>> here you fix the computation for wide character strings,
>> but I see no test cases with wide character stings.
> 
> The change above corrects the offset when eltsize refers to
> the size of an array rather than its character elements.
> It wasn't made to fix how wide strings are handled.  I don't
> know if the function is ever called for them in a way that
> matters (there are no wide character built-ins).  But it's
> something to look into.
> 

Now I am suprised.
your loop above locates always an INTEGER_TYPE,
in the later version it skips all ARRAY_TYPES,
So TYPE_SIZE_UNIT is never the size of an array,
it is always the element type (char, wchar_t, int *)
that the array is made of.
So you compute offset = varidx * sizeof(char)
but sizeof (char) is 1, so I thought naturally
you are concerned about sizeof(wchar_t).

And indeed I can write strlen((char*) & L"test"[i]).


>>
>> But down here you use a non-wide character function on a
>> wide character string:
>>
>>    /* Avoid returning a string that do

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Bernd Edlinger]

>@@ -11413,8 +11429,10 @@ string_constant (tree arg, tree *ptr_offset)
>  const char a[4] = "abc\000\000";
>  The excess elements contribute to TREE_STRING_LENGTH()
>  but not to strlen().  */
>-  unsigned HOST_WIDE_INT length
>-= strnlen (TREE_STRING_POINTER (init), TREE_STRING_LENGTH (init));
>+  unsigned HOST_WIDE_INT charsize
>+= tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (init;
>+  unsigned HOST_WIDE_INT length = TREE_STRING_LENGTH (init);
>+  length = string_length (TREE_STRING_POINTER (init), charsize, length);
>   if (compare_tree_int (array_size, length + 1) < 0)
> return NULL_TREE;

But TREE_STRING_LENGTH is the length in bytes including NUL-termination.
then length is passed to string_length with expects it in units of charsize.
and returns number of characters.
then compare_tree_int compares array_size which is in units of bytes,
but not the size of the innermost enclosing array.

I really don't see why we need to support wide characters especially
when there is no reasonable test coverage, and no usable wstrlen
builtin first.


Bernd.

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Bernd Edlinger]

>@@ -605,14 +605,21 @@ c_strlen (tree src, int only_value)
> 
>   /* Set MAXELTS to sizeof (SRC) / sizeof (*SRC) - 1, the maximum possible
>  length of SRC.  Prefer TYPE_SIZE() to TREE_STRING_LENGTH() if possible
>- in case the latter is less than the size of the array.  */
>-  HOST_WIDE_INT maxelts = TREE_STRING_LENGTH (src);
>+ in case the latter is less than the size of the array, such as when
>+ SRC refers to a short string literal used to initialize a large array.
>+ In that case, the elements of the array after the terminating NUL are
>+ all NUL.  */
>+  HOST_WIDE_INT strelts = TREE_STRING_LENGTH (src);
>+  strelts = strelts / eltsize - 1;
>+
>+  HOST_WIDE_INT maxelts = strelts;
>   tree type = TREE_TYPE (src);
>   if (tree size = TYPE_SIZE_UNIT (type))
> if (tree_fits_shwi_p (size))

If you already touch this area, please make at least the tree_fits_ and 
tree_to_ consistent.

>-  maxelts = tree_to_uhwi (size);
>-
>-  maxelts = maxelts / eltsize - 1;
>+  {
>+  maxelts = tree_to_uhwi (size);
>+  maxelts = maxelts / eltsize - 1;
>+  }
> 
>   /* PTR can point to the byte representation of any string type, including
>  char* and wchar_t*.  */
>@@ -620,10 +627,12 @@ c_strlen (tree src, int only_value)
> 
>   if (byteoff && TREE_CODE (byteoff) != INTEGER_CST)
> {

Please don't go into this if block, when eltsize != 1, the folding as it stands 
is
incorrect for eltsize != 1.

>-  /* If the string has an internal zero byte (e.g., "foo\0bar"), we can't
>-   compute the offset to the following null if we don't know where to
>+  /* If the string has an internal NUL character followed by any
>+   non-NUL characters (e.g., "foo\0bar"), we can't compute
>+   the offset to the following NUL if we don't know where to
>start searching for it.  */
>-  if (string_length (ptr, eltsize, maxelts) < maxelts)
>+  unsigned len = string_length (ptr, eltsize, strelts);
>+  if (len < strelts)
>   {

>> I really don't see why we need to support wide characters especially
>> when there is no reasonable test coverage, and no usable wstrlen
>> builtin first.
>
>I'm not sure what special support are you talking about.
>The string_constant function handles all kinds of strings
>and the change above doesn't affect that.  The purpose of
>the check above is to conservatively fail for constant
>arrays with excess initializers such as in the comment:
>
> const char a[4] = "abc\000\000";

Yes, fine, but as I said, conservative is not folding stuff that
is too complicated, for instance for the variable index case
_together_ with wide character strings.

Out of curiosity: how often have you seen existing code
to use strlen(&a[i]) and similar?  I know emacs (pr86528),
but how common is that code do you have numbers?



Bernd.

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Bernd Edlinger]

>   if (TREE_CODE (arg) == ADDR_EXPR)
> {
>+  tree argtype = TREE_TYPE (arg);
>+  chartype = argtype;

This assignment should be unnecessary here.  Right?

>+
>   arg = TREE_OPERAND (arg, 0);
>   tree ref = arg;
>   if (TREE_CODE (arg) == ARRAY_REF)
>   {
> tree idx = TREE_OPERAND (arg, 1);
>-if (TREE_CODE (idx) != INTEGER_CST)
>+if (TREE_CODE (idx) != INTEGER_CST
>+&& TREE_CODE (argtype) == POINTER_TYPE)

What else could the type of an ADDR_EXPR be?
argtype is TREE_TYPE(arg).
Do you have a test case where TREE_CODE(argtype) is not POINTER_TYPE?


Bernd.

[PATCH] Don't create non zero terminated string constant

[Bernd Edlinger]

Hi!

This fixes a not NUL terminated STRING_CST object.

Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
2018-07-20  Bernd Edlinger  

* gimple-fold.c (gimple_fold_builtin_printf): Don't create a not NUL
	terminated STRING_CST object.


--- gimple-fold.c.jj	2018-07-20 11:59:42.384727747 +0200
+++ gimple-fold.c	2018-07-20 12:19:45.195342409 +0200
@@ -3433,23 +3433,13 @@ gimple_fold_builtin_printf (gimple_stmt_
 	  && (int) len > 0)
 	{
 	  char *newstr;
-	  tree offset_node, string_cst;
 
 	  /* Create a NUL-terminated string that's one char shorter
 		 than the original, stripping off the trailing '\n'.  */
-	  newarg = build_string_literal (len, str);
-	  string_cst = string_constant (newarg, &offset_node);
-	  gcc_checking_assert (string_cst
-   && (TREE_STRING_LENGTH (string_cst)
-   == (int) len)
-   && integer_zerop (offset_node)
-   && (unsigned char)
-  TREE_STRING_POINTER (string_cst)[len - 1]
-  == target_newline);
-	  /* build_string_literal creates a new STRING_CST,
-		 modify it in place to avoid double copying.  */
-	  newstr = CONST_CAST (char *, TREE_STRING_POINTER (string_cst));
+	  newstr = xstrdup (str);
 	  newstr[len - 1] = '\0';
+	  newarg = build_string_literal (len, newstr);
+	  free (newstr);
 	  if (fn_puts)
 		{
 		  gcall *repl = gimple_build_call (fn_puts, 1, newarg);

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Bernd Edlinger]

Martin,

when I look at tree-ssa-forwprop.c:

   str1 = string_constant (src1, &off1);
   if (str1 == NULL_TREE)
 break;
   if (!tree_fits_uhwi_p (off1)
   || compare_tree_int (off1, TREE_STRING_LENGTH (str1) - 1) > 0
   || compare_tree_int (len1, TREE_STRING_LENGTH (str1)
  - tree_to_uhwi (off1)) > 0
   || TREE_CODE (TREE_TYPE (str1)) != ARRAY_TYPE
   || TYPE_MODE (TREE_TYPE (TREE_TYPE (str1)))
  != TYPE_MODE (char_type_node))
 break;

I don't think it is a good idea to let string_constant return
strings which have not necessarily valid content after the first
NUL byte.  It looks like the content has to be valid up to
TREE_STRING_LENGTH.

So may I suggest to do something like the following
(diff to your last patch):

--- expr.c.jj   2018-07-20 10:51:51.983605588 +0200
+++ expr.c  2018-07-20 15:07:29.769423479 +0200
@@ -11277,6 +11277,7 @@ tree
  string_constant (tree arg, tree *ptr_offset)
  {
tree array;
+  tree array_size;
STRIP_NOPS (arg);
  
/* Non-constant index into the character array in an ARRAY_REF
@@ -11295,9 +11296,11 @@ string_constant (tree arg, tree *ptr_off
  
arg = TREE_OPERAND (arg, 0);
tree ref = arg;
+  tree reftype = TREE_TYPE (ref);
if (TREE_CODE (arg) == ARRAY_REF)
{
  tree idx = TREE_OPERAND (arg, 1);
+ reftype = TREE_TYPE (TREE_OPERAND (arg, 0));
  if (TREE_CODE (idx) != INTEGER_CST
  && TREE_CODE (argtype) == POINTER_TYPE)
{
@@ -11313,6 +11316,11 @@ string_constant (tree arg, tree *ptr_off
return NULL_TREE;
}
}
+  if (TREE_CODE (reftype) != ARRAY_TYPE)
+   return NULL_TREE;
+  while (TREE_CODE (TREE_TYPE (reftype)) == ARRAY_TYPE)
+   reftype = TREE_TYPE (reftype);
+  array_size = TYPE_SIZE_UNIT (reftype);
array = get_addr_base_and_unit_offset (ref, &base_off);
if (!array
  || (TREE_CODE (array) != VAR_DECL
@@ -11345,7 +11353,10 @@ string_constant (tree arg, tree *ptr_off
return NULL_TREE;
  }
else if (DECL_P (arg))
-array = arg;
+{
+  array = arg;
+  array_size = DECL_SIZE_UNIT (array);
+}
else
  return NULL_TREE;
  
@@ -11410,24 +11421,18 @@ string_constant (tree arg, tree *ptr_off
if (!init || TREE_CODE (init) != STRING_CST)
  return NULL_TREE;
  
-  tree array_size = DECL_SIZE_UNIT (array);
if (!array_size || TREE_CODE (array_size) != INTEGER_CST)
  return NULL_TREE;
  
/* Avoid returning a string that doesn't fit in the array
- it is stored in, like
+ it is stored in, like:
   const char a[4] = "abcde";
- but do handle those that fit even if they have excess
- initializers, such as in
- const char a[4] = "abc\000\000";
- The excess elements contribute to TREE_STRING_LENGTH()
- but not to strlen().  */
-  unsigned HOST_WIDE_INT charsize
-= tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (init;
+ ... or:
+ const char a[4] = "abc\000";
+ ... because some callers access the string up to the limit
+ imposed by TREE_STRING_LENGTH.  */
unsigned HOST_WIDE_INT length = TREE_STRING_LENGTH (init);
-  length = string_length (TREE_STRING_POINTER (init), charsize,
- length / charsize);
-  if (compare_tree_int (array_size, length + 1) < 0)
+  if (compare_tree_int (array_size, length) < 0)
  return NULL_TREE;
  
*ptr_offset = offset;


Considering Richard's last comment, I don't know if TYPE_SIZE_UNIT
of the ARRAY_TYPE is the correct way to get the size of the
innermost arrayhere, but I think we will need it.



Bernd.

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Bernd Edlinger]

I think I have found a valid test case where the latest patch
does generate invalid code:

$ cat part.c
static const char a[3][8] = { "1234", "12345", "123456" };

int main ()
{
   volatile int i = 1;
   int n = __builtin_strlen (*(&a[1]+i));

   if (n != 6)
 __builtin_abort ();
}
$ gcc part.c -fdump-tree-original
$ ./a.out
Aborted (core dumped)
$ cat part.c.004t.original

;; Function main (null)
;; enabled by -tree-original


{
   volatile int i = 1;
   int n = (ssizetype) (SAVE_EXPR <(long unsigned int) i * 8>) <= 5 ? (int) (5 
- (unsigned int) (SAVE_EXPR <(long unsigned int) i * 8>)) : 0;

 volatile int i = 1;
 int n = (ssizetype) (SAVE_EXPR <(long unsigned int) i * 8>) <= 5 ? (int) 
(5 - (unsigned int) (SAVE_EXPR <(long unsigned int) i * 8>)) : 0;
   if (n != 6)
 {
   __builtin_abort ();
 }
}
return 0;


string_constant is called with arg = (const char *) (&a[1] + (sizetype) ((long 
unsigned int) i * 8))



Bernd.

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Bernd Edlinger]

On 07/21/18 00:15, Martin Sebor wrote:
> On 07/20/2018 08:51 AM, Bernd Edlinger wrote:
>> Martin,
>>
>> when I look at tree-ssa-forwprop.c:
>>
>>    str1 = string_constant (src1, &off1);
>>    if (str1 == NULL_TREE)
>>  break;
>>    if (!tree_fits_uhwi_p (off1)
>>    || compare_tree_int (off1, TREE_STRING_LENGTH (str1) - 1) 
>> > 0
>>    || compare_tree_int (len1, TREE_STRING_LENGTH (str1)
>>   - tree_to_uhwi (off1)) > 0
>>    || TREE_CODE (TREE_TYPE (str1)) != ARRAY_TYPE
>>    || TYPE_MODE (TREE_TYPE (TREE_TYPE (str1)))
>>   != TYPE_MODE (char_type_node))
>>  break;
>>
>> I don't think it is a good idea to let string_constant return
>> strings which have not necessarily valid content after the first
>> NUL byte.  It looks like the content has to be valid up to
>> TREE_STRING_LENGTH.
> 
> I'm not sure I understand when this could happen.  From the patch
> below it sounds like you are concerned about cases like:
> 
>    const char a[4] = "abc\000\000";
> 
> where the STRING_CST is bigger than the array.  But the string
> constant has valid content here up to TREE_STRING_LENGTH.  Am
> I missing something?  (A test case would be helpful.)
> 

No, I mean something like:

$ cat y.c
const char a[2][3] = { "1234", "xyz" };
char b[6];

int main ()
{
   __builtin_memcpy(b, a, 4);
   __builtin_memset(b + 4, 'a', 2);
   __builtin_printf("%.6s\n", b);
}
$ gcc y.c
y.c:1:24: warning: initializer-string for array of chars is too long
  const char a[2][3] = { "1234", "xyz" };
 ^~
y.c:1:24: note: (near initialization for 'a[0]')
$ ./a.out
1234aa

but expected would be "123xaa".


> In any case, unless the concern is specifically related to
> this bug fix let's discuss it separately so I can fix this
> bug.  I'm not opposed to making further changes here (in
> fact, I have one in the queue and two others that I raised
> in Bugzilla in response to our discussion so far), I just
> want to avoid mission creep.
> 

I think when you touch a function you should fix it completely
or restrict it to the subset that is known to be safe, and not
leave lots of already known bugs behind.

Fixing this bug by bug will soon exceed my ability to reverse
engineer test cases for the remaining bugs.


Bernd.

> Martin
> 
>>
>> So may I suggest to do something like the following
>> (diff to your last patch):
>>
>> --- expr.c.jj    2018-07-20 10:51:51.983605588 +0200
>> +++ expr.c    2018-07-20 15:07:29.769423479 +0200
>> @@ -11277,6 +11277,7 @@ tree
>>   string_constant (tree arg, tree *ptr_offset)
>>   {
>>     tree array;
>> +  tree array_size;
>>     STRIP_NOPS (arg);
>>
>>     /* Non-constant index into the character array in an ARRAY_REF
>> @@ -11295,9 +11296,11 @@ string_constant (tree arg, tree *ptr_off
>>
>>     arg = TREE_OPERAND (arg, 0);
>>     tree ref = arg;
>> +  tree reftype = TREE_TYPE (ref);
>>     if (TREE_CODE (arg) == ARRAY_REF)
>>   {
>>     tree idx = TREE_OPERAND (arg, 1);
>> +  reftype = TREE_TYPE (TREE_OPERAND (arg, 0));
>>     if (TREE_CODE (idx) != INTEGER_CST
>>     && TREE_CODE (argtype) == POINTER_TYPE)
>>   {
>> @@ -11313,6 +11316,11 @@ string_constant (tree arg, tree *ptr_off
>>   return NULL_TREE;
>>   }
>>   }
>> +  if (TREE_CODE (reftype) != ARRAY_TYPE)
>> +    return NULL_TREE;
>> +  while (TREE_CODE (TREE_TYPE (reftype)) == ARRAY_TYPE)
>> +    reftype = TREE_TYPE (reftype);
>> +  array_size = TYPE_SIZE_UNIT (reftype);
>>     array = get_addr_base_and_unit_offset (ref, &base_off);
>>     if (!array
>>     || (TREE_CODE (array) != VAR_DECL
>> @@ -11345,7 +11353,10 @@ string_constant (tree arg, tree *ptr_off
>>     return NULL_TREE;
>>   }
>>     else if (DECL_P (arg))
>> -    array = arg;
>> +    {
>> +  array = arg;
>> +  array_size = DECL_SIZE_UNIT (array);
>> +    }
>>     else
>>   return NULL_TREE;
>>
>> @@ -11410,24 +11421,18 @@ string_constant (tree arg, tree *ptr_off
>>     if (!init || TREE_CODE (init) != STRING_CST)
>>   return NULL_TREE;
>>
>> -  tree array_size = DECL_SIZE_UNIT (array);
>>     if (!array_size || TREE_CO

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Bernd Edlinger]

On 07/21/18 01:58, Martin Sebor wrote:
> On 07/20/2018 03:11 PM, Bernd Edlinger wrote:
>> I think I have found a valid test case where the latest patch
>> does generate invalid code:
> 
> This is due to another bug in string_constant() that's latent
> on trunk but that's exposed by the patch.  Trunk only "works"
> because of a bug/limitation in c_strlen() that the patch fixes
> or removes.
> 

I am not sure if that falls under the definition of "latent" bug.
A latent bug would be something unexpected in a completely different
area of the compiler that is triggered by an improved optimization
or a fixed bug elsewhere.

> The underlying root cause is the handling of POINTER_PLUS
> expressions in string_constant().  The original code (before
> the handling of aggregates was added) just dealt with string
> constants.  The new code does much more but doesn't get it
> quite right in these cases.
> 

I think you should be much more careful with the expressions
you evaluate in string_constant.  For instance when you look
at get_addr_base_and_unit_offset, you'll see it walks through
all kinds of type casts, VIEW_CONVERT_EXPR and MEM_REF with
nonzero displacement.  When you see something like that do
not fold that on the assumption that the source code does not
have undefined behavior.

So I'd say you should add a check that there is no type
cast in the expression you parse.  If that is the case,
your optimization will certainly be wrong.

As Richard already repeatedly said, and I can only emphasize
this once more:

The middle end does not follow the "C" standard too closely,
and it is also the C++, fortran, Ada and Go middle-end.
Even if the source code does not exhibit undefined behavior
the folding in the middle-end can introduce it.


Bernd.

> It shouldn't be too difficult to fix, but as valuable as
> the testing you are doing is, I'd really prefer to focus
> on one problem at a time and make incremental progress.
> It will make it easier to track down and fix regressions
> than lumping multiple fixes into a larger patch.
> 
> Martin
> 
>>
>> $ cat part.c
>> static const char a[3][8] = { "1234", "12345", "123456" };
>>
>> int main ()
>> {
>>    volatile int i = 1;
>>    int n = __builtin_strlen (*(&a[1]+i));
>>
>>    if (n != 6)
>>  __builtin_abort ();
>> }
>> $ gcc part.c -fdump-tree-original
>> $ ./a.out
>> Aborted (core dumped)
>> $ cat part.c.004t.original
>>
>> ;; Function main (null)
>> ;; enabled by -tree-original
>>
>>
>> {
>>    volatile int i = 1;
>>    int n = (ssizetype) (SAVE_EXPR <(long unsigned int) i * 8>) <= 5 ? (int) 
>> (5 - (unsigned int) (SAVE_EXPR <(long unsigned int) i * 8>)) : 0;
>>
>>  volatile int i = 1;
>>  int n = (ssizetype) (SAVE_EXPR <(long unsigned int) i * 8>) <= 5 ? 
>> (int) (5 - (unsigned int) (SAVE_EXPR <(long unsigned int) i * 8>)) : 0;
>>    if (n != 6)
>>  {
>>    __builtin_abort ();
>>  }
>> }
>> return 0;
>>
>>
>> string_constant is called with arg = (const char *) (&a[1] + (sizetype) 
>> ((long unsigned int) i * 8))
> 

[PATCH] Avoid out of scope access in hsa-dump.c

[Bernd Edlinger]

Hi,

this fixes an use of a buffer after the block scope
in hsa-dump.c: "buf" is assigned to "name" and used after
the scope ends in a fprintf.

I have not done any real checks, except boot-strapping with
all languages.
Is it OK for trunk?


Thanks
Bernd.
2018-07-22  Bernd Edlinger  

	hsa-dump.c (dump_hsa_symbol): Avoid out of scope access to buf.

Index: gcc/hsa-dump.c
===
--- gcc/hsa-dump.c	(revision 262904)
+++ gcc/hsa-dump.c	(working copy)
@@ -776,11 +776,11 @@ static void
 dump_hsa_symbol (FILE *f, hsa_symbol *symbol)
 {
   const char *name;
+  char buf[64];
   if (symbol->m_name)
 name = symbol->m_name;
   else
 {
-  char buf[64];
   sprintf (buf, "__%s_%i", hsa_seg_name (symbol->m_segment),
 	   symbol->m_name_number);
 

[PATCH] Fix folding of volatile values (PR 86617)

[Bernd Edlinger]

Hi!

This fixes PR c/86617, where volatile values are folded
incorrectly, because LHS and RHS of PLUS_EXPR and
MINUS_EXPR are the same pointer.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk (and active branches, 8.2 in particular)?


Thanks
Bernd.gcc:
2018-07-23  Bernd Edlinger  

	PR c/86617
	* genmatch.c (dt_operand::gen_match_op): Avoid folding volatile values.

testsuite:
2018-07-23  Bernd Edlinger  

	PR c/86617
	* gcc.dg/pr86617.c: New test.

Index: gcc/genmatch.c
===
--- gcc/genmatch.c	(revision 262904)
+++ gcc/genmatch.c	(working copy)
@@ -2748,12 +2748,14 @@ dt_operand::gen_match_op (FILE *f, int indent, con
   char match_opname[20];
   match_dop->get_name (match_opname);
   if (value_match)
-fprintf_indent (f, indent, "if (%s == %s || operand_equal_p (%s, %s, 0))\n",
-		opname, match_opname, opname, match_opname);
+fprintf_indent (f, indent, "if ((%s == %s && ! TREE_SIDE_EFFECTS (%s)) "
+		"|| operand_equal_p (%s, %s, 0))\n",
+		opname, match_opname, opname, opname, match_opname);
   else
-fprintf_indent (f, indent, "if (%s == %s || (operand_equal_p (%s, %s, 0) "
+fprintf_indent (f, indent, "if ((%s == %s && ! TREE_SIDE_EFFECTS (%s)) "
+		"|| (operand_equal_p (%s, %s, 0) "
 		"&& types_match (%s, %s)))\n",
-		opname, match_opname, opname, match_opname,
+		opname, match_opname, opname, opname, match_opname,
 		opname, match_opname);
   fprintf_indent (f, indent + 2, "{\n");
   return 1;
Index: gcc/testsuite/gcc.dg/pr86617.c
===
--- gcc/testsuite/gcc.dg/pr86617.c	(revision 0)
+++ gcc/testsuite/gcc.dg/pr86617.c	(working copy)
@@ -0,0 +1,11 @@
+/* { dg-options "-Os -fdump-rtl-final" } */
+
+volatile unsigned char u8;
+
+void test (void)
+{
+  u8 = u8 + u8;
+  u8 = u8 - u8;
+}
+
+/* { dg-final { scan-rtl-dump-times "mem/v" 6 "final" } } */

[PATCH] Make strlen range computations more conservative

[Bernd Edlinger]

Hi!

This patch makes strlen range computations more conservative.

Firstly if there is a visible type cast from type A to B before passing
then value to strlen, don't expect the type layout of B to restrict the
possible return value range of strlen.

Furthermore use the outermost enclosing array instead of the
innermost one, because too aggressive optimization will likely
convert harmless errors into security-relevant errors, because
as the existing test cases demonstrate, this optimization is actively
attacking string length checks in user code, while and not giving
any warnings.



Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.gcc:
2018-07-24  Bernd Edlinger  

* gimple-fold.c (get_range_strlen): Add a check for type casts.
Use outermost enclosing array size instead of innermost one.
* tree-ssa-strlen.c (maybe_set_strlen_range): Likewise.

testsuite:
2018-07-24  Bernd Edlinger  

* gcc.dg/strlenopt-40.c: Adjust test expectations.
* gcc.dg/strlenopt-45.c: Likewise.
* gcc.dg/strlenopt-48.c: Likewise.
* gcc.dg/strlenopt-51.c: Likewise.
* gcc.dg/strlenopt-54.c: New test.
Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c	(revision 262904)
+++ gcc/gimple-fold.c	(working copy)
@@ -1339,19 +1339,33 @@ get_range_strlen (tree arg, tree length[2], bitmap
 
 	  if (TREE_CODE (arg) == ARRAY_REF)
 	{
-	  tree type = TREE_TYPE (TREE_OPERAND (arg, 0));
+	  /* Avoid arrays of pointers.  */
+	  if (TREE_CODE (TREE_TYPE (arg)) == POINTER_TYPE)
+		return false;
 
-	  /* Determine the "innermost" array type.  */
-	  while (TREE_CODE (type) == ARRAY_TYPE
-		 && TREE_CODE (TREE_TYPE (type)) == ARRAY_TYPE)
-		type = TREE_TYPE (type);
+	  /* Look for the outermost enclosing array.  */
+	  while (TREE_CODE (arg) == ARRAY_REF
+		 && TREE_CODE (TREE_TYPE (TREE_OPERAND (arg, 0)))
+			== ARRAY_TYPE)
+		arg = TREE_OPERAND (arg, 0);
 
-	  /* Avoid arrays of pointers.  */
-	  tree eltype = TREE_TYPE (type);
-	  if (TREE_CODE (type) != ARRAY_TYPE
-		  || !INTEGRAL_TYPE_P (eltype))
+	  tree base = arg;
+	  while (TREE_CODE (base) == ARRAY_REF
+		 || TREE_CODE (base) == ARRAY_RANGE_REF
+		 || TREE_CODE (base) == COMPONENT_REF)
+		base = TREE_OPERAND (base, 0);
+
+	  /* If this looks like a type cast don't assume anything.  */
+	  if ((TREE_CODE (base) == MEM_REF
+		   && (! integer_zerop (TREE_OPERAND (base, 1))
+		   || TREE_TYPE (TREE_TYPE (TREE_OPERAND (base, 0)))
+			  != TREE_TYPE (base)))
+		  || TREE_CODE (base) == VIEW_CONVERT_EXPR)
 		return false;
 
+	  tree type = TREE_TYPE (arg);
+
+	  /* Fail when the array bound is unknown or zero.  */
 	  val = TYPE_SIZE_UNIT (type);
 	  if (!val || integer_zerop (val))
 		return false;
@@ -1362,9 +1376,9 @@ get_range_strlen (tree arg, tree length[2], bitmap
 		 the array could have zero length.  */
 	  *minlen = ssize_int (0);
 
-	  if (TREE_CODE (TREE_OPERAND (arg, 0)) == COMPONENT_REF
-		  && type == TREE_TYPE (TREE_OPERAND (arg, 0))
-		  && array_at_struct_end_p (TREE_OPERAND (arg, 0)))
+	  if (TREE_CODE (arg) == COMPONENT_REF
+		  && type == TREE_TYPE (arg)
+		  && array_at_struct_end_p (arg))
 		*flexp = true;
 	}
 	  else if (TREE_CODE (arg) == COMPONENT_REF
@@ -1371,6 +1385,20 @@ get_range_strlen (tree arg, tree length[2], bitmap
 		   && (TREE_CODE (TREE_TYPE (TREE_OPERAND (arg, 1)))
 		   == ARRAY_TYPE))
 	{
+	  tree base = TREE_OPERAND (arg, 0);
+	  while (TREE_CODE (base) == ARRAY_REF
+		 || TREE_CODE (base) == ARRAY_RANGE_REF
+		 || TREE_CODE (base) == COMPONENT_REF)
+		base = TREE_OPERAND (base, 0);
+
+	  /* If this looks like a type cast don't assume anything.  */
+	  if ((TREE_CODE (base) == MEM_REF
+		   && (! integer_zerop (TREE_OPERAND (base, 1))
+		   || TREE_TYPE (TREE_TYPE (TREE_OPERAND (base, 0)))
+			  != TREE_TYPE (base)))
+		  || TREE_CODE (base) == VIEW_CONVERT_EXPR)
+		return false;
+
 	  /* Use the type of the member array to determine the upper
 		 bound on the length of the array.  This may be overly
 		 optimistic if the array itself isn't NUL-terminated and
@@ -1386,10 +1414,6 @@ get_range_strlen (tree arg, tree length[2], bitmap
 
 	  tree type = TREE_TYPE (arg);
 
-	  while (TREE_CODE (type) == ARRAY_TYPE
-		 && TREE_CODE (TREE_TYPE (type)) == ARRAY_TYPE)
-		type = TREE_TYPE (type);
-
 	  /* Fail when the array bound is unknown or zero.  */
 	  val = TYPE_SIZE_UNIT (type);
 	  if (!val || integer_zerop (val))
Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c	(revision 262904)
+++ gcc/tree-ssa-strlen.c	(working copy)
@@ -1149,9 +1149,33 

Re: [PATCH] Make strlen range computations more conservative

[Bernd Edlinger]

On 07/24/18 23:46, Jeff Law wrote:
> On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
>> Hi!
>>
>> This patch makes strlen range computations more conservative.
>>
>> Firstly if there is a visible type cast from type A to B before passing
>> then value to strlen, don't expect the type layout of B to restrict the
>> possible return value range of strlen.
> Why do you think this is the right thing to do?  ie, is there language
> in the standards that makes you think the code as it stands today is
> incorrect from a conformance standpoint?  Is there a significant body of
> code that is affected in an adverse way by the current code?  If so,
> what code?
> 
> 

I think if you have an object, of an effective type A say char[100], then
you can cast the address of A to B, say typedef char (*B)[2] for instance
and then to const char *, say for use in strlen.  I may be wrong, but I think
that we should at least try not to pick up char[2] from B, but instead
use A for strlen ranges, or leave this range open.  Currently the range
info for strlen is [0..1] in this case, even if we see the type cast
in the generic tree.

One other example I have found in one of the test cases:

char c;

if (strlen(&c) != 0) abort();

this is now completely elided, but why?  Is there a code base where
that is used?  I doubt, but why do we care to eliminate something
stupid like that?  If we would emit a warning for that I'm fine with it,
But if we silently remove code like that I don't think that it
will improve anything.  So I ask, where is the code base which
gets an improvement from that optimization?



> 
>>
>> Furthermore use the outermost enclosing array instead of the
>> innermost one, because too aggressive optimization will likely
>> convert harmless errors into security-relevant errors, because
>> as the existing test cases demonstrate, this optimization is actively
>> attacking string length checks in user code, while and not giving
>> any warnings.
> Same questions here.
> 
> I'll also note that Martin is *very* aware of the desire to avoid
> introducing security relevent errors.  In fact his main focus is to help
> identify coding errors that have a security impact.  So please don't
> characterize his work as "actively attacking string length checks in
> user code".
> 

I do fully respect Martin's valuable contributions over the years,
and I did not intend to say anything about the quality of his work,
for GCC, it is just breathtaking!

What I meant is just, what this particular optimization can do.

> Ultimately we want highly accurate string lengths to help improve the
> quality of the warnings we generate for potentially dangerous code.
> These changes seem to take us in the opposite direction.
> 

No, I don't think so, we have full control on the direction, when
I do what Richi requested on his response, we will have one function
where the string length estimation is based upon, instead of several
open coded tree walks.

> So ISTM that you really need a stronger justification using the
> standards compliance and/or real world code that is made less safe by
> keeping string lengths as accurate as possible.
> 
> 

This work concentrates mostly on avoiding to interfere with code that
actually deserves warnings, but which is not being warned about.

>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
> I'd like to ask we hold on this until I return from PTO (Aug 1) so that
> we can discuss the best thing to do here for each class of change.
> 

Okay.

> I think you, Martin, Richi and myself should hash through the technical
> issues raised by the patch.  Obviously others can chime in, but I think
> the 4 of us probably need to drive the discussion.
> 

Yes, sure.  I will try to help when I can.

Currently I thought Martin is working on the string constant folding,
(therefore I thought this range patch would not collide with his patch)
and there are plenty of change requests, plus I think he has some more
patches on hold.  I would like to see the review comments resolved,
and maybe also get to see the follow up patches, maybe as a patch
series, so we can get a clearer picture?


Thanks
Bernd.

> Thanks,
> Jeff
> 

Re: [PATCH] Make strlen range computations more conservative

[Bernd Edlinger]

On 07/24/18 16:50, Richard Biener wrote:
> On Tue, 24 Jul 2018, Bernd Edlinger wrote:
> 
>> Hi!
>>
>> This patch makes strlen range computations more conservative.
>>
>> Firstly if there is a visible type cast from type A to B before passing
>> then value to strlen, don't expect the type layout of B to restrict the
>> possible return value range of strlen.
>>
>> Furthermore use the outermost enclosing array instead of the
>> innermost one, because too aggressive optimization will likely
>> convert harmless errors into security-relevant errors, because
>> as the existing test cases demonstrate, this optimization is actively
>> attacking string length checks in user code, while and not giving
>> any warnings.
>>
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
> 
> I'd like us to be explicit in what we support, not what we do not
> support, thus
> 
> + /* Avoid arrays of pointers.  */
> + if (TREE_CODE (TREE_TYPE (arg)) == POINTER_TYPE)
> +   return false;
> 
> should become
> 
> /* We handle arrays of integer types.  */
>if (TREE_CODE (TRE_TYPE (arg)) != INTEGER_TYPE)
>  return false;
> 

Yes.  I think I can also check the TYPE_MODE/PRECISION.

> + tree base = arg;
> + while (TREE_CODE (base) == ARRAY_REF
> +|| TREE_CODE (base) == ARRAY_RANGE_REF
> +|| TREE_CODE (base) == COMPONENT_REF)
> +   base = TREE_OPERAND (base, 0);
> +
> + /* If this looks like a type cast don't assume anything.  */
> + if ((TREE_CODE (base) == MEM_REF
> +  && (! integer_zerop (TREE_OPERAND (base, 1))
> +  || TREE_TYPE (TREE_TYPE (TREE_OPERAND (base, 0)))
> + != TREE_TYPE (base)))
> + || TREE_CODE (base) == VIEW_CONVERT_EXPR)
>  return false;
> 
> likewise - you miss to handle BIT_FIELD_REF.  So, instead
> 

I did not expect to see BIT_FIELD_REF in the inner tree elements,
but you never know.  The new version handles them, and bails out
if they happen to be there.
Is this handling now how you wanted it to be?

>if (!(DECL_P (base)
>  || TREE_CODE (base) == STRING_CST
>  || (TREE_CODE (base) == MEM_REF
>  && ...> 
> you should look at comparing TYPE_MAIN_VARIANT in your type
> check, aligned/unaligned or const/non-const accesses shouldn't
> be considered a "type cast".  Maybe even use

Good point.  TYPE_MAIN_VARIANT is my friend.

> types_compatible_p.  Not sure why you enforce zero-offset MEMs?
> Do we in the end only handle &decl bases of MEMs?  Given you
> strip arbitrary COMPONENT_REFs the offset in a MEM isn't
> so much different?
> 

something like:
ma0[1].a5_7[0]
gets transformed into:
(const char *) &(ma0 + 64)->a5_7[0]

ma0 + 64 is a MEM_REF[&ma0, 64] I don't really think that happens
too often, but I think other weirdo-type casts can look quite
similar.  But that happens very rarely.


> It looks like the component-ref stripping plus type-check part
> could be factored out into sth like get_base_address?  I don't
> have a good name or suggested semantics for it though.
> 

Yes, done.

While playing with the now more rigorous type checking I noticed
something that is most likely a pre-existent programming error:

@@ -1310,8 +1350,8 @@ get_range_strlen (tree arg, tree length[2], bitmap
  member.  */
   tree idx = TREE_OPERAND (op, 1);

- arg = TREE_OPERAND (op, 0);
- tree optype = TREE_TYPE (arg);
+ op = TREE_OPERAND (op, 0);
+ tree optype = TREE_TYPE (op);
   if (tree dom = TYPE_DOMAIN (optype))
 if (tree bound = TYPE_MAX_VALUE (dom))
   if (TREE_CODE (bound) == INTEGER_CST

I believe this was not meant to change "arg".

This is in a block that is guarded by:

   /* We can end up with &(*iftmp_1)[0] here as well, so handle it.  */
   if (TREE_CODE (arg) == ADDR_EXPR
   && TREE_CODE (TREE_OPERAND (arg, 0)) == ARRAY_REF)

so this is entered with arg = &ma0_3_5_7[0][0][0].a5_7[4]
op = ma0_3_5_7[0][0][0].a5_7[4] at this point,
then arg is accidentally set to TREE_OPERAND (op, 0)
which now makes arg = ma0_3_5_7[0][0][0].a5_7 this did not pass the
type check in get_inner_char_array_unless_typecast, but more
importantly this is passed to val = c_strlen (arg, 1),
which will likely return the first array initializer instead of the
fifth.

I have also added an else here:

@@ -1400,8 +1432,7 @@ get_range_strlen (tree arg, tree length[2], bitmap

Re: [PATCH] warn for strlen of arrays with missing nul (PR 86552)

[Bernd Edlinger]

> @@ -567,13 +597,17 @@ string_length (const void *ptr, unsigned eltsize, 
> unsigned maxelts)
> accesses.  Note that this implies the result is not going to be emitted
>into the instruction stream.
>  
> +   When ARR is non-null and the string is not properly nul-terminated,
> +   set *ARR to the declaration of the outermost constant object whose
> +   initializer (or one of its elements) is not nul-terminated.
> +
> The value returned is of type `ssizetype'.
>  
> Unfortunately, string_constant can't access the values of const char
> arrays with initializers, so neither can we do so here.  */

Maybe drop that sentence when it is no longer true?

>  
>  tree
> -c_strlen (tree src, int only_value)
> +c_strlen (tree src, int only_value, tree *arr /* = NULL */)
>  {
>STRIP_NOPS (src);
>if (TREE_CODE (src) == COND_EXPR
> @@ -581,24 +615,31 @@ c_strlen (tree src, int only_value)
>  {
>tree len1, len2;
>  
> -  len1 = c_strlen (TREE_OPERAND (src, 1), only_value);
> -  len2 = c_strlen (TREE_OPERAND (src, 2), only_value);
> +  len1 = c_strlen (TREE_OPERAND (src, 1), only_value, arr);
> +  len2 = c_strlen (TREE_OPERAND (src, 2), only_value, arr);

Wow, what happens here if the first operand is non-zero terminated and the 
second is zero-terminated?

>if (tree_int_cst_equal (len1, len2))
>   return len1;
>  }
>  
>if (TREE_CODE (src) == COMPOUND_EXPR
>&& (only_value || !TREE_SIDE_EFFECTS (TREE_OPERAND (src, 0


Bernd.

Re: [PATCH] Make strlen range computations more conservative

[Bernd Edlinger]

I have one more example similar to PR86259, that resembles IMHO real world code:

Consider the following:


int fun (char *p)
{
  char buf[16];

  assert(strlen(p) < 4); //here: security relevant check

  sprintf(buf, "echo %s - %s", p, p); //here: security relevant code
  return system(buf);
}


What is wrong with the assertion?

Nothing, except it is removed, when this function is called from untrusted code:

untrused_fun ()
{
   char b[2] = "ab";
   fun(b);
}

 don't try to execute that: after "ab" there can be "; rm -rF / ;" on your 
stack

Even the slightly more safe check "assert(strnlen(p, 4) < 4);" would have
been removed.

Now that is a simple error and it would be easy to fix -- normally.
But when the assertion is removed, the security relevant code
is allowed to continue where it creates more damage and is
suddenly much harder to debug.


So, I start to believe that strlen range assumptions are unsafe, unless
we can prove that the string is in fact zero terminated.

I would like to guard the strlen range checks with a new option, maybe
-fassume-zero-terminated-char-arrays, and enable that under -Ofast only.

What do you think?


Thanks
Bernd.

[PATCH] Avoid another non zero terminated string constant

[Bernd Edlinger]

Hi!

This fixes another not NUL terminated string literal that is created
in tree-ssa-forwprop.c at simplify_builtin_call.

src_buf is set up to contain a NUL at src_buf[src_len], thus use src_len + 1
as length parameter to build_string_literal.  All other uses of
build_string_literal do it right, as far as I can see.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
2018-07-29  Bernd Edlinger  

	* tree-ssa-forwprop.c (simplify_builtin_call): Don't create a not NUL
	terminated string literal.

Index: gcc/tree-ssa-forwprop.c
===
--- gcc/tree-ssa-forwprop.c	(revision 263045)
+++ gcc/tree-ssa-forwprop.c	(working copy)
@@ -1391,7 +1391,7 @@ simplify_builtin_call (gimple_stmt_iterator *gsi_p
 src_buf, ptr1_align, false))
 	break;
 
-	  new_str_cst = build_string_literal (src_len, src_buf);
+	  new_str_cst = build_string_literal (src_len + 1, src_buf);
 	  if (callee1)
 	{
 	  /* If STMT1 is a mem{,p}cpy call, adjust it and remove

[PATCH] Fix wrong code with truncated string literals (PR 86711/86714)

[Bernd Edlinger]

Hi!

This fixes two wrong code bugs where string_constant
returns over length string constants.  Initializers
like that are rejected in C++, but valid in C.

I have xfailed strlenopt-49.c, which tests this feature.
Personally I don't think that it is worth the effort to
optimize something that is per se invalid in C++.

The hunk in builtins.c is unrelated, but I would like
to use tree_to_shwi here, to be in line with the
tree_fits_shwi_p check above, and the rest of that
function which uses signed HWI throughout.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
gcc:
2018-07-29  Bernd Edlinger  

PR middle-end/86711
PR middle-end/86714
* builtins.c (c_strlen): Use tree_to_shwi because maxelts is signed.
* expr.c (string_constant): Don't return truncated string literals.
* fold-const.c (c_getstr): Fix function comment.  Remove unused third
argument.  Fix range checks.
* fold-const.c (c_getstr): Adjust protoype.

testsuite:
2018-07-29  Bernd Edlinger  

PR middle-end/86711
PR middle-end/86714
* gcc.c-torture/execute/pr86711.c: New test.
* gcc.c-torture/execute/pr86714.c: New test.
* gcc.dg/strlenopt-49.c: Add xfail.
Index: gcc/builtins.c
===
--- gcc/builtins.c	(revision 263045)
+++ gcc/builtins.c	(working copy)
@@ -617,7 +617,7 @@ c_strlen (tree src, int only_value)
   if (tree size = TYPE_SIZE_UNIT (type))
 if (tree_fits_shwi_p (size))
   {
-	maxelts = tree_to_uhwi (size);
+	maxelts = tree_to_shwi (size);
 	maxelts = maxelts / eltsize - 1;
   }
 
Index: gcc/expr.c
===
--- gcc/expr.c	(revision 263045)
+++ gcc/expr.c	(working copy)
@@ -11410,24 +11410,14 @@ string_constant (tree arg, tree *ptr_offset)
   if (!init || TREE_CODE (init) != STRING_CST)
 return NULL_TREE;
 
-  tree array_size = DECL_SIZE_UNIT (array);
-  if (!array_size || TREE_CODE (array_size) != INTEGER_CST)
-return NULL_TREE;
-
   /* Avoid returning a string that doesn't fit in the array
- it is stored in, like
- const char a[4] = "abcde";
- but do handle those that fit even if they have excess
- initializers, such as in
- const char a[4] = "abc\000\000";
- The excess elements contribute to TREE_STRING_LENGTH()
- but not to strlen().  */
-  unsigned HOST_WIDE_INT charsize
-= tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (init;
-  unsigned HOST_WIDE_INT length = TREE_STRING_LENGTH (init);
-  length = string_length (TREE_STRING_POINTER (init), charsize,
-			  length / charsize);
-  if (compare_tree_int (array_size, length + 1) < 0)
+ it is stored in, like:
+ const char a[4] = "abcd";
+ because callers expect to be able to access the string
+ up to the limit imposed by TREE_STRING_LENGTH which
+ always includes the terminating NUL char.  */
+  if (compare_tree_int (TYPE_SIZE_UNIT (TREE_TYPE (init)),
+			TREE_STRING_LENGTH (init)) < 0)
 return NULL_TREE;
 
   *ptr_offset = offset;
Index: gcc/fold-const.c
===
--- gcc/fold-const.c	(revision 263045)
+++ gcc/fold-const.c	(working copy)
@@ -14577,16 +14577,12 @@ fold_build_pointer_plus_hwi_loc (location_t loc, t
 /* Return a pointer P to a NUL-terminated string representing the sequence
of constant characters referred to by SRC (or a subsequence of such
characters within it if SRC is a reference to a string plus some
-   constant offset).  If STRLEN is non-null, store stgrlen(P) in *STRLEN.
-   If STRSIZE is non-null, store in *STRSIZE the size of the array
-   the string is stored in; in that case, even though P points to a NUL
-   terminated string, SRC need not refer to one.  This can happen when
-   SRC refers to a constant character array initialized to all non-NUL
-   values, as in the C declaration: char a[4] = "1234";  */
+   constant offset).  If STRLEN is non-null, store the number of bytes
+   in the string constant including the terminating NUL char.  *STRLEN is
+   typically strlen(P) + 1 in the absence of embedded NUL characters.  */
 
 const char *
-c_getstr (tree src, unsigned HOST_WIDE_INT *strlen /* = NULL */,
-	  unsigned HOST_WIDE_INT *strsize /* = NULL */)
+c_getstr (tree src, unsigned HOST_WIDE_INT *strlen /* = NULL */)
 {
   tree offset_node;
 
@@ -14613,40 +14609,24 @@ const char *
   unsigned HOST_WIDE_INT string_size = string_length;
   tree type = TREE_TYPE (src);
   if (tree size = TYPE_SIZE_UNIT (type))
-if (tree_fits_shwi_p (size))
+if (tree_fits_uhwi_p (size))
   string_size = tree_to_uhwi (size);
 
+  if (offset >= string_size)
+return NULL;
+
   if (strlen)
 {
   /* Compute and store the length of the substring at OFFSET.
 	 All offsets past the initial length refer to

[PATCH] Fix the damage done by my other patch from yesterday to strlenopt-49.c

[Bernd Edlinger]

Hi,

this is how I would like to handle the over length strings issue in the C FE.
If the string constant is exactly the right length and ends in one explicit
NUL character, shorten it by one character.

I thought Martin would be working on it,  but as this is a really simple fix,
I would dare to send it to gcc-patches anyway, hope you don't mind...

The patch is relative to the other patch here: 
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.gcc/c:
2018-07-30  Bernd Edlinger  

	* c-typeck.c (digest_init): Fix overlength strings.

testsuite:
2018-07-30  Bernd Edlinger  

	* gcc.dg/strlenopt-49.c: Adjust test expectations.

diff -pur gcc/c/c-typeck.c gcc/c/c-typeck.c
--- gcc/c/c-typeck.c	2018-06-20 18:35:15.0 +0200
+++ gcc/c/c-typeck.c	2018-07-30 12:17:34.175481372 +0200
@@ -7435,29 +7435,38 @@ digest_init (location_t init_loc, tree t
 		}
 	}
 
-	  TREE_TYPE (inside_init) = type;
 	  if (TYPE_DOMAIN (type) != NULL_TREE
 	  && TYPE_SIZE (type) != NULL_TREE
 	  && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
 	{
 	  unsigned HOST_WIDE_INT len = TREE_STRING_LENGTH (inside_init);
+	  unsigned unit = TYPE_PRECISION (typ1) / BITS_PER_UNIT;
 
 	  /* Subtract the size of a single (possibly wide) character
 		 because it's ok to ignore the terminating null char
 		 that is counted in the length of the constant.  */
-	  if (compare_tree_int (TYPE_SIZE_UNIT (type),
-(len - (TYPE_PRECISION (typ1)
-	/ BITS_PER_UNIT))) < 0)
+	  if (compare_tree_int (TYPE_SIZE_UNIT (type), len - unit) < 0)
 		pedwarn_init (init_loc, 0,
 			  ("initializer-string for array of chars "
 			   "is too long"));
-	  else if (warn_cxx_compat
-		   && compare_tree_int (TYPE_SIZE_UNIT (type), len) < 0)
-		warning_at (init_loc, OPT_Wc___compat,
-			("initializer-string for array chars "
-			 "is too long for C++"));
+	  else if (compare_tree_int (TYPE_SIZE_UNIT (type), len) < 0)
+		{
+		  if (warn_cxx_compat)
+		warning_at (init_loc, OPT_Wc___compat,
+("initializer-string for array chars "
+ "is too long for C++"));
+		  if (len >= 2 * unit)
+		{
+		  const char *p = TREE_STRING_POINTER (inside_init);
+
+		  len -= unit;
+		  if (memcmp (p + len - unit, "\0\0\0\0", unit) == 0)
+			inside_init = build_string (len, p);
+		}
+		}
 	}
 
+	  TREE_TYPE (inside_init) = type;
 	  return inside_init;
 	}
   else if (INTEGRAL_TYPE_P (typ1))
diff -pur gcc/testsuite/gcc.dg/strlenopt-49.c gcc/testsuite/gcc.dg/strlenopt-49.c
--- gcc/testsuite/gcc.dg/strlenopt-49.c	2018-07-30 13:02:34.735478726 +0200
+++ gcc/testsuite/gcc.dg/strlenopt-49.c	2018-07-30 13:08:21.074859303 +0200
@@ -11,9 +11,6 @@ const char a3[3] = "12\0";
 const char a8[8] = "1234567\0";
 const char a9[9] = "12345678\0";
 
-const char ax[9] = "12345678\0\0\0\0";   /* { dg-warning "initializer-string for array of chars is too long" } */
-const char ay[9] = "\00012345678\0\0\0\0";   /* { dg-warning "initializer-string for array of chars is too long" } */
-
 
 int len1 (void)
 {
@@ -27,27 +24,13 @@ int len (void)
   return len;
 }
 
-int lenx (void)
-{
-  size_t lenx = strlen (ax);
-  return lenx;
-}
-
-int leny (void)
-{
-  size_t leny = strlen (ay);
-  return leny;
-}
-
 int cmp88 (void)
 {
   int cmp88 = memcmp (a8, "1234567\0", sizeof a8);
   return cmp88;
 }
 
-/* { dg-final { scan-tree-dump-times "strlen" 0 "gimple" { xfail *-*-* } } }
-   { dg-final { scan-tree-dump-times "len0 = 0;" 1 "gimple" { xfail *-*-* } } }
-   { dg-final { scan-tree-dump-times "len = 18;" 1 "gimple" { xfail *-*-* } } }
-   { dg-final { scan-tree-dump-times "lenx = 8;" 1 "gimple" { xfail *-*-* } } }
-   { dg-final { scan-tree-dump-times "leny = 0;" 1 "gimple" { xfail *-*-* } } }
-   { dg-final { scan-tree-dump-times "cmp88 = 0;" 1 "gimple" { xfail *-*-* } } } */
+/* { dg-final { scan-tree-dump-times "strlen" 0 "gimple" } }
+   { dg-final { scan-tree-dump-times "len0 = 0;" 1 "gimple" } }
+   { dg-final { scan-tree-dump-times "len = 18;" 1 "gimple" } }
+   { dg-final { scan-tree-dump-times "cmp88 = 0;" 1 "gimple" } } */

Re: [PATCH] Fix the damage done by my other patch from yesterday to strlenopt-49.c

[Bernd Edlinger]

On 07/30/18 15:03, Richard Biener wrote:
> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
> 
>> Hi,
>>
>> this is how I would like to handle the over length strings issue in the C FE.
>> If the string constant is exactly the right length and ends in one explicit
>> NUL character, shorten it by one character.
>>
>> I thought Martin would be working on it,  but as this is a really simple fix,
>> I would dare to send it to gcc-patches anyway, hope you don't mind...
>>
>> The patch is relative to the other patch here: 
>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
> 
> I'll leave this to FE maintainers but can I ask you to verify the
> (other) FEs do not leak this kind of invalid initializers to the
> middle-end?  I suggest to put this verification in
> output_constructor which otherwise happily truncates initializers
> with excess size.  There's also gimplification which might elide
> a = { "abcd", "cdse" }; to  a.x = "abcd"; a.y = "cdse"; but
> hopefully there the GIMPLE verifier (verify_gimple_assign_single)
> verifies this - well, it only dispatches to useless_type_conversion_p
> (lhs_type, rhs1_type) for this case, but non-flexarrays should be
> handled fine there.
> 
> Richard.
> 

In the moment I would already be happy if all STRING_CSTs would
be zero terminated.

However Go does not create zero-terminated STRING_CSTs, @Ian sorry,
could you look at changing this to include the terminating NUL char?

Index: gcc/go/go-gcc.cc
===
--- gcc/go/go-gcc.cc(revision 263068)
+++ gcc/go/go-gcc.cc(working copy)
@@ -1394,7 +1394,7 @@ Gcc_backend::string_constant_expression(const std:
  TYPE_QUAL_CONST);
tree string_type = build_array_type(const_char_type, index_type);
TYPE_STRING_FLAG(string_type) = 1;
-  tree string_val = build_string(val.length(), val.data());
+  tree string_val = build_string(val.length() + 1, val.data());
TREE_TYPE(string_val) = string_type;
  
return this->make_expression(string_val);


A am pretty sure that the C++ FE allows overlength initializers
with -permissive.  They should be hedged in string_constant IMHO,
however with the patch I am still holding back on Jeff's request
I ran over a string constant in tree-ssa-strlen.c (get_min_string_length)
that had a terminating NUL char but the index range type did not
include the string terminator.  One just needs to be careful here.

A quick survey shows that Fortran creates C strings with range
1..n, which puts the pr86532 address computation again in question.
Remember, you asked for array_ref_element_size but not for
array_ref_low_bound, and Jeff acked the patch in this state.



Thanks
Bernd.

Re: [PATCH] Fix wrong code with truncated string literals (PR 86711/86714)

[Bernd Edlinger]

On 07/30/18 01:05, Martin Sebor wrote:
> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
>> Hi!
>>
>> This fixes two wrong code bugs where string_constant
>> returns over length string constants.  Initializers
>> like that are rejected in C++, but valid in C.
> 
> If by valid you are referring to declarations like the one in
> the added test:
> 
>      const char a[2][3] = { "1234", "xyz" };
> 
> then (as I explained), the excess elements in "1234" make
> the char[3] initialization and thus the test case undefined.
> I have resolved bug 86711 as invalid on those grounds.
> 
> Bug 86711 has a valid test case that needs to be fixed, along
> with bug 86688 that I raised for the same underlying problem:
> considering the excess nul as part of the string.  As has been
> discussed in a separate bug, rather than working around
> the excessively long strings in the middle-end, it would be
> preferable to avoid creating them to begin with.
> 
> I'm already working on a fix for bug 86688, in part because
> I introduced the code change and also because I'm making other
> changes in this area -- bug 86552.  Both of these in response
> to your comments.
> 

Sorry, I must admit, I have completely lost track on how many things
you are trying to work in parallel.

Nevertheless I started to review you pr86552 patch here:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01593.html

But so far you did not respond to me.

Well actually I doubt your patch does apply to trunk,
maybe you start to re-base that one, and post it again
instead?


Thanks
Bernd.

Re: [PATCH] Fix the damage done by my other patch from yesterday to strlenopt-49.c

[Bernd Edlinger]

On 07/30/18 17:57, Jakub Jelinek wrote:
> On Mon, Jul 30, 2018 at 03:52:39PM +, Joseph Myers wrote:
>> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
>>
>>> In the moment I would already be happy if all STRING_CSTs would
>>> be zero terminated.
>>
>> generic.texi says they need not be.  Making the STRING_CST contain only
>> the bytes of the initializer and not the trailing NUL in the C case where
>> the trailing NUL does not fit in the object initialized would of course
>> mean you get non-NUL-terminated STRING_CSTs for valid C code as well.
> 
> One thing is whether TREE_STRING_LENGTH includes the trailing NUL byte,
> that doesn't need to be the case e.g. for the shortened initializers.
> The other thing is whether we as a convenience for the compiler's internals
> want to waste some memory for the NUL termination; I think we could avoid
> some bugs that way.
> 

Yes, exactly, currently the middle-end tries determine if a STRING_CST
is nul terminated, but that is broken for wide character, for instance
c_getstr:

   else if (string[string_length - 1] != '\0')
 {
   /* Support only properly NUL-terminated strings but handle
  consecutive strings within the same array, such as the six
  substrings in "1\0002\0003".  */
   return NULL;
 }

It would be much better if any string constant could be zero terminated.

When always zero-terminated STRING_CST the check for a non-zero terminated
value is much more easy:

compare_tree_int (TYPE_SIZE_UNIT (TREE_TYPE (init)), TREE_STRING_LENGTH (init))



Bernd.

Re: [PATCH] Fix the damage done by my other patch from yesterday to strlenopt-49.c

[Bernd Edlinger]

On 07/30/18 18:01, Joseph Myers wrote:
> On Mon, 30 Jul 2018, Jakub Jelinek wrote:
> 
>> On Mon, Jul 30, 2018 at 03:52:39PM +, Joseph Myers wrote:
>>> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
>>>
>>>> In the moment I would already be happy if all STRING_CSTs would
>>>> be zero terminated.
>>>
>>> generic.texi says they need not be.  Making the STRING_CST contain only
>>> the bytes of the initializer and not the trailing NUL in the C case where
>>> the trailing NUL does not fit in the object initialized would of course
>>> mean you get non-NUL-terminated STRING_CSTs for valid C code as well.
>>
>> One thing is whether TREE_STRING_LENGTH includes the trailing NUL byte,
>> that doesn't need to be the case e.g. for the shortened initializers.
>> The other thing is whether we as a convenience for the compiler's internals
>> want to waste some memory for the NUL termination; I think we could avoid
>> some bugs that way.
> 
> TREE_STRING_LENGTH includes the NUL if it is logically part of the object,
> but should not if the NUL is purely an implementation convenience.
> 

To complicate things a bit more STRING_CST that are created by the Ada FE
for the purpose of ASM constraints, do not contain a NUL character.
That is in TREE_STRING_LENGTH, there is of course always another NUL char
after the payload.  Likewise for C __attribute__ values.


Thanks
Bernd.

Re: [PATCH] Fix wrong code with truncated string literals (PR 86711/86714)

[Bernd Edlinger]

On 07/30/18 21:52, Martin Sebor wrote:
> On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
>> On 07/30/18 01:05, Martin Sebor wrote:
>>> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
>>>> Hi!
>>>>
>>>> This fixes two wrong code bugs where string_constant
>>>> returns over length string constants.  Initializers
>>>> like that are rejected in C++, but valid in C.
>>>
>>> If by valid you are referring to declarations like the one in
>>> the added test:
>>>
>>>  const char a[2][3] = { "1234", "xyz" };
>>>
>>> then (as I explained), the excess elements in "1234" make
>>> the char[3] initialization and thus the test case undefined.
>>> I have resolved bug 86711 as invalid on those grounds.
>>>
>>> Bug 86711 has a valid test case that needs to be fixed, along
>>> with bug 86688 that I raised for the same underlying problem:
>>> considering the excess nul as part of the string.  As has been
>>> discussed in a separate bug, rather than working around
>>> the excessively long strings in the middle-end, it would be
>>> preferable to avoid creating them to begin with.
>>>
>>> I'm already working on a fix for bug 86688, in part because
>>> I introduced the code change and also because I'm making other
>>> changes in this area -- bug 86552.  Both of these in response
>>> to your comments.
>>>
>>
>> Sorry, I must admit, I have completely lost track on how many things
>> you are trying to work in parallel.
>>
>> Nevertheless I started to review you pr86552 patch here:
>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01593.html
>>
>> But so far you did not respond to me.
>>
>> Well actually I doubt your patch does apply to trunk,
>> maybe you start to re-base that one, and post it again
>> instead?
> 
> I read your comments and have been busy working on enhancing
> the patch (among other things).  There are a large number of
> additional contexts where constant strings are expected and
> where a missing nul needs to be detected.  Some include
> additional instances of strlen calls that my initial patch
> didn't handle, many more others that involve other string
> functions.  I have posted an updated patch that applies
> cleanly and that handles the first set.
> 
> There is also a class of problems involving constant character
> arrays initialized by a braced list, as in char [] = { x, y, z };
> Those are currently not recognized as strings even if they are
> nul-terminated, but they are far more likely to be a source of
> these problems than string literals, certainly in C++ where
> string initializers must fit in the array.  I am testing a patch
> to convert those into STRING_CST so they can be handled as well.
> 
> Since initializing arrays with more elements than fit is
> undefined in C and since the behavior is undefined at compile
> time it seems to me that rejecting such initializers with
> a hard error (as opposed to a warning) would be appropriate
> and obviate having to deal with them in the middle-end.
> 

We do not want to change what is currently accepted by the
front end. period.

But there is no reason why ambiguous string constants
have to be passed to the middle end.

For instance char c[2] = "a\0"; should look like c[1] = "a";
while c[2] = "aaa"; should look like c[2] = "aa"; varasm.c
will cut the excess precision off anyway.

That is TREE_STRING_LENGTH (str) == 3 and TREE_STRING_POINTER(str) = "aa\0";

I propose to have all STRING_CST always be created by the
FE with explicit nul termination, but the
TYPE_SIZE_UNIT (TREE_TYPE (str)) >= TREE_STRING_LENGTH(str) in normal case 
(null-terminated)
TREE_SIZE_UNIT (TREE_TYPE (str)) < TREE_STRING_LENGTH(str) if non zero 
terminated,
truncated in the initializer.

Do you understand what I mean?


Bernd.

Re: PING [PATCH] warn for strlen of arrays with missing nul (PR 86552)

[Bernd Edlinger]

Hi,

>@@ -621,6 +674,12 @@ c_strlen (tree src, int only_value)
>   maxelts = maxelts / eltsize - 1;
>   }
> 
>+  /* Unless the caller is prepared to handle it by passing in a non-null
>+ ARR, fail if the terminating nul doesn't fit in the array the string
>+ is stored in (as in const char a[3] = "123";  */
>+  if (!arr && maxelts < strelts)
>+return NULL_TREE;
>+

this is c_strlen, how is the caller ever supposed to handle non-zero terminated 
strings???
especially if you do this above?

>+c_strlen (tree src, int only_value, tree *arr /* = NULL */)
> {
>   STRIP_NOPS (src);
>+
>+  /* Used to detect non-nul-terminated strings in subexpressions
>+ of a conditional expression.  When ARR is null, point it at
>+ one of the elements for simplicity.  */
>+  tree arrs[] = { NULL_TREE, NULL_TREE };
>+  if (!arr)
>+arr = arrs;

>@@ -11427,7 +11478,9 @@ string_constant (tree arg, tree *ptr_offset)
>   unsigned HOST_WIDE_INT length = TREE_STRING_LENGTH (init);
>   length = string_length (TREE_STRING_POINTER (init), charsize,
> length / charsize);
>-  if (compare_tree_int (array_size, length + 1) < 0)
>+  if (nulterm)
>+*nulterm = array_elts > length;
>+  else if (array_elts <= length)
> return NULL_TREE;

I don't understand why you can't use
compare_tree_int (TYPE_SIZE_UNIT (TREE_TYPE (init)), TREE_STRING_LENGTH (init))
instead of this convoluted code above ???

Sorry, this patch does not look like it is ready any time soon.


But actually I am totally puzzled by your priorities.
This is what I see right now:

1) We have missing warnings.
2) We have wrong code bugs.
3) We have apparently a specification error on the C Language standard (*)


Why are you prioritizing 1) over 2) thus blocking my attempts to fix a wrong 
code
issue,and why do you not tackle 3) in your WG14?



(*) which means that GCC is currently removing code from assertions
as I pointed out here: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01695.html

This happens because GCC follows the language standards literally right now.

I would say too literally, and it proves that the language standard's logic is
flawed IMHO.

Thanks
Bernd.

[PATCH] [Ada] Make middle-end string literals NUL terminated

[Bernd Edlinger]

Hi!


This fixes a couple STRING_CST that are not explicitly NUL terminated.
These were caught in a new check in varasm.c I am currently working on.

Having a NUL terminated string does not change the binary output, but it
makes things easier for he middle-end.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
2018-07-31  Bernd Edlinger  

	* gcc-interface/trans.c (gnat_to_gnu): Make string literal properly
	NUL terminated.
	* gcc-interface/utils2.c (expand_sloc): Likewise.

diff -pur gcc/ada/gcc-interface/trans.c gcc/ada/gcc-interface/trans.c
--- gcc/ada/gcc-interface/trans.c	2018-07-17 10:10:04.0 +0200
+++ gcc/ada/gcc-interface/trans.c	2018-07-31 11:16:27.350728886 +0200
@@ -6079,7 +6079,7 @@ gnat_to_gnu (Node_Id gnat_node)
 	 where GCC will want to treat it as a C string.  */
 	  string[i] = 0;
 
-	  gnu_result = build_string (length, string);
+	  gnu_result = build_string (length + 1, string);
 
 	  /* Strings in GCC don't normally have types, but we want
 	 this to not be converted to the array type.  */
diff -pur gcc/ada/gcc-interface/utils2.c gcc/ada/gcc-interface/utils2.c
--- gcc/ada/gcc-interface/utils2.c	2017-12-21 07:57:41.0 +0100
+++ gcc/ada/gcc-interface/utils2.c	2018-07-31 11:44:01.517117923 +0200
@@ -1844,7 +1844,7 @@ expand_sloc (Node_Id gnat_node, tree *fi
 }
 
   const int len = strlen (str);
-  *filename = build_string (len, str);
+  *filename = build_string (len + 1, str);
   TREE_TYPE (*filename) = build_array_type (char_type_node,
 	build_index_type (size_int (len)));
   *line = build_int_cst (NULL_TREE, line_number);

[PATCH] Make GO string literals properly NUL terminated

[Bernd Edlinger]

Hi,


could someone please review this patch and check it in into the GO FE?


Thanks
Bernd.
2018-07-31  Bernd Edlinger  

	* go-gcc.cc (Gcc_backend::string_constant_expression): Make string
	literal properly NUL terminated.

diff -pur gcc/go/go-gcc.cc gcc/go/go-gcc.cc
--- gcc/go/go-gcc.cc	2018-06-28 19:46:36.0 +0200
+++ gcc/go/go-gcc.cc	2018-07-31 12:52:24.690236476 +0200
@@ -1394,7 +1394,7 @@ Gcc_backend::string_constant_expression(
 	  TYPE_QUAL_CONST);
   tree string_type = build_array_type(const_char_type, index_type);
   TYPE_STRING_FLAG(string_type) = 1;
-  tree string_val = build_string(val.length(), val.data());
+  tree string_val = build_string(val.length() + 1, val.data());
   TREE_TYPE(string_val) = string_type;
 
   return this->make_expression(string_val);

Re: [PATCH] Fix the damage done by my other patch from yesterday to strlenopt-49.c

[Bernd Edlinger]

On 07/30/18 15:03, Richard Biener wrote:
> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
> 
>> Hi,
>>
>> this is how I would like to handle the over length strings issue in the C FE.
>> If the string constant is exactly the right length and ends in one explicit
>> NUL character, shorten it by one character.
>>
>> I thought Martin would be working on it,  but as this is a really simple fix,
>> I would dare to send it to gcc-patches anyway, hope you don't mind...
>>
>> The patch is relative to the other patch here: 
>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
> 
> I'll leave this to FE maintainers but can I ask you to verify the
> (other) FEs do not leak this kind of invalid initializers to the
> middle-end?  I suggest to put this verification in
> output_constructor which otherwise happily truncates initializers
> with excess size.  There's also gimplification which might elide
> a = { "abcd", "cdse" }; to  a.x = "abcd"; a.y = "cdse"; but
> hopefully there the GIMPLE verifier (verify_gimple_assign_single)
> verifies this - well, it only dispatches to useless_type_conversion_p
> (lhs_type, rhs1_type) for this case, but non-flexarrays should be
> handled fine there.
> 

Okay, this is what I am currently playing with.
There is still a major fault in the fortran FE, but I believe sanitizing
the middle-end is worth it

IMHO sanitizing should have priority over new optimizations :(


Thanks
Bernd.
Index: gcc/varasm.c
===
--- gcc/varasm.c	(Revision 263072)
+++ gcc/varasm.c	(Arbeitskopie)
@@ -4774,6 +4774,29 @@ initializer_constant_valid_for_bitfield_p (tree va
   return false;
 }
 
+/* Check if a STRING_CST fits into the field.
+   Tolerate only the case when the NUL termination
+   does not fit into the field.   */
+
+bool
+check_string_literal (tree string, unsigned HOST_WIDE_INT size)
+{
+  tree eltype = TREE_TYPE (TREE_TYPE (string));
+  unsigned HOST_WIDE_INT elts = tree_to_uhwi (TYPE_SIZE_UNIT (eltype));
+  const char *p = TREE_STRING_POINTER (string);
+  int len = TREE_STRING_LENGTH (string);
+
+  if (elts != 1 && elts != 2 && elts != 4)
+return false;
+  if (len <= 0 || len % elts != 0)
+return false;
+  if ((unsigned)len != size && (unsigned)len != size + elts)
+return false;
+  if (memcmp (p + len - elts, "\0\0\0\0", elts) != 0)
+return false;
+  return true;
+}
+
 /* output_constructor outer state of relevance in recursive calls, typically
for nested aggregate bitfields.  */
 
@@ -4942,6 +4965,7 @@ output_constant (tree exp, unsigned HOST_WIDE_INT
 	case STRING_CST:
 	  thissize
 	= MIN ((unsigned HOST_WIDE_INT)TREE_STRING_LENGTH (exp), size);
+	  gcc_checking_assert (check_string_literal (exp, thissize));
 	  assemble_string (TREE_STRING_POINTER (exp), thissize);
 	  break;
 	case VECTOR_CST:

Re: [PATCH] Make GO string literals properly NUL terminated

[Bernd Edlinger]

On 07/31/18 16:40, Ian Lance Taylor wrote:
> On Tue, Jul 31, 2018 at 5:14 AM, Bernd Edlinger
>  wrote:
>>
>> could someone please review this patch and check it in into the GO FE?
> 
> I don't understand why the change is correct, and you didn't explain
> it.  Go strings are not NUL terminated.  Go strings always have an
> associated length.
> 

Yes, sorry.  Effectively for go this change is a no-op.
I'll elaborate a bit.

This makes it easier for the middle-end to distinguish between nul-terminated
and not nul terminated strings.  Especially if wide character strings
may also may come along.

In C a not nul terminated string might be declared like
char x[2] = "12";
it is always a STRING_CST object of length 3, with value "12\0".
The array_type is char[0..1]

while a nul terminated string is declared like
char x[3] = "12"
it is also a STRING_CST object of length 3, with value "12\0"
The array_type is char[0..2]

Note however the array type is different.
So with this convention one only needs to compare the array type
size with the string length which is much easier than looking for
a terminating wide character, which is rarely done right.

At the end varasm.c filters the excess NUL byte away, but
I would like to add a checking assertion there that this does not
strip more than max. one wide character nul byte.


Bernd.

Re: [PATCH] Make strlen range computations more conservative

[Bernd Edlinger]

> Certainly not every "strlen" has these semantics.  For example,
> this open-coded one doesn't:
> 
>int len = 0;
>for (int i = 0; s.a[i]; ++i)
>  ++len;
> 
> It computes 2 (with no warning for the out-of-bounds access).
> 

yes, which is questionable as well, but that happens only
if the source code accesses the array via s.a[i]
not if it happens to use char *, as this experiment shows:

$ cat y1.c
int len (const char *x)
{
   int len = 0;
   for (int i = 0; x[i]; ++i)
 ++len;
   return len;
}

const char a[3] = "123";

int main ()
{
   return len(a);
}

$ gcc -O3 y1.c
$  ./a.out ; echo $?
3

The loop is not optimized away.

$ cat y2.c
const char a[3] = "123";

int main ()
{
   int len = 0;
   for (int i = 0; a[i]; ++i)
 ++len;
   return len;
}

$ gcc -O3 y2.c
$ ./a.out ; echo $?
2


The point I make is that it is impossible to know where the function
is inlined, and if the original code can be broken in surprising ways.
And most importantly strlen is often used in security relevant ways.


> So if the standard doesn't guarantee it and different kinds
> of accesses behave differently, how do we explain what "works"
> and what doesn't without relying on GCC implementation details?
> 
> If we can't then the only language we have in common with users
> is the standard.  (This, by the way, is what the C memory model
> group is trying to address -- the language or feature that's
> missing from the standard that says when, if ever, these things
> might be valid.)

Sorry, but there are examples of undefined behaviour that GCC does
deliberately not use for code optimizations, but only for warnings.
I mean undefinedness of signed shift left overflow for instance.

I think the possible return value of strlen should be also not used
for code optimizations.

Because your optimization assumes the return value of strlen
is always in the range 0..size-1 even if the string is not nul terminated.
But that is the only value that can _never_ be returned if the string is
not nul terminated.  Therefore this is often used as check for
zero-termination. (*)

But in reality the return value is always in range size..infinity or
the function aborts, code like assert(strlen(x) < sizeof(x)) uses
this basic knowledge.  The standard should mention these magic
powers of strlen, and state that it will either abort or return >= sizeof(x).
It does not help anybody to be unclear.


(*): This is even done here:
__strcpy_chk (char *__restrict__ dest, const char *__restrict__ src,
  size_t slen)
{
  size_t len = strlen (src);
  if (len >= slen)
__chk_fail ();
  return memcpy (dest, src, len + 1);
}

If you are right __chk_fail will never be called. So why not optimize
it away?


Bernd.

Re: [PATCH] Make GO string literals properly NUL terminated

[Bernd Edlinger]

> The change to have all STRING_CSTs NUL terminated (but that NUL
> termination not necessarily inclided in STRING_LENGTH) is a good
> one.
> 
> I'm not sure how we can reliably verify NUL termination after the
> fact though and build_string already makes sure to NUL terminate
> STRING_CSTs.  So if GO strings are not NUL terminated then
> the STRING_CSTs still are.

The advantage is that there are less variations how string literals look
like in the middle end.  We will have a simple way to determine if
a string literal is NUL terminated or not.  And checking that property
in varasm.c is exactly the right thing to do.

String literals always have an array_type which may be shorter
than TREE_STRING_LENGTH, but that chops off only exactly
one wide character nul. Otherwise if the array_type is equal or larger,
we know for sure the value is nul terminated. In the middle-end
we can easily determine if a string is not NUL terminated by:

compare_tree_int (TYPE_SIZE_UNIT (TREE_TYPE (init)),
   TREE_STRING_LENGTH (init)) < 0

I did use that already in my patch for pr86711.

Additionally not having oversize string constants produced
by the front ends, where the extra characters are good for nothing,
also helps to improve correctness.


Bernd.

Re: [PATCH] Make GO string literals properly NUL terminated

[Bernd Edlinger]

>> > The change to have all STRING_CSTs NUL terminated (but that NUL
>> > termination not necessarily inclided in STRING_LENGTH) is a good
>> > one.
>> >
>> > I'm not sure how we can reliably verify NUL termination after the
>> > fact though and build_string already makes sure to NUL terminate
>> > STRING_CSTs.  So if GO strings are not NUL terminated then
>> > the STRING_CSTs still are.
>>
>> The advantage is that there are less variations how string literals look
>> like in the middle end.  We will have a simple way to determine if
>> a string literal is NUL terminated or not.  And checking that property
>> in varasm.c is exactly the right thing to do.
>>
>> String literals always have an array_type which may be shorter
>> than TREE_STRING_LENGTH, but that chops off only exactly
>> one wide character nul. Otherwise if the array_type is equal or larger,
>> we know for sure the value is nul terminated. In the middle-end
>> we can easily determine if a string is not NUL terminated by:
>>
>> compare_tree_int (TYPE_SIZE_UNIT (TREE_TYPE (init)),
>>TREE_STRING_LENGTH (init)) < 0
>>
>> I did use that already in my patch for pr86711.
>
> Hmm.  How does that tell you whether the string is NUL terminated?
> TREE_STRING_LENGTH includes the NUL termination and if it is
> a significant char then TYPE_SIZE_UNIT should as well.

I debugged that code a lot recently.
static const char x[2] = "ab"
gives a TREE_STRING_LENGTH of 3, the TREE_TYPE of that
beast is an array type for char[2]. and TYPE_SIZE_UNIT = 2.

An ordinary C string "ab" has TYPE_SIZE_UNIT(TREE_TYPE(x)) = 3.

Of course with wide caracher strings the TREE_STING_LENGTH
and TYPE_SIZE_UNIT of the ARRAY_TYPE are multiple of
the used wide character type.

So I would like to be able to assume that the STRING_CST objects
are internally always generated properly by the front end.
And that the ARRAY_TYPE of the string literal either has the
same length than the TREE_STRING_LENGTH or if it is shorter,
this is always exactly one (wide) character size less than TREE_STRING_LENGTH

The idea is to use this property of string literals where needed,
and check rigorously in varasm.c.

Does that make sense?

>
> Isn't a proper test to look at TREE_STRING_POINTER[TREE_STRING_LENGTH - 1]
> (for HOST_CHAR_BITS strings)?
>

There are also wide character strings, and all those test are broken everywhere
for wide characters right now.

Therefore checking the string constants at varasm.c revealed a lot of intersting
things.
I will post several patches in the afternoon.

> Relying on the type here looks somewhat fragile to me.
>
> Abstracting a string_cst_nul_terminated_p () helper would be a good
> idea I guess.

Yes. indeed.

> I realize using strlen(TREE_STRING_POINTER) doesn't work because
> of embedded NULs.
>
>> Additionally not having oversize string constants produced
>> by the front ends, where the extra characters are good for nothing,
>> also helps to improve correctness.
>>

Re: Committed: gcc.misc-tests/outputs.exp (outest): Fix typo "is_target"

[Bernd Edlinger]

Oops,

thanks for fixing this problem.

To my excuse I would like to note,
that the script error does not happen on x86_64-pc-linux-gnu,
probably it would only happen when a file is left over.

Since usually this is never executed because $outs is empty:

foreach f $outs {
file delete $f
# collect2 may create .cdtor* files in -save-temps link tests,
# ??? without regard to aux output naming conventions.
# Limit this exception to targets that define EH_FRAME_THROUGH_COLLECT2.
if { !(([istarget powerpc*-*-aix*] || [is_target hppa*-*-hpux*])
   && ([string match "*.cdtor.*" $f]
   || [string match "*.gcc_args" $f])) } {
lappend outb $f
}
}

Can you say which target was this, where you found this bug?
Which file was in $outs?

I am also a bit surprised that a script error in one test aborts
the whole gcc.target tests.  How can that be?

Thanks
Bernd.


On 2/16/21 2:33 AM, Hans-Peter Nilsson wrote:
> Committed as obvious.  Please be more careful; this typo
> should have been obvious in "make check" output as below.
> 
> Commit-log:
> ---
> Fix typo for istarget in "is_target hppa*-*-hpux*", yielding
> an error running the test-suite for any target not matching
> powerpc*-*-aix* (presumably, by code inspection), aborting
> the check-gcc (check-gcc-c) regression test run some 3000
> tests before the last one, missing e.g. all gcc.target
> tests like so:
> 
> -
> ...
> Running /x/gcc/gcc/testsuite/gcc.misc-tests/outputs.exp ...
> ERROR: (DejaGnu) proc "is_target hppa*-*-hpux*" does not exist.
> The error code is TCL LOOKUP COMMAND is_target
> The info on the error is:
> invalid command name "is_target"
> while executing
> "::tcl_unknown is_target hppa*-*-hpux*"
> ("uplevel" body line 1)
> invoked from within
> "uplevel 1 ::tcl_unknown $args"
> 
>   === gcc Summary ===
> ...
> -
> 
> gcc/testsuite:
>   * gcc.misc-tests/outputs.exp (outest): Fix typo "is_target".
> ---
>  gcc/testsuite/gcc.misc-tests/outputs.exp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp 
> b/gcc/testsuite/gcc.misc-tests/outputs.exp
> index d5a9709910c2..4d904bde31d5 100644
> --- a/gcc/testsuite/gcc.misc-tests/outputs.exp
> +++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
> @@ -192,7 +192,7 @@ proc outest { test sources opts dirs outputs } {
>   # collect2 may create .cdtor* files in -save-temps link tests,
>   # ??? without regard to aux output naming conventions.
>   # Limit this exception to targets that define EH_FRAME_THROUGH_COLLECT2.
> - if { !(([istarget powerpc*-*-aix*] || [is_target hppa*-*-hpux*])
> + if { !(([istarget powerpc*-*-aix*] || [istarget hppa*-*-hpux*])
>  && ([string match "*.cdtor.*" $f]
>  || [string match "*.gcc_args" $f])) } {
>   lappend outb $f
> 

Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions

[Bernd Edlinger]

On 8/2/21 3:07 PM, Eric Botcazou wrote:
>> It was pointed out in PR101598 to be inappropriate, that
>> ignored Ada decls receive the source line number which was
>> recorded in the function decl's DECL_SOURCE_LOCATION.
>> Therefore set all front-end-generated Ada decls with
>> DECL_IGNORED_P to UNKNOWN_LOCATION.
>>
>> 2021-07-24  Bernd Edlinger  
>>
>>  PR debug/101598
>>  * gcc-interface/trans.c (Subprogram_Body_to_gnu): Set the
>>  DECL_SOURCE_LOCATION of DECL_IGNORED_P gnu_subprog_decl to
>>  UNKNOWN_LOCATION.
> 
> Is that really needed in DWARF 5?  If no, I'm not sure that we want it.
> 

No, this one is completely optional, only DWARF 4 may have additional
issues without part 1/2 of this patch.

The location of these ignored Ada decls looks completely sane to me.
However, it was an unintentional side effect of the patch to allow
minimal debugging of ignored decls.  This means we can now step into
those functions or set line breakpoints there, while previously that
was not possible.  And I guess it could be considered an improvement.

So it's your choice, how you want these functions to be debugged.


Thanks
Bernd.

Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions

[Bernd Edlinger]

On 8/4/21 4:33 PM, Eric Botcazou wrote:
>> The location of these ignored Ada decls looks completely sane to me.
>> However, it was an unintentional side effect of the patch to allow
>> minimal debugging of ignored decls.  This means we can now step into
>> those functions or set line breakpoints there, while previously that
>> was not possible.  And I guess it could be considered an improvement.
>>
>> So it's your choice, how you want these functions to be debugged.
> 
> The requirement on the GDB side is that these functions *cannot* be stepped 
> into, i.e. that they be completely transparent for the GDB user.  But we 
> still 
> want to have location information in the compiler itself to debug it.
> 

Well, I see.

But it is okay that we can set a breakpoint on defs__struct1IP,
in the test case of PR 101598.
And the debugger shall only show assembler here.
Right?

Do you have an example where this location information is used in the
compiler itself for debugging?

Of course we could do something like

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index b91a9b5..c0ff4c6 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -28546,6 +28546,9 @@ dwarf2out_set_ignored_loc (unsigned int line, unsigned i
 {
   dw_fde_ref fde = cfun->fde;
 
+  if (is_ada ())
+return;
+
   fde->ignored_debug = false;
   set_cur_line_info_table (function_section (fde->decl));
 

But it would regress the attached test case (the Ada-equivalent
of PR 97937):

$ gnatmake -O2 main.adb -g -save-temps -f
produces line info for Test2:

test__test2:
.LFB8:
.cfi_startproc
.loc 1 8 4 view .LVU3
movl%edi, %eax
ret
.cfi_endproc

while with the above patch we would get something like

test__test2:
.LFB8:
.cfi_startproc
movl%edi, %eax
ret
.cfi_endproc

and, indeed it is impossible to step into test2 or get the source
line if we insert a breakpoint at the label test__test2.

I assume You would agree that having the location for Test2 is better
than no debug info at all?

So Maybe something like the following might work for You?

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index b91a9b5..c0ff4c6 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -28546,6 +28546,9 @@ dwarf2out_set_ignored_loc (unsigned int line, unsigned i
 {
   dw_fde_ref fde = cfun->fde;
 
+  if (is_ada () && DECL_ARTIFICIAL (cfun->decl))
+return;
+
   fde->ignored_debug = false;
   set_cur_line_info_table (function_section (fde->decl));
 

This would remove the location info in the test case of PR 101598,
and still have location info in the ada variant of PR 97937.


What do you think?


Thanks
Bernd.
package test is

   type Func_Ptr is access function (X : Integer) return Integer;

   function Test1 (X : Integer) return Integer;
   function Test2 (X : Integer) return Integer;
   function DoIt (X : Integer; Func : Func_Ptr) return Integer;

end test;
package body test is

   function Test1 (X : Integer) return Integer is
   begin
  return X;
   end Test1;

   function Test2 (X : Integer) return Integer is
   begin
  return X;
   end Test2;

   function DoIt (X : Integer; Func : Func_Ptr) return Integer is
   begin
  return Func (X);
   end DoIt;

end test;
with Ada.Text_IO; use Ada.Text_IO;
with test;

procedure Main is

   -- Declare a pointer type, pointing to a function that takes
   -- two Integer variables as input and returns a Integer


   X : Integer := 7;
   Y : Integer := test.DoIt (X, test.Test1'Access);
   Z : Integer := test.DoIt (X, test.Test2'Access);

begin
   Put_Line (X'Img & " " & Y'Img & " " & Z'Img);
end Main;

Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions

[Bernd Edlinger]

On 8/9/21 4:37 PM, Eric Botcazou wrote:
>> But it is okay that we can set a breakpoint on defs__struct1IP,
>> in the test case of PR 101598.
>> And the debugger shall only show assembler here.
>> Right?
> 
> The defs__struct1IP procedure should be totally transparent for the user, so 
> setting a breakpoint in it is not supposed to come into play.
> 

The symbol defs__struct1IP is a global symbol, so once a user know its name,
that user can set a breakpoint there, has never been changed, and I don't know
how to avoid that.

>> Do you have an example where this location information is used in the
>> compiler itself for debugging?
> 
> That's useful when you compile the code with -gnatD, i.e when you debug the 
> intermediate code generated by the front-end.
> 

Ah, thanks, I tried it but the defs__struct1IP function has
DECL_IGNORED_P = false when I build it with -gnatD.

So that would not be affected by setting DECL_SOURCE_LOCATION to
UNKNOWN_LOCATION as done in the proposed patch, because that is only
done for functions with DECL_IGNORED_P = true.

>> I assume You would agree that having the location for Test2 is better
>> than no debug info at all?
> 
> But we want no debug info at all for these IP functions.
> 
>> What do you think?
> 
> I guess I still don't understand why DECL_IGNORED_P was changed.
> 

We have several issues here.

First we have DECL_IGNORED_P = true functions, where DECL_SOURCE_LOCATION
is UNKNOWN_LOCATION, but they have *wrong* line numbers, either because a
preceding function's last line number extends to the ignored function, or
because of a bug in the assembler which mostly affects -gdwarf-4 with certain
versions if the binutils toolchain.

Then we have ordinary functions with DECL_IGNORED_P = false,
but they are morphed into a thunk calling a similar looking function
and the thunk has now DECL_IGNORED_P = true, and all debug info
removed, except the DECL_SOURCE_LOCATION.  To make this even worse,
the similar looking function is inlined into the thunk again, and
all debug info is again stripped away.

And when this happens it is desirable to at least see the source line where
the original function was declared.


As an example, please consider this test case:

$ cat test.ads
package test is

   type Func_Ptr is access function (X : Integer) return Integer;

   function Test1 (X : Integer) return Integer;
   function Test2 (X : Integer) return Integer;
   function DoIt (X : Integer; Func : Func_Ptr) return Integer;

end test;
$ cat test.ads
package test is

   type Func_Ptr is access function (X : Integer) return Integer;

   function Test1 (X : Integer) return Integer;
   function Test2 (X : Integer) return Integer;
   function DoIt (X : Integer; Func : Func_Ptr) return Integer;

end test;

$ cat test.adb
package body test is

   function Test1 (X : Integer) return Integer is
   begin
  return X;
   end Test1;

   function Test2 (X : Integer) return Integer is
   begin
  return X;
   end Test2;

   function DoIt (X : Integer; Func : Func_Ptr) return Integer is
   begin
  return Func (X);
   end DoIt;

end test;

$ cat main.adb
with Ada.Text_IO; use Ada.Text_IO;
with test; use test;

procedure Main is

   X : Integer := 7;
   Y : Integer := DoIt (X, Test1'Access);
   Z : Integer := DoIt (X, Test2'Access);

begin
   Put_Line (X'Img & " " & Y'Img & " " & Z'Img);
end Main;

$ gnatmake -f -g -O2 main.adb -save-temp -fdump-tree-all-lineno

Now Test1 and Test2 are ordinary functions, but Test2 ends up as DECL_IGNORED_P 
= true,
that happens between test.adb.052t.local-fnsummary2 and 
test.adb.092t.fixup_cfg3:

in test.adb.052t.local-fnsummary2 we have:

integer test.test1 (integer x)
{
   [local count: 1073741824]:
  [test.adb:5:7] return x_1(D);

}

and

integer test.test2 (integer x)
{
   [local count: 1073741824]:
  [test.adb:10:7] return x_1(D);

}


but in test.adb.092t.fixup_cfg3

we have

integer test.test1 (integer x)
{
   [local count: 1073741824]:
  [test.adb:5:7] return x_1(D);

}

and

integer test.test2 (integer x)
{
  integer D.4674;
  integer retval.5;
  integer _4;

   [local count: 1073741824]:
  # DEBUG x => x_1(D)
  _4 = x_1(D);
  # DEBUG x => NULL
  retval.5_2 = _4;
  return retval.5_2;

}


the line numbers are gone, and the function has DECL_IGNORED_P,
but still a useful DECL_SOURCE_LOCATION, I don't know
where the DECL_SOURCE_LOCATION can be seen in the dump files,
but from debugging this effect, I know that quite well.

This second effect is why as a special case DECL_IGNORED_P functions
with valid looking DECL_SOURCE_LOCATION have now a .loc statement,
because that is less surprising to a user than having no line numbers
at all here.


Thanks
Bernd.

Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions

[Bernd Edlinger]

On 8/10/21 10:56 PM, Eric Botcazou wrote:
>> Ah, thanks, I tried it but the defs__struct1IP function has
>> DECL_IGNORED_P = false when I build it with -gnatD.
>>
>> So that would not be affected by setting DECL_SOURCE_LOCATION to
>> UNKNOWN_LOCATION as done in the proposed patch, because that is only
>> done for functions with DECL_IGNORED_P = true.
> 
> Ouch, I should have checked it myself...  Thanks for doing the investigation.
> 

no problem.

>> Then we have ordinary functions with DECL_IGNORED_P = false,
>> but they are morphed into a thunk calling a similar looking function
>> and the thunk has now DECL_IGNORED_P = true, and all debug info
>> removed, except the DECL_SOURCE_LOCATION.  To make this even worse,
>> the similar looking function is inlined into the thunk again, and
>> all debug info is again stripped away.
>>
>> And when this happens it is desirable to at least see the source line where
>> the original function was declared.
>>
>>
>> As an example, please consider this test case:
>>
>> $ cat test.ads
>> package test is
>>
>>type Func_Ptr is access function (X : Integer) return Integer;
>>
>>function Test1 (X : Integer) return Integer;
>>function Test2 (X : Integer) return Integer;
>>function DoIt (X : Integer; Func : Func_Ptr) return Integer;
>>
>> end test;
>> $ cat test.ads
>> package test is
>>
>>type Func_Ptr is access function (X : Integer) return Integer;
>>
>>function Test1 (X : Integer) return Integer;
>>function Test2 (X : Integer) return Integer;
>>function DoIt (X : Integer; Func : Func_Ptr) return Integer;
>>
>> end test;
>>
>> $ cat test.adb
>> package body test is
>>
>>function Test1 (X : Integer) return Integer is
>>begin
>>   return X;
>>end Test1;
>>
>>function Test2 (X : Integer) return Integer is
>>begin
>>   return X;
>>end Test2;
>>
>>function DoIt (X : Integer; Func : Func_Ptr) return Integer is
>>begin
>>   return Func (X);
>>end DoIt;
>>
>> end test;
>>
>> $ cat main.adb
>> with Ada.Text_IO; use Ada.Text_IO;
>> with test; use test;
>>
>> procedure Main is
>>
>>X : Integer := 7;
>>Y : Integer := DoIt (X, Test1'Access);
>>Z : Integer := DoIt (X, Test2'Access);
>>
>> begin
>>Put_Line (X'Img & " " & Y'Img & " " & Z'Img);
>> end Main;
>>
>> $ gnatmake -f -g -O2 main.adb -save-temp -fdump-tree-all-lineno
>>
>> Now Test1 and Test2 are ordinary functions, but Test2 ends up as
>> DECL_IGNORED_P = true, that happens between test.adb.052t.local-fnsummary2
>> and test.adb.092t.fixup_cfg3:
> 
> Ouch (bis).  Quite unexpected that DECL_IGNORED_P is set out of nowhere.  
> It's 
> Identical Code Folding which turns Test2 into a thunk?
> 

Yes, the identical functions trigger this folding.

Originally I discovered this when I wanted to debug the
arm back-end, where we have several identical functions:

static bool
arm_align_anon_bitfield (void)
{
  return TARGET_AAPCS_BASED;
}

[...]

static bool
arm_cxx_guard_mask_bit (void)
{
  return TARGET_AAPCS_BASED;
}

the second one had no line numbers, but since it was not
at the beginning of the assembly gdb did show a totally
unrelated line.

In general I can say that debugging optimized code is not
a very pleasant experience.  But this issue happens only
rarely, while another issue is much more dominant.

You will probably see it quite often while debugging
the gcc middle end that stepping over inline functions
does not work right, one often steps over some code,
and ends up in the tree_check inline function.
That's because of an ambiguity in the dwarf debug
info of inline ranges.  It does not have the view number
where the inline range ends exactly, but only the PC.

I have been working on some gdb patches to work around the
problem, but they are stuck unfortunately :-(
"Improve debugging of optimized code"
https://sourceware.org/pipermail/gdb-patches/2021-January/175617.html

>> in test.adb.052t.local-fnsummary2 we have:
>>
>> integer test.test1 (integer x)
>> {
>>[local count: 1073741824]:
>>   [test.adb:5:7] return x_1(D);
>>
>> }
>>
>> and
>>
>> integer test.test2 (integer x)
>> {
>>[local count: 1073741824]:
>>   [test.adb:10:7] return x_1(D);
>>
>> }
>>
>>
>> but in test.adb.092t.fixup_cfg3
>>
>> we have
>>
>> integer test.test1 (integer x)
>> {
>>[local count: 1073741824]:
>>   [test.adb:5:7] return x_1(D);
>>
>> }
>>
>> and
>>
>> integer test.test2 (integer x)
>> {
>>   integer D.4674;
>>   integer retval.5;
>>   integer _4;
>>
>>[local count: 1073741824]:
>>   # DEBUG x => x_1(D)
>>   _4 = x_1(D);
>>   # DEBUG x => NULL
>>   retval.5_2 = _4;
>>   return retval.5_2;
>>
>> }
>>
>>
>> the line numbers are gone, and the function has DECL_IGNORED_P,
>> but still a useful DECL_SOURCE_LOCATION, I don't know
>> where the DECL_SOURCE_LOCATION can be seen in the dump files,
>> but from debugging this effect, I know that quite well.
>>
>> This second effect is why as a special case DECL_IGNORED_P functions
>> with valid looki

[PING**2] [PATCH] Fix PR c++/92024

[Bernd Edlinger]

Ping...

On 10/18/19 3:19 PM, Bernd Edlinger wrote:
> Ping...
> 
> for the c++ FE and testsuite changes in the updated patch
> here: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00916.html
> 
> 
> Thanks
> Bernd.
> 
> 
> 
> 
> On 10/12/19 8:10 PM, Bernd Edlinger wrote:
>> On 10/11/19 6:31 PM, Jason Merrill wrote:
>>> On 10/10/19 2:06 PM, Bernd Edlinger wrote:
>>>> On 10/10/19 7:49 PM, Jason Merrill wrote:
>>>>
>>>> if -Wshadow=compatible-local is used, the can_convert function crashes
>>>> in instantiate_class_template_1.
>>>
>>> Right, checking can_convert is problematic here, as it can cause template 
>>> instantiations that change the semantics of the program.  Or, in this case, 
>>> crash.
>>>
>>
>> So I try to make C++ behave more consistently with the code in c-decl.c,
>> thus dependent on warn_shadow but not on warn_shadow_local and/or
>> warn_shadow_compatible_local:
>>
>>if (warn_shadow)
>>   warning_code = OPT_Wshadow;
>> else if (comptypes (TREE_TYPE (old_decl), TREE_TYPE (new_decl)))
>>   warning_code = OPT_Wshadow_compatible_local;
>> else
>>   warning_code = OPT_Wshadow_local;
>> warned = warning_at (DECL_SOURCE_LOCATION (new_decl), 
>> warning_code,
>>  "declaration of %qD shadows a parameter",
>>  new_decl);
>>
>> I cannot remove the if (warn_shadow) since this breaks gcc.dg/pr48062.c
>> which uses:
>>
>> #pragma GCC diagnostic ignored "-Wshadow"
>>
>> to disable a -Wshadow=compatible-local warning, but while -Wno-shadow on the
>> command line disables also dependent warnings the pragma does not (always) 
>> do that.
>>
>> So instead I'd like to adjust the doc of -Wshadow to reflect the 
>> implementation
>> and remove the if(warn_shadow_local) to have C and C++ behave identical and
>> hopefully now in sync with the doc.
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
>>
>>
>> Thanks
>> Bernd.
>>

[PING] [PATCH] Fix dwarf-lineinfo inconsistency of inlined subroutines

[Bernd Edlinger]

Ping...

I'd like to ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html


Thanks
Bernd.

On 10/20/19 9:58 PM, Bernd Edlinger wrote:
> Hi,
> 
> this fixes an issue with the gdb step-over aka. "n" command.
> 
> It can be seen when you debug an optimized stage-3 cc1
> it does not affect -O0 code, though.
> 
> This example debug session will explain the effect.
> 
> (gdb) b get_alias_set
> Breakpoint 5 at 0xa099f0: file ../../gcc-trunk/gcc/alias.c, line 837.
> (gdb) r
> Breakpoint 5, get_alias_set (t=t@entry=0x77ff7ab0) at 
> ../../gcc-trunk/gcc/alias.c:837
> 837 if (t == error_mark_node
> (gdb) n
> 839 && (TREE_TYPE (t) == 0 || TREE_TYPE (t) == error_mark_node)))
> (gdb) n
> 3382return __t;  <-- now we have a problem: wrong line info here
> (gdb) bt
> #0  get_alias_set (t=t@entry=0x77ff7ab0) at 
> ../../gcc-trunk/gcc/tree.h:3382
> #1  0x00b25dfe in set_mem_attributes_minus_bitpos 
> (ref=0x7746f990, t=0x77ff7ab0, objectp=1, bitpos=...)
> at ../../gcc-trunk/gcc/emit-rtl.c:1957
> #2  0x01137a55 in make_decl_rtl (decl=0x77ff7ab0) at 
> ../../gcc-trunk/gcc/varasm.c:1518
> #3  0x0113b6e8 in assemble_variable (decl=0x77ff7ab0, 
> top_level=, at_end=, 
> dont_output_data=0) at ../../gcc-trunk/gcc/varasm.c:2246
> #4  0x0113f0ea in varpool_node::assemble_decl (this=0x7745b000) 
> at ../../gcc-trunk/gcc/varpool.c:584
> #5  0x0113fa17 in varpool_node::assemble_decl (this=0x7745b000) 
> at ../../gcc-trunk/gcc/varpool.c:750
> 
> 
> There are at least two problems here:
> 
> First you did not want to step into the TREE_TYPE, but it happens all
> the time, even if you use "n" to step over it.
> 
> And secondly, from the call stack, you don't know where you are in 
> get_alias_set.
> But the code that is executing at this point is actually the x == 0 || x == 
> error_mark_node
> from alias.c, line 839, which contains the inlined body of the TREE_TYPE, but
> the rest of the if.  So there is an inconsistency in the  
> 
> Contents of the .debug_info section:
> 
>  <2><4f686>: Abbrev Number: 12 (DW_TAG_inlined_subroutine)
> <4f687>   DW_AT_abstract_origin: <0x53d4e>
> <4f68b>   DW_AT_entry_pc: 0x7280
> <4f693>   DW_AT_GNU_entry_view: 1
> <4f695>   DW_AT_ranges  : 0xb480
> <4f699>   DW_AT_call_file   : 8  <- alias.c
> <4f69a>   DW_AT_call_line   : 839
> <4f69c>   DW_AT_call_column : 8
> <4f69d>   DW_AT_sibling : <0x4f717>
> 
>  The File Name Table (offset 0x253):
>   8 2   0   0   alias.c
>   102   0   0   tree.h
> 
> Contents of the .debug_ranges section:
> 
> b480 7280 7291 
> b480 2764 277e 
> b480 
> 
> The problem is at pc=0x7291 in the Line Number Section:
> 
>  Line Number Statements:
> 
>   [0x8826]  Special opcode 61: advance Address by 4 to 0x7284 and Line by 
> 0 to 3380
>   [0x8827]  Set is_stmt to 1
>   [0x8828]  Special opcode 189: advance Address by 13 to 0x7291 and Line 
> by 2 to 3382 (*)
>   [0x8829]  Set is_stmt to 0 (**)
>   [0x882a]  Copy (view 1)
>   [0x882b]  Set File Name to entry 8 in the File Name Table <- back to 
> alias.c
>   [0x882d]  Set column to 8
>   [0x882f]  Advance Line by -2543 to 839
>   [0x8832]  Copy (view 2)
>   [0x8833]  Set column to 27
>   [0x8835]  Special opcode 61: advance Address by 4 to 0x7295 and Line by 
> 0 to 839
>   [0x8836]  Set column to 3
>   [0x8838]  Set is_stmt to 1 <-- next line info counts: alias.c:847
>   [0x8839]  Special opcode 153: advance Address by 10 to 0x729f and Line 
> by 8 to 847
>   [0x883a]  Set column to 7
> 
> (*) this line is tree.h:3382, but the program counter is *not* within the 
> subroutine,
> but exactly at the first instruction *after* the subroutine according to the 
> debug_ranges.
> 
> What makes it worse, is that (**) makes gdb ignore the new location info 
> alias.c:839,
> which means, normally the n command would have continued to pc=0x729f, which 
> is at alias.c:847.
> 
> 
> The problem happens due to a block with only var
> This patch fixes this problem by moving (**) to the first statement with a 
> different line number.
> 
> In alias.c.316r.final this looks like that:
> 
> (note 2884 2883 1995 31 0x7f903a931ba0 NOTE_INSN_BLOCK_BEG)
> (note 1995 2884 2885 31 ../../gcc-trunk/gcc/tree.h:3377 
> NOTE_INSN_INLINE_ENTRY)
> (note 2885 1995 1996 31

[PING**2] [PATCH] Fix dwarf-lineinfo inconsistency of inlined subroutines

[Bernd Edlinger]

Ping...

On 10/27/19 9:14 AM, Bernd Edlinger wrote:
> Ping...
> 
> I'd like to ping for this patch:
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
> 
> 
> Thanks
> Bernd.
> 
> On 10/20/19 9:58 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> this fixes an issue with the gdb step-over aka. "n" command.
>>
>> It can be seen when you debug an optimized stage-3 cc1
>> it does not affect -O0 code, though.
>>
>> This example debug session will explain the effect.
>>
>> (gdb) b get_alias_set
>> Breakpoint 5 at 0xa099f0: file ../../gcc-trunk/gcc/alias.c, line 837.
>> (gdb) r
>> Breakpoint 5, get_alias_set (t=t@entry=0x77ff7ab0) at 
>> ../../gcc-trunk/gcc/alias.c:837
>> 837if (t == error_mark_node
>> (gdb) n
>> 839&& (TREE_TYPE (t) == 0 || TREE_TYPE (t) == error_mark_node)))
>> (gdb) n
>> 3382   return __t;  <-- now we have a problem: wrong line info here
>> (gdb) bt
>> #0  get_alias_set (t=t@entry=0x77ff7ab0) at 
>> ../../gcc-trunk/gcc/tree.h:3382
>> #1  0x00b25dfe in set_mem_attributes_minus_bitpos 
>> (ref=0x7746f990, t=0x77ff7ab0, objectp=1, bitpos=...)
>> at ../../gcc-trunk/gcc/emit-rtl.c:1957
>> #2  0x01137a55 in make_decl_rtl (decl=0x77ff7ab0) at 
>> ../../gcc-trunk/gcc/varasm.c:1518
>> #3  0x0113b6e8 in assemble_variable (decl=0x77ff7ab0, 
>> top_level=, at_end=, 
>> dont_output_data=0) at ../../gcc-trunk/gcc/varasm.c:2246
>> #4  0x0113f0ea in varpool_node::assemble_decl (this=0x7745b000) 
>> at ../../gcc-trunk/gcc/varpool.c:584
>> #5  0x0113fa17 in varpool_node::assemble_decl (this=0x7745b000) 
>> at ../../gcc-trunk/gcc/varpool.c:750
>>
>>
>> There are at least two problems here:
>>
>> First you did not want to step into the TREE_TYPE, but it happens all
>> the time, even if you use "n" to step over it.
>>
>> And secondly, from the call stack, you don't know where you are in 
>> get_alias_set.
>> But the code that is executing at this point is actually the x == 0 || x == 
>> error_mark_node
>> from alias.c, line 839, which contains the inlined body of the TREE_TYPE, but
>> the rest of the if.  So there is an inconsistency in the  
>>
>> Contents of the .debug_info section:
>>
>>  <2><4f686>: Abbrev Number: 12 (DW_TAG_inlined_subroutine)
>> <4f687>   DW_AT_abstract_origin: <0x53d4e>
>> <4f68b>   DW_AT_entry_pc: 0x7280
>> <4f693>   DW_AT_GNU_entry_view: 1
>> <4f695>   DW_AT_ranges  : 0xb480
>> <4f699>   DW_AT_call_file   : 8  <- alias.c
>> <4f69a>   DW_AT_call_line   : 839
>> <4f69c>   DW_AT_call_column : 8
>> <4f69d>   DW_AT_sibling : <0x4f717>
>>
>>  The File Name Table (offset 0x253):
>>   8 2   0   0   alias.c
>>   102   0   0   tree.h
>>
>> Contents of the .debug_ranges section:
>>
>> b480 7280 7291 
>> b480 2764 277e 
>> b480 
>>
>> The problem is at pc=0x7291 in the Line Number Section:
>>
>>  Line Number Statements:
>>
>>   [0x8826]  Special opcode 61: advance Address by 4 to 0x7284 and Line 
>> by 0 to 3380
>>   [0x8827]  Set is_stmt to 1
>>   [0x8828]  Special opcode 189: advance Address by 13 to 0x7291 and Line 
>> by 2 to 3382 (*)
>>   [0x8829]  Set is_stmt to 0 (**)
>>   [0x882a]  Copy (view 1)
>>   [0x882b]  Set File Name to entry 8 in the File Name Table <- back to 
>> alias.c
>>   [0x882d]  Set column to 8
>>   [0x882f]  Advance Line by -2543 to 839
>>   [0x8832]  Copy (view 2)
>>   [0x8833]  Set column to 27
>>   [0x8835]  Special opcode 61: advance Address by 4 to 0x7295 and Line 
>> by 0 to 839
>>   [0x8836]  Set column to 3
>>   [0x8838]  Set is_stmt to 1 <-- next line info counts: alias.c:847
>>   [0x8839]  Special opcode 153: advance Address by 10 to 0x729f and Line 
>> by 8 to 847
>>   [0x883a]  Set column to 7
>>
>> (*) this line is tree.h:3382, but the program counter is *not* within the 
>> subroutine,
>> but exactly at the first instruction *after* the subroutine according to the 
>> debug_ranges.
>>
>> What makes it worse, is that (**) makes gdb ignore the new location info 
>> alias.c:839,
>> which means, normally the 

[PATCH] Fix PR c++/92365

[Bernd Edlinger]

Hi,

this fixes an unexprected fallout from my previous patch on the 
-Wshadow=complatible-local.

By using can_convert_arg here, it avoids the issue, that can_convert tries to 
cast
int() to char*, which is a a possible NULL-pointer value in C++98 (but not in 
C++11).
As pointed out in the PR, there are still more issues with can_convert, but I 
would
like to fix the regression here without digging any deeper in the mud, at least 
for now.


Boot-strapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
2019-11-08  Bernd Edlinger  

	PR c++/92365
	* name-lookup.c (check_local_shadow): Use can_convert_arg
	instead of can_convert.

testsuite:
2019-11-08  Bernd Edlinger  

	PR c++/92365
	* g++.dg/pr92365.C: New test.

Index: gcc/cp/name-lookup.c
===
--- gcc/cp/name-lookup.c	(revision 277860)
+++ gcc/cp/name-lookup.c	(working copy)
@@ -2770,8 +2770,8 @@ check_local_shadow (tree decl)
 		  (now) doing the shadow checking too
 		  early.  */
 		   && !type_uses_auto (TREE_TYPE (decl))
-		   && can_convert (TREE_TYPE (old), TREE_TYPE (decl),
-   tf_none)))
+		   && can_convert_arg (TREE_TYPE (old), TREE_TYPE (decl),
+   decl, LOOKUP_IMPLICIT, tf_none)))
 	warning_code = OPT_Wshadow_compatible_local;
   else
 	warning_code = OPT_Wshadow_local;
Index: gcc/testsuite/g++.dg/pr92365.C
===
--- gcc/testsuite/g++.dg/pr92365.C	(revision 0)
+++ gcc/testsuite/g++.dg/pr92365.C	(working copy)
@@ -0,0 +1,12 @@
+/* PR c++/92365  */
+/* { dg-options "-std=c++98 -Wshadow=compatible-local" } */
+
+class a {
+public:
+  a(char *);
+};
+void b() {
+  a c(0);
+  if (0)
+int c;
+}

Re: [PING**3] [PATCH] Fix dwarf-lineinfo inconsistency of inlined subroutines

[Bernd Edlinger]

Ping...

On 11/2/19 7:49 AM, Bernd Edlinger wrote:
> Ping...
> 
> On 10/27/19 9:14 AM, Bernd Edlinger wrote:
>> Ping...
>>
>> I'd like to ping for this patch:
>> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
>>
>>
>> Thanks
>> Bernd.
>>
>> On 10/20/19 9:58 PM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this fixes an issue with the gdb step-over aka. "n" command.
>>>
>>> It can be seen when you debug an optimized stage-3 cc1
>>> it does not affect -O0 code, though.
>>>
>>> This example debug session will explain the effect.
>>>
>>> (gdb) b get_alias_set
>>> Breakpoint 5 at 0xa099f0: file ../../gcc-trunk/gcc/alias.c, line 837.
>>> (gdb) r
>>> Breakpoint 5, get_alias_set (t=t@entry=0x77ff7ab0) at 
>>> ../../gcc-trunk/gcc/alias.c:837
>>> 837   if (t == error_mark_node
>>> (gdb) n
>>> 839   && (TREE_TYPE (t) == 0 || TREE_TYPE (t) == error_mark_node)))
>>> (gdb) n
>>> 3382  return __t;  <-- now we have a problem: wrong line info here
>>> (gdb) bt
>>> #0  get_alias_set (t=t@entry=0x77ff7ab0) at 
>>> ../../gcc-trunk/gcc/tree.h:3382
>>> #1  0x00b25dfe in set_mem_attributes_minus_bitpos 
>>> (ref=0x7746f990, t=0x77ff7ab0, objectp=1, bitpos=...)
>>> at ../../gcc-trunk/gcc/emit-rtl.c:1957
>>> #2  0x01137a55 in make_decl_rtl (decl=0x77ff7ab0) at 
>>> ../../gcc-trunk/gcc/varasm.c:1518
>>> #3  0x0113b6e8 in assemble_variable (decl=0x77ff7ab0, 
>>> top_level=, at_end=, 
>>> dont_output_data=0) at ../../gcc-trunk/gcc/varasm.c:2246
>>> #4  0x0113f0ea in varpool_node::assemble_decl (this=0x7745b000) 
>>> at ../../gcc-trunk/gcc/varpool.c:584
>>> #5  0x0113fa17 in varpool_node::assemble_decl (this=0x7745b000) 
>>> at ../../gcc-trunk/gcc/varpool.c:750
>>>
>>>
>>> There are at least two problems here:
>>>
>>> First you did not want to step into the TREE_TYPE, but it happens all
>>> the time, even if you use "n" to step over it.
>>>
>>> And secondly, from the call stack, you don't know where you are in 
>>> get_alias_set.
>>> But the code that is executing at this point is actually the x == 0 || x == 
>>> error_mark_node
>>> from alias.c, line 839, which contains the inlined body of the TREE_TYPE, 
>>> but
>>> the rest of the if.  So there is an inconsistency in the  
>>>
>>> Contents of the .debug_info section:
>>>
>>>  <2><4f686>: Abbrev Number: 12 (DW_TAG_inlined_subroutine)
>>> <4f687>   DW_AT_abstract_origin: <0x53d4e>
>>> <4f68b>   DW_AT_entry_pc: 0x7280
>>> <4f693>   DW_AT_GNU_entry_view: 1
>>> <4f695>   DW_AT_ranges  : 0xb480
>>> <4f699>   DW_AT_call_file   : 8  <- alias.c
>>> <4f69a>   DW_AT_call_line   : 839
>>> <4f69c>   DW_AT_call_column : 8
>>> <4f69d>   DW_AT_sibling : <0x4f717>
>>>
>>>  The File Name Table (offset 0x253):
>>>   8 2   0   0   alias.c
>>>   102   0   0   tree.h
>>>
>>> Contents of the .debug_ranges section:
>>>
>>> b480 7280 7291 
>>> b480 2764 277e 
>>> b480 
>>>
>>> The problem is at pc=0x7291 in the Line Number Section:
>>>
>>>  Line Number Statements:
>>>
>>>   [0x8826]  Special opcode 61: advance Address by 4 to 0x7284 and Line 
>>> by 0 to 3380
>>>   [0x8827]  Set is_stmt to 1
>>>   [0x8828]  Special opcode 189: advance Address by 13 to 0x7291 and 
>>> Line by 2 to 3382 (*)
>>>   [0x8829]  Set is_stmt to 0 (**)
>>>   [0x882a]  Copy (view 1)
>>>   [0x882b]  Set File Name to entry 8 in the File Name Table <- back to 
>>> alias.c
>>>   [0x882d]  Set column to 8
>>>   [0x882f]  Advance Line by -2543 to 839
>>>   [0x8832]  Copy (view 2)
>>>   [0x8833]  Set column to 27
>>>   [0x8835]  Special opcode 61: advance Address by 4 to 0x7295 and Line 
>>> by 0 to 839
>>>   [0x8836]  Set column to 3
>>>   [0x8838]  Set is_stmt to 1 <-- next line info counts: alias.c:847
>>>   [0x8839]  Special opc

[PATCH] Fix PR97205

[Bernd Edlinger]

Hi,

this makes sure that stack allocated SSA_NAMEs are
at least MODE_ALIGNED.  Also increase the MEM_ALIGN
for the corresponding rtl objects.


Tested on x86_64-pc-linux-gnu and arm-none-eabi.

OK for trunk?


Thanks
Bernd.
From e8f80c0ed18c49e8b8ad4145401a2c1afa50af60 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Sun, 1 Nov 2020 07:32:20 +0100
Subject: [PATCH] Fix PR97205

This makes sure that stack allocated SSA_NAMEs are
at least MODE_ALIGNED.  Also increase the MEM_ALIGN
for the corresponding rtl objects.

gcc:
2020-11-01  Bernd Edlinger  

	PR target/97205
	* cfgexpand.c (align_local_variable): Make SSA_NAMEs
	at least MODE_ALIGNED.
	(expand_one_stack_var_at): Increase MEM_ALIGN for SSA_NAMEs.

testsuite:
2020-11-01  Bernd Edlinger  

	PR target/97205
	* gcc.c-torture/compile/pr97205.c: New test.
---
 gcc/cfgexpand.c   | 26 --
 gcc/testsuite/gcc.c-torture/compile/pr97205.c |  7 +++
 2 files changed, 27 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr97205.c

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index f3f17d3..3aec250 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -366,7 +366,15 @@ align_local_variable (tree decl, bool really_expand)
   unsigned int align;
 
   if (TREE_CODE (decl) == SSA_NAME)
-align = TYPE_ALIGN (TREE_TYPE (decl));
+{
+  tree type = TREE_TYPE (decl);
+  machine_mode mode = TYPE_MODE (type);
+
+  align = TYPE_ALIGN (type);
+  if (mode != BLKmode
+	  && align < GET_MODE_ALIGNMENT (mode))
+	align = GET_MODE_ALIGNMENT (mode);
+}
   else
 {
   align = LOCAL_DECL_ALIGNMENT (decl);
@@ -1022,6 +1030,14 @@ expand_one_stack_var_at (tree decl, rtx base, unsigned base_align,
 }
 
   set_rtl (decl, x);
+
+  if (TREE_CODE (decl) == SSA_NAME
+  && GET_MODE (x) != BLKmode
+  && MEM_ALIGN (x) < GET_MODE_ALIGNMENT (GET_MODE (x)))
+{
+  gcc_checking_assert (GET_MODE_ALIGNMENT (GET_MODE (x)) <= base_align);
+  set_mem_align (x, GET_MODE_ALIGNMENT (GET_MODE (x)));
+}
 }
 
 class stack_vars_data
@@ -1327,13 +1343,11 @@ expand_one_stack_var_1 (tree var)
 {
   tree type = TREE_TYPE (var);
   size = tree_to_poly_uint64 (TYPE_SIZE_UNIT (type));
-  byte_align = TYPE_ALIGN_UNIT (type);
 }
   else
-{
-  size = tree_to_poly_uint64 (DECL_SIZE_UNIT (var));
-  byte_align = align_local_variable (var, true);
-}
+size = tree_to_poly_uint64 (DECL_SIZE_UNIT (var));
+
+  byte_align = align_local_variable (var, true);
 
   /* We handle highly aligned variables in expand_stack_vars.  */
   gcc_assert (byte_align * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT);
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr97205.c b/gcc/testsuite/gcc.c-torture/compile/pr97205.c
new file mode 100644
index 000..6600011
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr97205.c
@@ -0,0 +1,7 @@
+int a;
+typedef __attribute__((aligned(2))) int x;
+int f ()
+{
+  x b = a;
+  return b;
+}
-- 
1.9.1

Re: [PATCH] Fix PR97205

[Bernd Edlinger]

On 11/2/20 3:07 PM, Richard Biener wrote:
> On Mon, 2 Nov 2020, Bernd Edlinger wrote:
> 
>> Hi,
>>
>> this makes sure that stack allocated SSA_NAMEs are
>> at least MODE_ALIGNED.  Also increase the MEM_ALIGN
>> for the corresponding rtl objects.
>>
>>
>> Tested on x86_64-pc-linux-gnu and arm-none-eabi.
>>
>> OK for trunk?
> 
> 
> @@ -1022,6 +1030,14 @@ expand_one_stack_var_at (tree decl, rtx base,
> unsigned base_align,
>  }
>  
>set_rtl (decl, x);
> +
> +  if (TREE_CODE (decl) == SSA_NAME
> +  && GET_MODE (x) != BLKmode
> +  && MEM_ALIGN (x) < GET_MODE_ALIGNMENT (GET_MODE (x)))
> +{
> +  gcc_checking_assert (GET_MODE_ALIGNMENT (GET_MODE (x)) <=
> base_align);
> +  set_mem_align (x, GET_MODE_ALIGNMENT (GET_MODE (x)));
> +}
>  }
>  
> 
> I wonder whether we cannot "fix" set_rtl to not call
> set_mem_attributes in this path, maybe directly call
> set_mem_align there instead?  That is, the preceeding
> code for ! SSA_NAME already tries to adjust alignment
> to honor that of the actual stack slot - IMHO the
> non-SSA and SSA cases should be merged after this
> patch, but maybe simply by calling set_mem_align
> instead of doing the DECL_ALIGN frobbing and do
> the alignment compute also for SSA_NAMEs?
> 
> The other pieces look OK but the above is a bit ugly
> at the moment.
> 

Hmm, how about this?

--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -1007,20 +1007,21 @@ expand_one_stack_var_at (tree decl, rtx base, unsigned 
base_align,
   x = plus_constant (Pmode, base, offset);
   x = gen_rtx_MEM (TREE_CODE (decl) == SSA_NAME
   ? TYPE_MODE (TREE_TYPE (decl))
-  : DECL_MODE (SSAVAR (decl)), x);
+  : DECL_MODE (decl), x);
+
+  /* Set alignment we actually gave this decl if it isn't an SSA name.
+ If it is we generate stack slots only accidentally so it isn't as
+ important, we'll simply set the alignment directly on the MEM_P.  */
+
+  if (base == virtual_stack_vars_rtx)
+offset -= frame_phase;
+  align = known_alignment (offset);
+  align *= BITS_PER_UNIT;
+  if (align == 0 || align > base_align)
+align = base_align;
 
   if (TREE_CODE (decl) != SSA_NAME)
 {
-  /* Set alignment we actually gave this decl if it isn't an SSA name.
- If it is we generate stack slots only accidentally so it isn't as
-important, we'll simply use the alignment that is already set.  */
-  if (base == virtual_stack_vars_rtx)
-   offset -= frame_phase;
-  align = known_alignment (offset);
-  align *= BITS_PER_UNIT;
-  if (align == 0 || align > base_align)
-   align = base_align;
-
   /* One would think that we could assert that we're not decreasing
 alignment here, but (at least) the i386 port does exactly this
 via the MINIMUM_ALIGNMENT hook.  */
@@ -1031,13 +1032,7 @@ expand_one_stack_var_at (tree decl, rtx base, unsigned 
base_align,
 
   set_rtl (decl, x);
 
-  if (TREE_CODE (decl) == SSA_NAME
-  && GET_MODE (x) != BLKmode
-  && MEM_ALIGN (x) < GET_MODE_ALIGNMENT (GET_MODE (x)))
-{
-  gcc_checking_assert (GET_MODE_ALIGNMENT (GET_MODE (x)) <= base_align);
-  set_mem_align (x, GET_MODE_ALIGNMENT (GET_MODE (x)));
-}
+  set_mem_align (x, align);
 }
 
 class stack_vars_data


Is it OK if it passes bootstrap and regtesting ?

Thanks
Bernd.

> Thanks,
> Richard,
> 
>>
>>
>> Thanks
>> Bernd.
>>
> 

Re: [PATCH] Fix PR97205

[Bernd Edlinger]

On 11/3/20 10:34 AM, Richard Biener wrote:
> On Mon, 2 Nov 2020, Bernd Edlinger wrote:
> 
>> On 11/2/20 3:07 PM, Richard Biener wrote:
>>> On Mon, 2 Nov 2020, Bernd Edlinger wrote:
>>>
>>>> Hi,
>>>>
>>>> this makes sure that stack allocated SSA_NAMEs are
>>>> at least MODE_ALIGNED.  Also increase the MEM_ALIGN
>>>> for the corresponding rtl objects.
>>>>
>>>>
>>>> Tested on x86_64-pc-linux-gnu and arm-none-eabi.
>>>>
>>>> OK for trunk?
>>>
>>>
>>> @@ -1022,6 +1030,14 @@ expand_one_stack_var_at (tree decl, rtx base,
>>> unsigned base_align,
>>>  }
>>>  
>>>set_rtl (decl, x);
>>> +
>>> +  if (TREE_CODE (decl) == SSA_NAME
>>> +  && GET_MODE (x) != BLKmode
>>> +  && MEM_ALIGN (x) < GET_MODE_ALIGNMENT (GET_MODE (x)))
>>> +{
>>> +  gcc_checking_assert (GET_MODE_ALIGNMENT (GET_MODE (x)) <=
>>> base_align);
>>> +  set_mem_align (x, GET_MODE_ALIGNMENT (GET_MODE (x)));
>>> +}
>>>  }
>>>  
>>>
>>> I wonder whether we cannot "fix" set_rtl to not call
>>> set_mem_attributes in this path, maybe directly call
>>> set_mem_align there instead?  That is, the preceeding
>>> code for ! SSA_NAME already tries to adjust alignment
>>> to honor that of the actual stack slot - IMHO the
>>> non-SSA and SSA cases should be merged after this
>>> patch, but maybe simply by calling set_mem_align
>>> instead of doing the DECL_ALIGN frobbing and do
>>> the alignment compute also for SSA_NAMEs?
>>>
>>> The other pieces look OK but the above is a bit ugly
>>> at the moment.
>>>
>>
>> Hmm, how about this?
> 
> That would work for me.  Guess removing the DECL_ALIGN frobbing
> in the != SSA_NAME path didn't work out or you didn't try out
> of caution?
> 

I didn't try, since it felt simply more correct this way,
and get_object_alignment would probably give a different
answer since it uses DECL_ALIGN too.


Bernd.

Re: [PATCH] Fix PR97205

[Bernd Edlinger]

On 11/3/20 11:16 AM, Richard Biener wrote:
> On Tue, 3 Nov 2020, Bernd Edlinger wrote:
> 
>>
>>
>> On 11/3/20 10:34 AM, Richard Biener wrote:
>>> On Mon, 2 Nov 2020, Bernd Edlinger wrote:
>>>
>>>> On 11/2/20 3:07 PM, Richard Biener wrote:
>>>>> On Mon, 2 Nov 2020, Bernd Edlinger wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> this makes sure that stack allocated SSA_NAMEs are
>>>>>> at least MODE_ALIGNED.  Also increase the MEM_ALIGN
>>>>>> for the corresponding rtl objects.
>>>>>>
>>>>>>
>>>>>> Tested on x86_64-pc-linux-gnu and arm-none-eabi.
>>>>>>
>>>>>> OK for trunk?
>>>>>
>>>>>
>>>>> @@ -1022,6 +1030,14 @@ expand_one_stack_var_at (tree decl, rtx base,
>>>>> unsigned base_align,
>>>>>  }
>>>>>  
>>>>>set_rtl (decl, x);
>>>>> +
>>>>> +  if (TREE_CODE (decl) == SSA_NAME
>>>>> +  && GET_MODE (x) != BLKmode
>>>>> +  && MEM_ALIGN (x) < GET_MODE_ALIGNMENT (GET_MODE (x)))
>>>>> +{
>>>>> +  gcc_checking_assert (GET_MODE_ALIGNMENT (GET_MODE (x)) <=
>>>>> base_align);
>>>>> +  set_mem_align (x, GET_MODE_ALIGNMENT (GET_MODE (x)));
>>>>> +}
>>>>>  }
>>>>>  
>>>>>
>>>>> I wonder whether we cannot "fix" set_rtl to not call
>>>>> set_mem_attributes in this path, maybe directly call
>>>>> set_mem_align there instead?  That is, the preceeding
>>>>> code for ! SSA_NAME already tries to adjust alignment
>>>>> to honor that of the actual stack slot - IMHO the
>>>>> non-SSA and SSA cases should be merged after this
>>>>> patch, but maybe simply by calling set_mem_align
>>>>> instead of doing the DECL_ALIGN frobbing and do
>>>>> the alignment compute also for SSA_NAMEs?
>>>>>
>>>>> The other pieces look OK but the above is a bit ugly
>>>>> at the moment.
>>>>>
>>>>
>>>> Hmm, how about this?
>>>
>>> That would work for me.  Guess removing the DECL_ALIGN frobbing
>>> in the != SSA_NAME path didn't work out or you didn't try out
>>> of caution?
>>>
>>
>> I didn't try, since it felt simply more correct this way,
>> and get_object_alignment would probably give a different
>> answer since it uses DECL_ALIGN too.
> 
> OK, I see.
> 
> Richard.
> 

Ok, good.

So this is what I will commit shortly.

Thanks
Bernd.
From e281da96736655c42296806162d1b979dd368544 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Sun, 1 Nov 2020 07:32:20 +0100
Subject: [PATCH] Fix PR97205

This makes sure that stack allocated SSA_NAMEs are
at least MODE_ALIGNED.  Also increase the MEM_ALIGN
for the corresponding rtl objects.

gcc:
2020-11-03  Bernd Edlinger  

	PR target/97205
	* cfgexpand.c (align_local_variable): Make SSA_NAMEs
	at least MODE_ALIGNED.
	(expand_one_stack_var_at): Increase MEM_ALIGN for SSA_NAMEs.

testsuite:
2020-11-03  Bernd Edlinger  

	PR target/97205
	* gcc.c-torture/compile/pr97205.c: New test.
---
 gcc/cfgexpand.c   | 43 ---
 gcc/testsuite/gcc.c-torture/compile/pr97205.c |  7 +
 2 files changed, 33 insertions(+), 17 deletions(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr97205.c

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index f3f17d3..6c41a7e 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -366,7 +366,15 @@ align_local_variable (tree decl, bool really_expand)
   unsigned int align;
 
   if (TREE_CODE (decl) == SSA_NAME)
-align = TYPE_ALIGN (TREE_TYPE (decl));
+{
+  tree type = TREE_TYPE (decl);
+  machine_mode mode = TYPE_MODE (type);
+
+  align = TYPE_ALIGN (type);
+  if (mode != BLKmode
+	  && align < GET_MODE_ALIGNMENT (mode))
+	align = GET_MODE_ALIGNMENT (mode);
+}
   else
 {
   align = LOCAL_DECL_ALIGNMENT (decl);
@@ -999,20 +1007,21 @@ expand_one_stack_var_at (tree decl, rtx base, unsigned base_align,
   x = plus_constant (Pmode, base, offset);
   x = gen_rtx_MEM (TREE_CODE (decl) == SSA_NAME
 		   ? TYPE_MODE (TREE_TYPE (decl))
-		   : DECL_MODE (SSAVAR (decl)), x);
+		   : DECL_MODE (decl), x);
+
+  /* Set alignment we actually gave this decl if it isn't an SSA name.
+ If it is we generate stack slots only accidentally so it isn't as
+ important, we'

[committed] Cleanup of a merge mistake in fold-const.c

[Bernd Edlinger]

Hi,


this removes a duplicated statement, in fold-const.c in function getbyterep:

The comment, "Ideally this would turn into a gcc_checking_assert over time."
and the following if-statement are duplicated so one of them can be removed:

  if (init_bytes > array_size)
init_bytes = array_size;


This happened due to a merge conflict a long time ago.

Bootstrapped and regtested on x86_64-pc-linux-gnu.

I think this qualifies as obvious, so I will commit it now.


Thanks
Bernd.
From 48a85b06992e4d915f29998f8db96ec2a019ea16 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Tue, 3 Nov 2020 14:20:14 +0100
Subject: [PATCH] Cleanup of a merge mistake in fold-const.c

This removes a duplicated statement.
It was apparently introduced due to a merge mistake.

2020-11-03  Bernd Edlinger  

	* fold-const.c (getbyterep): Remove duplicated statement.
---
 gcc/fold-const.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index ebd32bb..c47557d 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -15565,11 +15565,6 @@ getbyterep (tree src, unsigned HOST_WIDE_INT *strsize)
  is equal to strlen (A) + 1.  */
   const unsigned HOST_WIDE_INT array_size = tree_to_uhwi (mem_size);
   unsigned HOST_WIDE_INT init_bytes = TREE_STRING_LENGTH (src);
-
-  /* Ideally this would turn into a gcc_checking_assert over time.  */
-  if (init_bytes > array_size)
-init_bytes = array_size;
-
   const char *string = TREE_STRING_POINTER (src);
 
   /* Ideally this would turn into a gcc_checking_assert over time.  */
-- 
1.9.1

[PATCH] libgcc: Add a weak stub for __sync_synchronize

[Bernd Edlinger]

Hi,

this fixes a problem with a missing symbol __sync_synchronize
which happens when newlib is used together with libstdc++ for
the non-threaded simulator target arm-none-eabi.

There are several questions on stackoverflow about this issue.

I would like to add a weak symbol for this target, since this
is only a default implementation and not meant to override a
possibly more sophisticated synchronization function from the
c-runtime.


Regression tested successfully on arm-none-eabi with newlib-3.3.0.

Is it OK for trunk?


Thanks
Bernd.
From f8a3df552f4b98308096659c66b4c8ea68580f25 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Mon, 2 Nov 2020 11:43:44 +0100
Subject: [PATCH] libgcc: Add a weak stub for __sync_synchronize

This patch adds a default implementation for __sync_synchronize,
which prevents many unresolved symbol errors on arm-none-eabi.
This happens often in C++ programs even without any threading.

libgcc:
2020-11-02  Bernd Edlinger  

	* config.host: Use t-eabi for arm-none-eabi.
	* config/arm/t-eabi: New.
	* config/arm/eabi-sync.c: New.
---
 libgcc/config.host|  2 +-
 libgcc/config/arm/eabi-sync.c | 39 +++
 libgcc/config/arm/t-eabi  |  1 +
 3 files changed, 41 insertions(+), 1 deletion(-)
 create mode 100644 libgcc/config/arm/eabi-sync.c
 create mode 100644 libgcc/config/arm/t-eabi

diff --git a/libgcc/config.host b/libgcc/config.host
index fd8e55e..e25abf4 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -495,7 +495,7 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
 	tm_file="$tm_file arm/bpabi-lib.h"
 	case ${host} in
 	arm*-*-eabi* | arm*-*-rtems*)
-	  tmake_file="${tmake_file} arm/t-bpabi t-crtfm"
+	  tmake_file="${tmake_file} arm/t-bpabi t-crtfm arm/t-eabi"
 	  extra_parts="crtbegin.o crtend.o crti.o crtn.o"
 	  ;;
 	arm*-*-symbianelf*)
diff --git a/libgcc/config/arm/eabi-sync.c b/libgcc/config/arm/eabi-sync.c
new file mode 100644
index 000..bffdd4a
--- /dev/null
+++ b/libgcc/config/arm/eabi-sync.c
@@ -0,0 +1,39 @@
+/* Copyright (C) 2020 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+<http://www.gnu.org/licenses/>.  */
+
+void __attribute__ ((weak))
+__sync_synchronize (void)
+{
+#if defined (__ARM_ARCH_6__) || defined (__ARM_ARCH_6J__)   \
+|| defined (__ARM_ARCH_6K__) || defined (__ARM_ARCH_6T2__)  \
+|| defined (__ARM_ARCH_6Z__) || defined (__ARM_ARCH_6ZK__)  \
+|| defined (__ARM_ARCH_7__) || defined (__ARM_ARCH_7A__)
+#if defined (__ARM_ARCH_7__) || defined (__ARM_ARCH_7A__)
+__asm __volatile ("dmb" : : : "memory");
+#else
+__asm __volatile ("mcr p15, 0, r0, c7, c10, 5" : : : "memory");
+#endif
+#else
+__asm __volatile ("nop" : : : "memory");
+#endif
+}
diff --git a/libgcc/config/arm/t-eabi b/libgcc/config/arm/t-eabi
new file mode 100644
index 000..556032f
--- /dev/null
+++ b/libgcc/config/arm/t-eabi
@@ -0,0 +1 @@
+LIB2ADD_ST += $(srcdir)/config/arm/eabi-sync.c
-- 
1.9.1

[PING] [PATCH] libgcc: Add a weak stub for __sync_synchronize

[Bernd Edlinger]

Ping...

I'd like to ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557886.html

Thanks
Bernd.

On 11/3/20 4:08 PM, Bernd Edlinger wrote:
> Hi,
> 
> this fixes a problem with a missing symbol __sync_synchronize
> which happens when newlib is used together with libstdc++ for
> the non-threaded simulator target arm-none-eabi.
> 
> There are several questions on stackoverflow about this issue.
> 
> I would like to add a weak symbol for this target, since this
> is only a default implementation and not meant to override a
> possibly more sophisticated synchronization function from the
> c-runtime.
> 
> 
> Regression tested successfully on arm-none-eabi with newlib-3.3.0.
> 
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS env var

[Bernd Edlinger]

Hi,


I just wanted to ask, if there was any progress on this?


Thanks
Bernd.

On 12/21/19 10:50 AM, Bernd Edlinger wrote:
> Hi David,
> 
> thanks for fixing this issue.
> 
> Just one comment:
> 
>> +[DIAGNOSTICS_URLS_DEFAULT=DIAGNOSTICS_URL_AUTO])
>> +AC_DEFINE_UNQUOTED(DIAGNOSTICS_URLS_DEFAULT, $DIAGNOSTICS_URLS_DEFAULT,
>> +   [The default for -fdiagnostics-urls option])
> 
> I think for a feature as disruptive as this, when a
> terminal implements that it ought to advertise this feature via
> an environment variable.  So I would prefer the default
> to be auto-if-env.
> 
> Ideally there should be some neutral variable similar to TERM,
> maybe TERM_URL=yes if that convention does not exist yet,
> maybe we should invent it?
> 
> 
> Thanks
> Bernd.
> 

[PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

Hi,

this is patch is heavily based on David's original patch here:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html

and addresses Jakub's review comments here:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01412.html

So I hope you don't mind, when I pick up this patch since there
was not much activity recently on this issue, so I assumed you
would appreciate some help.

I will try to improve the patch a bit, and hope you are gonna like
it. I agree that this feature is fine, and should be enabled by
default, and just if it is positively clear that it won't work,
disabled in the auto mode.

Also as requested by Jakub this tries to be more compatible to
GCC_COLORS define, and adds the capability to switch between ST
and BEL string termination and also have a way to disable urls
even with -fdiagnostics-urls=always (like GCC_COLORS= disables colors).

In addition to that I propose to use GCC_URLS and if that
is not defined use TERM_URLS to control that feature for
all applications willing to support that.

Since I have seen much garbage from the URLs in the xfce4-terminal 0.6.3
admittedly an old Ubuntu installation, but still in LTS status,
and no attempt from the xfc4-terminal to _ever_ implement URLs, I would
like to detect the xfce4-terminal, and use that in auto mode
to switch off the URLs feature, since in best case the URLs will
just be ignored, but can and will often create garbage on the screen.

Likewise on MinGW, since the windows 10 cmd prompt does at best
ignore the URLs, but windows terminal and windows 7 cmd prompt
print garbage when URLs are output.

I have one question though, regarding the autoconf version that
we use, it is autoconf-2.69, right, at least that is what I read in
gcc/doc/install.texi?

I don't understand why the generated configure has additional
changes than what is changed in configure.ac.  Should I commit the
generated version as is, or use a different autoconf version?


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Benrd.
From fae99e05a356363ff719b5504e6250abe1c16aea Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Wed, 29 Jan 2020 15:31:10 +0100
Subject: [PATCH] PR 87488: Add --with-diagnostics-urls configuration option

2020-01-30  David Malcolm  
	Bernd Edlinger  

	PR 87488
	* config.in (DIAGNOSTICS_URLS_DEFAULT): New define.
	* configure.ac (--with-diagnostics-urls): New configuration
	option, based on --with-diagnostics-color.
	(DIAGNOSTICS_URLS_DEFAULT): New define.
	* config.h: Regenerate.
	* configure: Regenerate.
	* diagnostic.c (diagnostic_urls_init): Handle -1 for
	DIAGNOSTICS_URLS_DEFAULT from configure-time
	--with-diagnostics-urls=auto-if-env by querying for a GCC_URLS
	and TERM_URLS environment variable.
	* diagnostic-url.h (diagnostic_urls_use_st): New variable.
	* diagnostic-color.c (diagnostic_urls_use_st): Declare.
	(parse_gcc_urls, auto_enable_urls): New helper functions.
	(diagnostic_urls_enabled_p): Adjust.
	* pretty-print.c (pp_begin_url, pp_end_url, test_urls): Use
	diagnostic_urls_use_st.
	* doc/install.texi (--with-diagnostics-urls): Document new
	configuration option.
	* doc/invoke.texi (-fdiagnostics-urls): Add GCC_URLS vindex
	reference.  Update description of defaults based on the above.
---
 gcc/config.in  |  6 
 gcc/configure  | 87 +-
 gcc/configure.ac   | 28 
 gcc/diagnostic-color.c | 57 +++--
 gcc/diagnostic-url.h   |  1 +
 gcc/diagnostic.c   | 17 +-
 gcc/doc/install.texi   |  9 ++
 gcc/doc/invoke.texi| 15 +++--
 gcc/pretty-print.c | 11 +--
 9 files changed, 215 insertions(+), 16 deletions(-)

diff --git a/gcc/config.in b/gcc/config.in
index ec5c46a..b30fb20 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -76,6 +76,12 @@
 #endif
 
 
+/* The default for -fdiagnostics-urls option */
+#ifndef USED_FOR_TARGET
+#undef DIAGNOSTICS_URLS_DEFAULT
+#endif
+
+
 /* Define 0/1 if static analyzer feature is enabled. */
 #ifndef USED_FOR_TARGET
 #undef ENABLE_ANALYZER
diff --git a/gcc/configure b/gcc/configure
index 490fe6a..68340df 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -974,6 +974,7 @@ with_zstd_include
 with_zstd_lib
 enable_rpath
 with_libiconv_prefix
+with_libiconv_type
 enable_sjlj_exceptions
 with_gcc_major_version_only
 enable_secureplt
@@ -1014,6 +1015,7 @@ enable_host_shared
 enable_libquadmath_support
 with_linker_hash_style
 with_diagnostics_color
+with_diagnostics_urls
 enable_default_pie
 '
   ac_precious_vars='build_alias
@@ -1811,6 +1813,7 @@ Optional Packages:
   --with-gnu-ld   assume the C compiler uses GNU ld default=no
   --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib
   --without-libiconv-prefix don't search for libiconv in includedir and libdir
+  --with-libiconv-type=TYPE type of library to search for (auto/static/

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

Hi Andrew,

I just saw your patch here:
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01474.html
Re: [PATCH] gcc: Add new configure options to allow static libraries to be 
selected


Note: the artefacts in my patch below seem to be a missing re-generated 
gcc/configure
from your patch?
Is that right?  I did not notice any problem from this, does this work for you 
this way?
And, is it the right thing to push those changes along this patch, or do you
want to take care of this by yourself?


Thanks
Bernd.


On 1/31/20 5:58 PM, Bernd Edlinger wrote:
> Hi,
> 
> this is patch is heavily based on David's original patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html
> 
> and addresses Jakub's review comments here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01412.html
> 
> So I hope you don't mind, when I pick up this patch since there
> was not much activity recently on this issue, so I assumed you
> would appreciate some help.
> 
> I will try to improve the patch a bit, and hope you are gonna like
> it. I agree that this feature is fine, and should be enabled by
> default, and just if it is positively clear that it won't work,
> disabled in the auto mode.
> 
> Also as requested by Jakub this tries to be more compatible to
> GCC_COLORS define, and adds the capability to switch between ST
> and BEL string termination and also have a way to disable urls
> even with -fdiagnostics-urls=always (like GCC_COLORS= disables colors).
> 
> In addition to that I propose to use GCC_URLS and if that
> is not defined use TERM_URLS to control that feature for
> all applications willing to support that.
> 
> Since I have seen much garbage from the URLs in the xfce4-terminal 0.6.3
> admittedly an old Ubuntu installation, but still in LTS status,
> and no attempt from the xfc4-terminal to _ever_ implement URLs, I would
> like to detect the xfce4-terminal, and use that in auto mode
> to switch off the URLs feature, since in best case the URLs will
> just be ignored, but can and will often create garbage on the screen.
> 
> Likewise on MinGW, since the windows 10 cmd prompt does at best
> ignore the URLs, but windows terminal and windows 7 cmd prompt
> print garbage when URLs are output.
> 
> I have one question though, regarding the autoconf version that
> we use, it is autoconf-2.69, right, at least that is what I read in
> gcc/doc/install.texi?
> 
> I don't understand why the generated configure has additional
> changes than what is changed in configure.ac.  Should I commit the
> generated version as is, or use a different autoconf version?
> 
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
> 
> 
> Thanks
> Benrd.
> 

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

On 1/31/20 11:54 PM, Segher Boessenkool wrote:
> Hi!
> 
> Thanks for working on this.
> 
> On Fri, Jan 31, 2020 at 04:59:02PM +, Bernd Edlinger wrote:
>> I will try to improve the patch a bit, and hope you are gonna like
>> it. I agree that this feature is fine, and should be enabled by
>> default, and just if it is positively clear that it won't work,
>> disabled in the auto mode.
> 
> Why does it not ask the terminfo, instead of only disabling this for
> "dumb"?  It should disable it for *most* terminals!  The one I care

Unfortunately I was told that terminfo is not willing to support URLs
either, and it need to be administered centrally, which is per definition
an impossible task...


> about most, which caused me to open PR93168, is TERM=screen (which is
> what tmux uses), so at least exclude that one?  And doing all this


Definitely, if the situation with tmux is like xfce4-terminal (reportedly
the 0.8 version switched to a fixed VTE, which makes the URLs invisible,
but the URL feature request is pending sine 2017, with no activity whatsoever),
then detecting that and disabling the URLs until they finally implement
the URLs is straight forward.  I can add that to my patch if you confirm,
the right detection logic:

>From 
>https://unix.stackexchange.com/questions/10689/how-can-i-tell-if-im-in-a-tmux-session-from-a-bash-script
I read the safest way to find out if you are in a tmux session, is
to look for TERM=screen and TMUX is set.
Is that the case for your environment?

Note that it is well possible that this environment values are
not preserved in a ssh session, but nobody is perfect.


> beeping and screen-corrupting stuff for everything that sets TERM=xterm
> is a bad idea imnsho.
> 
>> Since I have seen much garbage from the URLs in the xfce4-terminal 0.6.3
>> admittedly an old Ubuntu installation, but still in LTS status,
>> and no attempt from the xfc4-terminal to _ever_ implement URLs,
> 
> This is true for *most* terminal emulators.
> 

Sadly, I would not do this if there is a chance that someone looses a
working feature, so I was told that a more aggressive approach would
"be straight harmful to the current state of things
 (i.e. hyperlinks at least not causing any problem, plus working
 out of the box wherever supported, for the vast majority of people)"
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda#gistcomment-3160953

So I would try to detect known terminals which are so buggy that they
print garbage instead of silently ignoring the URL escapes AND
which may or may not have fixed the visual glitches but have not plan
to implement URLs at all.  Once they implement URLs it would be nice if they
do something like set a TERM_URLS=yes so we know for sure, that the feature is
positively available, for instance.

> I have nothing against this feature, I just wish it wouldn't annoy me
> on pretty much every system I use.  None of which use "TERM=dumb", but
> none of which use "TERM=fancy-pants-term-v42" either.  (Did anyone ever
> use "dumb", anyway?)
> 

The dumb thing was old code, I only took the freedom to document it ;-)


Bernd.
> 
> Segher
> 

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

Hi Segher,

On 2/1/20 2:32 AM, Segher Boessenkool wrote:
> On Fri, Jan 31, 2020 at 11:38:04PM +0000, Bernd Edlinger wrote:
>> On 1/31/20 11:54 PM, Segher Boessenkool wrote:
>>> about most, which caused me to open PR93168, is TERM=screen (which is
>>> what tmux uses), so at least exclude that one?  And doing all this
>>
>> Definitely, if the situation with tmux is like xfce4-terminal (reportedly
>> the 0.8 version switched to a fixed VTE, which makes the URLs invisible,
>> but the URL feature request is pending sine 2017, with no activity 
>> whatsoever),
>> then detecting that and disabling the URLs until they finally implement
>> the URLs is straight forward.  I can add that to my patch if you confirm,
>> the right detection logic:
> 
> The situation is that it is a terminal multiplexer; you can connect any
> terminal to it, and swap those out, etc.  You might have one that has
> support for the url thing at one time, but when you look at that session
> from a different machine (from your phone, say), not anymore (or the
> other way around).  You can also connect multiple actual terminals at
> the same time.
> 
> In short, even *if* you could detect whether the terminal supports this
> url thing (and you cannot), you cannot detect whether it will support it
> two seconds from now, and even if the url thing you already displayed
> will misbehave *in the future*!
> 

Ah, okay, this is a totally wrong assumption then.

So if I understand you right, I should add a check for
tmux in should_colorize, where the TERM=dumb thing is,
and add TERM=screen, and TMUX=anything, to switch of
auto-color off, which will take down URLs at the same time?

Bernd.

>> >From 
>> >https://unix.stackexchange.com/questions/10689/how-can-i-tell-if-im-in-a-tmux-session-from-a-bash-script
>> I read the safest way to find out if you are in a tmux session, is
>> to look for TERM=screen and TMUX is set.
> 
> Yes, but the same considerations are true for all screen-like programs.
> I happen to like tmux best, some people swear by old-fashioned screen,
> and there are other alternatives too I think.
> 
>> Is that the case for your environment?
> 
> It's true on at least six machines I tested just now, but all of those
> are pretty similar anyway, so that doesn't say much.
> 
>> Note that it is well possible that this environment values are
>> not preserved in a ssh session, but nobody is perfect.
> 
> The session you are looking at is not the ssh session; it will keep
> running even if no actual terminal is connected, that's pretty much
> the point of running it, in many cases :-)
> 
>>>> Since I have seen much garbage from the URLs in the xfce4-terminal 0.6.3
>>>> admittedly an old Ubuntu installation, but still in LTS status,
>>>> and no attempt from the xfc4-terminal to _ever_ implement URLs,
>>>
>>> This is true for *most* terminal emulators.
>>
>> Sadly, I would not do this if there is a chance that someone looses a
>> working feature, so I was told that a more aggressive approach would
>> "be straight harmful to the current state of things
>>  (i.e. hyperlinks at least not causing any problem, plus working
>>  out of the box wherever supported, for the vast majority of people)"
>> https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda#gistcomment-3160953
> 
> I have seen not a *single* terminal emulator where this works 100%
> correctly.  I have seen many where it screws up display spectacularly
> (or sound even :-/ )
> 
>> So I would try to detect known terminals which are so buggy that they
>> print garbage instead of silently ignoring the URL escapes AND
>> which may or may not have fixed the visual glitches but have not plan
>> to implement URLs at all.
> 
> That is not buggy at all.  It is a bug to output the wrong escape codes,
> instead.
> 
>>> I have nothing against this feature, I just wish it wouldn't annoy me
>>> on pretty much every system I use.  None of which use "TERM=dumb", but
>>> none of which use "TERM=fancy-pants-term-v42" either.  (Did anyone ever
>>> use "dumb", anyway?)
>>
>> The dumb thing was old code, I only took the freedom to document it ;-)
> 
> I know :-)  I mean, does anyone have "TERM=dumb" in the environment?
> "TERM=ansi", sure, and I've used "TERM=vt220" many times, too, but I've
> never seen "TERM=dumb" used.
> 
> 
> Segher
> 

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

On 1/31/20 11:06 PM, David Malcolm wrote:
> On Fri, 2020-01-31 at 16:59 +0000, Bernd Edlinger wrote:
>> Hi,
>>
>> this is patch is heavily based on David's original patch here:
>> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html
>>
>> and addresses Jakub's review comments here:
>> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01412.html
>>
>> So I hope you don't mind, when I pick up this patch since there
>> was not much activity recently on this issue, so I assumed you
>> would appreciate some help.
> 
> Thanks Bernd; sorry, I got distracted by analyzer bug-fixing.  It's
> appreciated.
> 
>> I will try to improve the patch a bit, and hope you are gonna like
>> it. I agree that this feature is fine, and should be enabled by
>> default, and just if it is positively clear that it won't work,
>> disabled in the auto mode.
>>
>> Also as requested by Jakub this tries to be more compatible to
>> GCC_COLORS define, and adds the capability to switch between ST
>> and BEL string termination and also have a way to disable urls
>> even with -fdiagnostics-urls=always (like GCC_COLORS= disables
>> colors).
>>
>> In addition to that I propose to use GCC_URLS and if that
>> is not defined use TERM_URLS to control that feature for
>> all applications willing to support that.
> 
> I think I like the overall idea.
> 

Thanks!

>> Since I have seen much garbage from the URLs in the xfce4-terminal
>> 0.6.3
>> admittedly an old Ubuntu installation, but still in LTS status,
>> and no attempt from the xfc4-terminal to _ever_ implement URLs, I
>> would
>> like to detect the xfce4-terminal, and use that in auto mode
>> to switch off the URLs feature, since in best case the URLs will
>> just be ignored, but can and will often create garbage on the screen.
>>
>> Likewise on MinGW, since the windows 10 cmd prompt does at best
>> ignore the URLs, but windows terminal and windows 7 cmd prompt
>> print garbage when URLs are output.
> 
> That sounds reasonable, but we should document those exclusions, I
> think.
> 

done.

> I think the ChangeLog should also refer to "PR other/93168":
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93168
> 

done.

>> diff --git a/gcc/diagnostic-color.c b/gcc/diagnostic-color.c
>> index d554795..ad84d1f 100644
>> --- a/gcc/diagnostic-color.c
>> +++ b/gcc/diagnostic-color.c
>> @@ -239,6 +239,56 @@ colorize_init (diagnostic_color_rule_t rule)
>>  }
>>  }
>>  
>> +bool diagnostic_urls_use_st = false;
> 
> I don't like global variables (a pet peeve of mine); can you make this
> be a field of the pretty_printer instead?
> 
> Even better: convert pretty_printer::show_urls from a bool to a new
> enum; something like:
> 
> enum diagnostic_url_format
> {
>   URL_FORMAT_NONE,
>   URL_FORMAT_ST,
>   URL_FORMAT_BEL  
> };
> 
> with suitable leading comments (probably a good place to summarize some
> of the compatibility info within the source).
> 
> Then we could verify the differences between ST and BEL in the
> selftests, and also not have the selftests be affected by env vars.
> 

Okay, I have to include diagnostic-url.h from pretty-print.h in that case,
since both files are included from the generated options.c in alphabetic order 
/-).
I was first a bit reluctant to do so, since we usually don't have recursive
header files but probably that is okay then, alternatively I could use a 
bitfield
in pretty-print.h and put defines for URL_FORMAT_xxx in diagnostic-url.h.

> 
>> +/* Return true if we should use urls when in always mode, false otherwise.
>> +   Additionally initialize diagnostic_urls_use_st to true if ST escapes
>> +   should be used and false for BEL escapes.  */
> 
> Maybe have this return that 3-way enum instead?
> 

okay, done.

>> +
>> +static bool
>> +parse_gcc_urls()
>> +{
>> +  const char *p;
>> +
>> +  p = getenv ("GCC_URLS"); /* Plural! */
>> +  if (p == NULL)
>> +p = getenv ("TERM_URLS");
>> +
>> +  if (p == NULL)
>> +return true;
>> +  if (*p == '\0')
>> +return false;
>> +
>> +  if (!strcmp (p, "no"))
>> +return false;
>> +  if (!strcmp (p, "st"))
>> +diagnostic_urls_use_st = true;
>> +  else if (!strcmp (p, "bel"))
>> +diagnostic_urls_use_st = false;
>> +  return true;
>> +}
>> +
>> +/* Return true if we should use urls when in auto mode, false otherwise.  */
>> +
>>

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

On 2/1/20 9:55 AM, Jakub Jelinek wrote:
> On Sat, Feb 01, 2020 at 07:30:15AM +0000, Bernd Edlinger wrote:
>> @@ -239,20 +243,86 @@ colorize_init (diagnostic_color_rule_t rule)
>>  }
>>  }
>>  
>> +/* Return URL_FORMAT_XXX which tells how we should emit urls
>> +   when in always mode.
>> +   We use GCC_URLS and if that is not defined TERM_URLS.
>> +   If neither is defined the feature is enabled by default.  */
>> +
>> +static diagnostic_url_format
>> +parse_gcc_urls()
> 
> Formatting, missing space before (.
> 

Gotcha :) this is openssl style sneaking in...

fixed.

>> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
>> index 6ffafac..59d7ecd 100644
>> --- a/gcc/doc/install.texi
>> +++ b/gcc/doc/install.texi
>> @@ -2097,9 +2097,18 @@ option (if not used explicitly on the command line).  
>> @var{choice}
>>  can be one of @samp{never}, @samp{auto}, @samp{always}, and 
>> @samp{auto-if-env}
>>  where @samp{auto} is the default.  @samp{auto-if-env} means that
>>  @option{-fdiagnostics-color=auto} will be the default if @code{GCC_COLORS}
>> -is present and non-empty in the environment, and
>> +is present and non-empty in the environment at runtime, and
>>  @option{-fdiagnostics-color=never} otherwise.
> 
> I'm not sure "at runtime" is the right term here, usually we talk about
> runtime when running the program produced by gcc, not about compile time.
> So perhaps try to be even more verbose and say "in the environment of the
> compiler" or so?
> 

way better, thanks.

>> +The default depends on how the compiler has been configured.
>> +it can be any of the above @var{WHEN} options.
> 
> After full stop next sentence should start with capital letter.
> 

fixed.

>> +
>> +GCC can also be configured (via the
>> +@option{--with-diagnostics-urls=auto-if-env} configure-time option)
>> +so that the default is affected by environment variables.
>> +Under such a configuration, GCC defaults to using @samp{auto}
>> +if either @env{GCC_URLS} or @env{TERM_URLS} environment variables are
>> +present in the environment, or @samp{never} if neither are.
>> +
>> +But even with @option{-fdiagnostics-urls=always} the behavior will be
>> +dependent on those environmen variables:

ah, typo...

> 
> I know I start sentences with But all the time, but some style guides are
> against that, not sure if we want to do that in the documentation.
> 

okay I can start the sentence now with "However, even with..."

In the sentence above I should probably also say are "present _and non-empty_ 
in the
environment _of the compiler_".

So here is just an incremental update with the improvements so far:

diff --git a/gcc/diagnostic-color.c b/gcc/diagnostic-color.c
index f406139..73ca771 100644
--- a/gcc/diagnostic-color.c
+++ b/gcc/diagnostic-color.c
@@ -249,7 +249,7 @@ colorize_init (diagnostic_color_rule_t rule)
If neither is defined the feature is enabled by default.  */
 
 static diagnostic_url_format
-parse_gcc_urls()
+parse_gcc_urls ()
 {
   const char *p;
 
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 59d7ecd..1d3fec5 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2097,7 +2097,7 @@ option (if not used explicitly on the command line).  
@var{choice}
 can be one of @samp{never}, @samp{auto}, @samp{always}, and @samp{auto-if-env}
 where @samp{auto} is the default.  @samp{auto-if-env} means that
 @option{-fdiagnostics-color=auto} will be the default if @code{GCC_COLORS}
-is present and non-empty in the environment at runtime, and
+is present and non-empty in the environment of the compiler, and
 @option{-fdiagnostics-color=never} otherwise.
 
 @item --with-diagnostics-urls=@var{choice}
@@ -2106,8 +2106,8 @@ option (if not used explicitly on the command line).  
@var{choice}
 can be one of @samp{never}, @samp{auto}, @samp{always}, and @samp{auto-if-env}
 where @samp{auto} is the default.  @samp{auto-if-env} means that
 @option{-fdiagnostics-urls=auto} will be the default if @env{GCC_URLS}
-or @env{TERM_URLS} is present and non-empty in the environment at runtime, and
-@option{-fdiagnostics-urls=never} otherwise.
+or @env{TERM_URLS} is present and non-empty in the environment of the
+compiler, and @option{-fdiagnostics-urls=never} otherwise.
 
 @item --enable-lto
 @itemx --disable-lto
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 6df0efd..59306bc 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4044,18 +4044,19 @@ option.
 is a terminal, and @env{TERM} is not set to "dumb".
 
 The default depends on how the compiler has been configured.
-it can be any of the above @var{WHEN} options.
+It can be any of the above @var{WHEN} options.
 
 GCC can

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

On 2/1/20 2:41 PM, David Malcolm wrote:
> On Sat, 2020-02-01 at 07:30 +0000, Bernd Edlinger wrote:
>>
>> On 1/31/20 11:06 PM, David Malcolm wrote:
>>> On Fri, 2020-01-31 at 16:59 +, Bernd Edlinger wrote:
>>>> Hi,
>>>>
>>>> this is patch is heavily based on David's original patch here:
>>>> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html
>>>>
>>>> and addresses Jakub's review comments here:
>>>> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01412.html
>>>>
>>>> So I hope you don't mind, when I pick up this patch since there
>>>> was not much activity recently on this issue, so I assumed you
>>>> would appreciate some help.
>>>
>>> Thanks Bernd; sorry, I got distracted by analyzer bug-fixing.  It's
>>> appreciated.
>>>
>>>> I will try to improve the patch a bit, and hope you are gonna
>>>> like
>>>> it. I agree that this feature is fine, and should be enabled by
>>>> default, and just if it is positively clear that it won't work,
>>>> disabled in the auto mode.
>>>>
>>>> Also as requested by Jakub this tries to be more compatible to
>>>> GCC_COLORS define, and adds the capability to switch between ST
>>>> and BEL string termination and also have a way to disable urls
>>>> even with -fdiagnostics-urls=always (like GCC_COLORS= disables
>>>> colors).
>>>>
>>>> In addition to that I propose to use GCC_URLS and if that
>>>> is not defined use TERM_URLS to control that feature for
>>>> all applications willing to support that.
> 
> [..]
> 
> Thanks for the updated patch; here are some notes:
> 
>> diff --git a/gcc/diagnostic-color.c b/gcc/diagnostic-color.c
>> index d554795..f406139 100644
>> --- a/gcc/diagnostic-color.c
>> +++ b/gcc/diagnostic-color.c
>> @@ -216,6 +216,10 @@ should_colorize (void)
>>&& GetConsoleMode (h, &m);
>>  #else
>>char const *t = getenv ("TERM");
>> +  /* Do not enable colors when TMUX is detected, since that is
>> + known to not work reliably.  */
>> +  if (t && strcmp (t, "screen") && getenv ("TMUX"))
>> +return false;
>>return t && strcmp (t, "dumb") != 0 && isatty (STDERR_FILENO);
>>  #endif
>>  }
> 
> Does our existing colorization code not work with TMUX, or is it just the
> new URLs that are broken?  Segher?
> 

I seem to remember him saying that he always has to configure with
--with-diagnostics-color=never, and the URLs are on top of that.
But there was no configure option for that, which, given his explanation,
made immediately sense to me.

In the case of the xfce terminal, the color thing was always working fine,
but beginning with last october, the warnings look just terrible.

If that assumption turns out to be wrong, we can easily move that check from
the auto_color to the auto_url code, or add more terminals which are
of that kind.


>> @@ -239,20 +243,86 @@ colorize_init (diagnostic_color_rule_t rule)
>>  }
>>  }
>>  
>> +/* Return URL_FORMAT_XXX which tells how we should emit urls
>> +   when in always mode.
>> +   We use GCC_URLS and if that is not defined TERM_URLS.
>> +   If neither is defined the feature is enabled by default.  */
>> +
>> +static diagnostic_url_format
>> +parse_gcc_urls()
> 
> Perhaps rename this to parse_env_vars_for_urls or somesuch, given that
> it's not just GCC_URLS being parsed?
> 

Okay, no problem.

>> +/* Return true if we should use urls when in auto mode, false otherwise.  */
>> +
>> +static bool
>> +auto_enable_urls ()
>> +{
>> +#ifdef __MINGW32__
>> +  return false;
>> +#else
>> +  const char *p;
>> +
>> +  /* First check the terminal is capable to print color escapes,
>  ^^^
> grammar nit: "is capable of printing"
> 

Thanks.

>> + if not URLs won't work either.  */
>> +  if (!should_colorize ())
>> +return false;
>> +
>> +  p = getenv ("COLORTERM");
>> +  if (p == NULL)
>> +return true;
> 
> Is this part of the rejection of terminals that can't print color
> escapes, or is this some other heuristic based on the discussion?
> 

Yes, it has nothing to do with color, the point that was made on the
Hyperlink discussion gist page, was that the correct value would have been
COLORTERM="truecolor", instead of &

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

On 2/1/20 4:54 PM, Segher Boessenkool wrote:
> Hi!
> 
> On Sat, Feb 01, 2020 at 05:02:18AM +0000, Bernd Edlinger wrote:
>>>> Definitely, if the situation with tmux is like xfce4-terminal (reportedly
>>>> the 0.8 version switched to a fixed VTE, which makes the URLs invisible,
>>>> but the URL feature request is pending sine 2017, with no activity 
>>>> whatsoever),
>>>> then detecting that and disabling the URLs until they finally implement
>>>> the URLs is straight forward.  I can add that to my patch if you confirm,
>>>> the right detection logic:
>>>
>>> The situation is that it is a terminal multiplexer; you can connect any
>>> terminal to it, and swap those out, etc.  You might have one that has
>>> support for the url thing at one time, but when you look at that session
>>> from a different machine (from your phone, say), not anymore (or the
>>> other way around).  You can also connect multiple actual terminals at
>>> the same time.
>>>
>>> In short, even *if* you could detect whether the terminal supports this
>>> url thing (and you cannot), you cannot detect whether it will support it
>>> two seconds from now, and even if the url thing you already displayed
>>> will misbehave *in the future*!
>>
>> Ah, okay, this is a totally wrong assumption then.
>>
>> So if I understand you right, I should add a check for
>> tmux in should_colorize, where the TERM=dumb thing is,
>> and add TERM=screen, and TMUX=anything, to switch of
>> auto-color off, which will take down URLs at the same time?
> 
> Well, colourisation doesn't mess up the display so much, in practice; it
> just makes it completely unreadable (for me anyway), so I have GCC_COLORS=
> just like I need stuff for very many other programs to disable colours.
> Something similar can of course work to turn off the url thing, but since
> that make the display unusable on not very few systems, and the utility
> of this is much lower as well (people just love those colours, for some
> strange reason; urls is more meh), yes please, do not do the url thing
> with TERM=dumb or TERM=ansi or TERM=screen and maybe some similar; but I
> think many people will like their colours enabled.
> 
> 


re-sending this as I accidentally did not "reply-to-all"...

Okay in that case I would move the TUMX detection code to the auto_url
function, that is easy.  I would of course like to be as specific to
a single terminal as possible here, since it is possible that
tumx will implement URLs some day, at least there seems to be
a patch available here:
https://github.com/tmux/tmux/issues/911#issuecomment-554312483

so once there is a released tumx version, and that works reliably,
which I may still doubt, we should reconsider this auto detection.

So the situation may well arise that we would like to auto-enable tumx
and auto-disable screen if I see that right.  But certainly we should
only disable a potentially useful feature when there is hard evidence
that it is *only* causing real problems to real people.


And what is the meaning of TERM=ansi does it imply it does not
understand these OSC-8 escape codes ?


So I moved the check for TUMX to the url code path only now, as
Segher suggested.
I am yet undecided what to make out of TERM=ansi, but it is hopefully
only a theoretical issue.


I attached the new version again.

Is it OK for trunk?


Bernd.



From 68203865b77ec254324746316fc438fa65fbc2b3 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Wed, 29 Jan 2020 15:31:10 +0100
Subject: [PATCH] PR 87488: Add --with-diagnostics-urls configuration option

2020-01-30  David Malcolm  
	Bernd Edlinger  

	PR 87488
	PR other/93168
	* config.in (DIAGNOSTICS_URLS_DEFAULT): New define.
	* configure.ac (--with-diagnostics-urls): New configuration
	option, based on --with-diagnostics-color.
	(DIAGNOSTICS_URLS_DEFAULT): New define.
	* config.h: Regenerate.
	* configure: Regenerate.
	* diagnostic.c (diagnostic_urls_init): Handle -1 for
	DIAGNOSTICS_URLS_DEFAULT from configure-time
	--with-diagnostics-urls=auto-if-env by querying for a GCC_URLS
	and TERM_URLS environment variable.
	* diagnostic-url.h (diagnostic_url_format): New enum type.
	(diagnostic_urls_enabled_p): rename to...
	(parse_env_vars_for_urls): ... this, and change return type.
	* diagnostic-color.c (parse_gcc_urls): New helper function.
	(auto_enable_urls): Disable URLs on tumx, xfce4-terminal, mingw.
	(parse_env_vars_for_urls): Adjust.
	* pretty-print.h (pretty_printer::show_urls): rename to...
	(pretty_printer::url_format): ... this, and change to enum.
	* pretty-print.c (pretty_printer::pretty_printer,
	pp_begin_url, pp_end_url, test_urls): Adjust.
	* doc/install.texi (--with-diagnostics-urls): Document the new
	configurati

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

On 2/1/20 6:12 PM, Jakub Jelinek wrote:
> On Sat, Feb 01, 2020 at 03:43:20PM +0000, Bernd Edlinger wrote:
>> I seem to remember him saying that he always has to configure with
>> --with-diagnostics-color=never, and the URLs are on top of that.
>> But there was no configure option for that, which, given his explanation,
>> made immediately sense to me.
>>
>> In the case of the xfce terminal, the color thing was always working fine,
>> but beginning with last october, the warnings look just terrible.
>>
>> If that assumption turns out to be wrong, we can easily move that check from
>> the auto_color to the auto_url code, or add more terminals which are
>> of that kind.
> 
> For me colors work just fine in screen, it really depends on which
> terminals one is attaching the screen from.
> URLs don't work, but show up exactly as if they were disabled, no visual nor
> accoustic problems with those (and work fine in gnome-terminal which is
> recent).
> That said, my TERM is actually screen.xterm-256color rather than just screen
> (and xterm-256color in gnome-terminal).
> 

Okay, thanks.  That is a strong indication that there is no need
to interfere with screen, which proves that any auto-disabling should
have a very specific terminal detection logic.


Bernd.

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

On 1/31/20 11:54 PM, Segher Boessenkool wrote:
> none of which use "TERM=fancy-pants-term-v42" either.  (Did anyone ever
> use "dumb", anyway?)
> 

It seems like emacs shell does set TERM=dumb, and it is certainly
the right thing not to emit any control codes in that environment.



Bernd.

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

On 2/2/20 12:05 AM, Segher Boessenkool wrote:
> On Sat, Feb 01, 2020 at 05:21:30PM +0000, Bernd Edlinger wrote:
>> On 2/1/20 6:12 PM, Jakub Jelinek wrote:
>>> On Sat, Feb 01, 2020 at 03:43:20PM +0000, Bernd Edlinger wrote:
>>>> I seem to remember him saying that he always has to configure with
>>>> --with-diagnostics-color=never, and the URLs are on top of that.
>>>> But there was no configure option for that, which, given his explanation,
>>>> made immediately sense to me.
>>>>
>>>> In the case of the xfce terminal, the color thing was always working fine,
>>>> but beginning with last october, the warnings look just terrible.
>>>>
>>>> If that assumption turns out to be wrong, we can easily move that check 
>>>> from
>>>> the auto_color to the auto_url code, or add more terminals which are
>>>> of that kind.
>>>
>>> For me colors work just fine in screen, it really depends on which
>>> terminals one is attaching the screen from.
>>> URLs don't work, but show up exactly as if they were disabled, no visual nor
>>> accoustic problems with those (and work fine in gnome-terminal which is
>>> recent).
>>> That said, my TERM is actually screen.xterm-256color rather than just screen
>>> (and xterm-256color in gnome-terminal).
>>
>> Okay, thanks.  That is a strong indication that there is no need
>> to interfere with screen, which proves that any auto-disabling should
>> have a very specific terminal detection logic.
> 
> Jakub says that he tested with a recent gnome-terminal.  That works, of
> course.  Mnay other terminals will not, and switching what terminal is
> attached to your screen session will not work well either, as far as I
> can tell.
> 

I understood his statement, that the URLs are stripped from the data
stream by screen and are no longer visible, even if the terminal would
support them i.e. you connect from a gnome-terminal.
But work fine when the compiler runs natively in a gnome-terminal.

Or does screen pass the URL escapes thru to any terminal wether or not
the produce garbage?


Bernd.

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

On 2/2/20 1:28 AM, Sandra Loosemore wrote:
> On 2/1/20 8:43 AM, Bernd Edlinger wrote:
> 
>> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
>> index 6ffafac..1d3fec5 100644
>> --- a/gcc/doc/install.texi
>> +++ b/gcc/doc/install.texi
>> @@ -2097,9 +2097,18 @@ option (if not used explicitly on the command line).  
>> @var{choice}
>>  can be one of @samp{never}, @samp{auto}, @samp{always}, and 
>> @samp{auto-if-env}
>>  where @samp{auto} is the default.  @samp{auto-if-env} means that
>>  @option{-fdiagnostics-color=auto} will be the default if @code{GCC_COLORS}
>> -is present and non-empty in the environment, and
>> +is present and non-empty in the environment of the compiler, and
>>  @option{-fdiagnostics-color=never} otherwise.
>>  
>> +@item --with-diagnostics-urls=@var{choice}
>> +Tells GCC to use @var{choice} as the default for 
>> @option{-fdiagnostics-urls=}
>> +option (if not used explicitly on the command line).  @var{choice}
>> +can be one of @samp{never}, @samp{auto}, @samp{always}, and 
>> @samp{auto-if-env}
>> +where @samp{auto} is the default.  @samp{auto-if-env} means that
>> +@option{-fdiagnostics-urls=auto} will be the default if @env{GCC_URLS}
>> +or @env{TERM_URLS} is present and non-empty in the environment of the
>> +compiler, and @option{-fdiagnostics-urls=never} otherwise.
>> +
> 
> It would be good to rewrite both of the above paragraphs to get rid of the 
> future tense and put them in the active voice, like
> 
> @samp{auto-if-env} makes ... the default if ...
> 

done.

> Also @code{GCC_COLORS} ought to be @env{GCC_COLORS}, no?
> 

right.

>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> index b8ba8a3..59306bc 100644
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -4032,14 +4032,41 @@ arguments in the C++ frontend.
>>  @item -fdiagnostics-urls[=@var{WHEN}]
>>  @opindex fdiagnostics-urls
>>  @cindex urls
>> +@vindex GCC_URLS @r{environment variable}
>> +@vindex TERM_URLS @r{environment variable}
>>  Use escape sequences to embed URLs in diagnostics.  For example, when
>>  @option{-fdiagnostics-show-option} emits text showing the command-line
>>  option controlling a diagnostic, embed a URL for documentation of that
>>  option.
>>  
>>  @var{WHEN} is @samp{never}, @samp{always}, or @samp{auto}.
>> -The default is @samp{auto}, which means to use URL escape sequences only
>> -when the standard error is a terminal.
>> +@samp{auto} means to use URL escape sequences only when the standard error
>> +is a terminal, and @env{TERM} is not set to "dumb".
> 
> We should avoid literal quotes in the manual instead of proper markup. Maybe 
> @samp{dumb}?  Or is this trying to express something other than a literal 
> string?
> 

okay, in this case, maybe it gets clearer when I write:

"standard error is a terminal, and when not executing in an emacs shell."

I moved the "dumb" to a comment in the C-function doing that detection
now, and consider it an implementation detail for the emacs detection.


>> +
>> +The default depends on how the compiler has been configured.
>> +It can be any of the above @var{WHEN} options.
>> +
>> +GCC can also be configured (via the
>> +@option{--with-diagnostics-urls=auto-if-env} configure-time option)
>> +so that the default is affected by environment variables.
>> +Under such a configuration, GCC defaults to using @samp{auto}
>> +if either @env{GCC_URLS} or @env{TERM_URLS} environment variables are
>> +present and non-empty in the environment of the compiler, or @samp{never}
>> +if neither are.
>> +
>> +However, even with @option{-fdiagnostics-urls=always} the behavior will be
> 
> s/will be/is/, unless this is something that hasn't been implemented yet.  :-S
> 

okay, thanks.

>> +dependent on those environment variables:
>> +If @env{GCC_URLS} set to empty or "no", do not embed URLs in diagnostics.
> 
> s/set/is set/ ??
> 

yes.

> And please avoid literal quotes in the text here too.
> 

done.

>> +If set to "st", URLs use ST escape sequences.
>> +If set to "bel", the default, URLs use BEL escape sequences.
> 
> I have no idea what ST and BEL escape sequences are
> 

those are the acronyms of certain escape sequences, I added an explanation.

>> +Any other non-empty value enables the feature.
>> +If @env{GCC_URLS} is not set, use @env{TERM_URLS} as a fallback.
>> +
>> +At this time GCC tries to detect also a few terminals that are known to
>> +not implement the URL feature, and have an i

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

On 2/3/20 3:08 PM, Segher Boessenkool wrote:
> On Sun, Feb 02, 2020 at 08:00:44AM +0000, Bernd Edlinger wrote:
>>>> Okay, thanks.  That is a strong indication that there is no need
>>>> to interfere with screen, which proves that any auto-disabling should
>>>> have a very specific terminal detection logic.
>>>
>>> Jakub says that he tested with a recent gnome-terminal.  That works, of
>>> course.  Mnay other terminals will not, and switching what terminal is
>>> attached to your screen session will not work well either, as far as I
>>> can tell.
>>
>> I understood his statement, that the URLs are stripped from the data
>> stream by screen and are no longer visible, even if the terminal would
>> support them i.e. you connect from a gnome-terminal.
> 
> It looks like tmux strips it as well.  But in my earlier testing it did
> not?  Confused.  Maybe this was the auto-detect thing, dunno.  I guess
> I'll test with more tmux versions when I find some more time for this.
> 

Okay, I see, I will remove the tmux detection until further notice.

>> But work fine when the compiler runs natively in a gnome-terminal.
> 
> It is big garbage for me, both with bell (which is much worse on some
> other terminals), and with the string terminator escape (ESC \).
> 

So gnome terminal is a problem, since it depend heavily on the software
version, VTE library, and gnome-terminal.
Sometimes URLs are functional, sometimes competely buggy.

But, wait a moment, here is the deal:

I can detect old gnome terminals,
they have COLORTERM=gnome-terminal (and produce garbage)

but new gnome terminal with true URL-support have

COLORTERM=truecolor

So how about adding that to the detection logic ?

Jakub, can you confirm that the COLORTERM on your working
gnome-terminal is set to "truecolor" ?

Obviously, my top priority is not breaking URLs on that
working gnome version.


Thanks
Bernd.

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

On 2/3/20 9:26 PM, Jakub Jelinek wrote:
> On Mon, Feb 03, 2020 at 08:16:52PM +0000, Bernd Edlinger wrote:
>> Jakub, can you confirm that the COLORTERM on your working
>> gnome-terminal is set to "truecolor" ?
> 
> On the box where I have display attached to yes, but it isn't propagated
> through ssh to the workstation that I do GCC development on, $COLORTERM
> is unset there.  Only $TERM is set there (to xterm-256color).
> 

Yes, 

with an old gnome-terminal version (with display corruption),
I see TERM=xterm  COLORTERM=gnome-terminal

When I use a serial terminal to log in a linux box,
I have TERM=linux, and URLs do sometimes work,
sometimes not, sometime cause glitches, that depends
on the terminal where picocom is running.

We could enable auto URLs with TERM=xterm-256color,
Or better switch it off with TERM=linux and TERM=xterm,
which leaves TERM=screen and TERM=screen.xterm-256color
emit the URL escapes, since the screen can handle that
as it looks now.

I am not sure if this is too aggressive or not,
what do you think?


Thanks
Bernd.

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

On 2/3/20 10:05 PM, Segher Boessenkool wrote:
> On Mon, Feb 03, 2020 at 08:16:52PM +0000, Bernd Edlinger wrote:
>> So gnome terminal is a problem, since it depend heavily on the software
>> version, VTE library, and gnome-terminal.
>> Sometimes URLs are functional, sometimes competely buggy.
>>
>> But, wait a moment, here is the deal:
>>
>> I can detect old gnome terminals,
>> they have COLORTERM=gnome-terminal (and produce garbage)
>>
>> but new gnome terminal with true URL-support have
>>
>> COLORTERM=truecolor
>>
>> So how about adding that to the detection logic ?
> 
> It works on at least one of my older setups, too (will have to check
> the rest when I have time, unfortunately the weekend is just past).
> 

Cool.

so here is the next version, which removes tmux, and adds
detection of old gnome-terminal, and linux console sessions,
while also attempting to work with ssh sessions, where we
do we have a bit less reliable information, but I would
think that is still an improvement.  I'd let TERM_URLS and
GCC_URLS override the last two exceptions, as TERM=xterm
can also mean, really xterm, but while that one does not
print garbage, it does not handle the URLs either.


How do you like it this way?

Is it OK for trunk?


Thanks
Bernd.
From 35a6a850680907995e13dcd8497f5190710af0dd Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Wed, 29 Jan 2020 15:31:10 +0100
Subject: [PATCH] PR 87488: Add --with-diagnostics-urls configuration option

2020-01-30  David Malcolm  
	Bernd Edlinger  

	PR 87488
	PR other/93168
	* config.in (DIAGNOSTICS_URLS_DEFAULT): New define.
	* configure.ac (--with-diagnostics-urls): New configuration
	option, based on --with-diagnostics-color.
	(DIAGNOSTICS_URLS_DEFAULT): New define.
	* config.h: Regenerate.
	* configure: Regenerate.
	* diagnostic.c (diagnostic_urls_init): Handle -1 for
	DIAGNOSTICS_URLS_DEFAULT from configure-time
	--with-diagnostics-urls=auto-if-env by querying for a GCC_URLS
	and TERM_URLS environment variable.
	* diagnostic-url.h (diagnostic_url_format): New enum type.
	(diagnostic_urls_enabled_p): rename to...
	(parse_env_vars_for_urls): ... this, and change return type.
	* diagnostic-color.c (parse_gcc_urls): New helper function.
	(auto_enable_urls): Disable URLs on xfce4-terminal, gnome-terminal,
	the linux console, and mingw.
	(parse_env_vars_for_urls): Adjust.
	* pretty-print.h (pretty_printer::show_urls): rename to...
	(pretty_printer::url_format): ... this, and change to enum.
	* pretty-print.c (pretty_printer::pretty_printer,
	pp_begin_url, pp_end_url, test_urls): Adjust.
	* doc/install.texi (--with-diagnostics-urls): Document the new
	configuration option.
	* doc/invoke.texi (-fdiagnostics-urls): Add GCC_URLS and TERM_URLS
	vindex reference.  Update description of defaults based on the above.
---
 gcc/config.in  |   6 +++
 gcc/configure  |  41 +++-
 gcc/configure.ac   |  28 ++
 gcc/diagnostic-color.c | 102 ++---
 gcc/diagnostic-url.h   |  18 -
 gcc/diagnostic.c   |  21 --
 gcc/doc/install.texi   |  15 ++--
 gcc/doc/invoke.texi|  39 +--
 gcc/pretty-print.c |  44 ++---
 gcc/pretty-print.h |   5 ++-
 10 files changed, 293 insertions(+), 26 deletions(-)

diff --git a/gcc/config.in b/gcc/config.in
index 4829286..01fb18d 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -76,6 +76,12 @@
 #endif
 
 
+/* The default for -fdiagnostics-urls option */
+#ifndef USED_FOR_TARGET
+#undef DIAGNOSTICS_URLS_DEFAULT
+#endif
+
+
 /* Define 0/1 if static analyzer feature is enabled. */
 #ifndef USED_FOR_TARGET
 #undef ENABLE_ANALYZER
diff --git a/gcc/configure b/gcc/configure
index 5fa565a..f55cdb8 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -1015,6 +1015,7 @@ enable_host_shared
 enable_libquadmath_support
 with_linker_hash_style
 with_diagnostics_color
+with_diagnostics_urls
 enable_default_pie
 '
   ac_precious_vars='build_alias
@@ -1836,6 +1837,11 @@ Optional Packages:
   auto-if-env stands for -fdiagnostics-color=auto if
   GCC_COLOR environment variable is present and
   -fdiagnostics-color=never otherwise
+  --with-diagnostics-urls={never,auto,auto-if-env,always}
+  specify the default of -fdiagnostics-urls option
+  auto-if-env stands for -fdiagnostics-urls=auto if
+  GCC_URLS or TERM_URLS environment variable is
+  present and -fdiagnostics-urls=never otherwise
 
 Some influential environment variables:
   CC  C compiler command
@@ -18974,7 +18980,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18977 &qu

[PING] [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[Bernd Edlinger]

Ping...

the latest version of this patch is here:
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00121.html


Thanks
Bernd.

On 2/3/20 11:29 PM, Bernd Edlinger wrote:
> On 2/3/20 10:05 PM, Segher Boessenkool wrote:
>> On Mon, Feb 03, 2020 at 08:16:52PM +0000, Bernd Edlinger wrote:
>>> So gnome terminal is a problem, since it depend heavily on the software
>>> version, VTE library, and gnome-terminal.
>>> Sometimes URLs are functional, sometimes competely buggy.
>>>
>>> But, wait a moment, here is the deal:
>>>
>>> I can detect old gnome terminals,
>>> they have COLORTERM=gnome-terminal (and produce garbage)
>>>
>>> but new gnome terminal with true URL-support have
>>>
>>> COLORTERM=truecolor
>>>
>>> So how about adding that to the detection logic ?
>>
>> It works on at least one of my older setups, too (will have to check
>> the rest when I have time, unfortunately the weekend is just past).
>>
> 
> Cool.
> 
> so here is the next version, which removes tmux, and adds
> detection of old gnome-terminal, and linux console sessions,
> while also attempting to work with ssh sessions, where we
> do we have a bit less reliable information, but I would
> think that is still an improvement.  I'd let TERM_URLS and
> GCC_URLS override the last two exceptions, as TERM=xterm
> can also mean, really xterm, but while that one does not
> print garbage, it does not handle the URLs either.
> 
> 
> How do you like it this way?
> 
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 

[PATCH] Fix skip.exp test failure observed with gcc-9.2.0

[Bernd Edlinger]

Hi,

this is the split out patch on skip.exp which fixes a pre-existing
compatibilty issue with that test case and gcc-9.2.0 (and gcc-10 from
trunk of a few weeks ago at least, likely other versions too).


Is it OK for trunk?


Thanks
Bernd.

gdb/testsuite:
2019-12-15  Bernd Edlinger  

* gdb.base/skip.exp: Fix test failure observed with gcc-9.2.0.
From b15964b769373f25f276430914c5efa84d411032 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Sun, 15 Dec 2019 11:05:47 +0100
Subject: [PATCH] Fix skip.exp test failure observed with gcc-9.2.0

Need to step a second time because with this gcc version
the first step jumps back to main before entering foo.
---
 gdb/testsuite/gdb.base/skip.exp | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/gdb/testsuite/gdb.base/skip.exp b/gdb/testsuite/gdb.base/skip.exp
index d763194..15dec42 100644
--- a/gdb/testsuite/gdb.base/skip.exp
+++ b/gdb/testsuite/gdb.base/skip.exp
@@ -21,8 +21,8 @@ load_lib completion-support.exp
 standard_testfile
 
 if { [prepare_for_testing "failed to prepare" "skip" \
-  {skip.c skip1.c } \
-  {debug nowarnings}] } {
+			  {skip.c skip1.c } \
+			  {debug nowarnings}] } {
 return -1
 }
 
@@ -142,7 +142,9 @@ with_test_prefix "step after disabling 3" {
 
 gdb_test "step" "bar \\(\\) at.*" "step 1"
 gdb_test "step" ".*" "step 2"; # Return from foo()
-gdb_test "step" "foo \\(\\) at.*" "step 3"
+# With gcc 9.2.0 we jump once back to main before entering foo here.
+# If that happens try to step a second time.
+gdb_test "step" "foo \\(\\) at.*" "step 3" "main \\(\\) at .*" "step"
 gdb_test "step" ".*" "step 4"; # Return from bar()
 gdb_test "step" "main \\(\\) at.*" "step 5"
 }
@@ -261,7 +263,9 @@ with_test_prefix "step using -fu for baz" {
 gdb_test_no_output "skip enable 7"
 gdb_test "step" "bar \\(\\) at.*" "step 1"
 gdb_test "step" ".*" "step 2"; # Return from bar()
-gdb_test "step" "foo \\(\\) at.*" "step 3"
+# With gcc 9.2.0 we jump once back to main before entering foo here.
+# If that happens try to step a second time.
+gdb_test "step" "foo \\(\\) at.*" "step 3" "main \\(\\) at.*" "step"
 gdb_test "step" ".*" "step 4"; # Return from foo()
 gdb_test "step" "main \\(\\) at.*" "step 5"
 }
@@ -276,7 +280,9 @@ with_test_prefix "step using -rfu for baz" {
 gdb_test_no_output "skip enable 8"
 gdb_test "step" "bar \\(\\) at.*" "step 1"
 gdb_test "step" ".*" "step 2"; # Return from bar()
-gdb_test "step" "foo \\(\\) at.*" "step 3"
+# With gcc 9.2.0 we jump once back to main before entering foo here.
+# If that happens try to step a second time.
+gdb_test "step" "foo \\(\\) at.*" "step 3" "main \\(\\) at.*" "step"
 gdb_test "step" ".*" "step 4"; # Return from foo()
 gdb_test "step" "main \\(\\) at.*" "step 5"
 }
-- 
1.9.1

Re: [PATCH] Fix skip.exp test failure observed with gcc-9.2.0

[Bernd Edlinger]

Oh, sorry, worng mailing list.
Please ignore this one.

On 12/15/19 12:25 PM, Bernd Edlinger wrote:
> Hi,
> 
> this is the split out patch on skip.exp which fixes a pre-existing
> compatibilty issue with that test case and gcc-9.2.0 (and gcc-10 from
> trunk of a few weeks ago at least, likely other versions too).
> 
> 
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS env var

[Bernd Edlinger]

Hi David,

thanks for fixing this issue.

Just one comment:

> +[DIAGNOSTICS_URLS_DEFAULT=DIAGNOSTICS_URL_AUTO])
> +AC_DEFINE_UNQUOTED(DIAGNOSTICS_URLS_DEFAULT, $DIAGNOSTICS_URLS_DEFAULT,
> +[The default for -fdiagnostics-urls option])

I think for a feature as disruptive as this, when a
terminal implements that it ought to advertise this feature via
an environment variable.  So I would prefer the default
to be auto-if-env.

Ideally there should be some neutral variable similar to TERM,
maybe TERM_URL=yes if that convention does not exist yet,
maybe we should invent it?


Thanks
Bernd.

Re: [PATCH v4 12/12] constructor: Check if it is faster to load constant from memory

[Bernd Edlinger]

On 5/19/21 3:22 PM, H.J. Lu wrote:
> On Wed, May 19, 2021 at 2:33 AM Richard Biener
>  wrote:
>>
>> On Tue, May 18, 2021 at 9:16 PM H.J. Lu  wrote:
>>>
>>> When expanding a constant constructor, don't call expand_constructor if
>>> it is more efficient to load the data from the memory via move by pieces.
>>>
>>> gcc/
>>>
>>> PR middle-end/90773
>>> * expr.c (expand_expr_real_1): Don't call expand_constructor if
>>> it is more efficient to load the data from the memory.
>>>
>>> gcc/testsuite/
>>>
>>> PR middle-end/90773
>>> * gcc.target/i386/pr90773-24.c: New test.
>>> * gcc.target/i386/pr90773-25.c: Likewise.
>>> ---
>>>  gcc/expr.c | 10 ++
>>>  gcc/testsuite/gcc.target/i386/pr90773-24.c | 22 ++
>>>  gcc/testsuite/gcc.target/i386/pr90773-25.c | 20 
>>>  3 files changed, 52 insertions(+)
>>>  create mode 100644 gcc/testsuite/gcc.target/i386/pr90773-24.c
>>>  create mode 100644 gcc/testsuite/gcc.target/i386/pr90773-25.c
>>>
>>> diff --git a/gcc/expr.c b/gcc/expr.c
>>> index d09ee42e262..80e01ea1cbe 100644
>>> --- a/gcc/expr.c
>>> +++ b/gcc/expr.c
>>> @@ -10886,6 +10886,16 @@ expand_expr_real_1 (tree exp, rtx target, 
>>> machine_mode tmode,
>>> unsigned HOST_WIDE_INT ix;
>>> tree field, value;
>>>
>>> +   /* Check if it is more efficient to load the data from
>>> +  the memory directly.  FIXME: How many stores do we
>>> +  need here if not moved by pieces?  */
>>> +   unsigned HOST_WIDE_INT bytes
>>> + = tree_to_uhwi (TYPE_SIZE_UNIT (type));
>>
>> that's prone to fail - it could be a VLA.
> 
> What do you mean by fail?  Is it ICE or missed optimization?
> Do you have a testcase?
> 

I think for a VLA the TYPE_SIZE_UNIT may be unknown (NULL), or something like 
"x".

for instance something like

int test (int x)
{
  int vla[x];

  vla[x-1] = 0;
  return vla[x-1];
}


Bernd.

>>
>>> +   if ((bytes / UNITS_PER_WORD) > 2
>>> +   && MOVE_MAX_PIECES > UNITS_PER_WORD
>>> +   && can_move_by_pieces (bytes, TYPE_ALIGN (type)))
>>> + goto normal_inner_ref;
>>> +
>>
>> It looks like you're concerned about aggregate copies but this also handles
>> non-aggregates (which on GIMPLE might already be optimized of course).
> 
> Here I check if we copy more than 2 words and we can move more than
> a word in a single instruction.
> 
>> Also you say "if it's cheaper" but I see no cost considerations.  How do
>> we generally handle immed const vs. load from constant pool costs?
> 
> This trades 2 (update to 8) stores with one load plus one store.  Is there
> a way to check which one is faster?
> 
>>> FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (init), ix,
>>>   field, value)
>>>   if (tree_int_cst_equal (field, index))
>>> diff --git a/gcc/testsuite/gcc.target/i386/pr90773-24.c 
>>> b/gcc/testsuite/gcc.target/i386/pr90773-24.c
>>> new file mode 100644
>>> index 000..4a4b62533dc
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/i386/pr90773-24.c
>>> @@ -0,0 +1,22 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-O2 -march=x86-64" } */
>>> +
>>> +struct S
>>> +{
>>> +  long long s1 __attribute__ ((aligned (8)));
>>> +  unsigned s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13, s14;
>>> +};
>>> +
>>> +const struct S array[] = {
>>> +  { 0, 60, 640, 2112543726, 39682, 48, 16, 33, 10, 96, 2, 0, 0, 4 }
>>> +};
>>> +
>>> +void
>>> +foo (struct S *x)
>>> +{
>>> +  x[0] = array[0];
>>> +}
>>> +/* { dg-final { scan-assembler-times "movups\[\\t \]%xmm\[0-9\]+, 
>>> \\(%\[\^,\]+\\)" 1 } } */
>>> +/* { dg-final { scan-assembler-times "movups\[\\t \]%xmm\[0-9\]+, 
>>> 16\\(%\[\^,\]+\\)" 1 } } */
>>> +/* { dg-final { scan-assembler-times "movups\[\\t \]%xmm\[0-9\]+, 
>>> 32\\(%\[\^,\]+\\)" 1 } } */
>>> +/* { dg-final { scan-assembler-times "movups\[\\t \]%xmm\[0-9\]+, 
>>> 48\\(%\[\^,\]+\\)" 1 } } */
>>> diff --git a/gcc/testsuite/gcc.target/i386/pr90773-25.c 
>>> b/gcc/testsuite/gcc.target/i386/pr90773-25.c
>>> new file mode 100644
>>> index 000..2520b670989
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/i386/pr90773-25.c
>>> @@ -0,0 +1,20 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-O2 -march=skylake" } */
>>> +
>>> +struct S
>>> +{
>>> +  long long s1 __attribute__ ((aligned (8)));
>>> +  unsigned s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13, s14;
>>> +};
>>> +
>>> +const struct S array[] = {
>>> +  { 0, 60, 640, 2112543726, 39682, 48, 16, 33, 10, 96, 2, 0, 0, 4 }
>>> +};
>>> +
>>> +void
>>> +foo (struct S *x)
>>> +{
>>> +  x[0] = array[0];
>>> +}
>>> +/* { dg-final { scan-assembler-times "vmovdqu\[\\t \]%ymm\[0-9\]+, 
>>> \\(%\[\^,\]+\\)" 1 } } */
>>> +/* { dg-final { scan-assembler-times "vmovdqu\[\\t \]%ymm\[0-9\]+, 
>>> 32\\(%\[\^,\]+\

Re: [committed] libstdc++: Fix std::jthread assertion and re-enable skipped test

[Bernd Edlinger]

On 5/19/21 3:27 PM, Jonathan Wakely wrote:
> On 18/05/21 13:58 +0200, Bernd Edlinger wrote:
>> On 5/18/21 1:55 PM, Bernd Edlinger wrote:
>>> On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
>>>> libstdc++-v3/ChangeLog:
>>>>
>>>> * include/std/thread (jthread::_S_create): Fix static assert
>>>> message.
>>>> * testsuite/30_threads/jthread/95989.cc: Re-enable test.
>>>> * testsuite/30_threads/jthread/jthread.cc: Do not require
>>>> pthread effective target.
>>>> * testsuite/30_threads/jthread/2.cc: Moved to...
>>>> * testsuite/30_threads/jthread/version.cc: ...here.
>>>>
>>>> Tested powerpc64le-linux. Committed to trunk.
>>>>
>>>> Let's see if this test is actually fixed, or if it still causes
>>>> failures on some targets.
>>>>
>>>>
>>>
>>> Yes, indeed it is failing on x86_64-pc-linux-gnu.
>>>
>>
>> that means only this one:
>>
>> FAIL: 30_threads/jthread/95989.cc execution test
> 
> What's your glibc version?
> 
> 

that is ubuntu 20.04 with latest patches:

$ ldd --version
ldd (Ubuntu GLIBC 2.31-0ubuntu9.3) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.


Bernd.

Re: [committed] testuite: Check pthread for omp module testing

[Bernd Edlinger]

On 5/19/21 4:58 PM, Kito Cheng wrote:
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/modules/omp-1_a.C: Check pthread is available.
>   * g++.dg/modules/omp-1_b.C: Ditto.
>   * g++.dg/modules/omp-1_c.C: Ditto.
>   * g++.dg/modules/omp-2_a.C: Ditto.
>   * g++.dg/modules/omp-2_b.C: Ditto.
> ---
>  gcc/testsuite/g++.dg/modules/omp-1_a.C | 1 +
>  gcc/testsuite/g++.dg/modules/omp-1_b.C | 1 +
>  gcc/testsuite/g++.dg/modules/omp-1_c.C | 1 +
>  gcc/testsuite/g++.dg/modules/omp-2_a.C | 1 +
>  gcc/testsuite/g++.dg/modules/omp-2_b.C | 1 +
>  5 files changed, 5 insertions(+)
> 
> diff --git a/gcc/testsuite/g++.dg/modules/omp-1_a.C 
> b/gcc/testsuite/g++.dg/modules/omp-1_a.C
> index 722720a0e93..94e1171f03c 100644
> --- a/gcc/testsuite/g++.dg/modules/omp-1_a.C
> +++ b/gcc/testsuite/g++.dg/modules/omp-1_a.C
> @@ -1,4 +1,5 @@
>  // { dg-additional-options "-fmodules-ts -fopenmp" }
> +// { dg-require-effective-target pthread }
>  
>  export module foo;
>  // { dg-module-cmi foo }
> diff --git a/gcc/testsuite/g++.dg/modules/omp-1_b.C 
> b/gcc/testsuite/g++.dg/modules/omp-1_b.C
> index f3f5d92e517..09d97e4ac4e 100644
> --- a/gcc/testsuite/g++.dg/modules/omp-1_b.C
> +++ b/gcc/testsuite/g++.dg/modules/omp-1_b.C
> @@ -1,4 +1,5 @@
>  // { dg-additional-options "-fmodules-ts -fopenmp" }
> +// { dg-require-effective-target pthread }
>  
>  import foo;
>  
> diff --git a/gcc/testsuite/g++.dg/modules/omp-1_c.C 
> b/gcc/testsuite/g++.dg/modules/omp-1_c.C
> index f30f6115277..599a5a5d34f 100644
> --- a/gcc/testsuite/g++.dg/modules/omp-1_c.C
> +++ b/gcc/testsuite/g++.dg/modules/omp-1_c.C
> @@ -1,4 +1,5 @@
>  // { dg-additional-options "-fmodules-ts" }
> +// { dg-require-effective-target pthread }
>  
>  import foo;
>  
> diff --git a/gcc/testsuite/g++.dg/modules/omp-2_a.C 
> b/gcc/testsuite/g++.dg/modules/omp-2_a.C
> index d2291b6bbe0..b0d4bbc6e8a 100644
> --- a/gcc/testsuite/g++.dg/modules/omp-2_a.C
> +++ b/gcc/testsuite/g++.dg/modules/omp-2_a.C
> @@ -1,4 +1,5 @@
>  // { dg-additional-options "-fmodules-ts -fopenmp" }
> +// { dg-require-effective-target pthread }
>  
>  export module foo;
>  // { dg-module-cmi foo }
> diff --git a/gcc/testsuite/g++.dg/modules/omp-2_b.C 
> b/gcc/testsuite/g++.dg/modules/omp-2_b.C
> index 39f34c70275..aeee4d1561a 100644
> --- a/gcc/testsuite/g++.dg/modules/omp-2_b.C
> +++ b/gcc/testsuite/g++.dg/modules/omp-2_b.C
> @@ -1,4 +1,5 @@
>  // { dg-additional-options "-fmodules-ts" }
> +// { dg-require-effective-target pthread }
>  
>  import foo;
>  
> 

Hi,

this patch causes a couple test failures.

FAIL: g++.dg/modules/omp-1_c.C -std=c++17  dg-regexp 6 not found: "In module 
imported at [^\\n]*omp-1_c.C:3:1:\\nfoo: error: module contains OpenMP, use 
'-fopenmp' to enable\\n"
FAIL: g++.dg/modules/omp-1_c.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/omp-1_c.C -std=c++2a  dg-regexp 6 not found: "In module 
imported at [^\\n]*omp-1_c.C:3:1:\\nfoo: error: module contains OpenMP, use 
'-fopenmp' to enable\\n"
FAIL: g++.dg/modules/omp-1_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/omp-1_c.C -std=c++2b  dg-regexp 6 not found: "In module 
imported at [^\\n]*omp-1_c.C:3:1:\\nfoo: error: module contains OpenMP, use 
'-fopenmp' to enable\\n"
FAIL: g++.dg/modules/omp-1_c.C -std=c++2b (test for excess errors)

That's because the line number in the pattern match changes from 3 to 4.

I've adjusted this test with the following patch
tested on x86_64-pc-linux-gnu and committed as obvious:



Regards
Bernd.
From 4f4a2f199baf46d35492edadc16f30f32920c4df Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Thu, 20 May 2021 20:19:43 +0200
Subject: [PATCH] Fix a test failure in g++.dg/modules/omp-1_c.C

Adjust the line number due to previous commit,
which added a line for dg-require-effective-target.

2021-05-20  Bernd Edlinger  

	* g++.dg/modules/omp-1_c.C: Fix testcase.
---
 gcc/testsuite/g++.dg/modules/omp-1_c.C | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/modules/omp-1_c.C b/gcc/testsuite/g++.dg/modules/omp-1_c.C
index 599a5a5..71a24f6 100644
--- a/gcc/testsuite/g++.dg/modules/omp-1_c.C
+++ b/gcc/testsuite/g++.dg/modules/omp-1_c.C
@@ -3,7 +3,7 @@
 
 import foo;
 
-// { dg-regexp "In module imported at \[^\n]*omp-1_c.C:3:1:\nfoo: error: module contains OpenMP, use '-fopenmp' to enable\n" }
+// { dg-regexp "In module imported at \[^\n]*omp-1_c.C:4:1:\nfoo: error: module contains OpenMP, use '-fopenmp' to enable\n" }
 // { dg-prune-output "failed to read" }
 // { dg-prune-output "fatal error:" }
 // { dg-prune-output "compilation terminated" }
-- 
1.9.1

Re: [PATCH] constructor: Elide expand_constructor when can move by pieces is true

[Bernd Edlinger]

On 5/20/21 4:03 PM, H.J. Lu wrote:
> On Thu, May 20, 2021 at 12:51 AM Richard Biener
>  wrote:
>>
>> On Wed, May 19, 2021 at 3:22 PM H.J. Lu  wrote:
>>>
>>> On Wed, May 19, 2021 at 2:33 AM Richard Biener
>>>  wrote:

 On Tue, May 18, 2021 at 9:16 PM H.J. Lu  wrote:
>
> When expanding a constant constructor, don't call expand_constructor if
> it is more efficient to load the data from the memory via move by pieces.
>
> gcc/
>
> PR middle-end/90773
> * expr.c (expand_expr_real_1): Don't call expand_constructor if
> it is more efficient to load the data from the memory.
>
> gcc/testsuite/
>
> PR middle-end/90773
> * gcc.target/i386/pr90773-24.c: New test.
> * gcc.target/i386/pr90773-25.c: Likewise.
> ---
>  gcc/expr.c | 10 ++
>  gcc/testsuite/gcc.target/i386/pr90773-24.c | 22 ++
>  gcc/testsuite/gcc.target/i386/pr90773-25.c | 20 
>  3 files changed, 52 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr90773-24.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr90773-25.c
>
> diff --git a/gcc/expr.c b/gcc/expr.c
> index d09ee42e262..80e01ea1cbe 100644
> --- a/gcc/expr.c
> +++ b/gcc/expr.c
> @@ -10886,6 +10886,16 @@ expand_expr_real_1 (tree exp, rtx target, 
> machine_mode tmode,
> unsigned HOST_WIDE_INT ix;
> tree field, value;
>
> +   /* Check if it is more efficient to load the data from
> +  the memory directly.  FIXME: How many stores do we
> +  need here if not moved by pieces?  */
> +   unsigned HOST_WIDE_INT bytes
> + = tree_to_uhwi (TYPE_SIZE_UNIT (type));

 that's prone to fail - it could be a VLA.
>>>
>>> What do you mean by fail?  Is it ICE or missed optimization?
>>> Do you have a testcase?
>>>

> +   if ((bytes / UNITS_PER_WORD) > 2
> +   && MOVE_MAX_PIECES > UNITS_PER_WORD
> +   && can_move_by_pieces (bytes, TYPE_ALIGN (type)))
> + goto normal_inner_ref;
> +

 It looks like you're concerned about aggregate copies but this also handles
 non-aggregates (which on GIMPLE might already be optimized of course).
>>>
>>> Here I check if we copy more than 2 words and we can move more than
>>> a word in a single instruction.
>>>
 Also you say "if it's cheaper" but I see no cost considerations.  How do
 we generally handle immed const vs. load from constant pool costs?
>>>
>>> This trades 2 (update to 8) stores with one load plus one store.  Is there
>>> a way to check which one is faster?
>>
>> I'm not sure - it depends on whether the target can do stores from immediates
>> at all or what restrictions apply, what the immediate value actually is
>> (zero or all-ones should be way cheaper than sth arbitrary) and how the
>> pressure on the load unit is.  can_move_by_pieces (bytes, TYPE_ALIGN (type))
>> also does not guarantee it will actually move pieces larger than 
>> UNITS_PER_WORD,
>> that might depend on alignment.  There's by_pieces_ninsns that might provide
>> some hint here.
>>
>> I'm sure it works well for x86.
>>
>> I wonder if the existing code is in the appropriate place and we
>> shouldn't instead
>> handle this somewhere upthread where we ask to copy 'exp' into some other
>> memory location.  For your testcase that's expand_assignment but I can
>> imagine passing array[0] by value to a function resulting in similar copying.
>> Testing that shows we get
>>
>> pushq   array+56(%rip)
>> .cfi_def_cfa_offset 24
>> pushq   array+48(%rip)
>> .cfi_def_cfa_offset 32
>> pushq   array+40(%rip)
>> .cfi_def_cfa_offset 40
>> pushq   array+32(%rip)
>> .cfi_def_cfa_offset 48
>> pushq   array+24(%rip)
>> .cfi_def_cfa_offset 56
>> pushq   array+16(%rip)
>> .cfi_def_cfa_offset 64
>> pushq   array+8(%rip)
>> .cfi_def_cfa_offset 72
>> pushq   array(%rip)
>> .cfi_def_cfa_offset 80
>> callbar
>>
>> for that.  We do have the by-pieces infrastructure to generally do this kind 
>> of
>> copying but in both of these cases we do not seem to use it.  I also wonder
>> if the by-pieces infrastructure can pick up constant initializers 
>> automagically
>> (we could native_encode the initializer part and feed the by-pieces
>> infrastructure with an array of bytes).  There for example might be easy to
>> immediate-store byte parts and difficult ones where we could decide on a
>> case-by-case basis whether to load+store or immediate-store them.
> 
> I opened:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100704
> 
>> For example if I change your testcase to have the array[] i

Re: [PATCH] Add 3 target hooks for memset

[Bernd Edlinger]

On 5/20/21 10:49 PM, H.J. Lu wrote:
> On Wed, May 19, 2021 at 5:55 AM H.J. Lu  wrote:
>>
>> On Wed, May 19, 2021 at 2:25 AM Richard Biener
>>  wrote:
>>>
>>> On Tue, May 18, 2021 at 9:16 PM H.J. Lu  wrote:

 Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
 target instructions to duplicate QImode value to TImode/OImode/XImode
 value for memmset.

 PR middle-end/90773
 * builtins.c (builtin_memset_read_str): Call
 targetm.read_memset_value.
 (builtin_memset_gen_str): Call targetm.gen_memset_value.
 * target.def (read_memset_value): New hook.
 (gen_memset_value): Likewise.
 * targhooks.c: Inclue "builtins.h".
 (default_read_memset_value): New function.
 (default_gen_memset_value): Likewise.
 * targhooks.h (default_read_memset_value): New prototype.
 (default_gen_memset_value): Likewise.
 * doc/tm.texi.in: Add TARGET_READ_MEMSET_VALUE and
 TARGET_GEN_MEMSET_VALUE hooks.
 * doc/tm.texi: Regenerated.
 ---
  gcc/builtins.c | 47 --
  gcc/doc/tm.texi| 16 +
  gcc/doc/tm.texi.in |  4 
  gcc/target.def | 20 +
  gcc/targhooks.c| 56 ++
  gcc/targhooks.h|  4 
  6 files changed, 104 insertions(+), 43 deletions(-)

 diff --git a/gcc/builtins.c b/gcc/builtins.c
 index e1b284846b1..f78a36478ef 100644
 --- a/gcc/builtins.c
 +++ b/gcc/builtins.c
 @@ -6584,24 +6584,11 @@ expand_builtin_strncpy (tree exp, rtx target)
 previous iteration.  */

  rtx
 -builtin_memset_read_str (void *data, void *prevp,
 +builtin_memset_read_str (void *data, void *prev,
  HOST_WIDE_INT offset ATTRIBUTE_UNUSED,
  scalar_int_mode mode)
  {
 -  by_pieces_prev *prev = (by_pieces_prev *) prevp;
 -  if (prev != nullptr && prev->data != nullptr)
 -{
 -  /* Use the previous data in the same mode.  */
 -  if (prev->mode == mode)
 -   return prev->data;
 -}
 -
 -  const char *c = (const char *) data;
 -  char *p = XALLOCAVEC (char, GET_MODE_SIZE (mode));
 -
 -  memset (p, *c, GET_MODE_SIZE (mode));
 -
 -  return c_readstr (p, mode);
 +  return targetm.read_memset_value ((const char *) data, prev, mode);
  }

  /* Callback routine for store_by_pieces.  Return the RTL of a register
 @@ -6611,37 +6598,11 @@ builtin_memset_read_str (void *data, void *prevp,
 nullptr, it has the RTL info from the previous iteration.  */

  static rtx
 -builtin_memset_gen_str (void *data, void *prevp,
 +builtin_memset_gen_str (void *data, void *prev,
 HOST_WIDE_INT offset ATTRIBUTE_UNUSED,
 scalar_int_mode mode)
  {
 -  rtx target, coeff;
 -  size_t size;
 -  char *p;
 -
 -  by_pieces_prev *prev = (by_pieces_prev *) prevp;
 -  if (prev != nullptr && prev->data != nullptr)
 -{
 -  /* Use the previous data in the same mode.  */
 -  if (prev->mode == mode)
 -   return prev->data;
 -
 -  target = simplify_gen_subreg (mode, prev->data, prev->mode, 0);
 -  if (target != nullptr)
 -   return target;
 -}
 -
 -  size = GET_MODE_SIZE (mode);
 -  if (size == 1)
 -return (rtx) data;
 -
 -  p = XALLOCAVEC (char, size);
 -  memset (p, 1, size);
 -  coeff = c_readstr (p, mode);
 -
 -  target = convert_to_mode (mode, (rtx) data, 1);
 -  target = expand_mult (mode, target, coeff, NULL_RTX, 1);
 -  return force_reg (mode, target);
 +  return targetm.gen_memset_value ((rtx) data, prev, mode);
  }

  /* Expand expression EXP, which is a call to the memset builtin.  Return
 diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
 index 85ea9395560..51385044e76 100644
 --- a/gcc/doc/tm.texi
 +++ b/gcc/doc/tm.texi
 @@ -11868,6 +11868,22 @@ This function prepares to emit a conditional 
 comparison within a sequence
   @var{bit_code} is @code{AND} or @code{IOR}, which is the op on the 
 compares.
  @end deftypefn

 +@deftypefn {Target Hook} rtx TARGET_READ_MEMSET_VALUE (const char 
 *@var{c}, void *@var{prev}, scalar_int_mode @var{mode})
 +This function returns the RTL of a constant integer corresponding to
 +target reading @code{GET_MODE_SIZE (@var{mode})} bytes from the stringn
 +constant @var{str}.  If @var{prev} is not @samp{nullptr}, it contains
 +the RTL information from the previous interation.
 +@end deftypefn
 +
 +@deftypefn {Target Hook} rtx TARGET_GEN_MEMSET_VALUE (rtx @var{data}, 
 void *@var{prev}, scalar_int_mode @

Re: [PATCH] constructor: Elide expand_constructor when can move by pieces is true

[Bernd Edlinger]

On 5/21/21 8:57 AM, Richard Biener wrote:
> On Thu, May 20, 2021 at 4:04 PM H.J. Lu  wrote:
>>
>> On Thu, May 20, 2021 at 12:51 AM Richard Biener
>>  wrote:
>>>
>>> On Wed, May 19, 2021 at 3:22 PM H.J. Lu  wrote:

 On Wed, May 19, 2021 at 2:33 AM Richard Biener
  wrote:
>
> On Tue, May 18, 2021 at 9:16 PM H.J. Lu  wrote:
>>
>> When expanding a constant constructor, don't call expand_constructor if
>> it is more efficient to load the data from the memory via move by pieces.
>>
>> gcc/
>>
>> PR middle-end/90773
>> * expr.c (expand_expr_real_1): Don't call expand_constructor if
>> it is more efficient to load the data from the memory.
>>
>> gcc/testsuite/
>>
>> PR middle-end/90773
>> * gcc.target/i386/pr90773-24.c: New test.
>> * gcc.target/i386/pr90773-25.c: Likewise.
>> ---
>>  gcc/expr.c | 10 ++
>>  gcc/testsuite/gcc.target/i386/pr90773-24.c | 22 ++
>>  gcc/testsuite/gcc.target/i386/pr90773-25.c | 20 
>>  3 files changed, 52 insertions(+)
>>  create mode 100644 gcc/testsuite/gcc.target/i386/pr90773-24.c
>>  create mode 100644 gcc/testsuite/gcc.target/i386/pr90773-25.c
>>
>> diff --git a/gcc/expr.c b/gcc/expr.c
>> index d09ee42e262..80e01ea1cbe 100644
>> --- a/gcc/expr.c
>> +++ b/gcc/expr.c
>> @@ -10886,6 +10886,16 @@ expand_expr_real_1 (tree exp, rtx target, 
>> machine_mode tmode,
>> unsigned HOST_WIDE_INT ix;
>> tree field, value;
>>
>> +   /* Check if it is more efficient to load the data from
>> +  the memory directly.  FIXME: How many stores do we
>> +  need here if not moved by pieces?  */
>> +   unsigned HOST_WIDE_INT bytes
>> + = tree_to_uhwi (TYPE_SIZE_UNIT (type));
>
> that's prone to fail - it could be a VLA.

 What do you mean by fail?  Is it ICE or missed optimization?
 Do you have a testcase?

>
>> +   if ((bytes / UNITS_PER_WORD) > 2
>> +   && MOVE_MAX_PIECES > UNITS_PER_WORD
>> +   && can_move_by_pieces (bytes, TYPE_ALIGN (type)))
>> + goto normal_inner_ref;
>> +
>
> It looks like you're concerned about aggregate copies but this also 
> handles
> non-aggregates (which on GIMPLE might already be optimized of course).

 Here I check if we copy more than 2 words and we can move more than
 a word in a single instruction.

> Also you say "if it's cheaper" but I see no cost considerations.  How do
> we generally handle immed const vs. load from constant pool costs?

 This trades 2 (update to 8) stores with one load plus one store.  Is there
 a way to check which one is faster?
>>>
>>> I'm not sure - it depends on whether the target can do stores from 
>>> immediates
>>> at all or what restrictions apply, what the immediate value actually is
>>> (zero or all-ones should be way cheaper than sth arbitrary) and how the
>>> pressure on the load unit is.  can_move_by_pieces (bytes, TYPE_ALIGN (type))
>>> also does not guarantee it will actually move pieces larger than 
>>> UNITS_PER_WORD,
>>> that might depend on alignment.  There's by_pieces_ninsns that might provide
>>> some hint here.
>>>
>>> I'm sure it works well for x86.
>>>
>>> I wonder if the existing code is in the appropriate place and we
>>> shouldn't instead
>>> handle this somewhere upthread where we ask to copy 'exp' into some other
>>> memory location.  For your testcase that's expand_assignment but I can
>>> imagine passing array[0] by value to a function resulting in similar 
>>> copying.
>>> Testing that shows we get
>>>
>>> pushq   array+56(%rip)
>>> .cfi_def_cfa_offset 24
>>> pushq   array+48(%rip)
>>> .cfi_def_cfa_offset 32
>>> pushq   array+40(%rip)
>>> .cfi_def_cfa_offset 40
>>> pushq   array+32(%rip)
>>> .cfi_def_cfa_offset 48
>>> pushq   array+24(%rip)
>>> .cfi_def_cfa_offset 56
>>> pushq   array+16(%rip)
>>> .cfi_def_cfa_offset 64
>>> pushq   array+8(%rip)
>>> .cfi_def_cfa_offset 72
>>> pushq   array(%rip)
>>> .cfi_def_cfa_offset 80
>>> callbar
>>>
>>> for that.  We do have the by-pieces infrastructure to generally do this 
>>> kind of
>>> copying but in both of these cases we do not seem to use it.  I also wonder
>>> if the by-pieces infrastructure can pick up constant initializers 
>>> automagically
>>> (we could native_encode the initializer part and feed the by-pieces
>>> infrastructure with an array of bytes).  There for example might be easy to
>>> immediate-store byte parts and difficult ones where we could decide on a
>>> case-by

Re: [PATCHv2] Add a couple of A?CST1:CST2 match and simplify optimizations

[Bernd Edlinger]

On 5/25/21 4:22 PM, Richard Biener via Gcc-patches wrote:
> On Sun, May 23, 2021 at 12:03 PM apinski--- via Gcc-patches
>  wrote:
>>
>> From: Andrew Pinski 
>>
>> Instead of some of the more manual optimizations inside phi-opt,
>> it would be good idea to do a lot of the heavy lifting inside match
>> and simplify instead. In the process, this moves the three simple
>> A?CST1:CST2 (where CST1 or CST2 is zero) simplifications.
>>
>> OK? Boostrapped and tested on x86_64-linux-gnu with no regressions.
>>
>> Differences from V1:
>> * Use bit_xor 1 instead of bit_not to fix the problem with boolean types
>> which are not 1 bit precision.
> 
> OK.
> 
> Thanks,
> Richard.
> 

Hmm, sorry, no luck.

I think this caused:

home/ed/gnu/gcc-build/./gcc/xgcc -B/home/ed/gnu/gcc-build/./gcc/ 
-B/home/ed/gnu/install/x86_64-pc-linux-gnu/bin/ 
-B/home/ed/gnu/install/x86_64-pc-linux-gnu/lib/ -isystem 
/home/ed/gnu/install/x86_64-pc-linux-gnu/include -isystem 
/home/ed/gnu/install/x86_64-pc-linux-gnu/sys-include   -fchecking=1 -c -g -O2 
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition -Wmissing-format-attribute -Wno-overlength-strings 
-pedantic -Wno-long-long   -DHAVE_CONFIG_H -I. -I../../gcc-trunk/fixincludes 
-I../include -I../../gcc-trunk/fixincludes/../include 
../../gcc-trunk/fixincludes/fixtests.c
during GIMPLE pass: evrp
../../gcc-trunk/fixincludes/fixtests.c: In function ‘run_test’:
../../gcc-trunk/fixincludes/fixtests.c:155:1: internal compiler error: in 
operator[], at vec.h:890
  155 | }
  | ^
0x824622 vec::operator[](unsigned int)
../../gcc-trunk/gcc/vec.h:890
0x8247f0 vec::operator[](unsigned int)
../../gcc-trunk/gcc/tree.h:3366
0x8247f0 vec::operator[](unsigned int)
../../gcc-trunk/gcc/vec.h:1461
0x8247f0 range_def_chain::register_dependency(tree_node*, tree_node*, 
basic_block_def*)
../../gcc-trunk/gcc/gimple-range-gori.cc:179
0x18639bc fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
../../gcc-trunk/gcc/gimple-range.cc:439
0x1866c85 fold_using_range::fold_stmt(irange&, gimple*, fur_source&, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:376
0x1866fa2 gimple_ranger::fold_range_internal(irange&, gimple*, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:1067
0x1866fa2 gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:1097
0x186308a gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
../../gcc-trunk/gcc/gimple-range.cc:980
0x18637c7 fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
../../gcc-trunk/gcc/gimple-range.cc:431
0x1866c85 fold_using_range::fold_stmt(irange&, gimple*, fur_source&, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:376
0x1866fa2 gimple_ranger::fold_range_internal(irange&, gimple*, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:1067
0x1866fa2 gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:1097
0x186308a gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
../../gcc-trunk/gcc/gimple-range.cc:980
0x1149961 range_query::value_of_expr(tree_node*, gimple*)
../../gcc-trunk/gcc/value-query.cc:86
0x1871e51 hybrid_folder::value_of_expr(tree_node*, gimple*)
../../gcc-trunk/gcc/gimple-ssa-evrp.c:235
0xff9573 substitute_and_fold_engine::replace_uses_in(gimple*)
../../gcc-trunk/gcc/tree-ssa-propagate.c:575
0xff988c substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-propagate.c:845
0x183921f dom_walker::walk(basic_block_def*)
../../gcc-trunk/gcc/domwalk.c:309
0xff8d15 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-propagate.c:987
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [Makefile:76: fixtests.o] Error 1
make[2]: Leaving directory '/home/ed/gnu/gcc-build/fixincludes'
make[1]: *** [Makefile:3827: all-fixincludes] Error 2
make[1]: Leaving directory '/home/ed/gnu/gcc-build'
make: *** [Makefile:1011: all] Error 2


Bernd.


>> Thanks,
>> Andrew Pinski
>>
>> gcc:
>> * match.pd (A?CST1:CST2): Add simplifcations for A?0:+-1, A?+-1:0,
>> A?POW2:0 and A?0:POW2.
>> ---
>>  gcc/match.pd | 41 +
>>  1 file changed, 41 insertions(+)
>>
>> diff --git a/gcc/match.pd b/gcc/match.pd
>> index 1fc6b7b1557..ad6b057c56d 100644
>> --- a/gcc/match.pd
>> +++ b/gcc/match.pd
>> @@ -3711,6 +3711,47 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>> (if (integer_all_onesp (@1) && integer_zerop (@2))
>>  @0
>>
>> +/* A few simplifications of "a ? CST1 : CST2". */
>> +/* NOTE: Only do this on gimple as the if-chain-to-switch
>> +   optimization depends on the gimple to have if statements in it.

Re: [PATCHv2] Add a couple of A?CST1:CST2 match and simplify optimizations

[Bernd Edlinger]

On 5/26/21 2:05 PM, Richard Biener wrote:
> On Wed, May 26, 2021 at 1:37 PM Andrew Pinski  wrote:
>>
>> On Wed, May 26, 2021 at 4:28 AM Richard Biener
>>  wrote:
>>>
>>> On Wed, May 26, 2021 at 1:07 PM Andrew Pinski  wrote:
>>>>
>>>> On Wed, May 26, 2021 at 2:01 AM Andrew Pinski  wrote:
>>>>>
>>>>> On Wed, May 26, 2021 at 1:43 AM Bernd Edlinger
>>>>>  wrote:
>>>>>>
>>>>>> On 5/25/21 4:22 PM, Richard Biener via Gcc-patches wrote:
>>>>>>> On Sun, May 23, 2021 at 12:03 PM apinski--- via Gcc-patches
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> From: Andrew Pinski 
>>>>>>>>
>>>>>>>> Instead of some of the more manual optimizations inside phi-opt,
>>>>>>>> it would be good idea to do a lot of the heavy lifting inside match
>>>>>>>> and simplify instead. In the process, this moves the three simple
>>>>>>>> A?CST1:CST2 (where CST1 or CST2 is zero) simplifications.
>>>>>>>>
>>>>>>>> OK? Boostrapped and tested on x86_64-linux-gnu with no regressions.
>>>>>>>>
>>>>>>>> Differences from V1:
>>>>>>>> * Use bit_xor 1 instead of bit_not to fix the problem with boolean 
>>>>>>>> types
>>>>>>>> which are not 1 bit precision.
>>>>>>>
>>>>>>> OK.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Richard.
>>>>>>>
>>>>>>
>>>>>> Hmm, sorry, no luck.
>>>>>>
>>>>>> I think this caused:
>>>>>
>>>>> If anything it is a bad interaction with changes between r12-1046 and
>>>>> r12-1053; I am suspecting a bug in those changes rather than my
>>>>> changes causing the bug.  Debugging it right now.
>>>>
>>>> (gdb) p debug_tree(name)
>>>>  >>> type >>> size 
>>>> unit-size 
>>>> align:8 warn_if_not_align:0 symtab:0 alias-set -1
>>>> canonical-type 0x7ffff6b45b28 precision:1 min >>> 0x76b4a030 0> max >
>>>>
>>>> def_stmt _19 = ~_8;
>>>> version:19>
>>>>
>>>> So what is happening is evrp converted:
>>>> ct_12 = ct_5 + -1;
>>>> Into
>>>> ct_12 = ct_5 == 1 ? 0 : 1;
>>>> (this was done before my patch)
>>>
>>> Note this COND_EXPR is supposed to be combined
>>> with its single use in a GIMPLE_COND ...
>>
>> I Noticed it was not doing it (before my patch) inside evrp either.
> 
> I think it is at most done in forwprop, but even then it likely
> lacks a fold pattern - we only seem to forward comparisons
> into GIMPLE_CONDs explicitely, leaving the rest to
> match.pd patterns.
> 

How about this for a quick fix:

commit b71621f51bc2819bb7d202efabc17fec5cc92f8f
Author: Bernd Edlinger 
Date:   Wed May 26 18:45:09 2021 +0200

Fix gcc-bootstrap issue

... or at least try to.

2021-05-26  Bernd Edlinger  

* gimple-range-gori.cc (range_def_chain::register_dependency):
Resize m_def_chain when needed.

diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index a4c4bf5..722bf5d 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -177,6 +177,8 @@ range_def_chain::register_dependency (tree name, tree dep, 
basic_block bb)
 
   unsigned v = SSA_NAME_VERSION (name);
   struct rdc &src = m_def_chain[v];
+  if (v >= m_def_chain.length ())
+m_def_chain.safe_grow_cleared (num_ssa_names + 1);
   gimple *def_stmt = SSA_NAME_DEF_STMT (dep);
   unsigned dep_v = SSA_NAME_VERSION (dep);
   bitmap b;


Should I push this?
Or has anyone a better idea?


Thanks
Bernd.

>>>
>>>> And then it gets simplified to:
>>>>   _8 = ct_5 == 1;
>>>>   _19 = ~_8;
>>>>   ct_12 = (int) _19;
>>>> (after my match.pd patch)
>>>
>>> which this one then breaks.  I suppose instead of replacing
>>> ct_12  adjusting the GIMPLE_COND directly might be
>>> a better approach ... or not folding the generated COND_EXPR.
>>
>> I was going to try to see where COND_EXPR is created but it is late
>> and there seems to be other issues going on too.
>> For example, the above really should have been converted to:
>> _19 = ct_5 != 1;
>>   ct_12

Re: [PATCHv2] Add a couple of A?CST1:CST2 match and simplify optimizations

[Bernd Edlinger]

On 5/26/21 7:03 PM, Bernd Edlinger wrote:
> On 5/26/21 2:05 PM, Richard Biener wrote:
>> On Wed, May 26, 2021 at 1:37 PM Andrew Pinski  wrote:
>>>
>>> On Wed, May 26, 2021 at 4:28 AM Richard Biener
>>>  wrote:
>>>>
>>>> On Wed, May 26, 2021 at 1:07 PM Andrew Pinski  wrote:
>>>>>
>>>>> On Wed, May 26, 2021 at 2:01 AM Andrew Pinski  wrote:
>>>>>>
>>>>>> On Wed, May 26, 2021 at 1:43 AM Bernd Edlinger
>>>>>>  wrote:
>>>>>>>
>>>>>>> On 5/25/21 4:22 PM, Richard Biener via Gcc-patches wrote:
>>>>>>>> On Sun, May 23, 2021 at 12:03 PM apinski--- via Gcc-patches
>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>> From: Andrew Pinski 
>>>>>>>>>
>>>>>>>>> Instead of some of the more manual optimizations inside phi-opt,
>>>>>>>>> it would be good idea to do a lot of the heavy lifting inside match
>>>>>>>>> and simplify instead. In the process, this moves the three simple
>>>>>>>>> A?CST1:CST2 (where CST1 or CST2 is zero) simplifications.
>>>>>>>>>
>>>>>>>>> OK? Boostrapped and tested on x86_64-linux-gnu with no regressions.
>>>>>>>>>
>>>>>>>>> Differences from V1:
>>>>>>>>> * Use bit_xor 1 instead of bit_not to fix the problem with boolean 
>>>>>>>>> types
>>>>>>>>> which are not 1 bit precision.
>>>>>>>>
>>>>>>>> OK.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Richard.
>>>>>>>>
>>>>>>>
>>>>>>> Hmm, sorry, no luck.
>>>>>>>
>>>>>>> I think this caused:
>>>>>>
>>>>>> If anything it is a bad interaction with changes between r12-1046 and
>>>>>> r12-1053; I am suspecting a bug in those changes rather than my
>>>>>> changes causing the bug.  Debugging it right now.
>>>>>
>>>>> (gdb) p debug_tree(name)
>>>>>  >>>> type >>>> size 
>>>>> unit-size 
>>>>>     align:8 warn_if_not_align:0 symtab:0 alias-set -1
>>>>> canonical-type 0x76b45b28 precision:1 min >>>> 0x76b4a030 0> max >
>>>>>
>>>>> def_stmt _19 = ~_8;
>>>>> version:19>
>>>>>
>>>>> So what is happening is evrp converted:
>>>>> ct_12 = ct_5 + -1;
>>>>> Into
>>>>> ct_12 = ct_5 == 1 ? 0 : 1;
>>>>> (this was done before my patch)
>>>>
>>>> Note this COND_EXPR is supposed to be combined
>>>> with its single use in a GIMPLE_COND ...
>>>
>>> I Noticed it was not doing it (before my patch) inside evrp either.
>>
>> I think it is at most done in forwprop, but even then it likely
>> lacks a fold pattern - we only seem to forward comparisons
>> into GIMPLE_CONDs explicitely, leaving the rest to
>> match.pd patterns.
>>
> 
> How about this for a quick fix:
> 
> commit b71621f51bc2819bb7d202efabc17fec5cc92f8f
> Author: Bernd Edlinger 
> Date:   Wed May 26 18:45:09 2021 +0200
> 
> Fix gcc-bootstrap issue
> 
> ... or at least try to.
> 
> 2021-05-26  Bernd Edlinger  
> 
> * gimple-range-gori.cc (range_def_chain::register_dependency):
> Resize m_def_chain when needed.
> 
> diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
> index a4c4bf5..722bf5d 100644
> --- a/gcc/gimple-range-gori.cc
> +++ b/gcc/gimple-range-gori.cc
> @@ -177,6 +177,8 @@ range_def_chain::register_dependency (tree name, tree 
> dep, basic_block bb)
>  
>unsigned v = SSA_NAME_VERSION (name);
>struct rdc &src = m_def_chain[v];
> +  if (v >= m_def_chain.length ())
> +m_def_chain.safe_grow_cleared (num_ssa_names + 1);>gimple *def_stmt 
> = SSA_NAME_DEF_STMT (dep);
>unsigned dep_v = SSA_NAME_VERSION (dep);
>bitmap b;
> 
> 
> Should I push this?
> Or has anyone a better idea?
> 

Aehm, I meant of course:

--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -176,6 +176,8 @@ range_def_chain::register_dependency (tree name, tree dep, b
 return;
 
   unsign

Re: [committed] libstdc++: Fix std::jthread assertion and re-enable skipped test

[Bernd Edlinger]

On 5/19/21 3:37 PM, Bernd Edlinger wrote:
> On 5/19/21 3:27 PM, Jonathan Wakely wrote:
>> On 18/05/21 13:58 +0200, Bernd Edlinger wrote:
>>> On 5/18/21 1:55 PM, Bernd Edlinger wrote:
>>>> On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
>>>>> libstdc++-v3/ChangeLog:
>>>>>
>>>>> * include/std/thread (jthread::_S_create): Fix static assert
>>>>> message.
>>>>> * testsuite/30_threads/jthread/95989.cc: Re-enable test.
>>>>> * testsuite/30_threads/jthread/jthread.cc: Do not require
>>>>> pthread effective target.
>>>>> * testsuite/30_threads/jthread/2.cc: Moved to...
>>>>> * testsuite/30_threads/jthread/version.cc: ...here.
>>>>>
>>>>> Tested powerpc64le-linux. Committed to trunk.
>>>>>
>>>>> Let's see if this test is actually fixed, or if it still causes
>>>>> failures on some targets.
>>>>>
>>>>>
>>>>
>>>> Yes, indeed it is failing on x86_64-pc-linux-gnu.
>>>>
>>>
>>> that means only this one:
>>>
>>> FAIL: 30_threads/jthread/95989.cc execution test
>>
>> What's your glibc version?
>>
>>
> 
> that is ubuntu 20.04 with latest patches:
> 
> $ ldd --version
> ldd (Ubuntu GLIBC 2.31-0ubuntu9.3) 2.31
> Copyright (C) 2020 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> Written by Roland McGrath and Ulrich Drepper.
> 

The glibc version is probably not the reason,
I've got the same effect with Ubuntu EGLIBC 2.19-0ubuntu6.15 as well.

But I use binutils-2.36.1.

I think the problem is here:

libstdc++-v3/src/c++11/thread.cc:  __e = __gthread_join(_M_id._M_thread, 0);

which calls

libgcc/gthr-posix.h:  return __gthrw_(pthread_join) (__threadid, __value_ptr);

but this is only a weak reference to pthread_join:

669   return __gthrw_(pthread_join) (__threadid, __value_ptr);
(gdb) disass
Dump of assembler code for function std::thread::join():
   0x00405e20 <+0>: endbr64 
   0x00405e24 <+4>: push   %rbx
   0x00405e25 <+5>: mov%rdi,%rbx
   0x00405e28 <+8>: mov(%rdi),%rdi
   0x00405e2b <+11>:test   %rdi,%rdi
   0x00405e2e <+14>:je 0x405e44 
=> 0x00405e30 <+16>:xor%esi,%esi
   0x00405e32 <+18>:callq  0x0
   0x00405e37 <+23>:test   %eax,%eax
   0x00405e39 <+25>:jne0x405e49 
   0x00405e3b <+27>:movq   $0x0,(%rbx)
   0x00405e42 <+34>:pop%rbx
   0x00405e43 <+35>:retq   
   0x00405e44 <+36>:mov$0x16,%eax
   0x00405e49 <+41>:mov%eax,%edi
   0x00405e4b <+43>:callq  0x4012a9 
End of assembler dump.

but the pthread_join symbol is not checked for potentially being null.

The test case passes if I change this:

diff --git a/libstdc++-v3/testsuite/30_threads/jthread/95989.cc 
b/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
index fb3f43bc722..61a3ff76aa1 100644
--- a/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
+++ b/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
@@ -52,4 +52,5 @@ main()
   test01();
   test02();
   test03();
+  pthread_join(NULL, NULL);
 }


Thanks
Bernd.

[PATCH] Generate gimple-match.c and generic-match.c earlier

[Bernd Edlinger]

Hi,

I was wondering, why gimple-match.c and generic-match.c
are not built early but always last, which slows down parallel
makes significantly.

The reason seems to be that generated_files does not
mention gimple-match.c and generic-match.c.

This comment in Makefile.in says it all:

$(ALL_HOST_OBJS) : | $(generated_files)

So this patch adds gimple-match.c generic-match.c to generated_files.


Tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.


2021-05-28  Bernd Edlinger  

* Makefile.in (generated_files): Add gimple-match.c and
generic-match.c
From 5c14c3f5852ddcc1d3b76e7c53260b0187604cd7 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Fri, 28 May 2021 06:27:27 +0200
Subject: [PATCH] Generate gimple-match.c and generic-match.c earlier

I was wondering, why gimple-match.c and generic-match.c
are not built early but always last, which slows down parallel
makes significantly.

The reason seems to be that generated_files does not
mention gimple-match.c and generic-match.c.

This comment in Makefile.in says it all:

$(ALL_HOST_OBJS) : | $(generated_files)

So this patch adds gimple-match.c generic-match.c to generated_files.

2021-05-28  Bernd Edlinger  

	* Makefile.in (generated_files): Add gimple-match.c and
	generic-match.c
---
 gcc/Makefile.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index da2ef24..4cb2966 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2753,6 +2753,7 @@ generated_files = config.h tm.h $(TM_P_H) $(TM_D_H) $(TM_H) multilib.h \
$(ALL_GTFILES_H) gtype-desc.c gtype-desc.h version.h \
options.h target-hooks-def.h insn-opinit.h \
common/common-target-hooks-def.h pass-instances.def \
+   gimple-match.c generic-match.c \
c-family/c-target-hooks-def.h d/d-target-hooks-def.h \
case-cfn-macros.h \
cfn-operators.pd omp-device-properties.h
-- 
1.9.1

Re: [PATCH] Generate gimple-match.c and generic-match.c earlier

[Bernd Edlinger]

On 5/28/21 6:42 AM, Bernd Edlinger wrote:
> Hi,
> 
> I was wondering, why gimple-match.c and generic-match.c
> are not built early but always last, which slows down parallel
> makes significantly.
> 
> The reason seems to be that generated_files does not
> mention gimple-match.c and generic-match.c.
> 
> This comment in Makefile.in says it all:
> 

Oh, dear, git commit did eliminate the comments
starting with "#"
the mentined comment is

# Dependency information.

# In order for parallel make to really start compiling the expensive
# objects from $(OBJS) as early as possible, build all their
# prerequisites strictly before all objects.

> $(ALL_HOST_OBJS) : | $(generated_files)
> 
> So this patch adds gimple-match.c generic-match.c to generated_files.
> 
> 
> Tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 
> 
> 2021-05-28  Bernd Edlinger  
> 
>   * Makefile.in (generated_files): Add gimple-match.c and
>   generic-match.c
> 
From 99eab77ebfaa02ee22263d89eb3ca812cf65263b Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Fri, 28 May 2021 06:27:27 +0200
Subject: [PATCH] Generate gimple-match.c and generic-match.c earlier

I was wondering, why gimple-match.c and generic-match.c
are not built early but always last, which slows down parallel
makes significantly.

The reason seems to be that generated_files does not
mention gimple-match.c and generic-match.c.

This comment in Makefile.in says it all:

"In order for parallel make to really start compiling the expensive
objects from $(OBJS) as early as possible, build all their
prerequisites strictly before all objects."

So this patch adds gimple-match.c generic-match.c to generated_files.

2021-05-28  Bernd Edlinger  

	* Makefile.in (generated_files): Add gimple-match.c and
	generic-match.c
---
 gcc/Makefile.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index da2ef24..4cb2966 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2753,6 +2753,7 @@ generated_files = config.h tm.h $(TM_P_H) $(TM_D_H) $(TM_H) multilib.h \
$(ALL_GTFILES_H) gtype-desc.c gtype-desc.h version.h \
options.h target-hooks-def.h insn-opinit.h \
common/common-target-hooks-def.h pass-instances.def \
+   gimple-match.c generic-match.c \
c-family/c-target-hooks-def.h d/d-target-hooks-def.h \
case-cfn-macros.h \
cfn-operators.pd omp-device-properties.h
-- 
1.9.1

Re: [PATCH] Generate gimple-match.c and generic-match.c earlier

[Bernd Edlinger]

On 5/28/21 8:41 AM, Richard Biener wrote:
> On Fri, 28 May 2021, Bernd Edlinger wrote:
> 
>>
>>
>> On 5/28/21 6:42 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> I was wondering, why gimple-match.c and generic-match.c
>>> are not built early but always last, which slows down parallel
>>> makes significantly.
>>>
>>> The reason seems to be that generated_files does not
>>> mention gimple-match.c and generic-match.c.
>>>
>>> This comment in Makefile.in says it all:
>>>
>>
>> Oh, dear, git commit did eliminate the comments
>> starting with "#"
>> the mentined comment is
>>
>> # Dependency information.
>>
>> # In order for parallel make to really start compiling the expensive
>> # objects from $(OBJS) as early as possible, build all their
>> # prerequisites strictly before all objects.
>>
>>> $(ALL_HOST_OBJS) : | $(generated_files)
>>>
>>> So this patch adds gimple-match.c generic-match.c to generated_files.
>>>
>>>
>>> Tested on x86_64-pc-linux-gnu.
>>> Is it OK for trunk?
> 
> OK.  Does it really help though?
> 

Yes, I guess so, at least a little bit.

Prior to this patch the whole build stage was completed for everything
then those two big files got generated,
and then there are only two large files compiled in parallel for
several minutes at least.

So a make -j8 utilizes only 25 % cpu power
and make -j16 only 12.5 % utilization.
That can certainly be a bit annoying.


Bernd.


> Thanks,
> Richard.
> 
>>>
>>>
>>> Thanks
>>> Bernd.
>>>
>>>
>>> 2021-05-28  Bernd Edlinger  
>>>
>>> * Makefile.in (generated_files): Add gimple-match.c and
>>> generic-match.c
>>>
>>
> 

Re: [PATCH] Generate gimple-match.c and generic-match.c earlier

[Bernd Edlinger]

On 5/28/21 9:26 AM, Andrew Pinski wrote:
> On Thu, May 27, 2021 at 10:10 PM Bernd Edlinger
>  wrote:
>>
>> Hi,
>>
>> I was wondering, why gimple-match.c and generic-match.c
>> are not built early but always last, which slows down parallel
>> makes significantly.
>>
>> The reason seems to be that generated_files does not
>> mention gimple-match.c and generic-match.c.
>>
>> This comment in Makefile.in says it all:
>>
>> $(ALL_HOST_OBJS) : | $(generated_files)
>>
>> So this patch adds gimple-match.c generic-match.c to generated_files.
>>
>>
>> Tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
> 
> This should help for what I was complaining about in
> https://gcc.gnu.org/pipermail/gcc/2021-May/235963.html . I build with
> -j24 and it was stalling on compiling gimple-match.c for me.
> Looks like insn-attrtab.c is missed too; I saw genattrtab was running last 
> too.
> 

Yeah, probably insn-automata.c as well, sometimes it is picked up early 
sometimes not.
maybe $(simple_generated_c) should be added to generated_files,
but insn-attrtab.c is yet another exception.


Bernd.

> Thanks,
> Andrew
> 
>>
>>
>> Thanks
>> Bernd.
>>
>>
>> 2021-05-28  Bernd Edlinger  
>>
>> * Makefile.in (generated_files): Add gimple-match.c and
>> generic-match.c

[PATCH] For obj-c stage-final re-use the checksum from the previous stage

[Bernd Edlinger]

Hi Richard,

I've replicated your PR to make the objective-c checksum compare equal

commit fb2647aaf55b453b37badfd40c14c59486a74584
Author: Richard Biener 
Date:   Tue May 3 08:14:27 2016 +

Make-lang.in (cc1-checksum.c): For stage-final re-use the checksum from the 
previous stage.

2016-05-03  Richard Biener  

c/
* Make-lang.in (cc1-checksum.c): For stage-final re-use
the checksum from the previous stage.

cp/
* Make-lang.in (cc1plus-checksum.c): For stage-final re-use
the checksum from the previous stage.

From-SVN: r235804


This silences the stage compare.

Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.


2021-05-28  Bernd Edlinger  

objc/
* Make-lang.in (cc1obj-checksum.c): For stage-final re-use
the checksum from the previous stage.

objcp/
* Make-lang.in (cc1objplus-checksum.c): For stage-final re-use
the checksum from the previous stage.
From a61184fc909634dba1dca8956ab960998114c644 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Fri, 28 May 2021 06:54:13 +0200
Subject: [PATCH] For obj-c stage-final re-use the checksum from the previous
 stage

This silences the stage compare.

2021-05-28  Bernd Edlinger  

	objc/
	* Make-lang.in (cc1obj-checksum.c): For stage-final re-use
	the checksum from the previous stage.

	objcp/
	* Make-lang.in (cc1objplus-checksum.c): For stage-final re-use
	the checksum from the previous stage.
---
 gcc/objc/Make-lang.in  | 14 +++---
 gcc/objcp/Make-lang.in | 15 +++
 2 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/gcc/objc/Make-lang.in b/gcc/objc/Make-lang.in
index c91148a..9011140 100644
--- a/gcc/objc/Make-lang.in
+++ b/gcc/objc/Make-lang.in
@@ -57,11 +57,19 @@ OBJC_OBJS = objc/objc-lang.o objc/objc-act.o hash-table.o \
 
 objc_OBJS = $(OBJC_OBJS) cc1obj-checksum.o
 
+# compute checksum over all object files and the options
+# re-use the checksum from the prev-final stage so it passes
+# the bootstrap comparison and allows comparing of the cc1 binary
 cc1obj-checksum.c : build/genchecksum$(build_exeext) checksum-options \
 $(OBJC_OBJS) $(C_AND_OBJC_OBJS) $(BACKEND) $(LIBDEPS)
-	build/genchecksum$(build_exeext) $(OBJC_OBJS) $(C_AND_OBJC_OBJS) \
-$(BACKEND) $(LIBDEPS) checksum-options > cc1obj-checksum.c.tmp && \
-	$(srcdir)/../move-if-change cc1obj-checksum.c.tmp cc1obj-checksum.c
+	if [ -f ../stage_final ] \
+	   && cmp -s ../stage_current ../stage_final; then \
+	  cp ../prev-gcc/$@ $@; \
+	else \
+	  build/genchecksum$(build_exeext) $(OBJC_OBJS) $(C_AND_OBJC_OBJS) \
+		$(BACKEND) $(LIBDEPS) checksum-options > $@.tmp && \
+	  $(srcdir)/../move-if-change $@.tmp $@; \
+	fi
 
 cc1obj$(exeext): $(OBJC_OBJS) $(C_AND_OBJC_OBJS) cc1obj-checksum.o $(BACKEND) \
 		 $(LIBDEPS) $(objc.prev)
diff --git a/gcc/objcp/Make-lang.in b/gcc/objcp/Make-lang.in
index dfa4d23..3ecc50b 100644
--- a/gcc/objcp/Make-lang.in
+++ b/gcc/objcp/Make-lang.in
@@ -60,12 +60,19 @@ OBJCXX_OBJS = objcp/objcp-act.o objcp/objcp-lang.o objcp/objcp-decl.o \
 
 obj-c++_OBJS = $(OBJCXX_OBJS) cc1objplus-checksum.o
 
+# compute checksum over all object files and the options
+# re-use the checksum from the prev-final stage so it passes
+# the bootstrap comparison and allows comparing of the cc1 binary
 cc1objplus-checksum.c : build/genchecksum$(build_exeext) checksum-options \
 	$(OBJCXX_OBJS) $(BACKEND) $(CODYLIB) $(LIBDEPS)
-	build/genchecksum$(build_exeext) $(OBJCXX_OBJS) $(BACKEND) $(CODYLIB) \
-		$(LIBDEPS) checksum-options > cc1objplus-checksum.c.tmp && \
-	$(srcdir)/../move-if-change cc1objplus-checksum.c.tmp \
-	cc1objplus-checksum.c
+	if [ -f ../stage_final ] \
+	   && cmp -s ../stage_current ../stage_final; then \
+	  cp ../prev-gcc/$@ $@; \
+	else \
+	  build/genchecksum$(build_exeext) $(OBJCXX_OBJS) $(BACKEND) \
+		$(CODYLIB) $(LIBDEPS) checksum-options > $@.tmp && \
+	  $(srcdir)/../move-if-change $@.tmp $@; \
+	fi
 
 cc1objplus$(exeext): $(OBJCXX_OBJS) cc1objplus-checksum.o $(BACKEND) \
 		 $(CODYLIB) $(LIBDEPS) $(obj-c++.prev)
-- 
1.9.1

[PATCH] diagnostics: Fix sporadic test failure

[Bernd Edlinger]

Hi,

it turns out to be reproducible this way:

COLUMNS=80 make check-gcc-c RUNTESTFLAGS="plugin.exp=diagnostic*"

Running /home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
 -fplugin=./diagnostic_plugin_test_tree_expression_range.so  1 blank line(s) in 
output
FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
 -fplugin=./diagnostic_plugin_test_tree_expression_range.so  expected multiline 
pattern lines 550-551 not found: "
__builtin_types_compatible_p \(long, int\) \+ f \(i\)\);.*\n
~\^~~\n"
FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
 -fplugin=./diagnostic_plugin_test_tree_expression_range.so (test for excess 
errors)

a lot more errors happen with COLUMNS=20.

Tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.


2021-05-28  Bernd Edlinger  

* gcc.dg/plugin/diagnostic_plugin_show_trees.c (plugin_init): Fix 
caret_max_with.
* gcc.dg/plugin/diagnostic_plugin_test_inlining.c
(plugin_init): Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_paths.c (plugin_init): Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_string_literals.c
(plugin_init): Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.c
(plugin_init): Likewise.
From 50420cb535560ec1388d34c2d3d2a3f0d339a132 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Fri, 28 May 2021 14:26:02 +0200
Subject: [PATCH] diagnostics: Fix sporadic test failure

it turns out to be reproducible this way:

COLUMNS=80 make check-gcc-c RUNTESTFLAGS="plugin.exp=diagnostic*"

Running /home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
 -fplugin=./diagnostic_plugin_test_tree_expression_range.so  1 blank line(s) in output
FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
 -fplugin=./diagnostic_plugin_test_tree_expression_range.so  expected multiline pattern lines 550-551 not found: "__builtin_types_compatible_p \(long, int\) \+ f \(i\)\);.*\n~\^~~\n"
FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
 -fplugin=./diagnostic_plugin_test_tree_expression_range.so (test for excess errors)

a lot more errors happen with COLUMNS=20.

2021-05-28  Bernd Edlinger  

	* gcc.dg/plugin/diagnostic_plugin_show_trees.c (plugin_init): Fix caret_max_with.
	* gcc.dg/plugin/diagnostic_plugin_test_inlining.c
	(plugin_init): Likewise.
	* gcc.dg/plugin/diagnostic_plugin_test_paths.c (plugin_init): Likewise.
	* gcc.dg/plugin/diagnostic_plugin_test_string_literals.c
	(plugin_init): Likewise.
	* gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.c
	(plugin_init): Likewise.
---
 gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_show_trees.c  | 2 ++
 gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_inlining.c   | 2 ++
 gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_paths.c  | 2 ++
 gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_string_literals.c| 2 ++
 .../gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.c| 2 ++
 5 files changed, 10 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_show_trees.c b/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_show_trees.c
index 71e6740..ac72503 100644
--- a/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_show_trees.c
+++ b/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_show_trees.c
@@ -115,6 +115,8 @@ plugin_init (struct plugin_name_args *plugin_info,
   if (!plugin_default_version_check (version, &gcc_version))
 return 1;
 
+  global_dc->caret_max_width = 80;
+
   register_callback (plugin_name,
 		 PLUGIN_PRE_GENERICIZE,
 		 callback,
diff --git a/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_inlining.c b/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_inlining.c
index 49b78cc..02c4629 100644
--- a/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_inlining.c
+++ b/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_inlining.c
@@ -169,6 +169,8 @@ plugin_init (struct plugin_name_args *plugin_info,
   if (!plugin_default_version_check (version, &gcc_version))
 return 1;
 
+  global_dc->caret_max_width = 80;
+
   pass_info.pass = new pass_test_inlining (g);
   pass_info.reference_pass_name = "*warn_function_noreturn";
   pass_info.ref_pass_instance_number = 1;
diff --git a/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_paths.c b/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_paths.c
index 7672875..5c2da02 100644
--- a/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_paths.c
+++ b/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_paths.c
@@ -450,6 +450,8 @@ plugin_init (struct plugin_name_args *plugin_info,
   if (!plugin_default_vers

Re: [PATCH] diagnostics: Fix sporadic test failure

[Bernd Edlinger]

On 5/29/21 9:31 PM, Jeff Law wrote:
> 
> 
> On 5/28/2021 6:38 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> it turns out to be reproducible this way:
>>
>> COLUMNS=80 make check-gcc-c RUNTESTFLAGS="plugin.exp=diagnostic*"
>>
>> Running /home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
>> FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
>>   -fplugin=./diagnostic_plugin_test_tree_expression_range.so  1 blank 
>> line(s) in output
>> FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
>>   -fplugin=./diagnostic_plugin_test_tree_expression_range.so  expected 
>> multiline pattern lines 550-551 not found: "    
>> __builtin_types_compatible_p \(long, int\) \+ f \(i\)\);.*\n 
>>    ~\^~~\n"
>> FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
>>   -fplugin=./diagnostic_plugin_test_tree_expression_range.so (test for 
>> excess errors)
>>
>> a lot more errors happen with COLUMNS=20.
>>
>> Tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
>>
>>
>> Thanks
>> Bernd.
>>
>>
>> 2021-05-28  Bernd Edlinger  
>>
>> * gcc.dg/plugin/diagnostic_plugin_show_trees.c (plugin_init): Fix 
>> caret_max_with.
>> * gcc.dg/plugin/diagnostic_plugin_test_inlining.c
>> (plugin_init): Likewise.
>> * gcc.dg/plugin/diagnostic_plugin_test_paths.c (plugin_init): Likewise.
>> * gcc.dg/plugin/diagnostic_plugin_test_string_literals.c
>> (plugin_init): Likewise.
>> * gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.c
>> (plugin_init): Likewise.
> So while you've got a patch here, you haven't indicated what the problem 
> actually was.  I'm guessing caret_max_width was uninitialized and thus we got 
> random-ish values.  Presumably those randomish-values are what caused tests 
> to occasionally appear to truncate their output and fail?
> 
> If that's the case, this is fine.  If it's something deeper, please provide a 
> bit of background to help in evaluating the patch.
> 

Yes, the problem is just the function get_terminal_width in diagnostic.c, can
somehow learn the X-terminal's window dimensions where the make check is
started:

int
get_terminal_width (void)
{
  const char * s = getenv ("COLUMNS");
  if (s != NULL) {
int n = atoi (s);
if (n > 0)
  return n;
  }

#ifdef TIOCGWINSZ
  struct winsize w;
  w.ws_col = 0;
  if (ioctl (0, TIOCGWINSZ, &w) == 0 && w.ws_col > 0)
return w.ws_col;
#endif

  return INT_MAX;
}

and this is used to initialize context->caret_max_width in 
diagnostic_set_caret_max_width,
and possibly also other places. This causes a small variation in the output that
is trips the test cases.  It is just an extra newline in some cases, that I 
have not
debugged why exactly this happens, but I assume this is intentional to make the
diagnostics spanning multiple lines better readable to a human.


Thanks,
Bernd.

> Thanks,
> jeff
> 

[PING] [PATCH] For obj-c stage-final re-use the checksum from the previous stage

[Bernd Edlinger]

Ping...

On 5/28/21 9:47 AM, Bernd Edlinger wrote:
> Hi Richard,
> 
> I've replicated your PR to make the objective-c checksum compare equal
> 
> commit fb2647aaf55b453b37badfd40c14c59486a74584
> Author: Richard Biener 
> Date:   Tue May 3 08:14:27 2016 +
> 
> Make-lang.in (cc1-checksum.c): For stage-final re-use the checksum from 
> the previous stage.
> 
> 2016-05-03  Richard Biener  
> 
>   c/
>   * Make-lang.in (cc1-checksum.c): For stage-final re-use
>   the checksum from the previous stage.
> 
>   cp/
>   * Make-lang.in (cc1plus-checksum.c): For stage-final re-use
>   the checksum from the previous stage.
> 
> From-SVN: r235804
> 
> 
> This silences the stage compare.
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 
> 
> 2021-05-28  Bernd Edlinger  
> 
>   objc/
>   * Make-lang.in (cc1obj-checksum.c): For stage-final re-use
>   the checksum from the previous stage.
> 
>   objcp/
>   * Make-lang.in (cc1objplus-checksum.c): For stage-final re-use
>   the checksum from the previous stage.
> 

Re: [PATCH] For obj-c stage-final re-use the checksum from the previous stage

[Bernd Edlinger]

On 6/8/21 3:54 PM, Jason Merrill wrote:
> 
> This breaks bootstrap2.
> 
> Jason
> 


Sorry for the breakage,

I've committed the following as obvious after
confirming that it fixes bootstrap2:

Subject: [PATCH] Fix bootstrap2 breakage due to re-use of obj-c checksum

gcc/objc:
2021-06-08  Bernd Edlinger  

* Make-lang.in (cc1-obj-checksum.c): Check previous
stage checksum exists.

gcc/objcp:
2021-06-08  Bernd Edlinger  

* Make-lang.in (cc1objplus-checksum.c): Check previous
stage checksum exists.
---
 gcc/objc/Make-lang.in  | 3 ++-
 gcc/objcp/Make-lang.in | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/objc/Make-lang.in b/gcc/objc/Make-lang.in
index 9011140..25fbd4c 100644
--- a/gcc/objc/Make-lang.in
+++ b/gcc/objc/Make-lang.in
@@ -63,7 +63,8 @@ objc_OBJS = $(OBJC_OBJS) cc1obj-checksum.o
 cc1obj-checksum.c : build/genchecksum$(build_exeext) checksum-options \
 $(OBJC_OBJS) $(C_AND_OBJC_OBJS) $(BACKEND) $(LIBDEPS)
if [ -f ../stage_final ] \
-  && cmp -s ../stage_current ../stage_final; then \
+  && cmp -s ../stage_current ../stage_final \
+  && [ -f ../prev-gcc/$@ ]; then \
  cp ../prev-gcc/$@ $@; \
else \
  build/genchecksum$(build_exeext) $(OBJC_OBJS) $(C_AND_OBJC_OBJS) \
diff --git a/gcc/objcp/Make-lang.in b/gcc/objcp/Make-lang.in
index 3ecc50b..2e27be5 100644
--- a/gcc/objcp/Make-lang.in
+++ b/gcc/objcp/Make-lang.in
@@ -66,7 +66,8 @@ obj-c++_OBJS = $(OBJCXX_OBJS) cc1objplus-checksum.o
 cc1objplus-checksum.c : build/genchecksum$(build_exeext) checksum-options \
$(OBJCXX_OBJS) $(BACKEND) $(CODYLIB) $(LIBDEPS)
if [ -f ../stage_final ] \
-  && cmp -s ../stage_current ../stage_final; then \
+  && cmp -s ../stage_current ../stage_final \
+  && [ -f ../prev-gcc/$@ ]; then \
  cp ../prev-gcc/$@ $@; \
else \
  build/genchecksum$(build_exeext) $(OBJCXX_OBJS) $(BACKEND) \
-- 
1.9.1


Thanks
Bernd.

Re: [PATCH] Generate gimple-match.c and generic-match.c earlier

[Bernd Edlinger]

On 7/14/21 2:47 PM, Tamar Christina wrote:
> Hi,
> 
> Ever since this commit 
> 
> commit c9114f2804b91690e030383de15a24e0b738e856
> Author: Bernd Edlinger 
> Date:   Fri May 28 06:27:27 2021 +0200
> 
> Various tools have been having trouble with cross compilation resulting in
> 
> make[2]: *** No rule to make target 
> '../build-x86_64-build_pc-linux-gnu/libcpp/libcpp.a', needed by 
> 'build/genmatch'.
> 
> (took a while to track down).  I don't understand this part of the build 
> system well enough to know how to fix this.
> It looks like `libcpp.a` has special handling for cross compilers which now 
> seems to be broken.
> 
> I can't reproduce it with our normal cross compiler scripts. Which handles 
> the stages on its own, but e.g.
> https://github.com/crosstool-ng/crosstool-ng does reproduce the failure.
> 

Sorry for the breakage!

I do not know this tool at all, but this here looks suspicious,
as it it by-passes the dependencies in the top-level Makefile:

https://github.com/crosstool-ng/crosstool-ng/blob/755850d07ec4e8dc44787d1a0e35fe19507f17f6/scripts/build/cc/gcc.sh#L682-L683
CT_DoExecLog CFG make ${CT_JOBSFLAGS} configure-gcc 
configure-libcpp configure-build-libiberty
CT_DoExecLog ALL make ${CT_JOBSFLAGS} all-libcpp all-build-libiberty
...
https://github.com/crosstool-ng/crosstool-ng/blob/755850d07ec4e8dc44787d1a0e35fe19507f17f6/scripts/build/cc/gcc.sh#L711-L712
CT_DoExecLog ALL make ${CT_JOBSFLAGS} -C gcc ${libgcc_rule} \
  ${repair_cc}


but the top-level Makefile has also a dependency to all-build-libcpp:

dependencies = { module=all-gcc; on=all-build-libcpp; };
dependencies = { module=all-gcc; on=all-libcpp; hard=true; };

Maybe this just worked by chance, when building with "make -j" started a 
parallel build,
might build the build-libcpp dependency eventually, but due to the patch it is
needed earlier?


Bernd.



> Any ideas what's going on?
> 
> Kind Regards,
> Tamar
> 
>> -----Original Message-
>> From: Gcc-patches  On Behalf Of
>> Michael Matz
>> Sent: Friday, May 28, 2021 4:33 PM
>> To: Bernd Edlinger 
>> Cc: gcc-patches@gcc.gnu.org; Richard Biener 
>> Subject: Re: [PATCH] Generate gimple-match.c and generic-match.c earlier
>>
>> Hello,
>>
>> On Fri, 28 May 2021, Bernd Edlinger wrote:
>>
>>>>> I was wondering, why gimple-match.c and generic-match.c are not
>>>>> built early but always last, which slows down parallel makes
>>>>> significantly.
>>>>>
>>>>> The reason seems to be that generated_files does not mention
>>>>> gimple-match.c and generic-match.c.
>>>>>
>>>>> This comment in Makefile.in says it all:
>>>>>
>>>>> $(ALL_HOST_OBJS) : | $(generated_files)
>>>>>
>>>>> So this patch adds gimple-match.c generic-match.c to generated_files.
>>>>>
>>>>>
>>>>> Tested on x86_64-pc-linux-gnu.
>>>>> Is it OK for trunk?
>>>>
>>>> This should help for what I was complaining about in
>>>> https://gcc.gnu.org/pipermail/gcc/2021-May/235963.html . I build
>>>> with
>>>> -j24 and it was stalling on compiling gimple-match.c for me.
>>>> Looks like insn-attrtab.c is missed too; I saw genattrtab was running last
>> too.
>>>>
>>>
>>> Yeah, probably insn-automata.c as well, sometimes it is picked up
>>> early sometimes not. maybe $(simple_generated_c) should be added to
>>> generated_files, but insn-attrtab.c is yet another exception.
>>
>> You can't put files in there that are sometimes slow to generate (which insn-
>> {attrtab,automata}.c are on some targets), as _everything_ then waits for
>> them to be created first.
>>
>> Ideally there would be a way for gnumake to mark some targets as "ugh-
>> slow" and back-propagate this to all dependencies so that those are put in
>> front of the work queue in a parallel make.  Alas, something like that never
>> came into existence :-/  (When order-only deps were introduced I got
>> excited, but then came to realize that that wasn't what was really needed for
>> this case, a "weak" version of it would be required at least, or better yet a
>> specific facility to impose a cost with a target)
>>
>>
>> Ciao,
>> Michael.
>>
>>>
>>>
>>> Bernd.
>>>
>>>> Thanks,
>>>> Andrew
>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> Bernd.
>>>>>
>>>>>
>>>>> 2021-05-28  Bernd Edlinger  
>>>>>
>>>>> * Makefile.in (generated_files): Add gimple-match.c and
>>>>> generic-match.c
>>>

[PATCH 0/2] Fix bogus line info in DECL_IGNORED_P functions

[Bernd Edlinger]

This fixes a regression which was introduced accidentally with
commit e69ac020372 ("Add line debug info for virtual thunks").

That is certain Ada functions have now a .loc directive which is
probably not how the debug experience of those functions was intended.

Currently those functions stop in the debugger when stepped into, and
show the source location where the data type was declared.  It was
pointed out in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575#c7
that the previous behaviour is what Ada really wants here.

The prevoious debug experience can be achieved by setting
DECL_SOURCE_LOCATION of such functions in the Ada front end
to UNKNOWN_LOCATION.  This is done by (2/2).

However it turns out that the test case which is from the
gdb-test suite has a special feature that the ignored function
is compiled before the first normal function, and that triggers
a misbehaviour of the dwarf-4 assembler.  That shows a corner
case where the current handling of ignored functions with
no line info at all fails to suppress the bogus line numbers.
That is fixed by (1/2), by emiting a dummy .file directive
when there was no preceeding .file directive.


This was boot-strapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?

Thanks,

Bernd Edlinger (2):
  Fix debug info for ignored decls at start of assembly
  Ada: Remove debug line number for DECL_IGNORED_P functions

 gcc/ada/gcc-interface/trans.c |  4 +++-
 gcc/dwarf2out.c   | 29 +
 gcc/final.c   |  5 ++---
 3 files changed, 30 insertions(+), 8 deletions(-)

-- 
1.9.1

[PATCH 1/2] Fix debug info for ignored decls at start of assembly

[Bernd Edlinger]

Ignored functions decls that are compiled at the start of
the assembly have bogus line numbers until the first .file
directive, as reported in PR101575.

The work around for this issue is to emit a dummy .file
directive when the first function is DECL_IGNORED_P, when
that is not already done, mostly for -fdwarf-4.

2021-07-24  Bernd Edlinger  

PR ada/101575
* dwarf2out.c (dwarf2out_begin_prologue): Move init
of fde->ignored_debug to dwarf2out_set_ignored_loc.
(dwarf2out_set_ignored_loc): This is now also called
when no .loc statement is to be generated, in that case
we emit a dummy .file statement when needed.
* final.c (final_start_function_1,
final_scan_insn_1): Call debug_hooks->set_ignored_loc
for all DECL_IGNORED_P functions.
---
 gcc/dwarf2out.c | 29 +
 gcc/final.c |  5 ++---
 2 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 884f1e1..8de0d6f 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -1115,7 +1115,6 @@ dwarf2out_begin_prologue (unsigned int line 
ATTRIBUTE_UNUSED,
   fde->dw_fde_current_label = dup_label;
   fde->in_std_section = (fnsec == text_section
 || (cold_text_section && fnsec == cold_text_section));
-  fde->ignored_debug = DECL_IGNORED_P (current_function_decl);
   in_text_section_p = fnsec == text_section;
 
   /* We only want to output line number information for the genuine dwarf2
@@ -28546,10 +28545,32 @@ dwarf2out_set_ignored_loc (unsigned int line, 
unsigned int column,
 {
   dw_fde_ref fde = cfun->fde;
 
-  fde->ignored_debug = false;
-  set_cur_line_info_table (function_section (fde->decl));
+  if (filename)
+{
+  set_cur_line_info_table (function_section (fde->decl));
+
+  dwarf2out_source_line (line, column, filename, 0, true);
+}
+  else
+{
+  fde->ignored_debug = true;
+
+  /* Work around for PR101575: output a dummy .file directive.  */
+  if (in_first_function_p
+ && debug_info_level >= DINFO_LEVEL_TERSE
+ && dwarf_debuginfo_p ()
+#if defined(HAVE_AS_GDWARF_5_DEBUG_FLAG) && 
defined(HAVE_AS_WORKING_DWARF_N_FLAG)
+ && dwarf_version <= 4
+#endif
+ && output_asm_line_debug_info ())
+   {
+ const char *filename0 = get_AT_string (comp_unit_die (), DW_AT_name);
 
-  dwarf2out_source_line (line, column, filename, 0, true);
+ if (filename0 == NULL)
+   filename0 = "";
+ maybe_emit_file (lookup_filename (filename0));
+   }
+}
 }
 
 /* Record the beginning of a new source file.  */
diff --git a/gcc/final.c b/gcc/final.c
index ac6892d..82a5767 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -1725,7 +1725,7 @@ final_start_function_1 (rtx_insn **firstp, FILE *file, 
int *seen,
   if (!dwarf2_debug_info_emitted_p (current_function_decl))
 dwarf2out_begin_prologue (0, 0, NULL);
 
-  if (DECL_IGNORED_P (current_function_decl) && last_linenum && last_filename)
+  if (DECL_IGNORED_P (current_function_decl))
 debug_hooks->set_ignored_loc (last_linenum, last_columnnum, last_filename);
 
 #ifdef LEAF_REG_REMAP
@@ -2205,8 +2205,7 @@ final_scan_insn_1 (rtx_insn *insn, FILE *file, int 
optimize_p ATTRIBUTE_UNUSED,
}
  else if (!DECL_IGNORED_P (current_function_decl))
debug_hooks->switch_text_section ();
- if (DECL_IGNORED_P (current_function_decl) && last_linenum
- && last_filename)
+ if (DECL_IGNORED_P (current_function_decl))
debug_hooks->set_ignored_loc (last_linenum, last_columnnum,
  last_filename);
 
-- 
1.9.1

[PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions

[Bernd Edlinger]

It was pointed out in PR101598 to be inappropriate, that
ignored Ada decls receive the source line number which was
recorded in the function decl's DECL_SOURCE_LOCATION.
Therefore set all front-end-generated Ada decls with
DECL_IGNORED_P to UNKNOWN_LOCATION.

2021-07-24  Bernd Edlinger  

PR debug/101598
* gcc-interface/trans.c (Subprogram_Body_to_gnu): Set the
DECL_SOURCE_LOCATION of DECL_IGNORED_P gnu_subprog_decl to
UNKNOWN_LOCATION.
---
 gcc/ada/gcc-interface/trans.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/ada/gcc-interface/trans.c b/gcc/ada/gcc-interface/trans.c
index f61183d..3df56aa 100644
--- a/gcc/ada/gcc-interface/trans.c
+++ b/gcc/ada/gcc-interface/trans.c
@@ -3885,7 +3885,9 @@ Subprogram_Body_to_gnu (Node_Id gnat_node)
 }
 
   /* Set the line number in the decl to correspond to that of the body.  */
-  if (!Sloc_to_locus (Sloc (gnat_node), &locus, false, gnu_subprog_decl))
+  if (DECL_IGNORED_P (gnu_subprog_decl))
+locus = UNKNOWN_LOCATION;
+  else if (!Sloc_to_locus (Sloc (gnat_node), &locus, false, gnu_subprog_decl))
 locus = input_location;
   DECL_SOURCE_LOCATION (gnu_subprog_decl) = locus;
 
-- 
1.9.1

Re: [PATCH 1/2] Fix debug info for ignored decls at start of assembly

[Bernd Edlinger]

On 7/28/21 2:51 PM, Richard Biener wrote:
> On Mon, 26 Jul 2021, Bernd Edlinger wrote:
> 
>> Ignored functions decls that are compiled at the start of
>> the assembly have bogus line numbers until the first .file
>> directive, as reported in PR101575.
>>
>> The work around for this issue is to emit a dummy .file
>> directive when the first function is DECL_IGNORED_P, when
>> that is not already done, mostly for -fdwarf-4.
> 
> I wonder if it makes sense to unconditionally announce the
> TU with a .file directive at the beginning.  ISTR this is
> what we now do with -gdwarf-5.
> 

Yes, that would work, even when the file name is not guessed
correctly.

Initially I had "" unconditionally here, and it did
not really hurt, except that it is visible with readelf.

> Note get_AT_string (comp_unit_die (), DW_AT_name) doesn't
> work with LTO, you'll get  then.
> 

Yeah, that's why I wanted to restrict that to the case where
it's absolutely necessary.

> Is the dwarf assembler bug reported/fixed?  Can you include
> a reference please?
> 

I've just added a bug report, it's unlikely to be fixed IMHO:
https://sourceware.org/bugzilla/show_bug.cgi?id=28149

I will add that to the patch description:

Ignored functions decls that are compiled at the start of
the assembly have bogus line numbers until the first .file
directive, as reported in PR101575.

The corresponding binutils bug report is
https://sourceware.org/bugzilla/show_bug.cgi?id=28149

The work around for this issue is to emit a dummy .file
directive when the first function is DECL_IGNORED_P, when
that is not already done, mostly for -fdwarf-4.


Thanks
Bernd.

> Thanks,
> Richard.
> 
>> 2021-07-24  Bernd Edlinger  
>>
>>  PR ada/101575
>>  * dwarf2out.c (dwarf2out_begin_prologue): Move init
>>  of fde->ignored_debug to dwarf2out_set_ignored_loc.
>>  (dwarf2out_set_ignored_loc): This is now also called
>>  when no .loc statement is to be generated, in that case
>>  we emit a dummy .file statement when needed.
>>  * final.c (final_start_function_1,
>>  final_scan_insn_1): Call debug_hooks->set_ignored_loc
>>  for all DECL_IGNORED_P functions.
>> ---
>>  gcc/dwarf2out.c | 29 +
>>  gcc/final.c |  5 ++---
>>  2 files changed, 27 insertions(+), 7 deletions(-)
>>
>> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
>> index 884f1e1..8de0d6f 100644
>> --- a/gcc/dwarf2out.c
>> +++ b/gcc/dwarf2out.c
>> @@ -1115,7 +1115,6 @@ dwarf2out_begin_prologue (unsigned int line 
>> ATTRIBUTE_UNUSED,
>>fde->dw_fde_current_label = dup_label;
>>fde->in_std_section = (fnsec == text_section
>>   || (cold_text_section && fnsec == cold_text_section));
>> -  fde->ignored_debug = DECL_IGNORED_P (current_function_decl);
>>in_text_section_p = fnsec == text_section;
>>  
>>/* We only want to output line number information for the genuine dwarf2
>> @@ -28546,10 +28545,32 @@ dwarf2out_set_ignored_loc (unsigned int line, 
>> unsigned int column,
>>  {
>>dw_fde_ref fde = cfun->fde;
>>  
>> -  fde->ignored_debug = false;
>> -  set_cur_line_info_table (function_section (fde->decl));
>> +  if (filename)
>> +{
>> +  set_cur_line_info_table (function_section (fde->decl));
>> +
>> +  dwarf2out_source_line (line, column, filename, 0, true);
>> +}
>> +  else
>> +{
>> +  fde->ignored_debug = true;
>> +
>> +  /* Work around for PR101575: output a dummy .file directive.  */
>> +  if (in_first_function_p
>> +  && debug_info_level >= DINFO_LEVEL_TERSE
>> +  && dwarf_debuginfo_p ()
>> +#if defined(HAVE_AS_GDWARF_5_DEBUG_FLAG) && 
>> defined(HAVE_AS_WORKING_DWARF_N_FLAG)
>> +  && dwarf_version <= 4
>> +#endif
>> +  && output_asm_line_debug_info ())
>> +{
>> +  const char *filename0 = get_AT_string (comp_unit_die (), DW_AT_name);
>>  
>> -  dwarf2out_source_line (line, column, filename, 0, true);
>> +  if (filename0 == NULL)
>> +filename0 = "";
>> +  maybe_emit_file (lookup_filename (filename0));
>> +}
>> +}
>>  }
>>  
>>  /* Record the beginning of a new source file.  */
>> diff --git a/gcc/final.c b/gcc/final.c
>> index ac6892d..82a5767 100644
>> --- a/gcc/final.c
>> +++ b/gcc/final.c
>> @@ -1725,7 +1725,7 @@ final_start_function_1 (rtx_insn **firstp, FILE *file, 
>> int