Re: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode switch

[Bernd Edlinger]

On 4/11/24 05:03, Li, Pan2 wrote:
> Committed, thanks Juzhe and Kito.
> 
> Pan


Hi Pan,

this commit caused a regression:

FAIL: gcc.c-torture/compile/930623-1.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -O1  (internal compiler error: in 
emit_vec_extract, at config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -O2  (internal compiler error: in 
emit_vec_extract, at config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -O3 -g  (internal compiler error: in 
emit_vec_extract, at config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -Os  (internal compiler error: in 
emit_vec_extract, at config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (internal compiler error: in emit_vec_extract, at 
config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (test for excess errors)

gcc/testsuite/gcc.c-torture/compile/930623-1.c:10:3: internal compiler error: 
in emit_vec_extract, at config/riscv/riscv-v.cc:5059^M
0xbba2de riscv_vector::emit_vec_extract(rtx_def*, rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/config/riscv/riscv-v.cc:5059^M
0x186945f riscv_legitimize_move(machine_mode, rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/config/riscv/riscv.cc:2895^M
0x1ef50b2 gen_movsi(rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/config/riscv/riscv.md:2225^M
0xffc91c rtx_insn* insn_gen_fn::operator()(rtx_def*, 
rtx_def*) const^M
../../gcc-trunk/gcc/recog.h:441^M
0xffc91c emit_move_insn_1(rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/expr.cc:4551^M
0xffcdf4 emit_move_insn(rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/expr.cc:4721^M
0x1002f17 emit_move_multi_word^M
../../gcc-trunk/gcc/expr.cc:4517^M
0xffcdf4 emit_move_insn(rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/expr.cc:4721^M
0x1efc6b7 gen_untyped_call(rtx_def*, rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/config/riscv/riscv.md:3478^M
0x185fc7c target_gen_untyped_call^M
../../gcc-trunk/gcc/config/riscv/riscv.md:3453^M
0xe8e81f expand_builtin_apply^M
../../gcc-trunk/gcc/builtins.cc:1761^M
0xea053c expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)^M
../../gcc-trunk/gcc/builtins.cc:8001^M
0xff9e27 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)^M
../../gcc-trunk/gcc/expr.cc:12353^M
0xec4c3d expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)^M
../../gcc-trunk/gcc/expr.h:316^M
0xec4c3d expand_call_stmt^M
../../gcc-trunk/gcc/cfgexpand.cc:2865^M
0xec4c3d expand_gimple_stmt_1^M
../../gcc-trunk/gcc/cfgexpand.cc:3932^M
0xec4c3d expand_gimple_stmt^M
../../gcc-trunk/gcc/cfgexpand.cc:4077^M
0xeca206 expand_gimple_basic_block^M
../../gcc-trunk/gcc/cfgexpand.cc:6133^M
0xecc287 execute^M
../../gcc-trunk/gcc/cfgexpand.cc:6872^M
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M
compiler exited with status 1

I've built the git revision f3fdcf4a37a with 
../gcc-trunk/configure --target=riscv-unknown-elf 
--prefix=/home/ed/gnu/riscv-unknown-elf --enable-languages=c,c++ 
--disable-multilib --with-arch=rv32imac --with-abi=ilp32

I am a bit surprised since the target is not supposed to support floating point
or vector instructions AFAIK.

The issue does not happen with gcc-trunk from yesterday.

Regards
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 

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/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/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 1/2] Fix debug info for ignored decls at start of assembly

[Bernd Edlinger]

On 7/29/21 9:23 AM, Richard Biener wrote:
> On Wed, 28 Jul 2021, Bernd Edlinger wrote:
> 
>> 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.
> 
> I think I'd prefer that, since if we don't announce a .file
> before the first assembler statement but ask gas to produce
> line info it might be tempted to create line info referencing
> the possibly temporary filename of the assembler file which
> is undesirable from a build reproducability point.
> 

Yeah, I understand.

Meanwhile I found a simple C test case without ignored functions

$ cat test1.c
asm("nop");
int main () 
{
  return 0;
}

$ gcc -g test1.c
$ readelf --debug-dump=decodedline a.out 
Contents of the .debug_line section:

CU: ./test1.c:
File nameLine numberStarting addressView
Stmt
test1.c50x401106
   x
test1.c30x401107
   x
test1.c40x40110b
   x
test1.c50x401110
   x
test1.c-0x401112

even with the proposed patch, so I agree it is incomplete.

I tried the gdb test case and compile it with different LTO
options, but the gen_AT_string was always valid, in some
cases a lto debug section together with a couple .file 
directives was output before the .file 0.
So I'd like to use the file name from gen_AT_string, since
it's most of the time accurate, and avoids unnecessary confusion
on the readers of the produced debug info.

So I'd propose the attached patch instead.
Is it OK for trunk?


> Richard.
> 
>>> 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
>>&

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 *seen,
>>if (!dwarf2

[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), , false, gnu_subprog_decl))
+  if (DECL_IGNORED_P (gnu_subprog_decl))
+locus = UNKNOWN_LOCATION;
+  else if (!Sloc_to_locus (Sloc (gnat_node), , false, gnu_subprog_decl))
 locus = input_location;
   DECL_SOURCE_LOCATION (gnu_subprog_decl) = locus;
 
-- 
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 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

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
>>>

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.

[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] 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, ) == 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
> 

[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, _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, _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_version_check (version, _versi

[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

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

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 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

[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: [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.

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  = 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: [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  = 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 = (int)

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 

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
>>> 

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/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[] 

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: [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: [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\]+, 
>>> 

Re: [PATCH] Run pass_sink_code once more before store_mergin

[Bernd Edlinger]

On 5/18/21 12:34 PM, Richard Biener wrote:
> On Tue, 18 May 2021, Xionghu Luo wrote:
> 
>> Hi,
>>
>> On 2021/5/18 15:02, Richard Biener wrote:
>>> Can you, for the new gcc.dg/tree-ssa/ssa-sink-18.c testcase, add
>>> a comment explaining what operations we expect to sink?  The testcase
>>> is likely somewhat fragile in the exact number of sinkings
>>> (can you check on some other target and maybe P8BE with -m32 for
>>> example?), so for future adjustments it would be nice to easiliy
>>> figure out what we expect to happen.
>>>
>>> OK with that change.
>>
>> Thanks a lot for the reminder! ssa-sink-18.c generates different code
>> for m32 and m64 exactly due to different type size conversion and ivopts
>> selection, since -m32 and -m64 couldn't co-exist in one test file, shall
>> I restrict it to -m64 only or check target lp64/target ilp32?
>> I've verified this case shows same behavior on X86, AArch64 and Power for
>> both m32 and m64.
>>
>> -m32:
>>[local count: 75120046]:
>>   # len_155 = PHI 
>>   len_182 = len_155 + 1;
>>   _35 = (unsigned int) ip_249;
>>   _36 = _35 + len_182;
>>   _380 = (uint8_t *) _36;
>>   if (maxlen_179 > len_182)
>> goto ; [94.50%]
>>   else
>> goto ; [5.50%]
>> ...
>>
>> Sinking _329 = (uint8_t *) _36;
>>  from bb 29 to bb 86
>> Sinking _36 = _35 + len_182;
>>  from bb 29 to bb 86
>> Sinking _35 = (unsigned int) ip_249;
>>  from bb 29 to bb 86
>>
>> Pass statistics of "sink": 
>> Sunk statements: 3
>>
>>
>> -m64:
>>[local count: 75120046]:
>>   # ivtmp.23_34 = PHI 
>>   _38 = (unsigned int) ivtmp.23_34;
>>   len_161 = _38 + 4294967295;
>>   _434 = (unsigned long) ip_254;
>>   _433 = ivtmp.23_34 + _434;
>>   _438 = (uint8_t *) _433;
>>   if (_38 < maxlen_187)
>> goto ; [94.50%]
>>   else
>> goto ; [5.50%]
>> ...
>>
>> Sinking _367 = (uint8_t *) _320;
>>  from bb 31 to bb 90
>> Sinking _320 = _321 + ivtmp.25_326;
>>  from bb 31 to bb 90
>> Sinking _321 = (unsigned long) ip_229;
>>  from bb 31 to bb 90
>> Sinking len_158 = _322 + 4294967295;
>>  from bb 31 to bb 33
>>
>> Pass statistics of "sink": 
>> Sunk statements: 4
>>
>>
>> Regarding to the comments part:
>>
>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c 
>> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c
>> index 52b9a74b65f..5147f7b85cd 100644
>> --- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c
>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c
>> @@ -193,16 +193,17 @@ compute_on_bytes (uint8_t *in_data, int in_len, 
>> uint8_t *out_data, int out_len)
>>return op - out_data;
>>   }
>> + /* For this case, pass sink2 sinks statements from hot loop header to loop
>> +exits after gimple loop optimizations, which generates instructions 
>> executed
>> +each iteration in loop, but the results are used outside of loop:
>> +With -m64,
>> +"Sinking _367 = (uint8_t *) _320;
>> + from bb 31 to bb 90
>> + Sinking _320 = _321 + ivtmp.25_326;
>> + from bb 31 to bb 90
>> + Sinking _321 = (unsigned long) ip_229;
>> + from bb 31 to bb 90
>> + Sinking len_158 = _322 + 4294967295;
>> +from bb 31 to bb 33"  */
>>
>> - /* { dg-final { scan-tree-dump-times "Sunk statements: 4" 1 "sink2" } } */
>> + /* { dg-final { scan-tree-dump-times "Sunk statements: 4" 1 "sink2" { 
>> target lp64 } } } */
>> + /* { dg-final { scan-tree-dump-times "Sunk statements: 3" 1 "sink2" { 
>> target ilp32 } } } */
> 
> Yes, that looks good.
> 
> Thanks,
> Richard.
> 

Hi,

I've noticed the test case gcc.dg/tree-ssa/ssa-sink-3.c was accidentally
committed as empty file, and therefore fails:

FAIL: gcc.dg/tree-ssa/ssa-sink-3.c (test for excess errors)

I've commited as obvious the following fix (which restores the test case and
Xionghu Luo's intended change.


Thanks
Bernd.
From 51cfa55431c38f3c29c7b7287ad8a2da5c06 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Wed, 19 May 2021 09:51:44 +0200
Subject: [PATCH] Fix commit mistake in testcase gcc.dg/tree-ssa/ssa-sink-3.c

the test case was accidenally changed to empty file.

2021-05-19  Bernd Edlinger  

	* gcc.dg/tree-ssa/ssa-sink-3.c: Fix test case.
---
 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-3.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-3.c b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-3.c
index e69de29..ad88ccc 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-3.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-3.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */ 
+/* { dg-options "-O2 -fdump-tree-sink-stats" } */
+extern void foo(int a);
+int
+main (int argc)
+{
+  int a;
+  a = argc + 1;
+  if (argc + 3)
+{
+  foo (a);
+}
+}
+/* We should sink the a = argc + 1 calculation into the if branch  */
+/* { dg-final { scan-tree-dump-times "Sunk statements: 1" 1 "sink1" } } */
-- 
1.9.1

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

[Bernd Edlinger]

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

> 
> Bernd.
> 

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

[Bernd Edlinger]

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.


Bernd.

Re: [PATCH V2] Split loop for NE condition.

[Bernd Edlinger]

On 5/18/21 1:00 PM, Segher Boessenkool wrote:> On Tue, May 18, 2021 at 
08:36:34AM +0200, Bernd Edlinger wrote:
>> On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
>>> Bootstrap and regtest pass on ppc64le.  Is this ok for trunk?
> 
>> I've tried this patch and it does not seem to pass its own test:
>>
>> FAIL: gcc.dg/loop-split1.c scan-tree-dump-times lsplit "Loop split" 9
> 
> On what target?  :-P
> 
>> Note you should always do a bootstrap and regression test as described
>> here: https://gcc.gnu.org/contribute.html#testing
>>
>> Also please state in your future patch submissions how you tested the patch,
>> like "bootstrap and regression test on x86_64-pc-linux-gnu" for instance.
> 
> Jiu Fu did all that.  If you understand that ppc64le means
> powerpc64-linux of course.
> 

Yeah indeed, I overlooked that, sorry for the noise.

> It is interesting one loop fails on x86.  But that is why we have
> stage1 :-)
> 

Sure, after looking more closely it seems like 90% of the test works
already.


Bernd.


> 
> Segher
> 

Re: [PATCH v3 00/12] Allow TImode/OImode/XImode in op_by_pieces operations

[Bernd Edlinger]

On 5/17/21 3:15 PM, H.J. Lu via Gcc-patches wrote:
> Changes in the v3 patches:
> 
> 1. Split the TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE changes
> into the generic part and the x86 part.
> 
> 
> 1. 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.
> 2. x86: Avoid stack realignment when copying data
> 3. x86: Remov MAX_BITSIZE_MODE_ANY_INT.  Only x86 backend defines it.
> 4. x86: Use TImode/OImode/XImode integers for piecewise move and store.
> 5. x86: Add tests for TImode/OImode/XImode for piecewise move and store.
> 6. x86: Adjust existing tests.
> 
> On x86-64, SPEC CPU 2017 performance impact is neutral.  Glibc code size
> differences with -O2 build are:
> 
>  Before After
> libc.so 19065721906444
> 
> Some code sequence differences in libc.so are:
> 
> :
>   ...
>   jne   | jne
> 
>   test   %r15,%r15test   
> %r15,%r15
>   je| je 
> 
>   mov%r13d,(%r14) mov
> %r13d,(%r14)
>   lea0x10(%r14),%rdi  lea
> 0x10(%r14),%rdi
>   mov$0x1,%ecxmov
> $0x1,%ecx
>   mov%r13d,%edx   mov
> %r13d,%edx
>   mov%r15,0x40(%r12)  mov
> %r15,0x40(%r12)
>   mov%r15,%rsimov
> %r15,%rsi
>   call call   
> 
>   lea0xa2f9b(%rip),%rax# | lea
> 0xa2fab(%rip),%rax# 
>   xor%esi,%esixor
> %esi,%esi
>   mov%ebp,%edimov
> %ebp,%edi
>   mov%rax,0x8(%r12)   mov
> %rax,0x8(%r12)
>   movzwl 0x12(%rsp),%eax  movzwl 
> 0x12(%rsp),%eax
>   mov$0x8,%edx  <
>   lea0xc(%rsp),%rcx   lea
> 0xc(%rsp),%rcx
>   mov%r14,0x48(%r12)<
>   add$0x40,%r14 <
>   mov$0x4,%r8dmov
> $0x4,%r8d
> > movq   
> $0x0,0x1d0(%r14)
> > mov
> $0x8,%edx
>   rol$0x8,%ax rol
> $0x8,%ax
>   mov%ebp,(%r12)| mov
> %r14,0x48(%r12)
>   movq   $0x0,0x190(%r14)   | add
> $0x40,%r14
>   mov%ax,0x4(%r12)  <
>   mov%r14,0x30(%r12)  mov
> %r14,0x30(%r12)
> > mov
> %ax,0x4(%r12)
> > mov
> %ebp,(%r12)
>   movl   $0x1,0xc(%rsp)   movl   
> $0x1,0xc(%rsp)
>   callcall   
> 
>   mov%r12,%rdimov
> %r12,%rdi
>   movabs $0x101010101010101,%rdx<
>   test   %eax,%eaxtest   
> %eax,%eax
>   mov$0xff,%eax   mov
> $0xff,%eax
>   cmove  %eax,%ebxcmove  
> %eax,%ebx
>   movzbl %bl,%eax   | movd   
> %ebx,%xmm0
>   mov%ebx,0xc(%rsp)   mov
> %ebx,0xc(%rsp)
>   mov%rax,%rsi  | 
> punpcklbw %xmm0,%xmm0
>   imul   %rdx,%rsi  | 
> punpcklwd %xmm0,%xmm0
>   mul%rdx   | pshufd 
> $0x0,%xmm0,%xmm0
>   add%rsi,%rdx  | movups 
> %xmm0,0x50(%r12)
>   mov%rax,0x50(%r12)| movups 
> %xmm0,0x60(%r12)
>   mov%rdx,0x58(%r12)| movups 
> %xmm0,0x70(%r12)
>   mov%rax,0x60(%r12)| movups 
> %xmm0,0x80(%r12)
>   mov%rdx,0x68(%r12)| movups 
> 

Re: [PATCH V2] Split loop for NE condition.

[Bernd Edlinger]

On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
> When there is the possibility that overflow/wrap may happen on the loop index,
> a few optimizations would not happen. For example code:
> 
> foo (int *a, int *b, unsigned k, unsigned n)
> {
>   while (++k != n)
> a[k] = b[k]  + 1;
> }
> 
> For this code, if "k > n", k would wrap.  if "k < n" at begining,
> it could be optimized (e.g. vectorization).
> 
> We can split the loop into two loops:
> 
>   while (++k > n)
> a[k] = b[k]  + 1;
>   while (l++ < n)
> a[k] = b[k]  + 1;
> 
> then for the second loop, it could be optimized.
> 
> This patch is spltting this kind of small loop to achieve better performance.
> 
> Bootstrap and regtest pass on ppc64le.  Is this ok for trunk?
> 
> Thanks!
> 
> Jiufu Guo.
> 
> gcc/ChangeLog:
> 
> 2021-05-15  Jiufu Guo  
> 
>   * tree-ssa-loop-split.c (connect_loop_phis): Add new param.
>   (get_ne_cond_branch): New function.
>   (split_ne_loop): New function.
>   (split_loop_on_ne_cond): New function.
>   (tree_ssa_split_loops): Use split_loop_on_ne_cond.
> 
> gcc/testsuite/ChangeLog:
> 
> 2021-05-15  Jiufu Guo  
> 
>   * gcc.dg/loop-split1.c: New test.
>   * g++.dg/vect/pr98064.cc: Suppress warning.
> ---
>  gcc/testsuite/g++.dg/vect/pr98064.cc |   4 +-
>  gcc/testsuite/gcc.dg/loop-split1.c   | 108 +++
>  gcc/tree-ssa-loop-split.c| 188 ++-
>  3 files changed, 296 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/loop-split1.c
> 
> diff --git a/gcc/testsuite/g++.dg/vect/pr98064.cc 
> b/gcc/testsuite/g++.dg/vect/pr98064.cc
> index 74043ce7725..dcb2985d05a 100644
> --- a/gcc/testsuite/g++.dg/vect/pr98064.cc
> +++ b/gcc/testsuite/g++.dg/vect/pr98064.cc
> @@ -1,5 +1,7 @@
>  // { dg-do compile }
> -// { dg-additional-options "-O3" }
> +// { dg-additional-options "-O3 -Wno-stringop-overflow" }
> +/* There is warning message when "short g = var_8; g; g++"
> +   is optimized/analyzed as string operation,e.g. memset.  */
>  
>  const long long (const long long &__a, long long &__b) {
>if (__b < __a)
> diff --git a/gcc/testsuite/gcc.dg/loop-split1.c 
> b/gcc/testsuite/gcc.dg/loop-split1.c
> new file mode 100644
> index 000..30b006b1b14
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/loop-split1.c
> @@ -0,0 +1,108 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fsplit-loops -fdump-tree-lsplit-details" } */
> +
> +void
> +foo (int *a, int *b, unsigned l, unsigned n)
> +{
> +  while (++l != n)
> +a[l] = b[l]  + 1;
> +}
> +void
> +foo_1 (int *a, int *b, unsigned n)
> +{
> +  unsigned l = 0;
> +  while (++l != n)
> +a[l] = b[l]  + 1;
> +}
> +
> +void
> +foo1 (int *a, int *b, unsigned l, unsigned n)
> +{
> +  while (l++ != n)
> +a[l] = b[l]  + 1;
> +}
> +
> +/* No wrap.  */
> +void
> +foo1_1 (int *a, int *b, unsigned n)
> +{
> +  unsigned l = 0;
> +  while (l++ != n)
> +a[l] = b[l]  + 1;
> +}
> +
> +unsigned
> +foo2 (char *a, char *b, unsigned l, unsigned n)
> +{
> +  while (++l != n)
> +if (a[l] != b[l])
> +  break;
> +
> +  return l;
> +}
> +
> +unsigned
> +foo2_1 (char *a, char *b, unsigned l, unsigned n)
> +{
> +  l = 0;
> +  while (++l != n)
> +if (a[l] != b[l])
> +  break;
> +
> +  return l;
> +}
> +
> +unsigned
> +foo3 (char *a, char *b, unsigned l, unsigned n)
> +{
> +  while (l++ != n)
> +if (a[l] != b[l])
> +  break;
> +
> +  return l;
> +}
> +
> +/* No wrap.  */
> +unsigned
> +foo3_1 (char *a, char *b, unsigned l, unsigned n)
> +{
> +  l = 0;
> +  while (l++ != n)
> +if (a[l] != b[l])
> +  break;
> +
> +  return l;
> +}
> +
> +void bar();
> +void foo4(unsigned n,  unsigned i)
> +{
> +  do
> +{
> +  if (i == n)
> +return;
> +  bar();
> +  ++i;
> +}
> +  while (1);
> +}
> +
> +unsigned
> +foo5 (double *a, unsigned n, unsigned i)
> +{
> +  while (a[i] > 0 && i != n)
> +i++;
> +
> +  return i;
> +}
> +
> +unsigned
> +find_skip_diff (char *p, char *q, unsigned n, unsigned i)
> +{
> +  while (p[i] == q[i] && ++i != n)
> +p++,q++;
> +
> +  return i;
> +}
> +
> +/* { dg-final { scan-tree-dump-times "Loop split" 9 "lsplit" } } */
> diff --git a/gcc/tree-ssa-loop-split.c b/gcc/tree-ssa-loop-split.c
> index 3a09bbc39e5..5c1742b5ff4 100644
> --- a/gcc/tree-ssa-loop-split.c
> +++ b/gcc/tree-ssa-loop-split.c
> @@ -41,6 +41,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "cfghooks.h"
>  #include "gimple-fold.h"
>  #include "gimplify-me.h"
> +#include "tree-ssa-loop-ivopts.h"
>  
>  /* This file implements two kinds of loop splitting.
>  
> @@ -233,7 +234,8 @@ easy_exit_values (class loop *loop)
> this.  The loops need to fulfill easy_exit_values().  */
>  
>  static void
> -connect_loop_phis (class loop *loop1, class loop *loop2, edge new_e)
> +connect_loop_phis (class loop *loop1, class loop *loop2, edge new_e,
> +bool use_prev = false)
>  {
>basic_block rest = loop_preheader_edge 

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

[Bernd Edlinger]

On 5/16/21 10:36 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.
> 
> 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 | 37 +
>  1 file changed, 37 insertions(+)
> 
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 10503b97ab5..844f7dd5f87 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -3711,6 +3711,43 @@ 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. */
> +#if GIMPLE
> +(simplify
> + (cond @0 INTEGER_CST@1 INTEGER_CST@2)
> + (switch
> +  (if (integer_zerop (@2))
> +   (switch
> +/* a ? 1 : 0 -> a if 0 and 1 are integral types. */
> +(if (integer_onep (@1))
> + (convert (convert:boolean_type_node @0)))
> +/* a ? -1 : 0 -> -a. */
> +(if (integer_all_onesp (@1))
> + (negate (convert (convert:boolean_type_node @0
> +/* a ? powerof2cst : 0 -> a << (log2(powerof2cst)) */
> +(if (!POINTER_TYPE_P (type) && integer_pow2p (@1))
> + (with {
> +   tree shift = build_int_cst (integer_type_node, wi::exact_log2 
> (wi::to_wide (@1)));
> +  }
> +  (lshift (convert (convert:boolean_type_node @0)) { shift; })
> +  (if (integer_zerop (@1))
> +   (switch
> +/* a ? 0 : 1 -> !a. */
> +(if (integer_onep (@2))
> + (convert (bit_not:boolean_type_node (convert:boolean_type_node @0
> +/* a ? -1 : 0 -> -(!a). */
> +(if (integer_all_onesp (@2))
> + (negate (convert (bit_not:boolean_type_node (convert:boolean_type_node 
> @0)
> +/* a ? powerof2cst : 0 -> (!a) << (log2(powerof2cst)) */
> +(if (!POINTER_TYPE_P (type) && integer_pow2p (@2))
> + (with {
> +   tree shift = build_int_cst (integer_type_node, wi::exact_log2 
> (wi::to_wide (@2)));
> +  }
> +  (lshift (convert (bit_not:boolean_type_node (convert:boolean_type_node 
> @0))) { shift; })))
> +#endif
> +
>  /* Simplification moved from fold_cond_expr_with_comparison.  It may also
> be extended.  */
>  /* This pattern implements two kinds simplification:
> 

Hi Andrew,

Sorry, but I don't know what is exactly  wrong with this patch,
but it seems to cause this, when I try to bootstrap it:


/home/ed/gnu/gcc-build-2/./prev-gcc/xgcc -B/home/ed/gnu/gcc-build-2/./prev-gcc/ 
-B/home/ed/gnu/install/x86_64-pc-linux-gnu/bin/ 
-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 
-fchecking=1  -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada 
-Iada/gcc-interface -I../../gcc-trunk-1/gcc/ada 
-I../../gcc-trunk-1/gcc/ada/gcc-interface -Iada/libgnat 
-I../../gcc-trunk-1/gcc/ada/libgnat 
../../gcc-trunk-1/gcc/ada/libgnat/a-charac.ads -o ada/libgnat/a-charac.o
/home/ed/gnu/gcc-build-2/./prev-gcc/xgcc -B/home/ed/gnu/gcc-build-2/./prev-gcc/ 
-B/home/ed/gnu/install/x86_64-pc-linux-gnu/bin/ 
-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 
-fchecking=1  -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada 
-Iada/gcc-interface -I../../gcc-trunk-1/gcc/ada 
-I../../gcc-trunk-1/gcc/ada/gcc-interface -Iada/libgnat 
-I../../gcc-trunk-1/gcc/ada/libgnat 
../../gcc-trunk-1/gcc/ada/libgnat/a-chlat1.ads -o ada/libgnat/a-chlat1.o
+===GNAT BUG DETECTED==+
| 12.0.0 20210517 (experimental) (x86_64-pc-linux-gnu) Storage_Error stack 
overflow or erroneous memory access|
| Error detected at a-charac.ads:16:12 |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please 

Re: [PATCH 4/5] Rework indirect struct handling for OpenACC/OpenMP in gimplify.c

[Bernd Edlinger]

On 5/14/21 11:26 PM, Julian Brown wrote:
> This patch reworks indirect struct handling in gimplify.c (i.e. for struct
> components mapped with "mystruct->a[0:n]", "mystruct->b", etc.), for
> both OpenACC and OpenMP.  The key observation leading to these changes
> was that component mappings of references-to-structures is already
> implemented and working, and indirect struct component handling via a
> pointer can work quite similarly.  That lets us remove some earlier,
> special-case handling for mapping indirect struct component accesses
> for OpenACC, which required the pointed-to struct to be manually mapped
> before the indirect component mapping.
> 
> With this patch, you can map struct components directly (e.g. an array
> slice "mystruct->a[0:n]") just like you can map a non-indirect struct
> component slice ("mystruct.a[0:n]"). Both references-to-pointers (with
> the former syntax) and references to structs (with the latter syntax)
> work now.
> 
> For Fortran class pointers, we no longer re-use GOMP_MAP_TO_PSET for the
> class metadata (the structure that points to the class data and vptr)
> -- it is instead treated as any other struct.
> 
> For C++, the struct handling also works for class members ("this->foo"),
> without having to explicitly map "this[:1]" first.
> 
> For OpenACC, we permit chained indirect component references
> ("mystruct->a->b[0:n]"), though only the last part of such mappings will
> trigger an attach/detach operation.  To properly use such a construct
> on the target, you must still manually map "mystruct->a[:1]" first --
> but there's no need to map "mystruct[:1]" explicitly before that.
> 
> This patch incorporates parts of Chung-Lin's patch "Recommit "Enable
> gimplify GOMP_MAP_STRUCT handling of (COMPONENT_REF (INDIRECT_REF
> ...)) map clauses"." from the og10 branch.
> 
> OK for trunk?
> 
> Thanks,
> 
> Julian
> 
> 2021-05-14  Julian Brown  
>   Chung-Lin Tang  
> 
> gcc/fortran/
>   * trans-openmp.c (gfc_trans_omp_clauses): Don't create GOMP_MAP_TO_PSET
>   mappings for class metadata, nor GOMP_MAP_POINTER mappings for
>   POINTER_TYPE_P decls.
> 
> gcc/
>   * gimplify.c (tree-hash-traits.h): Include.
>   (extract_base_bit_offset): Add BASE_IND parameter.  Handle
>   pointer-typed indirect references alongside reference-typed ones.
>   (strip_components_and_deref, aggregate_base_p): New functions.
>   (build_struct_group): Update struct_map_to_clause type.  Add pointer
>   type indirect ref handling, including chained references.  Handle
>   pointers and references to structs in OpenACC regions as well as
>   OpenMP ones.
>   (gimplify_scan_omp_clauses): Remove struct_deref_set handling.  Rework
>   pointer-type indirect structure access handling to work more like
>   the reference-typed handling.
>   * omp-low.c (scan_sharing_clauses): Handle pointer-type indirect struct
>   references, and references to pointers to structs also.
> 
> gcc/testsuite/
>   * g++.dg/goacc/member-array-acc.C: New test (XFAILed for now).
>   * g++.dg/gomp/member-array-omp.C: New test (XFAILed for now).
> 
> libgomp/
>   * testsuite/libgomp.oacc-c-c++-common/deep-copy-15.c: New test.
>   * testsuite/libgomp.oacc-c-c++-common/deep-copy-16.c: New test.
>   * testsuite/libgomp.oacc-c++/deep-copy-17.C: New test.
> ---
>  gcc/fortran/trans-openmp.c|  20 +-
>  gcc/gimplify.c| 285 ++
>  gcc/omp-low.c |  16 +-
>  gcc/testsuite/g++.dg/goacc/member-array-acc.C |  14 +
>  gcc/testsuite/g++.dg/gomp/member-array-omp.C  |  14 +
>  .../testsuite/libgomp.oacc-c++/deep-copy-17.C | 101 +++
>  .../libgomp.oacc-c-c++-common/deep-copy-15.c  |  71 +
>  .../libgomp.oacc-c-c++-common/deep-copy-16.c  | 231 ++
>  8 files changed, 612 insertions(+), 140 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/goacc/member-array-acc.C
>  create mode 100644 gcc/testsuite/g++.dg/gomp/member-array-omp.C
>  create mode 100644 libgomp/testsuite/libgomp.oacc-c++/deep-copy-17.C
>  create mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/deep-copy-15.c
>  create mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/deep-copy-16.c
> 
> diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
> index 5666cd68c7e..ff614ffe744 100644
> --- a/gcc/fortran/trans-openmp.c
> +++ b/gcc/fortran/trans-openmp.c
> @@ -2721,30 +2721,16 @@ gfc_trans_omp_clauses (stmtblock_t *block, 
> gfc_omp_clauses *clauses,
> tree present = gfc_omp_check_optional_argument (decl, true);
> if (openacc && n->sym->ts.type == BT_CLASS)
>   {
> -   tree type = TREE_TYPE (decl);
> if (n->sym->attr.optional)
>   sorry ("optional class parameter");
> -   if (POINTER_TYPE_P (type))
> - {
> -

Re: [PATCH] tree-sra: Avoid refreshing into const base decls (PR 100453)

[Bernd Edlinger]

On 5/13/21 5:17 PM, Jeff Law via Gcc-patches wrote:
> 
> On 5/13/2021 6:23 AM, Martin Jambor wrote:
>> Hi,
>>
>> When SRA transforms an assignment where the RHS is an aggregate decl
>> that it creates replacements for, the (least efficient) fallback
>> method of dealing with them is to store all the replacements back into
>> the original decl and then let the original assignment takes its
>> course.
>>
>> That of course should not need to be done for TREE_READONLY bases
>> which cannot change contents.  The SRA code handled this situation in
>> one of two necessary places but only for DECL_IN_CONSTANT_POOL const
>> decls, this patch modifies both to check TREE_READONLY.
>>
>> Bootstrapped and tested on aarch64-linux, OK for trunk?
>>
>> Thanks,
>>
>> Martin
>>
>>
>>
>> gcc/ChangeLog:
>>
>> 2021-05-12  Martin Jambor  
>>
>> PR tree-optimization/100453
>> * tree-sra.c (sra_modify_assign): All const base accesses do not
>> need refreshing, not just those from decl_pool.
>> (sra_modify_assign): Do not refresh into a const base decl.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2021-05-12  Martin Jambor  
>>
>> PR tree-optimization/100453
>> * gcc.dg/tree-ssa/pr100453.c: New test.
> 
> OK
> 
> jeff
> 
> 

Looks like this caused:

=== acats tests ===
FAIL:   c41325a
FAIL:   c45347d
FAIL:   c74402a
FAIL:   c95085m
FAIL:   cc3601a

=== gnat tests ===

FAIL: gnat.dg/addr12.adb (test for excess errors)
UNRESOLVED: gnat.dg/addr12.adb compilation failed to produce executable
FAIL: gnat.dg/addr12_a.adb (test for excess errors)
FAIL: gnat.dg/bip_overlay.adb (test for excess errors)
FAIL: gnat.dg/global.adb (test for excess errors)
FAIL: gnat.dg/spark1.adb  (test for errors, line 8)
FAIL: gnat.dg/spark1.adb (test for excess errors)
FAIL: gnat.dg/sync2.adb (test for excess errors)
FAIL: gnat.dg/synchronized1.adb (test for excess errors)


Bernd.

Re: [PATCH, LIBPHOBOS] Cleanup temp files in libphobos unittest at src/std/process.d

[Bernd Edlinger]

On 5/14/21 1:54 PM, Iain Buclaw wrote:
> 
> Oops, sorry I meant src/MERGE, druntime has nothing to do with it.
> 
> So yes, please add 63f4caa900e17c541042617b2fa187059b86bf88 to
> libphobos/src/MERGE and it's good to go.
> 

Okay, so this is what I've pushed now:

commit cb787efa45782adab764575a2efc356e082828b6
Author: Bernd Edlinger 
Date:   Fri May 14 07:10:59 2021 +0200

Cleanup temp files in libphobos unittest at src/std/process.d
    
    2021-05-14  Bernd Edlinger  

* src/std/process.d (unittest): Remove tmpname on exit.
* src/MERGE: Merge upstream phobos 63f4caa90.

diff --git a/libphobos/src/MERGE b/libphobos/src/MERGE
index 49622c5..ac709f9 100644
--- a/libphobos/src/MERGE
+++ b/libphobos/src/MERGE
@@ -1,4 +1,4 @@
-32cfe9b61570d52d9885b0208fd20de0d351b51e
+63f4caa900e17c541042617b2fa187059b86bf88
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/phobos repository.
diff --git a/libphobos/src/std/process.d b/libphobos/src/std/process.d
index 63ec493..1e977aa 100644
--- a/libphobos/src/std/process.d
+++ b/libphobos/src/std/process.d
@@ -2581,6 +2581,7 @@ private auto executeImpl(alias pipeFunc, Cmd, 
ExtraPipeFuncArgs...)(
 
 ReturnType!executeShell r;
 auto tmpname = uniqueTempPath;
+scope(exit) if (exists(tmpname)) remove(tmpname);
 auto t = stderr;
 // Open a new scope to minimize code ran with stderr redirected.
 {


Thanks
Bernd.

Re: [PATCH, LIBPHOBOS] Cleanup temp files in libphobos unittest at src/std/process.d

[Bernd Edlinger]

Hi Iain,

On 5/14/21 11:55 AM, Iain Buclaw wrote:
> Excerpts from Bernd Edlinger's message of May 14, 2021 7:19 am:
>> Hi,
>>
>> I've noticed that a couple temp files are leaked after each full
>> gcc test-suite run.
>>
>> I'd like to fix that by the following patch.
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
>>
> 
> Thanks, looks reasonable to me.  Can you first post the patch upstream?
> 
> https://github.com/dlang/phobos/pulls
> 
> Just targeting the dmd-cxx branch is fine.  Then update
> libdruntime/MERGE with the latest commit reference.
> 

Okay, done, https://github.com/dlang/phobos/pull/8074 
that merge was very fast indeed :-)

Will that PR be eventually pushed to the https://github.com/dlang/druntime
as well, so I can update the libdruntime/MERGE with this commit-reference?


Thanks
Bernd.

[PATCH, LIBPHOBOS] Cleanup temp files in libphobos unittest at src/std/process.d

[Bernd Edlinger]

Hi,

I've noticed that a couple temp files are leaked after each full
gcc test-suite run.

I'd like to fix that by the following patch.


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


Thanks
Bernd.
From 6ad9e8552646e6ff54981cf7102ffcb311b6860f Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Fri, 14 May 2021 07:10:59 +0200
Subject: [PATCH] Cleanup temp files in libphobos unittest at src/std/process.d

2021-05-14  Bernd Edlinger  

	* src/std/process.d (unittest): Remove tmpname on exit.
---
 libphobos/src/std/process.d | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libphobos/src/std/process.d b/libphobos/src/std/process.d
index 63ec493..1e977aa 100644
--- a/libphobos/src/std/process.d
+++ b/libphobos/src/std/process.d
@@ -2581,6 +2581,7 @@ private auto executeImpl(alias pipeFunc, Cmd, ExtraPipeFuncArgs...)(
 
 ReturnType!executeShell r;
 auto tmpname = uniqueTempPath;
+scope(exit) if (exists(tmpname)) remove(tmpname);
 auto t = stderr;
 // Open a new scope to minimize code ran with stderr redirected.
 {
-- 
1.9.1

Re: [PATCH] avoid using an incompletely populated struct (PR 100574)

[Bernd Edlinger]

On 5/14/21 12:35 AM, Martin Sebor wrote:
> On 5/13/21 11:36 AM, Martin Sebor wrote:
>> On 5/13/21 11:20 AM, Bernd Edlinger wrote:
>>> On 5/13/21 3:55 AM, Martin Sebor via Gcc-patches wrote:
>>>> A logic bug in the handling of PHI arguments in compute_objsize
>>>> that are all null pointers lets an incompletely populated struct
>>>> be used in a way that triggers an assertion causing an ICE.
>>>>
>>>> The attached patch corrects that by having compute_objsize fail
>>>> when the struct isn't fully populated (when all os the PHI's
>>>> arguments are null).
>>>>
>>>> Martin
>>>
>>> Martin,
>>>
>>> I'm getting test failures with your patch here:
>>>
>>> Running target unix/-m32
>>> FAIL: g++.dg/pr100574.C  -std=gnu++14 (test for excess errors)
>>> FAIL: g++.dg/pr100574.C  -std=gnu++17 (test for excess errors)
>>> FAIL: g++.dg/pr100574.C  -std=gnu++2a (test for excess errors)
>>>
>>> /home/ed/gnu/gcc-trunk/gcc/testsuite/g++.dg/pr100574.C:6:7: error: 
>>> 'operator new' takes type 'size_t' ('unsigned int') as first parameter 
>>> [-fpermissive]^M
>>> compiler exited with status 1
>>
>> Thanks, I've just fixed it.
> 
> I hadn't checked in the patch yet.  I'm only now about to do it and
> see I inadvertently committed the test in response to your email
> about the failures.  I didn't realize you were testing the patch
> I had posted for review, before I committed it.
> 

Oh, well.

I just wanted to help, since you didn't tell how you tested the patch.


Bernd.

> Martin
> 
>>
>> Martin
>>
>>>
>>>
>>> Bernd.
>>>
>>
> 

Re: [PATCH] avoid using an incompletely populated struct (PR 100574)

[Bernd Edlinger]

On 5/13/21 3:55 AM, Martin Sebor via Gcc-patches wrote:
> A logic bug in the handling of PHI arguments in compute_objsize
> that are all null pointers lets an incompletely populated struct
> be used in a way that triggers an assertion causing an ICE.
> 
> The attached patch corrects that by having compute_objsize fail
> when the struct isn't fully populated (when all os the PHI's
> arguments are null).
> 
> Martin

Martin,

I'm getting test failures with your patch here:

Running target unix/-m32
FAIL: g++.dg/pr100574.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/pr100574.C  -std=gnu++17 (test for excess errors)
FAIL: g++.dg/pr100574.C  -std=gnu++2a (test for excess errors)

/home/ed/gnu/gcc-trunk/gcc/testsuite/g++.dg/pr100574.C:6:7: error: 'operator 
new' takes type 'size_t' ('unsigned int') as first parameter [-fpermissive]^M
compiler exited with status 1


Bernd.

Re: [PATCH] Warn for excessive argument alignment in main

[Bernd Edlinger]

On 5/13/21 3:37 PM, H.J. Lu via Gcc-patches wrote:
> Warn for excessive argument alignment in main instead of ICE.
> 
> gcc/
> 
>   PR c/100575
>   * cfgexpand.c (expand_stack_alignment): Add a bool argument for
>   expanding main.  Warn for excessive argument alignment in main.
>   (pass_expand::execute): Pass true to expand_stack_alignment when
>   expanding main.
> 
> gcc/testsuite/
> 
>   PR c/100575
>   * c-c++-common/pr100575.c: New test.
> ---
>  gcc/cfgexpand.c   | 26 --
>  gcc/testsuite/c-c++-common/pr100575.c | 11 +++
>  2 files changed, 31 insertions(+), 6 deletions(-)
>  create mode 100644 gcc/testsuite/c-c++-common/pr100575.c
> 
> diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> index e3814ee9d06..50ccb720e6c 100644
> --- a/gcc/cfgexpand.c
> +++ b/gcc/cfgexpand.c
> @@ -6363,7 +6363,7 @@ discover_nonconstant_array_refs (void)
> virtual_incoming_args_rtx with the virtual register.  */
>  
>  static void
> -expand_stack_alignment (void)
> +expand_stack_alignment (bool expanding_main)
>  {
>rtx drap_rtx;
>unsigned int preferred_stack_boundary;
> @@ -6385,9 +6385,18 @@ expand_stack_alignment (void)
>if (targetm.calls.update_stack_boundary)
>  targetm.calls.update_stack_boundary ();
>  
> -  /* The incoming stack frame has to be aligned at least at
> - parm_stack_boundary.  */
> -  gcc_assert (crtl->parm_stack_boundary <= INCOMING_STACK_BOUNDARY);
> +  if (crtl->parm_stack_boundary > INCOMING_STACK_BOUNDARY)
> +{
> +  /* The incoming stack frame has to be aligned at least at
> +  parm_stack_boundary.  NB: The incoming stack frame alignment
> +  for main is fixed.  */
> +  if (expanding_main)
> + warning_at (DECL_SOURCE_LOCATION (current_function_decl),
> + OPT_Wmain, "argument alignment of %q+D is too large",
> + current_function_decl);
> +  else
> + gcc_unreachable ();
> +}

Could you do this instead in ix86_minimum_incoming_stack_boundary

  /* The incoming stack frame has to be aligned at least at
 parm_stack_boundary.  */
  if (incoming_stack_boundary < crtl->parm_stack_boundary)
incoming_stack_boundary = crtl->parm_stack_boundary;

  /* Stack at entrance of main is aligned by runtime.  We use the
 smallest incoming stack boundary. */
  if (incoming_stack_boundary > MAIN_STACK_BOUNDARY
  && DECL_NAME (current_function_decl)
  && MAIN_NAME_P (DECL_NAME (current_function_decl))
  && DECL_FILE_SCOPE_P (current_function_decl))
incoming_stack_boundary = MAIN_STACK_BOUNDARY;


maybe just repeat this after incoming_stack_boundary is set to
MAIN_STACK_BOUNDARY:

  /* The incoming stack frame has to be aligned at least at
 parm_stack_boundary.  */
  if (incoming_stack_boundary < crtl->parm_stack_boundary)
incoming_stack_boundary = crtl->parm_stack_boundary;

and print the warning here?


Thanks
Bernd.

[PATCH] Fix ICE in output_rnglists, at dwarf2out.c:12294 [PR100515]

[Bernd Edlinger]

Hi,

this fixes another regression from my previous patch.


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


Thanks
Bernd.
From 62da66525c4b7ac1cfd5cad5b8e690ce928802e5 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Tue, 11 May 2021 17:55:18 +0200
Subject: [PATCH] Fix ICE in output_rnglists, at dwarf2out.c:12294

In this testcase the compile unit consists of a single
text section with a single embedded DECL_IGNORED_P function.
So we have a kind of multi-range text section here.
To avoid an ICE in output_rnglists we need to make sure
that have_multiple_function_sections is set to true.
This is a regression from
e69ac020372 ("Add line debug info for virtual thunks")

2021-05-11  Bernd Edlinger  

	PR debug/100515
	* dwarg2out.c (dwarf2out_finish): Set
	have_multiple_function_sections with multi-range text_section.

	* gcc.dg/debug/dwarf2/pr100515.c: New testcase.
---
 gcc/dwarf2out.c  |  1 +
 gcc/testsuite/gcc.dg/debug/dwarf2/pr100515.c | 19 +++
 2 files changed, 20 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/pr100515.c

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index a5ec21a..1593092 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -31956,6 +31956,7 @@ dwarf2out_finish (const char *filename)
 add_AT_addr (main_comp_unit_die, DW_AT_entry_pc, const0_rtx, true);
 
 	  add_ranges (NULL);
+	  have_multiple_function_sections = true;
 	}
 }
 
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr100515.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr100515.c
new file mode 100644
index 000..7c72fcd
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr100515.c
@@ -0,0 +1,19 @@
+/* PR debug/100515 */
+/* { dg-do compile } */
+/* { dg-options "-g -O2 -fopenmp" } */
+
+void
+foo (int x)
+{
+#pragma omp taskloop
+  for (int i = 0; i < x; i++)
+;
+}
+
+void
+bar (int x)
+{
+#pragma omp taskloop
+  for (int i = 0; i < x; i++)
+;
+}
-- 
1.9.1

Re: [PATCH] Bump LTO_major_version to 11.

[Bernd Edlinger]

Hi Eric,

I have a slightly different issue, last week it was still okay,
but now I get (using gcc-4.8 as bootstrap compiler):

gcc -std=gnu99 -c -g  -gnatpg -gnatwns -gnata -W -Wall -nostdinc -I- -I. 
-Iada/generated -Iada -Iada/gcc-interface -I../../gcc-trunk/gcc/ada 
-I../../gcc-trunk/gcc/ada/gcc-interface -Iada/libgnat 
-I../../gcc-trunk/gcc/ada/libgnat ../../gcc-trunk/gcc/ada/atree.adb -o 
ada/atree.o
atree.adb:569:30: "Shift_Right" is not visible (more references follow)
atree.adb:569:30: non-visible declaration at interfac.ads:147
atree.adb:569:30: non-visible declaration at interfac.ads:127
atree.adb:569:30: non-visible declaration at interfac.ads:107
atree.adb:569:30: non-visible declaration at interfac.ads:87
atree.adb:569:30: non-visible declaration at s-unstyp.ads:220
atree.adb:569:30: non-visible declaration at s-unstyp.ads:200
atree.adb:569:30: non-visible declaration at s-unstyp.ads:180
atree.adb:569:30: non-visible declaration at s-unstyp.ads:160
atree.adb:569:30: non-visible declaration at s-unstyp.ads:140
atree.adb:569:30: non-visible declaration at s-unstyp.ads:120
atree.adb:631:26: "Shift_Left" is not visible (more references follow)
atree.adb:631:26: non-visible declaration at interfac.ads:143
atree.adb:631:26: non-visible declaration at interfac.ads:123
atree.adb:631:26: non-visible declaration at interfac.ads:103
atree.adb:631:26: non-visible declaration at interfac.ads:83
atree.adb:631:26: non-visible declaration at s-unstyp.ads:216
atree.adb:631:26: non-visible declaration at s-unstyp.ads:196
atree.adb:631:26: non-visible declaration at s-unstyp.ads:176
atree.adb:631:26: non-visible declaration at s-unstyp.ads:156
atree.adb:631:26: non-visible declaration at s-unstyp.ads:136
atree.adb:631:26: non-visible declaration at s-unstyp.ads:116
make[3]: *** [ada/atree.o] Error 1
make[3]: *** Waiting for unfinished jobs


On 5/10/21 10:51 AM, Eric Botcazou wrote:
>> Ready for master?
> 
> This breaks the build for me:
> 
> make[3]: *** No rule to make target '/home/eric/cvs/gcc/gcc/version.c', 
> needed 
> by 'ada/stamp-sdefault'.  Stop.
> make[3]: *** Waiting for unfinished jobs
> 


Thanks
Bernd.

[PATCH] Reset prologue_location before calling code_end [PR 100467]

[Bernd Edlinger]

Hi,

this fixes a fallout from my previous patch to improve
debug info of virtual thunks.

Tested on x86_64-pc-linux-gnu with --target_board=unix/-m32
Is it OK for trunk?


Thanks
Bernd.
From 7bea6a83f4daf97ac1cfeb6c2e10fb7ae742340f Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Sat, 8 May 2021 07:46:17 +0200
Subject: [PATCH] Reset prologue_location before calling code_end

Some targets emit thunks from the targetm.asm_out.code_end
function and set the DECL_IGNORED_P, but due to
e69ac020372 ("Add line debug info for virtual thunks")
the value in prologue_location is no longer ignored.

So reset that value before calling the backend.

2021-05-08  Bernd Edlinger  

	PR middle-end/100467
	* toplev.c (compile_file): Call insn_locations_init before
	targetm.asm_out.code_end.
---
 gcc/toplev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/toplev.c b/gcc/toplev.c
index d8cc254..7e23253 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -523,6 +523,7 @@ compile_file (void)
 
   /* This must be at the end before unwind and debug info.
 	 Some target ports emit PIC setup thunks here.  */
+  insn_locations_init ();
   targetm.asm_out.code_end ();
 
   /* Do dbx symbols.  */
-- 
1.9.1

Re: [PATCH v2] Add line debug info for virtual thunks [PR97937]

[Bernd Edlinger]

Hi!


I've re-based and re-tested this patch on current trunk.
Otherwise the patch is unchanged, from the previous v2 version.

This patch is fixing two issues with functions where we
do not have proper debug info:

1. Functions without line-numbers at all, are excluded from
the CU's address range in the debug info.  This makes the
debugger not display any line numbers but instead the debugger
steps into assembler.

2. Functions with a declaration line number show this line
number instead of a completely unrelated line-number from a
different function that was emitted before the current one.

So, since we are again in stage 1:
Is it OK for trunk?


Thanks
Bernd.


On 1/13/21 3:59 PM, Bernd Edlinger wrote:
> Hi,
> 
> this is a new improved version of my patch.
> The previous patch had two defects:
> It failed with -ffunction-section.  Although
> the line info was emitted, that was not working
> since the debug_ranges did not contain the
> thunk.
> And secondly it failed to address the case of
> functions without any source line information.
> 
> The new pattch addresses both cases, of DECL_IGNORED_P
> functions:
> 
> In the case of virtual thunks we emit the line
> number from the declaration.
> Other than the previous version this patch
> also explicitly adds the virtual thunk to the
> debug_ranges and debug_aranges.  If that is not
> done, the debugger does not recognize the line
> table for these functions.
> 
> But if that location info is unavailable,
> the function is explicitly removed from the
> debug_ranges and debug_aranges.  That has
> the same effect as a theoretical .noloc assembler
> directive.
> 
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 
From 6f057870153999ef63d89e40cee930bf0cd1d688 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Tue, 12 Jan 2021 16:27:53 +0100
Subject: [PATCH] Add line debug info for virtual thunks

There is no debug info when the DECL_IGNORED_P flag
is set.  But sometimes we have the line info of the
function decl, as in the case of on virtual thunks.
So instead of no line info at all, we emit at least
the location of the function decl.
On the other side, there are DECL_IGNORED_P functions
which do not have any source line info at all.
Remove those from the debug_range info, to make it
clear for the debugger that the line info for these
functions is invalid.  This has the effect that the
debugger will not step into the function without
debug info.

2021-04-29  Bernd Edlinger  

	PR ipa/97937
	* debug.h (gcc_debug_hooks): Add set_ignored_loc function pointer.
	* dwarf2out.h (dw_fde_node::ignored_debug): New data item.
	* dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Add dummy
	set_ignored_loc callbacks.
	* debug.c (do_nothing_debug_hooks): Likewise.
	* vmsdbgout.c (vmsdbg_debug_hooks): Likewise.
	* dwarf2out.c (text_section_used, cold_text_section_used): Remove.
	(in_text_section_p, last_text_label, last_cold_label,
	switch_text_ranges, switch_cold_ranges): New data items.
	(dwarf2out_note_section_used): Remove.
	(dwarf2out_begin_prologue): Set fde->ignored_debug and
	in_text_section_p.
	(mark_ignored_debug_section): New helper function.
	(dwarf2out_end_epilogue, dwarf2out_switch_text_section): Call
	mark_ignored_debug_section.
	(dwarf2_debug_hooks): Use dwarf2out_set_ignored_loc.
	(dwarf2_lineno_debug_hooks): Use dummy for set_ignored_loc.
	(size_of_aranges): Adjust formula for multi-part text ranges size.
	(output_aranges): Output multi-part text ranges.
	(dwarf2out_set_ignored_loc): New callback function.
	(dwarf2out_finish): Output multi-part text ranges.
	(dwarf2out_c_finalize): Clear new data items.
	* final.c (final_start_function_1): Call set_ignored_loc callback.
	(final_scan_insn_1): Likewise.
	* ggc-page.c (gt_ggc_mx): New helper function.
	* stringpool.c (gt_pch_nx): Likewise.
---
 gcc/dbxout.c |   2 +
 gcc/debug.c  |   1 +
 gcc/debug.h  |   4 +
 gcc/dwarf2out.c  | 244 +++
 gcc/dwarf2out.h  |   2 +
 gcc/final.c  |   8 ++
 gcc/ggc-page.c   |   6 ++
 gcc/stringpool.c |   6 ++
 gcc/vmsdbgout.c  |   1 +
 9 files changed, 224 insertions(+), 50 deletions(-)

diff --git a/gcc/dbxout.c b/gcc/dbxout.c
index 70b635c..d20527b 100644
--- a/gcc/dbxout.c
+++ b/gcc/dbxout.c
@@ -362,6 +362,7 @@ const struct gcc_debug_hooks dbx_debug_hooks =
   dbxout_end_block,
   debug_true_const_tree,	 /* ignore_block */
   dbxout_source_line,		 /* source_line */
+  debug_nothing_int_int_charstar,	 /* set_ignored_loc */
   dbxout_begin_prologue,	 /* begin_prologue */
   debug_nothing_int_charstar,	 /* end_prologue */
   debug_nothing_int_charstar,	 /* begin_epilogue */
@@ -409,6 +410,7 @@ const struct gcc_debug_hooks xcoff_debug_hooks =
   xcoffout_end_block,
   debug_true_const_tr

Re: [PATCH] Fix target/100106 ICE in gen_movdi

[Bernd Edlinger]

Aehm,

forgot to mention,

tested on arm-none-eabi (arm-sim target)
is it OK for trunk?


Thanks
Bernd.

On 4/22/21 8:37 AM, Bernd Edlinger wrote:
> As the test case shows, the outer mode may have a higher alignment
> requirement than the inner mode here.
> 
> 2021-04-22  Bernd Edlinger  
> 
>   PR target/100106
>   * gimplify-rtx.c (simplify_context::simplify_subreg): Check the
>   memory alignment for the outer mode.
> 
>   * gcc.c-torture/compile/pr100106.c: New testcase.
> ---
>  gcc/simplify-rtx.c |  1 +
>  gcc/testsuite/gcc.c-torture/compile/pr100106.c | 11 +++
>  2 files changed, 12 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr100106.c
> 
> diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
> index d13c390..ad3b7b2 100644
> --- a/gcc/simplify-rtx.c
> +++ b/gcc/simplify-rtx.c
> @@ -7217,6 +7217,7 @@ simplify_context::simplify_subreg (machine_mode 
> outermode, rtx op,
>   have instruction to move the whole thing.  */
>&& (! MEM_VOLATILE_P (op)
> || ! have_insn_for (SET, innermode))
> +  && !(STRICT_ALIGNMENT && MEM_ALIGN (op) < GET_MODE_ALIGNMENT 
> (outermode))
>&& known_le (outersize, innersize))
>  return adjust_address_nv (op, outermode, byte);
>  
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr100106.c 
> b/gcc/testsuite/gcc.c-torture/compile/pr100106.c
> new file mode 100644
> index 000..7f98b4f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr100106.c
> @@ -0,0 +1,11 @@
> +union a {
> +  float _Complex b;
> +  long long c;
> +};
> +
> +void g(union a);
> +
> +void e() {
> +  union a f = {1.0f};
> +  g(f);
> +}
> 

[PATCH] Fix target/100106 ICE in gen_movdi

[Bernd Edlinger]

As the test case shows, the outer mode may have a higher alignment
requirement than the inner mode here.

2021-04-22  Bernd Edlinger  

PR target/100106
* gimplify-rtx.c (simplify_context::simplify_subreg): Check the
memory alignment for the outer mode.

* gcc.c-torture/compile/pr100106.c: New testcase.
---
 gcc/simplify-rtx.c |  1 +
 gcc/testsuite/gcc.c-torture/compile/pr100106.c | 11 +++
 2 files changed, 12 insertions(+)
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr100106.c

diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index d13c390..ad3b7b2 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -7217,6 +7217,7 @@ simplify_context::simplify_subreg (machine_mode 
outermode, rtx op,
  have instruction to move the whole thing.  */
   && (! MEM_VOLATILE_P (op)
  || ! have_insn_for (SET, innermode))
+  && !(STRICT_ALIGNMENT && MEM_ALIGN (op) < GET_MODE_ALIGNMENT (outermode))
   && known_le (outersize, innersize))
 return adjust_address_nv (op, outermode, byte);
 
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr100106.c 
b/gcc/testsuite/gcc.c-torture/compile/pr100106.c
new file mode 100644
index 000..7f98b4f
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr100106.c
@@ -0,0 +1,11 @@
+union a {
+  float _Complex b;
+  long long c;
+};
+
+void g(union a);
+
+void e() {
+  union a f = {1.0f};
+  g(f);
+}
-- 
1.9.1

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 v2] Add line debug info for virtual thunks [PR97937]

[Bernd Edlinger]

Ping?

The patch was posted before Stage 4 started:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563391.html

Thanks
Bernd.


On 1/13/21 3:59 PM, Bernd Edlinger wrote:
> Hi,
> 
> this is a new improved version of my patch.
> The previous patch had two defects:
> It failed with -ffunction-section.  Although
> the line info was emitted, that was not working
> since the debug_ranges did not contain the
> thunk.
> And secondly it failed to address the case of
> functions without any source line information.
> 
> The new pattch addresses both cases, of DECL_IGNORED_P
> functions:
> 
> In the case of virtual thunks we emit the line
> number from the declaration.
> Other than the previous version this patch
> also explicitly adds the virtual thunk to the
> debug_ranges and debug_aranges.  If that is not
> done, the debugger does not recognize the line
> table for these functions.
> 
> But if that location info is unavailable,
> the function is explicitly removed from the
> debug_ranges and debug_aranges.  That has
> the same effect as a theoretical .noloc assembler
> directive.
> 
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 

[PATCH v2] Add line debug info for virtual thunks [PR97937]

[Bernd Edlinger]

Hi,

this is a new improved version of my patch.
The previous patch had two defects:
It failed with -ffunction-section.  Although
the line info was emitted, that was not working
since the debug_ranges did not contain the
thunk.
And secondly it failed to address the case of
functions without any source line information.

The new pattch addresses both cases, of DECL_IGNORED_P
functions:

In the case of virtual thunks we emit the line
number from the declaration.
Other than the previous version this patch
also explicitly adds the virtual thunk to the
debug_ranges and debug_aranges.  If that is not
done, the debugger does not recognize the line
table for these functions.

But if that location info is unavailable,
the function is explicitly removed from the
debug_ranges and debug_aranges.  That has
the same effect as a theoretical .noloc assembler
directive.


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


Thanks
Bernd.
From feffb6731523e3a77566c2a5f541c6b90e1ffb19 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Tue, 12 Jan 2021 16:27:53 +0100
Subject: [PATCH] Add line debug info for virtual thunks

There is no debug info when the DECL_IGNORED_P flag
is set.  But sometimes we have the line info of the
function decl, as in the case of on virtual thunks.
So instead of no line info at all, we emit at least
the location of the function decl.
On the other side, there are DECL_IGNORED_P functions
which do not have any source line info at all.
Remove those from the debug_range info, to make it
clear for the debugger that the line info for these
functions is invalid.  This has the effect that the
debugger will not step into the function without
debug info.

2021-01-13  Bernd Edlinger  

	PR ipa/97937
	* debug.h (gcc_debug_hooks): Add set_ignored_loc function pointer.
	* dwarf2out.h (dw_fde_node::ignored_debug): New data item.
	* dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Add dummy
	set_ignored_loc callbacks.
	* debug.c (do_nothing_debug_hooks): Likewise.
	* vmsdbgout.c (vmsdbg_debug_hooks): Likewise.
	* dwarf2out.c (text_section_used, cold_text_section_used): Remove.
	(in_text_section_p, last_text_label, last_cold_label,
	switch_text_ranges, switch_cold_ranges): New data items.
	(dwarf2out_note_section_used): Remove.
	(dwarf2out_begin_prologue): Set fde->ignored_debug and
	in_text_section_p.
	(mark_ignored_debug_section): New helper function.
	(dwarf2out_end_epilogue, dwarf2out_switch_text_section): Call
	mark_ignored_debug_section.
	(dwarf2_debug_hooks): Use dwarf2out_set_ignored_loc.
	(dwarf2_lineno_debug_hooks): Use dummy for set_ignored_loc.
	(size_of_aranges): Adjust formula for multi-part text ranges size.
	(output_aranges): Output multi-part text ranges.
	(dwarf2out_set_ignored_loc): New callback function.
	(dwarf2out_finish): Output multi-part text ranges.
	(dwarf2out_c_finalize): Clear new data items.
	* final.c (final_start_function_1): Call set_ignored_loc callback.
	(final_scan_insn_1): Likewise.
	* ggc-page.c (gt_ggc_mx): New helper function.
	* stringpool.c (gt_pch_nx): Likewise.
---
 gcc/dbxout.c |   2 +
 gcc/debug.c  |   1 +
 gcc/debug.h  |   4 +
 gcc/dwarf2out.c  | 244 +++
 gcc/dwarf2out.h  |   2 +
 gcc/final.c  |   8 ++
 gcc/ggc-page.c   |   6 ++
 gcc/stringpool.c |   6 ++
 gcc/vmsdbgout.c  |   1 +
 9 files changed, 224 insertions(+), 50 deletions(-)

diff --git a/gcc/dbxout.c b/gcc/dbxout.c
index 70b635c..d20527b 100644
--- a/gcc/dbxout.c
+++ b/gcc/dbxout.c
@@ -362,6 +362,7 @@ const struct gcc_debug_hooks dbx_debug_hooks =
   dbxout_end_block,
   debug_true_const_tree,	 /* ignore_block */
   dbxout_source_line,		 /* source_line */
+  debug_nothing_int_int_charstar,	 /* set_ignored_loc */
   dbxout_begin_prologue,	 /* begin_prologue */
   debug_nothing_int_charstar,	 /* end_prologue */
   debug_nothing_int_charstar,	 /* begin_epilogue */
@@ -409,6 +410,7 @@ const struct gcc_debug_hooks xcoff_debug_hooks =
   xcoffout_end_block,
   debug_true_const_tree,	 /* ignore_block */
   xcoffout_source_line,
+  debug_nothing_int_int_charstar,	 /* set_ignored_loc */
   xcoffout_begin_prologue,	 /* begin_prologue */
   debug_nothing_int_charstar,	 /* end_prologue */
   debug_nothing_int_charstar,	 /* begin_epilogue */
diff --git a/gcc/debug.c b/gcc/debug.c
index 0a7fcfa..39add0d 100644
--- a/gcc/debug.c
+++ b/gcc/debug.c
@@ -36,6 +36,7 @@ const struct gcc_debug_hooks do_nothing_debug_hooks =
   debug_nothing_int_int,	 /* end_block */
   debug_true_const_tree,	 /* ignore_block */
   debug_nothing_int_int_charstar_int_bool, /* source_line */
+  debug_nothing_int_int_charstar,	 /* set_ignored_loc */
   debug_nothing_int_int_charstar,	 /* begin_prologue */
   debug_nothing_int_charstar,	 /* end_prologue */
   debug_nothing_int_charstar,	 /* begin_epilogue */
diff --git a/gcc/debug.h b/gcc/debug.h
index 67e5

Re: [PATCH v2] testsuite: Fix test failures from outputs.exp [PR98225]

[Bernd Edlinger]

On 1/8/21 8:27 PM, David Edelsohn wrote:
> Hi, Bernd
> 
> Thanks for investigating this and creating a revised version of the
> patch.  With the second patch, the gcc.misc-test/outputs.exp results
> are clean on AIX.
> 

Many thanks for confirming that the patch works.

Is it OK to push?

Thanks
Bernd.

> Thanks, David
> 
> On Fri, Jan 8, 2021 at 1:59 PM Bernd Edlinger  
> wrote:
>>
>> On 1/8/21 3:23 PM, David Edelsohn wrote:
>>> On Thu, Jan 7, 2021 at 5:18 PM Bernd Edlinger  
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 1/7/21 5:12 PM, Rainer Orth wrote:
>>>>>   The unsetenv needs to be wrapped in
>>>>>
>>>>> if [info exists env(MAKEFLAGS)] {
>>>>>
>>>>
>>>> Done.
>>>>
>>>>> @@ -163,6 +167,9 @@ proc outest { test sources opts dirs out
>>>>>   if { $ogl != {} } {
>>>>>   pass "$test: $d$o"
>>>>>   file delete $ogl
>>>>> + } elseif { [string match "*.ld1_args" $o] } {
>>>>> + # This file may be missing if !HAVE_GNU_LD
>>>>> + pass "$test: $d$o"
>>>>>
>>>>>   Always PASSing the test even if it isn't run is wrong.  Either wrap
>>>>>   the whole group of tests with response files in
>>>>>
>>>>> if [check_effective_target_gld] {
>>>>>
>>>>>   or make the test for the *.ld1_args file conditional on that
>>>>>   (e.g. along the lines of $ltop used elsewhere).  I'd welcome input
>>>>>   from Alexandre which is preferred.
>>>>>
>>>>
>>>> Ah, yes that is a good idea.  Thanks.
>>>>
>>>>
>>>> I think the .cdtor.* handling, is probably a bad example that I followed 
>>>> here.
>>>> I don't know why that is there in the first place, as there
>>>> are no C++ test cases, these files should not be created at all.
>>>> If they are ever created we would have a couple of other files created
>>>> as well IMHO.
>>>> If there are still missing files in some cases,
>>>> I'd prefer to track these per test case, instead of globally.
>>>>
>>>> Therefore I propose to remove that exception for now.
>>>>
>>>> Is it OK for trunk?
>>>
>>> As Alex said, please don't just remove features and functionality if
>>> you don't know why they were added.  The history is online in the
>>> mailing list and the repo history.
>>>
>>> AIX uses constructors to register EH frames and libgcc has an EH
>>> frame.  ctors and dtors can be found in non-C++ code.
>>>
>>
>> Okydoky.
>>
>> I think I understand now better what the issue is here.
>> Although the name cdtor suggests that it has something to do with
>> C++ it is also needed to collect EH frame info, in certain targets.
>> Those are mainly AIX but also hppa*-*-hpux*.
>> I believe those exceptions are only necessary for targets that
>> define EH_FRAME_THROUGH_COLLECT2.
>>
>> I have tested this new version of my patch but only on not-affected
>> x86_64-pc-linux-gnu.
>>
>> @David, @Rainer: I would very much appreciate if you could give this patch
>> a test on your systems.
>>
>>
>> Thanks
>> Berns.

[PATCH v2] testsuite: Fix test failures from outputs.exp [PR98225]

[Bernd Edlinger]

On 1/8/21 3:23 PM, David Edelsohn wrote:
> On Thu, Jan 7, 2021 at 5:18 PM Bernd Edlinger  
> wrote:
>>
>> Hi,
>>
>> On 1/7/21 5:12 PM, Rainer Orth wrote:
>>>   The unsetenv needs to be wrapped in
>>>
>>> if [info exists env(MAKEFLAGS)] {
>>>
>>
>> Done.
>>
>>> @@ -163,6 +167,9 @@ proc outest { test sources opts dirs out
>>>   if { $ogl != {} } {
>>>   pass "$test: $d$o"
>>>   file delete $ogl
>>> + } elseif { [string match "*.ld1_args" $o] } {
>>> + # This file may be missing if !HAVE_GNU_LD
>>> + pass "$test: $d$o"
>>>
>>>   Always PASSing the test even if it isn't run is wrong.  Either wrap
>>>   the whole group of tests with response files in
>>>
>>> if [check_effective_target_gld] {
>>>
>>>   or make the test for the *.ld1_args file conditional on that
>>>   (e.g. along the lines of $ltop used elsewhere).  I'd welcome input
>>>   from Alexandre which is preferred.
>>>
>>
>> Ah, yes that is a good idea.  Thanks.
>>
>>
>> I think the .cdtor.* handling, is probably a bad example that I followed 
>> here.
>> I don't know why that is there in the first place, as there
>> are no C++ test cases, these files should not be created at all.
>> If they are ever created we would have a couple of other files created
>> as well IMHO.
>> If there are still missing files in some cases,
>> I'd prefer to track these per test case, instead of globally.
>>
>> Therefore I propose to remove that exception for now.
>>
>> Is it OK for trunk?
> 
> As Alex said, please don't just remove features and functionality if
> you don't know why they were added.  The history is online in the
> mailing list and the repo history.
> 
> AIX uses constructors to register EH frames and libgcc has an EH
> frame.  ctors and dtors can be found in non-C++ code.
> 

Okydoky.

I think I understand now better what the issue is here.
Although the name cdtor suggests that it has something to do with
C++ it is also needed to collect EH frame info, in certain targets.
Those are mainly AIX but also hppa*-*-hpux*.
I believe those exceptions are only necessary for targets that
define EH_FRAME_THROUGH_COLLECT2.

I have tested this new version of my patch but only on not-affected
x86_64-pc-linux-gnu.

@David, @Rainer: I would very much appreciate if you could give this patch
a test on your systems.


Thanks
Berns.
From 861f6631c34bdcbc0d6f61247cc231c1f1b36708 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Thu, 7 Jan 2021 09:37:32 +0100
Subject: [PATCH] testsuite: Fix test failures from outputs.exp [PR98225]

The .ld1_args file is not created when HAVE_GNU_LD is false.
The ltrans0.ltrans_arg file is not created when the make jobserver
is available, so remove the MAKEFLAGS variable.
Add an exception for *.gcc_args files similar to the
exception for *.cdtor.* files.
Limit both exceptions to targets that define EH_FRAME_THROUGH_COLLECT2.
That means although the test case does not use C++ constructors
or destructors it is still using dwarf2 frame info.

2021-01-07  Bernd Edlinger  

	PR testsuite/98225
	* gcc.misc-tests/outputs.exp: Unset MAKEFLAGS.
	Expect .ld1_args only when GNU LD is used.
	Add an exception for *.gcc_args files.
---
 gcc/testsuite/gcc.misc-tests/outputs.exp | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp b/gcc/testsuite/gcc.misc-tests/outputs.exp
index 80d4b61..d5a9709 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -50,6 +50,9 @@ if !$skip_lto {
 set ltop [check_linker_plugin_available]
 }
 
+# Check for GNU LD.  Some files like .ld1_args depend on this.
+set gld [check_effective_target_gld]
+
 # Prepare additional options to be used for linking.
 # We do not compile to an executable, because that requires naming an output.
 set link_options ""
@@ -67,6 +70,12 @@ if {[board_info $dest exists output_format]} {
 append link_options " additional_flags=-Wl,-oformat,[board_info $dest output_format]"
 }
 
+# Avoid possible influence from the make jobserver,
+# otherwise ltrans0.ltrans_args files may be missing.
+if [info exists env(MAKEFLAGS)] {
+unsetenv MAKEFLAGS
+}
+
 # For the test named TEST, run the compiler with SOURCES and OPTS, and
 # look in DIRS for OUTPUTS.  SOURCES is a list of suffixes for source
 # files starting with $b in $srcdir/$subdir, OPTS is a string with
@@ -130,6 +139,7 @@ proc outest { test sources opts dirs outputs } {
 	foreach og $olist {
 	if { [string index $og 0] == &qu

[PATCH] testsuite: Fix test failures from outputs.exp [PR98225]

[Bernd Edlinger]

Hi,

On 1/7/21 5:12 PM, Rainer Orth wrote:
>   The unsetenv needs to be wrapped in
> 
> if [info exists env(MAKEFLAGS)] {
> 

Done.

> @@ -163,6 +167,9 @@ proc outest { test sources opts dirs out
>   if { $ogl != {} } {
>   pass "$test: $d$o"
>   file delete $ogl
> + } elseif { [string match "*.ld1_args" $o] } {
> + # This file may be missing if !HAVE_GNU_LD
> + pass "$test: $d$o"
> 
>   Always PASSing the test even if it isn't run is wrong.  Either wrap
>   the whole group of tests with response files in
> 
> if [check_effective_target_gld] {
> 
>   or make the test for the *.ld1_args file conditional on that
>   (e.g. along the lines of $ltop used elsewhere).  I'd welcome input
>   from Alexandre which is preferred.
> 

Ah, yes that is a good idea.  Thanks.


I think the .cdtor.* handling, is probably a bad example that I followed here.
I don't know why that is there in the first place, as there
are no C++ test cases, these files should not be created at all.
If they are ever created we would have a couple of other files created
as well IMHO.
If there are still misssing files in some cases,
I'd prefer to track these per test case, instead of globally.

Therefore I propose to remove that exception for now.


Is it OK for trunk?


Thanks
Bernd.
From 9e0fc10b1c655320ccb63c1798141f4a572410f8 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Thu, 7 Jan 2021 09:37:32 +0100
Subject: [PATCH] testsuite: Fix test failures from outputs.exp [PR98225]

The .ld1_args file is not created when HAVE_GNU_LD is false.
The ltrans0.ltrans_arg file is not created when the make jobserver
is available, so remove the MAKEFLAGS variable.
There are no .cdtor.* files ever created with any of the tests,
so remove the exception for those files.

2021-01-07  Bernd Edlinger  

	PR testsuite/98225
	* gcc.misc-tests/outputs.exp: Unset MAKEFLAGS.
	Expect .ld1_args only when GNU LD is used.
	Remove exception for .cdtor.* files.
---
 gcc/testsuite/gcc.misc-tests/outputs.exp | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp b/gcc/testsuite/gcc.misc-tests/outputs.exp
index 80d4b61..05e5b1b2 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -50,6 +50,9 @@ if !$skip_lto {
 set ltop [check_linker_plugin_available]
 }
 
+# Check for GNU LD.  Some files like .ld1_args depend on this.
+set gld [check_effective_target_gld]
+
 # Prepare additional options to be used for linking.
 # We do not compile to an executable, because that requires naming an output.
 set link_options ""
@@ -67,6 +70,12 @@ if {[board_info $dest exists output_format]} {
 append link_options " additional_flags=-Wl,-oformat,[board_info $dest output_format]"
 }
 
+# Avoid possible influence from the make jobserver,
+# otherwise ltrans0.ltrans_args files may be missing.
+if [info exists env(MAKEFLAGS)] {
+unsetenv MAKEFLAGS
+}
+
 # For the test named TEST, run the compiler with SOURCES and OPTS, and
 # look in DIRS for OUTPUTS.  SOURCES is a list of suffixes for source
 # files starting with $b in $srcdir/$subdir, OPTS is a string with
@@ -130,6 +139,7 @@ proc outest { test sources opts dirs outputs } {
 	foreach og $olist {
 	if { [string index $og 0] == "!" } {
 		global gspd ltop
+		global gld
 		set cond [expr $og]
 		continue
 	}
@@ -179,11 +189,7 @@ proc outest { test sources opts dirs outputs } {
 set outb {}
 foreach f $outs {
 	file delete $f
-	# collect2 may create .cdtor* files in -save-temps link tests,
-	# ??? without regard to aux output naming conventions.
-	if ![string match "*.cdtor.*" $f] then {
-	lappend outb $f
-	}
+	lappend outb $f
 }
 foreach d $dirs {
 	file delete -force $d
@@ -285,10 +291,10 @@ outest "$b exe savetmp namedb" $sing "-o $b.exe -save-temps" {} {{--0.i --0.s --
 outest "$b exe savetmp named2" $mult "-o $b.exe -save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o .exe}}
 
 # Additional files are created when an @file is used
-outest "$b exe savetmp namedb" $sing "@/dev/null -o $b.exe -save-temps" {} {{--0.i --0.s --0.o .args.0 .ld1_args .exe}}
-outest "$b exe savetmp named2" $mult "@/dev/null -o $b.exe -save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o .args.0 .ld1_args .exe}}
-outest "$b exe savetmp named2" $mult "@/dev/null -I dummy -o $b.exe -save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 .ld1_args .exe}}
-outest "$b exe savetmp named2" $mult "@/dev/null -I dummy -L dummy -o $b.exe -save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 .args.3 .ld1_args .exe}}
+outes

[PATCH] Fix test failures from outputs.exp (PR testsuite/98225)

[Bernd Edlinger]

Hi,


this should fix the test failures in this test case.


Is it OK for trunk?


Thanks
Bernd.
From a8008af3db94a9dff7ae243ebfb40f45c54b3a81 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Thu, 7 Jan 2021 09:37:32 +0100
Subject: [PATCH] Fix test failures from outputs.exp

The .ld1_args file is not created when HAVE_GNU_LD is false.
The ltrans0.ltrans_arg file is not created when the make jobserver
is avaliable.

2021-01-07  Bernd Edlinger  

	PR testsuite/98225
	* gcc.misc-tests/outputs.exp: Fix test case.
---
 gcc/testsuite/gcc.misc-tests/outputs.exp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp b/gcc/testsuite/gcc.misc-tests/outputs.exp
index 80d4b61..495dbcd 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -67,6 +67,10 @@ if {[board_info $dest exists output_format]} {
 append link_options " additional_flags=-Wl,-oformat,[board_info $dest output_format]"
 }
 
+# Avoid possible influence from the make jobserver,
+# otherwise ltrans0.ltrans_args files may be missing.
+unsetenv MAKEFLAGS
+
 # For the test named TEST, run the compiler with SOURCES and OPTS, and
 # look in DIRS for OUTPUTS.  SOURCES is a list of suffixes for source
 # files starting with $b in $srcdir/$subdir, OPTS is a string with
@@ -163,6 +167,9 @@ proc outest { test sources opts dirs outputs } {
 		if { $ogl != {} } {
 		pass "$test: $d$o"
 		file delete $ogl
+		} elseif { [string match "*.ld1_args" $o] } {
+		# This file may be missing if !HAVE_GNU_LD
+		pass "$test: $d$o"
 		} else {
 		fail "$test: $d$o"
 		}
-- 
1.9.1

Re: [PATCH] Add line debug info for virtual thunks (PR ipa/97937)

[Bernd Edlinger]

On 1/6/21 12:49 PM, Eric Botcazou wrote:
>> currently there is a problem when debugging a virtual thunk.  That is
>> a decl with DECL_IGNORED_P.  Currently the line information displayed
>> in gdb is completely bogus, thus the last line of whatever function
>> is immediately before the PC of the thunk.
> 
> DECL_IGNORED_P means completely ignored for debug info purposes though and I 
> think that the Ada compiler expects this semantic.
> 
>> This patch improves the debug experience at least a bit by emitting
>> at the line number information where the thunk has been defined.
>> I do not dare to touch anything but dwarf2 debug info, therefore
>> the patch is a bit awkward.
> 
> Please run the GDB testsuite with Ada support on the patch.
> 

Yes, I always do that, and this patch did not affect any Ada tests.
Anyway, I guess this patch will need some rework, to probably attack
the DECL_IGNORED_P without line info.

One thing I remembered from previous testing, and I was not sure if
it is a correctness issue or not, is this:

As I had to call begin_function also for DECL_IGNORED_P,
I noticed that there are a number of Ada functions with
DECL_IGNORED_P, but their  crtl->has_bb_partition is set,
and therefore this block is executed with my patch, but
it is currently not executed:

See dwarf2out_begin_function:

  if (crtl->has_bb_partition && !cold_text_section)
{
  gcc_assert (current_function_decl == fun);
  cold_text_section = unlikely_text_section ();
  switch_to_section (cold_text_section);
  ASM_OUTPUT_LABEL (asm_out_file, cold_text_section_label);
  switch_to_section (sec);
}

I had expected that functions with DECL_IGNORED_P should not need
that side effect.  Anyway I had not seen any effect from this.


Bernd.

Re: [PATCH] Add line debug info for virtual thunks (PR ipa/97937)

[Bernd Edlinger]

On 1/4/21 10:45 PM, Jeff Law wrote:
> 
> 
> On 1/4/21 1:06 PM, Bernd Edlinger wrote:
>> --- a/gcc/final.c
>> +++ b/gcc/final.c
>> @@ -1735,7 +1735,12 @@ final_start_function_1 (rtx_insn **firstp, FILE 
>> *file, int *seen,
>>   last_filename);
>>  
>>if (!dwarf2_debug_info_emitted_p (current_function_decl))
>> -dwarf2out_begin_prologue (0, 0, NULL);
>> +{
>> +  if (write_symbols == DWARF2_DEBUG)
>> +dwarf2out_begin_prologue (last_linenum, last_columnnum, last_filename);
>> +  else
>> +dwarf2out_begin_prologue (0, 0, NULL);
>> +}
> The only way you're getting into this code is for DEBUG_DWARF2 and
> VMS_AND_DWARF2_DEBUG and in the latter case we want to make the same
> fix.  So drop the newly added conditional and just make the code
> something like this:
> 
> 
> if (!dwarf2_debug_info_emitted_p (current_function_decl))
> Â  dwarf2out_begin_prologue (last_linenum, last_columnnum, last_filename)
> 
> 

No, this is block is entered iff
 (write_symbols != DWARF2_DEBUG && write_symbols != VMS_AND_DWARF2_DEBUG)
  || DECL_IGNORED (current_function_decl))

so emitting .loc info here could easily break DBX, XCOFF, and VMS w/o DWARF
while I have no way to test anything for these debug formats.


Bernd.

Re: [PATCH] Add line debug info for virtual thunks (PR ipa/97937)

[Bernd Edlinger]

On 1/6/21 8:01 AM, Alexandre Oliva wrote:
> On Jan  5, 2021, Richard Biener  wrote:
> 
>> But isn't this a consumer issue then?  If there is no line info for
>> a PC range then gdb shouldn't display any.
> 
> No, there *is* line info there, carried over from an earlier .loc
> directive, as there isn't anything like ".noloc" to output with a
> function that is not expected or supposed to have line number info.
> 
> Without that, the assembler just extends the previous .loc directive
> onto the function.
> 

Theoretically we could exclude the range of the no-loc function
from the .debug_ranges, then gdb would not even step into the function.

However if we have at least a single line info as in the case of the thunks,
then that would be better than nothing (what this patch does).


Bernd.

Re: [PATCH] Restore input_location after recursive expand_call_inline

[Bernd Edlinger]

On 1/5/21 5:51 PM, Jeff Law wrote:
> 
> 
> On 1/5/21 1:05 AM, Richard Biener wrote:
>> On Tue, 5 Jan 2021, Bernd Edlinger wrote:
>>
>>>
>>> On 1/4/21 10:23 PM, Jeff Law wrote:
>>>>
>>>> On 1/4/21 1:12 PM, Bernd Edlinger wrote:
>>>>> Hi,
>>>>>
>>>>> I spotted a place where input_location is clobbered accidentally.
>>>>>
>>>>> That is in a recursive call to expand_call_inline.  The input_location
>>>>> is usually restored by goto egress in this function.
>>>>>
>>>>> Additionally the return value of the recursive expand call is thrown
>>>>> away, which does not look like a good idea.
>>>>>
>>>>> Although this causes no problems ATM, I wanted to fix it anyway.
>>>>>
>>>>>
>>>>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>>>>> Is it OK for trunk?
>>>>>
>>>>>
>>>>> Thanks
>>>>> Bernd.
>>>>>
>>>>> 0001-Restore-input_location-after-recursive-expand_call_i.patch
>>>>>
>>>>> From 88b963bba7b32972abf0ea44a01c03d643d7c6ca Mon Sep 17 00:00:00 2001
>>>>> From: Bernd Edlinger 
>>>>> Date: Mon, 4 Jan 2021 11:35:31 +0100
>>>>> Subject: [PATCH] Restore input_location after recursive expand_call_inline
>>>>>
>>>>> This is just a precautionary fix.
>>>>>
>>>>> 2021-01-04  Bernd Edlinger  
>>>>>
>>>>>   * tree-inline.c (expand_call_inline): Restore input_location.
>>>>>   Return result from recursive call.
>>>> I suspect that we're always supposed to inline in this case.  As
>>>> asserting that successfully_inlined is true before jumping to "egress"
>>>> seems wise.
>>>>
>>>> OK with that change after the usual testing.
>>>>
>>> No this does not work:
>>>
>>> +FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++98 (internal compiler error)
>>> +FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++98 (test for excess errors)
>>> +UNRESOLVED: g++.dg/ipa/devirt-5.C  -std=gnu++98 compilation failed to 
>>> produce executable
>>> +FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++14 (internal compiler error)
>>> +FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++14 (test for excess errors)
>>> +UNRESOLVED: g++.dg/ipa/devirt-5.C  -std=gnu++14 compilation failed to 
>>> produce executable
>>> +FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++17 (internal compiler error)
>>> +FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++17 (test for excess errors)
>>> +UNRESOLVED: g++.dg/ipa/devirt-5.C  -std=gnu++17 compilation failed to 
>>> produce executable
>>> +FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++2a (internal compiler error)
>>> +FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++2a (test for excess errors)
>>> +UNRESOLVED: g++.dg/ipa/devirt-5.C  -std=gnu++2a compilation failed to 
>>> produce executable
>>> +FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++98 (internal compiler error)
>>> +FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++98 (test for excess errors)
>>> +UNRESOLVED: g++.dg/ipa/devirt-c-4.C  -std=gnu++98 compilation failed to 
>>> produce executable
>>> +FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++14 (internal compiler error)
>>> +FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++14 (test for excess errors)
>>> +UNRESOLVED: g++.dg/ipa/devirt-c-4.C  -std=gnu++14 compilation failed to 
>>> produce executable
>>> +FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++17 (internal compiler error)
>>> +FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++17 (test for excess errors)
>>> +UNRESOLVED: g++.dg/ipa/devirt-c-4.C  -std=gnu++17 compilation failed to 
>>> produce executable
>>> +FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++2a (internal compiler error)
>>> +FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++2a (test for excess errors)
>>> +UNRESOLVED: g++.dg/ipa/devirt-c-4.C  -std=gnu++2a compilation failed to 
>>> produce executable
>>> +FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++98 (internal compiler error)
>>> +FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++98 (test for excess errors)
>>> +UNRESOLVED: g++.dg/ipa/imm-devirt-2.C  -std=gnu++98 compilation failed to 
>>> produce executable
>>> +FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++14 (internal compiler error)
>>> +FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++14 (test for excess errors)
>>> +UNRESOLVED: g++.dg/ip

Re: [PATCH] Restore input_location after recursive expand_call_inline

[Bernd Edlinger]

On 1/4/21 10:23 PM, Jeff Law wrote:
> 
> 
> On 1/4/21 1:12 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> I spotted a place where input_location is clobbered accidentally.
>>
>> That is in a recursive call to expand_call_inline.  The input_location
>> is usually restored by goto egress in this function.
>>
>> Additionally the return value of the recursive expand call is thrown
>> away, which does not look like a good idea.
>>
>> Although this causes no problems ATM, I wanted to fix it anyway.
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
>>
>>
>> Thanks
>> Bernd.
>>
>> 0001-Restore-input_location-after-recursive-expand_call_i.patch
>>
>> From 88b963bba7b32972abf0ea44a01c03d643d7c6ca Mon Sep 17 00:00:00 2001
>> From: Bernd Edlinger 
>> Date: Mon, 4 Jan 2021 11:35:31 +0100
>> Subject: [PATCH] Restore input_location after recursive expand_call_inline
>>
>> This is just a precautionary fix.
>>
>> 2021-01-04  Bernd Edlinger  
>>
>>  * tree-inline.c (expand_call_inline): Restore input_location.
>>  Return result from recursive call.
> I suspect that we're always supposed to inline in this case.  As
> asserting that successfully_inlined is true before jumping to "egress"
> seems wise.
> 
> OK with that change after the usual testing.
> 

No this does not work:

+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++98 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-5.C  -std=gnu++98 compilation failed to produce 
executable
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++14 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-5.C  -std=gnu++14 compilation failed to produce 
executable
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++17 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-5.C  -std=gnu++17 compilation failed to produce 
executable
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++2a (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-5.C  -std=gnu++2a compilation failed to produce 
executable
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++98 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-c-4.C  -std=gnu++98 compilation failed to 
produce executable
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++14 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-c-4.C  -std=gnu++14 compilation failed to 
produce executable
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++17 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-c-4.C  -std=gnu++17 compilation failed to 
produce executable
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++2a (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-c-4.C  -std=gnu++2a compilation failed to 
produce executable
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++98 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/imm-devirt-2.C  -std=gnu++98 compilation failed to 
produce executable
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++14 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/imm-devirt-2.C  -std=gnu++14 compilation failed to 
produce executable
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++17 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/imm-devirt-2.C  -std=gnu++17 compilation failed to 
produce executable
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++2a (test for excess errors)
+UNRESOLVED: g++.dg/ipa/imm-devirt-2.C  -std=gnu++2a compilation failed to 
produce executable
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++98 (test for excess errors)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++14 (test for excess errors)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++17 (test for excess errors)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++2a (test for excess errors)
+FAIL: g++.dg/ipa/pr79776.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/ipa/pr79776.C

[PATCH] Restore input_location after recursive expand_call_inline

[Bernd Edlinger]

Hi,

I spotted a place where input_location is clobbered accidentally.

That is in a recursive call to expand_call_inline.  The input_location
is usually restored by goto egress in this function.

Additionally the return value of the recursive expand call is thrown
away, which does not look like a good idea.

Although this causes no problems ATM, I wanted to fix it anyway.


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


Thanks
Bernd.
From 88b963bba7b32972abf0ea44a01c03d643d7c6ca Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Mon, 4 Jan 2021 11:35:31 +0100
Subject: [PATCH] Restore input_location after recursive expand_call_inline

This is just a precautionary fix.

2021-01-04  Bernd Edlinger  

	* tree-inline.c (expand_call_inline): Restore input_location.
	Return result from recursive call.
---
 gcc/tree-inline.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 360b85f..9f7d914 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -4840,9 +4840,9 @@ expand_call_inline (basic_block bb, gimple *stmt, copy_body_data *id,
   gimple_call_set_fndecl (stmt, edge->callee->decl);
   update_stmt (stmt);
   id->src_node->remove ();
-  expand_call_inline (bb, stmt, id, to_purge);
+  successfully_inlined = expand_call_inline (bb, stmt, id, to_purge);
   maybe_remove_unused_call_args (cfun, stmt);
-  return true;
+  goto egress;
 }
   fn = cg_edge->callee->decl;
   cg_edge->callee->get_untransformed_body ();
-- 
1.9.1

[PATCH] Add line debug info for virtual thunks (PR ipa/97937)

[Bernd Edlinger]

Hi,


currently there is a problem when debugging a virtual thunk.  That is
a decl with DECL_IGNORED_P.  Currently the line information displayed
in gdb is completely bogus, thus the last line of whatever function
is immediately before the PC of the thunk.

This patch improves the debug experience at least a bit by emitting
at the line number information where the thunk has been defined.
I do not dare to touch anything but dwarf2 debug info, therefore
the patch is a bit awkward.


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


Thanks
Bernd.
From 0a44bb870e90623689cae484f8a8899706480876 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Sun, 3 Jan 2021 11:18:39 +0100
Subject: [PATCH] Add line debug info for virtual thunks

There is no full debug info since the DECL_IGNORED_P
flag is set on virtual thunks.
But instead of no line info at all, emit at least
the location of the function decl.

2021-01-03  Bernd Edlinger  

	PR ipa/97937
	* final.c (final_start_function_1): Always emit function start line
	information for dwarf2 debug.
	(final_end_function): Always call end_function for dwarf2 debug.
	* varasm.c (assemble_start_function): Always call begin_function
	for dwarf2 debug.
---
 gcc/final.c  | 9 +++--
 gcc/varasm.c | 2 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/gcc/final.c b/gcc/final.c
index fc9a05e..5a274c1 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -1735,7 +1735,12 @@ final_start_function_1 (rtx_insn **firstp, FILE *file, int *seen,
  last_filename);
 
   if (!dwarf2_debug_info_emitted_p (current_function_decl))
-dwarf2out_begin_prologue (0, 0, NULL);
+{
+  if (write_symbols == DWARF2_DEBUG)
+	dwarf2out_begin_prologue (last_linenum, last_columnnum, last_filename);
+  else
+	dwarf2out_begin_prologue (0, 0, NULL);
+}
 
 #ifdef LEAF_REG_REMAP
   if (crtl->uses_only_leaf_regs)
@@ -1879,7 +1884,7 @@ final_end_function (void)
 {
   app_disable ();
 
-  if (!DECL_IGNORED_P (current_function_decl))
+  if (!DECL_IGNORED_P (current_function_decl) || write_symbols == DWARF2_DEBUG)
 debug_hooks->end_function (high_function_linenum);
 
   /* Finally, output the function epilogue:
diff --git a/gcc/varasm.c b/gcc/varasm.c
index ce5d449..513922d 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -1930,7 +1930,7 @@ assemble_start_function (tree decl, const char *fnname)
   ASM_OUTPUT_FUNCTION_PREFIX (asm_out_file, fnname);
 #endif
 
-  if (!DECL_IGNORED_P (decl))
+  if (!DECL_IGNORED_P (decl) || write_symbols == DWARF2_DEBUG)
 (*debug_hooks->begin_function) (decl);
 
   /* Make function name accessible from other files, if appropriate.  */
-- 
1.9.1

[PING] [PATCH] Fix -save-temp leaking lto files in /tmp

[Bernd Edlinger]

Hi,

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

Thanks
Bernd.

On 12/14/20 4:31 PM, Bernd Edlinger wrote:
> Hi,
> 
> On 2/21/20 8:35 AM, Richard Biener wrote:
>>
>> IIRC this definitely clashes with Alex work to overhaul
>> -auxdir/-dumpdir queued for GCC 11 where some of the above
>> is improved.
>>
>> So whatever we do we should do it for GCC 11 after Alex patches
>> land.
>>
>> Richard.
>>
> 
> Okay, I think this patch was applied in the mean time.
> Just some 20-30 temp files are left from a full run of the testsuite.
> 
> So I rewrote my patch, and found this time it looks
> feasible to avoid all remaining temp files with unpredictable
> random names, so that is an improvement over the state earlier
> this year.
> 
> 
> Attached is my new patch, to clean up the rest of the -save-temps
> files.  That consist just of a couple of @file parameters.
> 
> I added a few test cases, and the testsuite runs without any
> temp files leaking.
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 

Re: [PATCH] Fix -save-temp leaking lto files in /tmp

[Bernd Edlinger]

Hi,

On 2/21/20 8:35 AM, Richard Biener wrote:
> 
> IIRC this definitely clashes with Alex work to overhaul
> -auxdir/-dumpdir queued for GCC 11 where some of the above
> is improved.
> 
> So whatever we do we should do it for GCC 11 after Alex patches
> land.
> 
> Richard.
> 

Okay, I think this patch was applied in the mean time.
Just some 20-30 temp files are left from a full run of the testsuite.

So I rewrote my patch, and found this time it looks
feasible to avoid all remaining temp files with unpredictable
random names, so that is an improvement over the state earlier
this year.


Attached is my new patch, to clean up the rest of the -save-temps
files.  That consist just of a couple of @file parameters.

I added a few test cases, and the testsuite runs without any
temp files leaking.

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


Thanks
Bernd.
From 5e07f814f102d6dabebcb6652a40f5a1b9716479 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Sun, 13 Dec 2020 08:24:57 +0100
Subject: [PATCH] Fix -save-temp leaking lto files in /tmp

When linking with -flto and -save-temps, various
temporary files are created in /tmp.
The same happens when invoking the driver with @file
parameter, and using -L or -I options.

2020-12-12  Bernd Edlinger  

	* collect-utils.c (collect_execute): Check dumppfx.
	* collect2.c (maybe_run_lto_and_relink, do_link): Pass atsuffix
	to collect_execute.
	(do_link): Add new parameter atsuffix.
	(main): Handle -dumpdir option.  Skip one argument for
	-o, -isystem and -B options.
	* gcc.c (make_at_file): New helper function.
	(close_at_file): Use it.

gcc/testsuite:
2020-12-12  Bernd Edlinger  

	* gcc.misc-tests/outputs.exp: Adjust testcase.
---
 gcc/collect-utils.c  |  2 +-
 gcc/collect2.c   | 43 
 gcc/gcc.c| 28 -
 gcc/testsuite/gcc.misc-tests/outputs.exp | 31 ++-
 4 files changed, 74 insertions(+), 30 deletions(-)

diff --git a/gcc/collect-utils.c b/gcc/collect-utils.c
index 095db8d..921bb34 100644
--- a/gcc/collect-utils.c
+++ b/gcc/collect-utils.c
@@ -127,7 +127,7 @@ collect_execute (const char *prog, char **argv, const char *outname,
   /* Note: we assume argv contains at least one element; this is
  checked above.  */
 
-  if (!save_temps || !atsuffix)
+  if (!save_temps || !atsuffix || !dumppfx)
 	response_file = make_temp_file ("");
   else
 	response_file = concat (dumppfx, atsuffix, NULL);
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 3a43a5a..3f097f9 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -644,7 +644,7 @@ maybe_run_lto_and_relink (char **lto_ld_argv, char **object_lst,
 
   /* Run the LTO back end.  */
   pex = collect_execute (prog, lto_c_argv, NULL, NULL, PEX_SEARCH,
-			 at_file_supplied, NULL);
+			 at_file_supplied, "lto_args");
   {
 	int c;
 	FILE *stream;
@@ -728,7 +728,7 @@ maybe_run_lto_and_relink (char **lto_ld_argv, char **object_lst,
   /* Run the linker again, this time replacing the object files
  optimized by the LTO with the temporary file generated by the LTO.  */
   fork_execute ("ld", out_lto_ld_argv, HAVE_GNU_LD && at_file_supplied,
-		NULL);
+		"ld_args");
   /* We assume that temp files were created, and therefore we need to take
  that into account (maybe run dsymutil).  */
   post_ld_pass (/*temp_file*/true);
@@ -740,7 +740,8 @@ maybe_run_lto_and_relink (char **lto_ld_argv, char **object_lst,
 {
   /* Our caller is relying on us to do the link
  even though there is no LTO back end work to be done.  */
-  fork_execute ("ld", lto_ld_argv, HAVE_GNU_LD && at_file_supplied, NULL);
+  fork_execute ("ld", lto_ld_argv, HAVE_GNU_LD && at_file_supplied,
+		"ld_args");
   /* No LTO objects were found, so no new temp file.  */
   post_ld_pass (/*temp_file*/false);
 }
@@ -751,13 +752,13 @@ maybe_run_lto_and_relink (char **lto_ld_argv, char **object_lst,
LD_ARGV is an array of arguments for the linker.  */
 
 static void
-do_link (char **ld_argv)
+do_link (char **ld_argv, const char *atsuffix)
 {
   struct pex_obj *pex;
   const char *prog = "ld";
   pex = collect_execute (prog, ld_argv, NULL, NULL,
 			 PEX_LAST | PEX_SEARCH,
-			 HAVE_GNU_LD && at_file_supplied, NULL);
+			 HAVE_GNU_LD && at_file_supplied, atsuffix);
   int ret = collect_wait (prog, pex);
   if (ret)
 {
@@ -973,10 +974,10 @@ main (int argc, char **argv)
 	  {
 	/* Parse the output filename if it's given so that we can make
 	   meaningful temp filenames.  */
-	if (argv[i][2] == '\0')
-	  output_file = argv[i+1];
-	else
+	if (argv[i][2] != '\0')
 	  output_file = [i][2];
+	else if (argv[i+1] !

Re: [PATCH] Remove misleading debug line entries

[Bernd Edlinger]

On 12/8/20 7:57 PM, Bernd Edlinger wrote:
> On 12/8/20 11:35 AM, Richard Biener wrote:
>>
>> + {
>> +   /* Remove a nonbind marker when the outer scope of the
>> +  inline function is completely removed.  */
>> +   if (gimple_debug_nonbind_marker_p (stmt)
>> +   && BLOCK_ABSTRACT_ORIGIN (b))
>> + {
>> +   while (TREE_CODE (b) == BLOCK
>> +  && !inlined_function_outer_scope_p (b))
>> + b = BLOCK_SUPERCONTEXT (b);
>>
>> So given we never remove a inlined_function_outer_scope_p BLOCK from
>> the block tree can we assert that we find such a BLOCK?  If we never
>> elide those BLOCKs how can it happen that we elide it in the end?

We can remove inlined function outer scope when they have no subblocks
any more, or only unused subblocks, and there is an exception from the
rule when no debug info is generated, that is due to this:

>else if (!flag_auto_profile && debug_info_level == DINFO_LEVEL_NONE
> && !optinfo_wants_inlining_info_p ())
>  {
>/* Even for -g0 don't prune outer scopes from artificial
>   functions, otherwise diagnostics using tree_nonartificial_location
>   will not be emitted properly.  */
>if (inlined_function_outer_scope_p (scope))
>  {
>tree ao = BLOCK_ORIGIN (scope);
>if (ao
>&& TREE_CODE (ao) == FUNCTION_DECL
>&& DECL_DECLARED_INLINE_P (ao)
>&& lookup_attribute ("artificial", DECL_ATTRIBUTES (ao)))
>  unused = false;
>  }
>  }
> 

I instrumented the remove_unused_scope_block_p now as follows,
to better understand what happens here:

diff --git a/gcc/tree-ssa-live.c b/gcc/tree-ssa-live.c
index 9ea24a1..3dd859c 100644
--- a/gcc/tree-ssa-live.c
+++ b/gcc/tree-ssa-live.c
@@ -525,9 +525,15 @@ remove_unused_scope_block_p (tree scope, bool 
in_ctor_dtor_block)
*t = BLOCK_SUBBLOCKS (*t);
while (BLOCK_CHAIN (*t))
  {
+   gcc_assert (TREE_USED (*t));
+   if (debug_info_level != DINFO_LEVEL_NONE)
+ gcc_assert (!inlined_function_outer_scope_p 
(BLOCK_SUPERCONTEXT (*t)));
BLOCK_SUPERCONTEXT (*t) = supercontext;
t = _CHAIN (*t);
  }
+   gcc_assert (TREE_USED (*t));
+   if (debug_info_level != DINFO_LEVEL_NONE)
+ gcc_assert (!inlined_function_outer_scope_p (BLOCK_SUPERCONTEXT 
(*t)));
BLOCK_CHAIN (*t) = next;
BLOCK_SUPERCONTEXT (*t) = supercontext;
t = _CHAIN (*t);

This survives a bootstrap, but I consider that just as an experiment...

This means that the BLOCK_SUPERCONTEXT pointers never skip
an inlined_function_outer_scope_p, *except* when no debug info is
generated, but then it is fine, as there are either no debug_nonbind_marker_p,
or it would not matter, if an outer scope is missed.

After the above loop runs, the BLOCK_SUBBLOCKS->BLOCK_CHAIN have only
Blocks with TREE_USED
Blocks with !TREE_USED are removed from the SUBBLOCKS->CHAIN list, but
have still a valid BLOCK_SUPERCONTEXT. However BLOCK_CHAIN and BLOCK_SUBBLOCKS
are not used any more, and could theoretically misused for something, but
fortunately that is not necessary.

I think that result suggests that the proposed patch does the right thing,
already as-is.


Do you agree?


Thanks
Bernd.

Re: [PATCH] Remove misleading debug line entries

[Bernd Edlinger]

On 12/8/20 11:35 AM, Richard Biener wrote:
> 
> + {
> +   /* Remove a nonbind marker when the outer scope of the
> +  inline function is completely removed.  */
> +   if (gimple_debug_nonbind_marker_p (stmt)
> +   && BLOCK_ABSTRACT_ORIGIN (b))
> + {
> +   while (TREE_CODE (b) == BLOCK
> +  && !inlined_function_outer_scope_p (b))
> + b = BLOCK_SUPERCONTEXT (b);
> 
> So given we never remove a inlined_function_outer_scope_p BLOCK from
> the block tree can we assert that we find such a BLOCK?  If we never
> elide those BLOCKs how can it happen that we elide it in the end?
> 
> +   if (TREE_CODE (b) == BLOCK)
> + {
> +   if (TREE_USED (b))
> 

For gimple_debug_inline_entry_p inlined_function_outer_scope_p (b)
is always true, and the code always proceeds to gsi_remove the
gimple_debug_inline_entry_p.

But for gimple_debug_begin_stmt_p all paths are actually taken.

> Iff we ever elide such block then this will still never be
> false since we've otherwise removed the BLOCK from the block

I can assure you TREE_USED (b) can be false here.

> tree already when we arrive here.  Iff we did that, then the
> above search for a inlined_function_outer_scope_p BLOCK
> might find the "wrong" inline instance.
> 

Indeed, that is a good question.

I tried to find out if there are constraints that are
preserved by remove_unused_scope_block_p, that can be
used to prove that the BLOCK_SUPERCONTEXT walking loop
does not fine the "wrong" inline instance.

diff --git a/gcc/tree-ssa-live.c b/gcc/tree-ssa-live.c
index 9ea24a1..997ccee 100644
--- a/gcc/tree-ssa-live.c
+++ b/gcc/tree-ssa-live.c
@@ -525,6 +525,10 @@ remove_unused_scope_block_p (tree scope, bool 
in_ctor_dtor_block)
*t = BLOCK_SUBBLOCKS (*t);
while (BLOCK_CHAIN (*t))
  {
+   gcc_assert (supercontext == BLOCK_SUPERCONTEXT 
(BLOCK_SUPERCONTEXT (*t)));
+   if (!TREE_USED (*t))
+ gcc_assert (!inlined_function_outer_scope_p 
(BLOCK_SUPERCONTEXT (*t)));
+   gcc_assert (!TREE_USED (BLOCK_SUPERCONTEXT (*t)));
BLOCK_SUPERCONTEXT (*t) = supercontext;
t = _CHAIN (*t);
  }


So I think I can prove that the above assertions hold,
at least when this block is not taken:

   else if (!flag_auto_profile && debug_info_level == DINFO_LEVEL_NONE
&& !optinfo_wants_inlining_info_p ())
 {
   /* Even for -g0 don't prune outer scopes from artificial
  functions, otherwise diagnostics using tree_nonartificial_location
  will not be emitted properly.  */
   if (inlined_function_outer_scope_p (scope))
 {
   tree ao = BLOCK_ORIGIN (scope);
   if (ao
   && TREE_CODE (ao) == FUNCTION_DECL
   && DECL_DECLARED_INLINE_P (ao)
   && lookup_attribute ("artificial", DECL_ATTRIBUTES (ao)))
 unused = false;
 }
 }

in that case it should be irrelevant, since we wont have debug_begin_stmt_p
if debug_info_level == DINFO_LEVEL_NONE.

So the above assertions mean, that *if* !TREE_USED (b)
which is the precondition for the while loop, then we know that
BLOCK_SUPERCONTEXT (b) *was* not a inlined_function_outer_scope_p,
and it was replaced by BLOCK_SUPERCONTEXT (BLOCKL_SUPERCONTEXT (b))
so the loop skips one step, but the result is still the same
inline block.

However what concerns me, is that the assertion
if (TREE_USED (*t))
   gcc_assert (!inlined_function_outer_scope_p (BLOCK_SUPERCONTEXT (*t))
does not hold.  I think that means, that it can happen, that
a USED block is moved out of the inline block.  And while I have
no test case for it, that sheds a big question on the correctness
of the debug info when that happens.

But I think that is a different issue if I at all.


> So I think we only eliminate the inline scopes if all
> subblocks are unused but then if there's a used outer
> inline instance your patch will assign that outer inline
> instances BLOCK to debug stmts formerly belonging to the
> elided inline instance, no?  (we also mess with
> BLOCK_SUPERCONTEXT during BLOCK removal so I'm not sure
> the walking works as expected)
> 

I did not look at before, and just expected it to behave
reasonably, that is just elide *unused* lexical scopes, and
*empty* subroutines, but that it seems to move *used* lexical
scopes to the grandfather scope, while *removing* the now
*emptied* original inline block is odd.

Or maybe I missed something...


> I guess we could, during the remove_unused_scope_block_p
> DFS walk, record and pass down the "current"
> inlined_function_outer_scope_p BLOCK and for BLOCKs
> we elide record that somehow?  (since we elide the block
> we could abuse fragment_origin/chain for this)
> Then in the patched loop do
> 

I would rather not move *used* blocks out of an inline scope,
whether 

Re: [PATCH] Remove misleading debug line entries

[Bernd Edlinger]

On 12/7/20 11:50 AM, Richard Biener wrote:
> The ipa-param-manipulation.c hunk is OK, please commit separately.
> 

done.

> The tree-inline.c and cfgexpand.c changes are OK as well, for the
> tree-ssa-live.c change see below
> 
> 
> From 85b0e37d0c0d3ecac4908ebbfd67edc612ef22b2 Mon Sep 17 00:00:00 2001
> From: Bernd Edlinger 
> Date: Wed, 2 Dec 2020 12:32:02 +0100
> Subject: [PATCH] Remove misleading debug line entries
> 
> This removes gimple_debug_begin_stmts without block info which remain
> after a gimple block originating from an inline function is unused.
> 
> The line numbers from these stmts are from the inline function,
> but since the inline function is completely optimized away,
> there will be no DW_TAG_inlined_subroutine so the debugger has
> no callstack available at this point, and therefore those
> line table entries are not helpful to the user.
> 
> 2020-12-02  Bernd Edlinger  
> 
>   * cfgexpand.c (expand_gimple_basic_block): Remove special handling
>   of debug_inline_entries without block info.
>   * ipa-param-manipulation.c
>   (ipa_param_body_adjustments::modify_call_stmt): Set location info.
>   * tree-inline.c (remap_gimple_stmt): Drop debug_nonbind_markers when
>   the call statement has no block info.
>   (copy_debug_stmt): Remove debug_nonbind_markers when inlining
>   and the block info is mapped to NULL.
>   * tree-ssa-live.c (clear_unused_block_pointer): Remove
>   debug_nonbind_markers originating from inlined functions.
> ---
>  gcc/cfgexpand.c  |  9 +
>  gcc/ipa-param-manipulation.c |  2 ++
>  gcc/tree-inline.c| 14 ++
>  gcc/tree-ssa-live.c  | 22 --
>  4 files changed, 33 insertions(+), 14 deletions(-)
> 
> diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> index 7e0bdd58e85..df7b62080b6 100644
> --- a/gcc/cfgexpand.c
> +++ b/gcc/cfgexpand.c
> @@ -5953,14 +5953,7 @@ expand_gimple_basic_block (basic_block bb, bool 
> disable_tail_calls)
> else if (gimple_debug_begin_stmt_p (stmt))
>   val = GEN_RTX_DEBUG_MARKER_BEGIN_STMT_PAT ();
> else if (gimple_debug_inline_entry_p (stmt))
> - {
> -   tree block = gimple_block (stmt);
> -
> -   if (block)
> - val = GEN_RTX_DEBUG_MARKER_INLINE_ENTRY_PAT ();
> -   else
> - goto delink_debug_stmt;
> - }
> + val = GEN_RTX_DEBUG_MARKER_INLINE_ENTRY_PAT ();
> else
>   gcc_unreachable ();
>  
> diff --git a/gcc/ipa-param-manipulation.c b/gcc/ipa-param-manipulation.c
> index 2bbea21be2e..9ab4a10096d 100644
> --- a/gcc/ipa-param-manipulation.c
> +++ b/gcc/ipa-param-manipulation.c
> @@ -1681,6 +1681,8 @@ ipa_param_body_adjustments::modify_call_stmt (gcall 
> **stmt_p)
>   }
>   }
>gcall *new_stmt = gimple_build_call_vec (gimple_call_fn (stmt), vargs);
> +  if (gimple_has_location (stmt))
> + gimple_set_location (new_stmt, gimple_location (stmt));
>gimple_call_set_chain (new_stmt, gimple_call_chain (stmt));
>gimple_call_copy_flags (new_stmt, stmt);
>if (tree lhs = gimple_call_lhs (stmt))
> diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
> index d9814bd10d3..360b85f14dc 100644
> --- a/gcc/tree-inline.c
> +++ b/gcc/tree-inline.c
> @@ -1819,12 +1819,11 @@ remap_gimple_stmt (gimple *stmt, copy_body_data *id)
> /* If the inlined function has too many debug markers,
>don't copy them.  */
> if (id->src_cfun->debug_marker_count
> -   > param_max_debug_marker_count)
> +   > param_max_debug_marker_count
> +   || id->reset_location)
>   return stmts;
>  
> gdebug *copy = as_a  (gimple_copy (stmt));
> -   if (id->reset_location)
> - gimple_set_location (copy, input_location);
> id->debug_stmts.safe_push (copy);
> gimple_seq_add_stmt (, copy);
> return stmts;
> @@ -3169,7 +3168,14 @@ copy_debug_stmt (gdebug *stmt, copy_body_data *id)
>  }
>  
>if (gimple_debug_nonbind_marker_p (stmt))
> -return;
> +{
> +  if (id->call_stmt && !gimple_block (stmt))
> + {
> +   gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
> +   gsi_remove (, true);
> + }
> +  return;
> +}
>  
>/* Remap all the operands in COPY.  */
>memset (, 0, sizeof (wi));
> diff --git a/gcc/tree-ssa-live.c b/gcc/tree-ssa-live.c
> index 21a9ee43e6b..acba4a58626 100644
> --- a/gcc/tree-ssa-live.c
> +++ b/gcc/tree-ssa-live.c
> @@ -623,13 +623,31 @@ clear_u

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

[Bernd Edlinger]

On 12/7/20 4:04 PM, Jason Merrill wrote:
> On 12/5/20 7:37 AM, Bernd Edlinger wrote:
>> On 12/2/20 7:57 PM, Jason Merrill wrote:
>>> On 12/1/20 1:28 PM, Bernd Edlinger wrote:>>>> +  tree type = 
>>> targetm.cxx.guard_mask_bit ()
>>>> +  ? TREE_TYPE (guard) : char_type_node;
>>>> +
>>>> +  if (is_atomic_expensive_p (TYPE_MODE (type)))
>>>> +    guard = integer_zero_node;
>>>> +  else
>>>> +    guard = build_atomic_load_type (guard, MEMMODEL_ACQUIRE, type);
>>>
>>> It should still work to load a single byte, it just needs to be the 
>>> least-significant byte.
> 
> I still don't think you need to load the whole word to check the guard bit.
> 

Of course that is also possible.  But I would not expect an
address offset and a byte access to be cheaper than a word access.

I just saw that get_guard_bits does the same thing:
access the first byte if !targetm.cxx.guard_mask_bit ()
and access the whole word otherwise, which is only
there for ARM EABI.

>> And this isn't an EABI issue; it looks like the non-EABI code is also broken 
>> for big-endian targets, both the atomic load and the normal load in 
>> get_guard_bits.
>>>
>>
>> I think the non-EABI code is always using bit 0 in the first byte,
>> by using the endian-neutral #define _GLIBCXX_GUARD_BIT __guard_test_bit (0, 
>> 1).
> 
> Except that set_guard sets the least-significant bit on all targets.
> 

Hmm, as I said, get_guard_bits gets the guard as a word if 
!targetm.cxx.guard_mask_bit (),
and as the first byte otherwise.  Of course it could get the third byte,
if !targetm.cxx.guard_mask_bit () && BYTES_BIG_ENDIAN, but it would be more 
complicated
this way, wouldn't it?


Bernd.

>> Only ARM EABI uses bit 0 in byte 3 if big-endian and bit 0 in byte 0 
>> otherwise.
>>
>> For all other targets when _GLIBCXX_USE_FUTEX is defined,
>> __cxa_guard_XXX accesses the value as int* while the memory
>> is a 64-bit long, so I could imagine that is an aliasing violation.
>>
>>
>> But nothing that needs to be fixed immediately.
> 
> Agreed.
> 
>> Attached is the corrected patch.
>>
>> Tested again on arm-none-eabi with arm-sim.
>> Is it OK for trunk?
>>
>> Thanks
>> Bernd.
>>
>>> Jason
>>>
> 

[COMMITTED] Fix location info in ipa_param_body_adjustments::modify_call_stmt

[Bernd Edlinger]

On 12/7/20 11:50 AM, Richard Biener wrote:
> 
> The ipa-param-manipulation.c hunk is OK, please commit separately.
> 

Okay, this is the part I just committed.

commit 92e563d91b012f09da8fd152e934f6b964ae49cb
Author: Bernd Edlinger 
Date:   Mon Dec 7 16:00:00 2020 +0100

Fix location info in ipa_param_body_adjustments::modify_call_stmt

Copy the location info from the passed in call stmt
to the newly built gimple call stmt.

2020-12-07  Bernd Edlinger  

* ipa-param-manipulation.c
(ipa_param_body_adjustments::modify_call_stmt): Set location info.

diff --git a/gcc/ipa-param-manipulation.c b/gcc/ipa-param-manipulation.c
index 2bbea21..9ab4a10 100644
--- a/gcc/ipa-param-manipulation.c
+++ b/gcc/ipa-param-manipulation.c
@@ -1681,6 +1681,8 @@ ipa_param_body_adjustments::modify_call_stmt (gcall 
**stmt_p)
}
}
   gcall *new_stmt = gimple_build_call_vec (gimple_call_fn (stmt), vargs);
+  if (gimple_has_location (stmt))
+   gimple_set_location (new_stmt, gimple_location (stmt));
   gimple_call_set_chain (new_stmt, gimple_call_chain (stmt));
   gimple_call_copy_flags (new_stmt, stmt);
   if (tree lhs = gimple_call_lhs (stmt))

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

[Bernd Edlinger]

On 12/2/20 7:57 PM, Jason Merrill wrote:
> On 12/1/20 1:28 PM, Bernd Edlinger wrote:
>> On 11/24/20 11:10 PM, Jason Merrill wrote:
>>> On 11/22/20 3:05 AM, Bernd Edlinger wrote:
>>>> Hi,
>>>>
>>>> this avoids the need to use -fno-threadsafe-statics on
>>>> arm-none-eabi or working around that problem by supplying
>>>> a dummy __sync_synchronize function which might
>>>> just lead to silent code failure of the worst kind
>>>> (non-reproducable, racy) at runtime, as was pointed out
>>>> on previous discussions here.
>>>>
>>>> When the atomic access involves a call to __sync_synchronize
>>>> it is better to call __cxa_guard_acquire unconditionally,
>>>> since it handles the atomics too, or is a non-threaded
>>>> implementation when there is no gthread support for this target.
>>>>
>>>> This fixes also a bug for the ARM EABI big-endian target,
>>>> that is, previously the wrong bit was checked.
>>>
>>> Instead of a new target macro, can't you follow 
>>> fold_builtin_atomic_always_lock_free/can_atomic_load_p?
>>
>> Yes, thanks, that should work too.
>> Would you like this better?
> 
>> +is_atomic_expensive_p (machine_mode mode)
>> +{
>> +  if (!flag_inline_atomics)
>> +    return false;
> 
> Why not true?
> 

Ooops...
Yes, I ought to return true here.
I must have made a mistake when I tested the last version of this patch,
sorry for the confusion.

>> +  if (!can_compare_and_swap_p (mode, false) || !can_atomic_load_p (mode))
>> +    return false;
> 
> This also seems backwards; I'd think we want to return false if either of 
> those tests are true.  Or maybe just can_atomic_load_p, and not bother about 
> compare-and-swap.
> 


Yes, you are right.
Unfortuately can_atomic_load_p is too weak, since it does not cover
the memory barrier.

And can_compare_and_swap_p (..., false) is actually a bit too strong,
but if it returns true, we should be able to use any atomic without
need for a library call.

>> +  tree type = targetm.cxx.guard_mask_bit ()
>> +  ? TREE_TYPE (guard) : char_type_node;
>> +
>> +  if (is_atomic_expensive_p (TYPE_MODE (type)))
>> +    guard = integer_zero_node;
>> +  else
>> +    guard = build_atomic_load_type (guard, MEMMODEL_ACQUIRE, type);
> 
> It should still work to load a single byte, it just needs to be the 
> least-significant byte.  And this isn't an EABI issue; it looks like the 
> non-EABI code is also broken for big-endian targets, both the atomic load and 
> the normal load in get_guard_bits.
> 

I think the non-EABI code is always using bit 0 in the first byte,
by using the endian-neutral #define _GLIBCXX_GUARD_BIT __guard_test_bit (0, 1).

Only ARM EABI uses bit 0 in byte 3 if big-endian and bit 0 in byte 0 otherwise.

For all other targets when _GLIBCXX_USE_FUTEX is defined,
__cxa_guard_XXX accesses the value as int* while the memory
is a 64-bit long, so I could imagine that is an aliasing violation.


But nothing that needs to be fixed immediately.


Attached is the corrected patch.

Tested again on arm-none-eabi with arm-sim.
Is it OK for trunk?

Thanks
Bernd.

> Jason
> 
From c1a6dcaa906113cba0dc88e36460a65aba35ec38 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Tue, 1 Dec 2020 18:54:48 +0100
Subject: [PATCH] Avoid atomic for guard acquire when that is expensive

When the atomic access involves a call to __sync_synchronize
it is better to call __cxa_guard_acquire unconditionally,
since it handles the atomics too, or is a non-threaded
implementation when there is no gthread support for this target.

This fixes also a bug for the ARM EABI big-endian target,
that is, previously the wrong bit was checked.

2020-11-22  Bernd Edlinger  

	* decl2.c: (is_atomic_expensive_p): New helper function.
	(build_atomic_load_byte): Rename to...
	(build_atomic_load_type): ... and add new parameter type.
	(get_guard_cond): Skip the atomic here if that is expensive.
	Use the correct type for the atomic load on certain targets.
---
 gcc/cp/decl2.c | 33 +
 1 file changed, 29 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 1bc7b7e..c7ddcc9 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -48,6 +48,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "intl.h"
 #include "c-family/c-ada-spec.h"
 #include "asan.h"
+#include "optabs-query.h"
 
 /* Id for dumping the raw trees.  */
 int raw_dump_id;
@@ -3297,18 +3298,34 @@ get_guard (tree decl)
   return guard;
 }
 
+/* Returns true if accessing the GUARD atomic is expensive,
+   i.e. involves a call to __sync_synchronize 

Re: [PATCH] Remove misleading debug line entries

[Bernd Edlinger]

On 12/3/20 9:30 AM, Richard Biener wrote:
> On Wed, 2 Dec 2020, Bernd Edlinger wrote:
> 
>> On 12/2/20 8:50 AM, Richard Biener wrote:
>>> On Tue, 1 Dec 2020, Bernd Edlinger wrote:
>>>
>>>> Hi!
>>>>
>>>>
>>>> This removes gimple_debug stmts without block info after a
>>>> NULL INLINE_ENTRY.
>>>>
>>>> The line numbers from these stmts are from the inline function,
>>>> but since the inline function is completely optimized away,
>>>> there will be no DW_TAG_inlined_subroutine so the debugger has
>>>> no callstack available at this point, and therefore those
>>>> line table entries are not helpful to the user.
>>>>
>>>> 2020-11-20  Bernd Edlinger  
>>>>
>>>>* cfgexpand.c (expand_gimple_basic_block): Remove debug_begin_stmts
>>>>following a removed debug_inline_entry.
>>>>
>>>>
>>>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>>>> Is it OK for trunk?
>>>
>>> So are those visited by clear_unused_block_pointer?  If so wouldn't
>>> it be more appropriate to remove those there, when we elide the
>>> inlined block scope?
>>>
>>
>> That's what I thought initially, but that is only true for 99% of the 
>> inline statements.  However 1% of the inline_entries without block info,
>> and debug_begin_stmts without block info, that have line numbers from
>> an inline header, do actually originate here:
>>
>> copy_debug_stmt (gdebug *stmt, copy_body_data *id)
>> {
>>   tree t, *n;
>>   struct walk_stmt_info wi;
>>
>>   if (tree block = gimple_block (stmt))
>> {
>>   n = id->decl_map->get (block);
>>   gimple_set_block (stmt, n ? *n : id->block);
>> }
>>
>> because id->block is NULL, and decl_map does not have
>> an entry.
>>
>> So I tracked it down why that happens.
>>
>> I think remap_gimple_stmt should just drop those nonbind markers
>> on the floor when the call statement has no block information.
>>
>> Once that is fixed, the special handling of inline entries without
>> block info can as well be moved from remap_gimple_stmt to
>> clear_unused_block_pointer.
>>
>> What do you think of this (not yet fully tested) patch?
>>
>> Is it OK when bootstrap and reg-testing passes?
> 
> diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
> index d9814bd..e87c653 100644
> --- a/gcc/tree-inline.c
> +++ b/gcc/tree-inline.c
> @@ -1819,7 +1819,8 @@ remap_gimple_stmt (gimple *stmt, copy_body_data *id)
>   /* If the inlined function has too many debug markers,
>  don't copy them.  */
>   if (id->src_cfun->debug_marker_count
> - > param_max_debug_marker_count)
> + > param_max_debug_marker_count
> + || !id->block)
> return stmts;
> 
> Isn't this overly pessimistic in throwing away all debug markers
> of an inline rather than just those which are associated with
> the outermost scope (that's mapped to NULL if !id->block)?  Can
> we instead remap the block here (move it from copy_debug_stmt)
> and elide the copy only when it maps to NULL?
> 

Yes, indeed, I missed the fact that this is also called up from
tree_function_versioning.  id->block is always NULL in that case.
But since this should be a 1:1 copy, missing block info should not
get worse as it already is.  Fortunately it is possible to distinguish
that from the actual inlining by looking at id->call_stmt.


> 
>   gdebug *copy = as_a  (gimple_copy (stmt));
> diff --git a/gcc/tree-ssa-live.c b/gcc/tree-ssa-live.c
> index 21a9ee4..ca119c6 100644
> --- a/gcc/tree-ssa-live.c
> +++ b/gcc/tree-ssa-live.c
> @@ -623,13 +623,25 @@ clear_unused_block_pointer (void)
>{
> unsigned i;
> tree b;
> -   gimple *stmt = gsi_stmt (gsi);
> +   gimple *stmt;
>  
> +  next:
> +   stmt = gsi_stmt (gsi);
> if (!is_gimple_debug (stmt) && !gimple_clobber_p (stmt))
>   continue;
> b = gimple_block (stmt);
> if (b && !TREE_USED (b))
> - gimple_set_block (stmt, NULL);
> + {
> +   if (gimple_debug_nonbind_marker_p (stmt)
> +   && BLOCK_ABSTRACT_ORIGIN (b))
> 
> why only for inlined BLOCKs?  Did you want to restrict it further
> to inlined_function_outer_scope_p?
> 

Yes.
I had assumed that check would be sufficient, but as you said,
I have to walk the block structure, until I find a
inlined_functi

Re: [PATCH] Remove misleading debug line entries

[Bernd Edlinger]

On 12/2/20 8:50 AM, Richard Biener wrote:
> On Tue, 1 Dec 2020, Bernd Edlinger wrote:
> 
>> Hi!
>>
>>
>> This removes gimple_debug stmts without block info after a
>> NULL INLINE_ENTRY.
>>
>> The line numbers from these stmts are from the inline function,
>> but since the inline function is completely optimized away,
>> there will be no DW_TAG_inlined_subroutine so the debugger has
>> no callstack available at this point, and therefore those
>> line table entries are not helpful to the user.
>>
>> 2020-11-20  Bernd Edlinger  
>>
>>  * cfgexpand.c (expand_gimple_basic_block): Remove debug_begin_stmts
>>  following a removed debug_inline_entry.
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
> 
> So are those visited by clear_unused_block_pointer?  If so wouldn't
> it be more appropriate to remove those there, when we elide the
> inlined block scope?
> 

That's what I thought initially, but that is only true for 99% of the 
inline statements.  However 1% of the inline_entries without block info,
and debug_begin_stmts without block info, that have line numbers from
an inline header, do actually originate here:

copy_debug_stmt (gdebug *stmt, copy_body_data *id)
{
  tree t, *n;
  struct walk_stmt_info wi;

  if (tree block = gimple_block (stmt))
{
  n = id->decl_map->get (block);
  gimple_set_block (stmt, n ? *n : id->block);
}

because id->block is NULL, and decl_map does not have
an entry.

So I tracked it down why that happens.

I think remap_gimple_stmt should just drop those nonbind markers
on the floor when the call statement has no block information.

Once that is fixed, the special handling of inline entries without
block info can as well be moved from remap_gimple_stmt to
clear_unused_block_pointer.

What do you think of this (not yet fully tested) patch?

Is it OK when bootstrap and reg-testing passes?


Thanks
Bernd.

> Thanks,
> Richard.
> 
>>
>> Thanks
>> Bernd.
>>
> 
From 1f97917fcbb15f7277dc9d6030dca05beab825c7 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Wed, 2 Dec 2020 12:32:02 +0100
Subject: [PATCH] Remove misleading debug line entries

This removes gimple_debug_begin_stmts without block info which remain
after a gimple block originating from an inline function is unused.

The line numbers from these stmts are from the inline function,
but since the inline function is completely optimized away,
there will be no DW_TAG_inlined_subroutine so the debugger has
no callstack available at this point, and therefore those
line table entries are not helpful to the user.

2020-12-02  Bernd Edlinger  

	* cfgexpand.c (expand_gimple_basic_block): Remove special handling
	of debug_inline_entries without block info.
	* tree-inline.c (remap_gimple_stmt): Drop debug_nonbind_markers when
	the call statement has no block info.
	* tree-ssa-live.c (clear_unused_block_pointer): Remove
	debug_nonbind_markers originating from inlined functions.
---
 gcc/cfgexpand.c |  9 +
 gcc/tree-inline.c   |  3 ++-
 gcc/tree-ssa-live.c | 16 ++--
 3 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 1df6f4b..2ef8298 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -5831,14 +5831,7 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
 	  else if (gimple_debug_begin_stmt_p (stmt))
 		val = GEN_RTX_DEBUG_MARKER_BEGIN_STMT_PAT ();
 	  else if (gimple_debug_inline_entry_p (stmt))
-		{
-		  tree block = gimple_block (stmt);
-
-		  if (block)
-		val = GEN_RTX_DEBUG_MARKER_INLINE_ENTRY_PAT ();
-		  else
-		goto delink_debug_stmt;
-		}
+		val = GEN_RTX_DEBUG_MARKER_INLINE_ENTRY_PAT ();
 	  else
 		gcc_unreachable ();
 
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index d9814bd..e87c653 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -1819,7 +1819,8 @@ remap_gimple_stmt (gimple *stmt, copy_body_data *id)
 	  /* If the inlined function has too many debug markers,
 	 don't copy them.  */
 	  if (id->src_cfun->debug_marker_count
-	  > param_max_debug_marker_count)
+	  > param_max_debug_marker_count
+	  || !id->block)
 	return stmts;
 
 	  gdebug *copy = as_a  (gimple_copy (stmt));
diff --git a/gcc/tree-ssa-live.c b/gcc/tree-ssa-live.c
index 21a9ee4..ca119c6 100644
--- a/gcc/tree-ssa-live.c
+++ b/gcc/tree-ssa-live.c
@@ -623,13 +623,25 @@ clear_unused_block_pointer (void)
   {
 	unsigned i;
 	tree b;
-	gimple *stmt = gsi_stmt (gsi);
+	gimple *stmt;
 
+  next:
+	stmt = gsi_stmt (gsi);
 	if (!is_gimple_debug (stmt) && !gimple_clobber_p (stmt))
 	  continue;
 	b = gimple_block (stmt);
 	if (b && !TREE_USED (b))
-	  gimple_set_block (stmt, NULL);
+	  {
+	if (gimple_debug_nonbind_marker_p

[PATCH] Remove misleading debug line entries

[Bernd Edlinger]

Hi!


This removes gimple_debug stmts without block info after a
NULL INLINE_ENTRY.

The line numbers from these stmts are from the inline function,
but since the inline function is completely optimized away,
there will be no DW_TAG_inlined_subroutine so the debugger has
no callstack available at this point, and therefore those
line table entries are not helpful to the user.

2020-11-20  Bernd Edlinger  

* cfgexpand.c (expand_gimple_basic_block): Remove debug_begin_stmts
following a removed debug_inline_entry.


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


Thanks
Bernd.
From 464867ca9b4cc6270fb6d41dc5346dc55395efb0 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Fri, 13 Nov 2020 16:26:28 +0100
Subject: [PATCH] Remove misleading debug line entries

This removes gimple_debug stmts without block info after a
NULL INLINE_ENTRY.

The line numbers from these stmts are from the inline function,
but since the inline function is completely optimized away,
there will be no DW_TAG_inlined_subroutine so the debugger has
no callstack available at this point, and therefore those
line table entries are not helpful to the user.

2020-11-20  Bernd Edlinger  

	* cfgexpand.c (expand_gimple_basic_block): Remove debug_begin_stmts
	following a removed debug_inline_entry.
---
 gcc/cfgexpand.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 1df6f4b..6bd38ac 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -5785,6 +5785,7 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
 	  tree value = NULL_TREE;
 	  rtx val = NULL_RTX;
 	  machine_mode mode;
+	  bool skip_inline_loc = false;
 
 	  if (!gimple_debug_nonbind_marker_p (stmt))
 		{
@@ -5837,7 +5838,10 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
 		  if (block)
 		val = GEN_RTX_DEBUG_MARKER_INLINE_ENTRY_PAT ();
 		  else
-		goto delink_debug_stmt;
+		{
+		  skip_inline_loc = true;
+		  goto delink_debug_stmt;
+		}
 		}
 	  else
 		gcc_unreachable ();
@@ -5877,6 +5881,8 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
 	  stmt = gsi_stmt (nsi);
 	  if (!is_gimple_debug (stmt))
 		break;
+	  if (skip_inline_loc && !gimple_block (stmt))
+		goto delink_debug_stmt;
 	}
 
 	  set_curr_insn_location (sloc);
-- 
1.9.1

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

[Bernd Edlinger]

On 11/24/20 11:10 PM, Jason Merrill wrote:
> On 11/22/20 3:05 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this avoids the need to use -fno-threadsafe-statics on
>> arm-none-eabi or working around that problem by supplying
>> a dummy __sync_synchronize function which might
>> just lead to silent code failure of the worst kind
>> (non-reproducable, racy) at runtime, as was pointed out
>> on previous discussions here.
>>
>> When the atomic access involves a call to __sync_synchronize
>> it is better to call __cxa_guard_acquire unconditionally,
>> since it handles the atomics too, or is a non-threaded
>> implementation when there is no gthread support for this target.
>>
>> This fixes also a bug for the ARM EABI big-endian target,
>> that is, previously the wrong bit was checked.
> 
> Instead of a new target macro, can't you follow 
> fold_builtin_atomic_always_lock_free/can_atomic_load_p?
> 

Yes, thanks, that should work too.
Would you like this better?


Thanks
Bernd.
From 863b023786f7e8321979bcdb33c027d37d5e155b Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Tue, 1 Dec 2020 18:54:48 +0100
Subject: [PATCH] Avoid atomic for guard acquire when that is expensive

When the atomic access involves a call to __sync_synchronize
it is better to call __cxa_guard_acquire unconditionally,
since it handles the atomics too, or is a non-threaded
implementation when there is no gthread support for this target.

This fixes also a bug for the ARM EABI big-endian target,
that is, previously the wrong bit was checked.

2020-11-22  Bernd Edlinger  

	* decl2.c: (is_atomic_expensive_p): New helper function.
	(build_atomic_load_byte): Rename to...
	(build_atomic_load_type): ... and add new parameter type.
	(get_guard_cond): Skip the atomic here if that is expensive.
	Use the correct type for the atomic load on certain targets.
---
 gcc/cp/decl2.c | 33 +
 1 file changed, 29 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 1bc7b7e..5001e8f 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -48,6 +48,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "intl.h"
 #include "c-family/c-ada-spec.h"
 #include "asan.h"
+#include "optabs-query.h"
 
 /* Id for dumping the raw trees.  */
 int raw_dump_id;
@@ -3297,18 +3298,34 @@ get_guard (tree decl)
   return guard;
 }
 
+/* Returns true if accessing the GUARD atomic is expensive,
+   i.e. involves a call to __sync_synchronize or similar.
+   In this case let __cxa_guard_acquire handle the atomics.  */
+
+static bool
+is_atomic_expensive_p (machine_mode mode)
+{
+  if (!flag_inline_atomics)
+return false;
+
+  if (!can_compare_and_swap_p (mode, false) || !can_atomic_load_p (mode))
+return false;
+
+  return true;
+}
+
 /* Return an atomic load of src with the appropriate memory model.  */
 
 static tree
-build_atomic_load_byte (tree src, HOST_WIDE_INT model)
+build_atomic_load_type (tree src, HOST_WIDE_INT model, tree type)
 {
-  tree ptr_type = build_pointer_type (char_type_node);
+  tree ptr_type = build_pointer_type (type);
   tree mem_model = build_int_cst (integer_type_node, model);
   tree t, addr, val;
   unsigned int size;
   int fncode;
 
-  size = tree_to_uhwi (TYPE_SIZE_UNIT (char_type_node));
+  size = tree_to_uhwi (TYPE_SIZE_UNIT (type));
 
   fncode = BUILT_IN_ATOMIC_LOAD_N + exact_log2 (size) + 1;
   t = builtin_decl_implicit ((enum built_in_function) fncode);
@@ -3351,7 +3368,15 @@ get_guard_cond (tree guard, bool thread_safe)
   if (!thread_safe)
 guard = get_guard_bits (guard);
   else
-guard = build_atomic_load_byte (guard, MEMMODEL_ACQUIRE);
+{
+  tree type = targetm.cxx.guard_mask_bit ()
+		  ? TREE_TYPE (guard) : char_type_node;
+
+  if (is_atomic_expensive_p (TYPE_MODE (type)))
+	guard = integer_zero_node;
+  else
+	guard = build_atomic_load_type (guard, MEMMODEL_ACQUIRE, type);
+}
 
   /* Mask off all but the low bit.  */
   if (targetm.cxx.guard_mask_bit ())
-- 
1.9.1

[PING] [PATCH] Avoid atomic for guard acquire when that is expensive

[Bernd Edlinger]

Hi,

I'd like to ping for this patch:

https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559882.html

Thanks
Bernd.

On 11/22/20 9:05 AM, Bernd Edlinger wrote:
> Hi,
> 
> this avoids the need to use -fno-threadsafe-statics on
> arm-none-eabi or working around that problem by supplying
> a dummy __sync_synchronize function which might
> just lead to silent code failure of the worst kind
> (non-reproducable, racy) at runtime, as was pointed out
> on previous discussions here.
> 
> When the atomic access involves a call to __sync_synchronize
> it is better to call __cxa_guard_acquire unconditionally,
> since it handles the atomics too, or is a non-threaded
> implementation when there is no gthread support for this target.
> 
> This fixes also a bug for the ARM EABI big-endian target,
> that is, previously the wrong bit was checked.
> 
> 
> Regression tested successfully on arm-none-eabi with newlib-3.3.0.
> 
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 

[PATCH] Avoid atomic for guard acquire when that is expensive

[Bernd Edlinger]

Hi,

this avoids the need to use -fno-threadsafe-statics on
arm-none-eabi or working around that problem by supplying
a dummy __sync_synchronize function which might
just lead to silent code failure of the worst kind
(non-reproducable, racy) at runtime, as was pointed out
on previous discussions here.

When the atomic access involves a call to __sync_synchronize
it is better to call __cxa_guard_acquire unconditionally,
since it handles the atomics too, or is a non-threaded
implementation when there is no gthread support for this target.

This fixes also a bug for the ARM EABI big-endian target,
that is, previously the wrong bit was checked.


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

Is it OK for trunk?


Thanks
Bernd.
From 9fd070407408cf10789f5e9eb5ddda2fb3798e6f Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Sun, 22 Nov 2020 08:11:14 +0100
Subject: [PATCH] Avoid atomic for guard acquire when that is expensive

When the atomic access involves a call to __sync_synchronize
it is better to call __cxa_guard_acquire unconditionally,
since it handles the atomics too, or is a non-threaded
implementation when there is no gthread support for this target.

This fixes also a bug for the ARM EABI big-endian target,
that is, previously the wrong bit was checked.

gcc:
2020-11-22  Bernd Edlinger  

	* target.def (guard_atomic_expensive): New hook.
	* doc/tm.texi: Document TARGET_CXX_GUARD_ATOMIC_EXPENSIVE.
	* doc/tm.texi.in: Likewise.
	* config/arm/arm.c (arm_cxx_guard_atomic_expensive): New callback.

gcc/cp:
2020-11-22  Bernd Edlinger  

	* decl2.c: (build_atomic_load_byte): Rename to...
	(build_atomic_load_type): ... and add new parameter type.
	(get_guard_cond): Skip the atomic here if that is expensive.
	Use the correct type for the atomic load on certain targets.
---
 gcc/config/arm/arm.c | 13 +
 gcc/cp/decl2.c   | 12 
 gcc/doc/tm.texi  |  7 +++
 gcc/doc/tm.texi.in   |  2 ++
 gcc/target.def   | 10 ++
 5 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 04190b1..04ca1fe 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -235,6 +235,7 @@ static rtx arm_dwarf_register_span (rtx);
 
 static tree arm_cxx_guard_type (void);
 static bool arm_cxx_guard_mask_bit (void);
+static bool arm_cxx_guard_atomic_expensive (void);
 static tree arm_get_cookie_size (tree);
 static bool arm_cookie_has_size (void);
 static bool arm_cxx_cdtor_returns_this (void);
@@ -593,6 +594,9 @@ static const struct attribute_spec arm_attribute_table[] =
 #undef TARGET_CXX_GUARD_MASK_BIT
 #define TARGET_CXX_GUARD_MASK_BIT arm_cxx_guard_mask_bit
 
+#undef TARGET_CXX_GUARD_ATOMIC_EXPENSIVE
+#define TARGET_CXX_GUARD_ATOMIC_EXPENSIVE arm_cxx_guard_atomic_expensive
+
 #undef TARGET_CXX_GET_COOKIE_SIZE
 #define TARGET_CXX_GET_COOKIE_SIZE arm_get_cookie_size
 
@@ -28882,6 +28886,15 @@ arm_cxx_guard_mask_bit (void)
 }
 
 
+/* Return true if atomics involve a call to __sync_synchronize.  */
+
+static bool
+arm_cxx_guard_atomic_expensive (void)
+{
+  return TARGET_AAPCS_BASED && !TARGET_HAVE_DMB && !TARGET_HAVE_DMB_MCR;
+}
+
+
 /* The EABI specifies that all array cookies are 8 bytes long.  */
 
 static tree
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 1bc7b7e..e2b29a6 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -3300,15 +3300,15 @@ get_guard (tree decl)
 /* Return an atomic load of src with the appropriate memory model.  */
 
 static tree
-build_atomic_load_byte (tree src, HOST_WIDE_INT model)
+build_atomic_load_type (tree src, HOST_WIDE_INT model, tree type)
 {
-  tree ptr_type = build_pointer_type (char_type_node);
+  tree ptr_type = build_pointer_type (type);
   tree mem_model = build_int_cst (integer_type_node, model);
   tree t, addr, val;
   unsigned int size;
   int fncode;
 
-  size = tree_to_uhwi (TYPE_SIZE_UNIT (char_type_node));
+  size = tree_to_uhwi (TYPE_SIZE_UNIT (type));
 
   fncode = BUILT_IN_ATOMIC_LOAD_N + exact_log2 (size) + 1;
   t = builtin_decl_implicit ((enum built_in_function) fncode);
@@ -3350,8 +3350,12 @@ get_guard_cond (tree guard, bool thread_safe)
 
   if (!thread_safe)
 guard = get_guard_bits (guard);
+  else if (targetm.cxx.guard_atomic_expensive ())
+guard = integer_zero_node;
   else
-guard = build_atomic_load_byte (guard, MEMMODEL_ACQUIRE);
+guard = build_atomic_load_type (guard, MEMMODEL_ACQUIRE,
+targetm.cxx.guard_mask_bit ()
+? TREE_TYPE (guard) : char_type_node);
 
   /* Mask off all but the low bit.  */
   if (targetm.cxx.guard_mask_bit ())
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 2b88f78..92215cf 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -10728,6 +10728,13 @@ This hook determines how guard variables are used.  It should return
 @code{true} indicates that only the least significant bit should be used.
 @end deftypefn
 
+@deftypefn {Target Hook} bool TARGET_CXX_GUARD_ATOMIC

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

[Bernd Edlinger]

On 11/17/20 4:41 PM, Richard Earnshaw (lists) wrote:
> 
> libgcc is *still* the wrong place for this.  It belongs in the system
> library (eg newlib, or glibc, or whatever), which knows about the system
> it's running on.  (Sorry, I should have said this before, but I've
> context-switched this out since it's been a long time since it came up).
> 

No problem.  I just saw it from the other end.

It is odd that this problem does not go away even if gcc is configured
with --disable-threads, which should be the default for arm-none-eabi
anyway.

If we assume a threaded environment then it is still libgcc
which does not define __GTHREADS in libgcc/gthr.h, and libstdc++'s
__cxa_guard_acquire is not making use of functions like __gthread_mutex_lock.
But that appears to be this way by design.

Of course the race is not fixed if you ask newlib to implement just this
__sync_synchronize function.

> This hack will just lead to silent code failure of the worst kind
> (non-reproducable, racy) at runtime.
> 

So in a arm-none-eabi system with armv6 or higher where the intrinsic
__sync_synchronize is not a library call but an instruction
we have exactly this worst kind scenario, already.

It is however possible that the default of -fthreadsafe_statics
is inappropriate for --disable-threads ?


Bernd.


> R.
> 

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

[Bernd Edlinger]

On 11/17/20 1:44 PM, Richard Earnshaw (lists) wrote:
> On 03/11/2020 15:08, 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.
>>
> 
> I seem to recall that this was a deliberate decision - you can't guess
> this correctly, at least when trying to build portable code - you just
> have to know which runtime you will be using.
> 

Therefore I suggest to use the weak attribute.  It is on purpose not
implementing all of the atomics.

The use case, is a C++ program which initializes a local static variable.

$ cat test.cc
#include 
main(int argc, char **argv)
{
  static std::string x = "test";
  return 0;
}

compiles to this:
sub sp, sp, #20
str r0, [fp, #-24]
str r1, [fp, #-28]
ldr r3, .L14
ldrbr4, [r3]
bl  __sync_synchronize
and r3, r4, #255
and r3, r3, #1
cmp r3, #0
moveq   r3, #1
movne   r3, #0
and r3, r3, #255
cmp r3, #0
beq .L8
ldr r0, .L14
bl  __cxa_guard_acquire
mov r3, r0

so __sync_synchronize is not defined in newlib since the target (arm-sim)
is known to be not multi-threaded,
but __cxa_guard_acquire is also not a thread safe function,
because __GTHREADS is not defined by libgcc, since it is known
at configure time, that the target does not support threads.
So libstdc++ does not try to use a mutex or any atomics either,
because it is not compiled with __GTHREADS.

I can further narrow down the patch by only defining this function when
__GTHREADS is not defined, to make it more clear.


> I think Ramana had some changes in the works at one point to address
> (some) of this, but I'm not sure what happened to them.  Ramana?
> 
> 
> +#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__)
> 
> Ug, no!  Use the ACLE macros to avoid this sort of mess.
> 

Ah, thanks, copy-paste from freebsd-atomic.c :)


I've attached the updated patch.
Is it OK?


Thanks
Bernd.
From ca44e1fcb4b991306cbcde6293d20c77ce74ad68 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-17  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 | 38 ++
 libgcc/config/arm/t-eabi  |  1 +
 3 files changed, 40 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 66af834..eaf74f1 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -496,7 +496,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..c37bacf
--- /dev/null
+++ b/libgcc/config/arm/eabi-sync.c
@@ -0,0 +1,38 @@
+/* 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

[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.
> 

[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

[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

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'll simply set the alignment di

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/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.
>>
> 

[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: [PING] [PATCH] [ARM] Adjust test expectations of unaligned-memcpy-2/3.c (PR 91614)

[Bernd Edlinger]

On 4/22/20 8:20 PM, Jeff Law wrote:
> On Thu, 2020-03-26 at 04:23 +0100, Bernd Edlinger wrote:
>> Hi,
>>
>> I am pinging this because PR 91614 has been raised to P2 now:
>> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00370.html
> It's been nearly a month since the ping and many since the patch was posted
> originally.
> 
> I interpret Richard E's comments from Sept as a reject of the patch as-is.
> 
> I tend to agree with Richard in that testing assembly code for this is going 
> to
> be quite fragile and an execution test would be better.
> 

Yes, that is/was my understanding as well, I just wanted to make sure this was 
not
a mis-understanding or a message lost in transmission.
I think we can live with this test case as known fail.
Jeff, could you please make this tracker a P4 instead of P2 ?

FYI: I received no bounce, but any message can easily be dropped by spam 
filters...


Thanks,
Bernd.

> Jeff
> 

[PING] [PATCH] [ARM] Adjust test expectations of unaligned-memcpy-2/3.c (PR 91614)

[Bernd Edlinger]

Hi,

I am pinging this because PR 91614 has been raised to P2 now:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00370.html

Thanks
Bernd.


On 9/6/19 2:12 PM, Bernd Edlinger wrote:
> On 9/5/19 5:55 PM, Richard Earnshaw (lists) wrote:
>> On 03/09/2019 21:45, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> due to the introduction of unaligned_loaddi and unaligned_storedi,
>>> two test cases show some regression as PR 91614 points out.
>>>
>>> I would like to change the test expectations if these two test cases,
>>> since they seem to be bogus.
>>>
>>> That is the test case already failed for arm_prefer_ldrd_strd targets,
>>> since not a ldrd or strd is created but a ldm/stm instead, which
>>> is probably not what is intended.
>>>
>>> That is for arm_prefer_ldrd_strd the previously used instruction movdi:
>>>
>>> (insn 11 10 12 2 (set (mem/c:DI (reg:SI 112) [0 MEM  
>>> [(voidD.71 *)]+0 S8 A32])
>>>  (reg:DI 114)) "unaligned-memcpy-2.c":11:3 642 {*movdi_vfp}
>>>   (nil))
>>>
>>> is split up very early in subreg1 into:
>>>
>>> (insn 21 10 22 2 (set (mem/c:SI (reg:SI 112) [0 MEM  
>>> [(voidD.71 *)]+0 S4 A32])
>>>  (reg:SI 119)) "unaligned-memcpy-2.c":11:3 640 {*arm_movsi_vfp}
>>>   (nil))
>>> (insn 22 21 12 2 (set (mem/c:SI (plus:SI (reg:SI 112)
>>>  (const_int 4 [0x4])) [0 MEM  [(voidD.71 
>>> *)]+4 S4 A32])
>>>  (reg:SI 120 [+4 ])) "unaligned-memcpy-2.c":11:3 640 
>>> {*arm_movsi_vfp}
>>>   (nil))
>>>
>>> which is finally replaced by:
>>>
>>> (insn 35 10 12 2 (parallel [
>>>  (set (mem/c:SI (reg/f:SI 3 r3 [111]) [0 MEM  
>>> [(voidD.71 *)]+0 S4 A32])
>>>  (reg:SI 1 r1))
>>>  (set (mem/c:SI (plus:SI (reg/f:SI 3 r3 [111])
>>>  (const_int 4 [0x4])) [0 MEM  
>>> [(voidD.71 *)]+4 S4 A32])
>>>  (reg:SI 2 r2))
>>>  ]) "unaligned-memcpy-2.c":11:3 378 {*stm2_}
>>>   (expr_list:REG_DEAD (reg:SI 2 r2)
>>>  (expr_list:REG_DEAD (reg:SI 1 r1)
>>>  (nil
>>>
>>> ... so stm instead of strd.
>>>
>>> Since the unalinged_storedi is an unspec, it is expanded as strd which is
>>> kind of okay, but there is register pair spilled which was not there 
>>> previously:
>>>
>>> aligned_dest:
>>> @ args = 0, pretend = 0, frame = 0
>>> @ frame_needed = 0, uses_anonymous_args = 0
>>> @ link register save eliminated.
>>> strd    r4, [sp, #-8]!
>>> ldr    r4, [r0]    @ unaligned
>>> movw    r3, #:lower16:.LANCHOR0
>>> ldr    r5, [r0, #4]    @ unaligned
>>> movt    r3, #:upper16:.LANCHOR0
>>> strd    r4, [r3]
>>> ldr    r2, [r0, #8]    @ unaligned
>>> str    r2, [r3, #8]
>>> ldrh    r2, [r0, #12]    @ unaligned
>>> strh    r2, [r3, #12]    @ movhi
>>> ldrb    r2, [r0, #14]    @ zero_extendqisi2
>>> strb    r2, [r3, #14]
>>> ldrd    r4, [sp]
>>> add    sp, sp, #8
>>> bx    lr
>>>
>>> The patch filters out ldrd/strd that sp-relative, and adds a few
>>> missing scan-assembler rules, in order to make the test results more stable.
>>>
>>> Alternative could be to use two movsi instead of the unaligned_load/storedi,
>>> but that would end up in ldm/stm which looks plain wrong to me.
>>>
>>>
>>> Tested using various arm-linux-gnueabihf cross-compilers.
>>> Is it OK for trunk?
>>>
>>>
>>> Thanks
>>> Bernd.
>>>
>> 2019-09-03  Bernd Edlinger  
>>
>> PR target/91614
>> * gcc.target/arm/unaligned-memcpy-2.c: Adjust test expectations.
>> * gcc.target/arm/unaligned-memcpy-3.c: Likewise.
>>
>> Index: gcc/testsuite/gcc.target/arm/unaligned-memcpy-2.c
>> ===
>> --- gcc/testsuite/gcc.target/arm/unaligned-memcpy-2.c    (Revision 275341)
>> +++ gcc/testsuite/gcc.target/arm/unaligned-memcpy-2.c    (Arbeitskopie)
>> @@ -15,9 +15,11 @@
>>     loads/stores for the remainder.  */
>>
>>  /* { dg-final { scan-assembler-times "ldmia" 0 } } */
>> -/* { dg-final { scan-assembler-times "ldrd" 0 } } */
>> +/* { dg-final { sc

[PATCH] Avoid collect2 calling signal unsafe functions and/or unlink, with uninitialized memory (for gcc-9 branch)

[Bernd Edlinger]

Hi,

this fixes the signal handler calling signal unsafe vfprintf and/or passing
uninitialized memory to unlink in signal handler.

This time it is the patch for the gcc-9 branch.

The difference to the gcc-8 branch is in tool_cleanup:
The variable that suppress the vfprintf is verbose = false;
not debug = false, to match the different logic in maybe_unlink.


Bootstrapped and reg-tested with x86_64-pc-linux-gnu.
Is it OK for the gcc-9 branch?


Thanks
Bernd.
From d52ac2c0394f0432e183511f8a6d4f96b49f88a5 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Mon, 17 Feb 2020 17:40:07 +0100
Subject: [PATCH] Avoid collect2 calling signal unsafe functions and/or unlink
 with uninitialized memory

2020-02-20  Bernd Edlinger  

	* collect2.c (tool_cleanup): Avoid calling not signal-safe
	functions.
	(maybe_run_lto_and_relink): Avoid possible signal handler
	access to unintialzed memory (lto_o_files).
---
 gcc/collect2.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gcc/collect2.c b/gcc/collect2.c
index eb84f84..8f092e7 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -384,6 +384,10 @@ static void scan_prog_file (const char *, scanpass, scanfilter);
 void
 tool_cleanup (bool from_signal)
 {
+  /* maybe_unlink may call notice, which is not signal safe.  */
+  if (from_signal)
+verbose = false;
+
   if (c_file != 0 && c_file[0])
 maybe_unlink (c_file);
 
@@ -743,7 +747,10 @@ maybe_run_lto_and_relink (char **lto_ld_argv, char **object_lst,
 	  ++num_files;
 	  }
 
-	lto_o_files = XNEWVEC (char *, num_files + 1);
+	/* signal handler may access uninitialized memory
+	   and delete whatever it points to, if lto_o_files
+	   is not allocated with calloc.  */
+	lto_o_files = XCNEWVEC (char *, num_files + 1);
 	lto_o_files[num_files] = NULL;
 	start = XOBFINISH (_obstack, char *);
 	for (i = 0; i < num_files; ++i)
-- 
2.7.4

Re: [PATCH] Fix -save-temp leaking lto files in /tmp

[Bernd Edlinger]

Hi Tobias,

On 2/20/20 5:09 PM, Tobias Burnus wrote:
> Hi Bernd, hi all,
> 
> note that you can get even more files: If you do offloading,
> LTO is additionally run for each offloading target (there
> can be more than one), cf. https://gcc.gnu.org/wiki/Offloading
> 
> Some of those files are probably also from mkoffload etc.
> See below.
> 
> On 2/20/20 4:33 PM, Bernd Edlinger wrote:
> 
>> On 2/20/20 2:34 PM, Richard Biener wrote:
>>> I don't think this is an improvement.  The files still
>>> will be (correctly) retained and now in addition to that
>>> there's temporary directories piling up?
>> Well, the temp. directory has a known name,
>> in case the command line is
>>
>> gcc -save-temps -lto -o test test.c
>>
>> there are those 4 in a *known* place, test.lto_tmpdir:
> 
> Here, with offloading (compiler only supports one
> offloading target), I get for
>    gfortran -fopenacc -save-temps -o test kernels-map-2.F90
> 
> (1) in the current directory:
> kernels-map-2.f90
> kernels-map-2.o
> test.lto_wrapper_args
> kernels-map-2.res
> kernels-map-2.s
> ccv97orQ.i
> ccv97orQ.s
> 
> (2) in /tmp:
> ccXtFBKP.ofldlist
> cckm9TaT
> cc1aPJVX
> ccwnCSfQ
> ccEwCVRX
> ccv97orQ.c
> ccgtnzbU.mkoffload
> ccsZzs01
> ccouoZqP.target.o
> cc6o87mX.crtoffloadtable.o
> test
> 
> And with "-flto" in addition:
> 
> (1) Current directory:
> kernels-map-2.f90
> kernels-map-2.o
> test.lto_wrapper_args
> kernels-map-2.res
> kernels-map-2.s
> ccdBFFxF.i
> ccdBFFxF.s
> test.ltrans0.o
> test.ltrans.out
> test.ltrans0.s
> test.ltrans0.ltrans.o
> test
> 
> (2) in /tmp:
> ccX5EDTE.ofldlist
> ccpAKbE7
> ccxnuNsz
> ccq5sdmF
> ccWUsloz
> ccZ5rev7.mkoffload
> ccdBFFxF.c
> cc3PGOK1
> ccW4hTGF.target.o
> ccWH1ft2
> ccsKJG3z.crtoffloadtable.o
> ccmE0bPK
> ccB54fLv
> cckO6O6c
> 

I cannot test anything with offload, because that setup is out of my reach.
I believe this patch will improve the situation significantly, but I would
be curious to know if the temp files move away from /tmp if you
might give this patch a try.  It will not prevent the ccX.i/s
in the $PWD, unfortunately.


Thanks
Bernd.

Re: [PATCH] Fix -save-temp leaking lto files in /tmp

[Bernd Edlinger]

On 2/20/20 2:34 PM, Richard Biener wrote:
> On Thu, 20 Feb 2020, Bernd Edlinger wrote:
> 
>> Hi,
>>
>> this is the remaining issue that happens when -flto and -save-temps
>> is used together, it leaks several files in /tmp.
>>
>> I try to give more background to how these temp files are
>> created, and in all likelihood the leaking of these
>> files is wanted, and certainly very helpful for debugging
>> lto issues, that's for sure.  It is just not helpful
>> that they need to be looked up in the /tmp folder, even
>> if you want to debug something with lto.
>>
>> The short story is...
>>
>> They are created here:
>>
>>   if (parallel)
>> {
>>   makefile = make_temp_file (".mk");
>>   mstream = fopen (makefile, "w");
>>
>> and here:
>>
>>   /* Note: we assume argv contains at least one element; this is
>>  checked above.  */
>>
>>   response_file = make_temp_file ("");
>>
>>   f = fopen (response_file, "w");
>>
>> And in a few other places as well, it depends a bit
>> if -o is used or not (i.e. linker_output != NULL or not).
>>
>> and not removed here:
>>
>>
>>   if (response_file && !save_temps)
>> {
>>   unlink (response_file);
>>   response_file = NULL;
>> }
>>
>> and here:
>>
>>   do_wait (new_argv[0], pex);
>>   maybe_unlink (makefile);
>>   makefile = NULL;
>>
>>
>> the code with the response_file is executed both in
>> lto-wrapper and collect2, but in collect2 only when
>> if is invoked from lto-wrapper, triggered by the @file
>> argument list.
>>
>> Therefore I figured that the best possible
>> solution is just let lto-wrapper create a temp-file
>> for those problem cases, and use TMPDIR to have
>> all make_temp_file that follow use that to folder to
>> place the those response files and other stuff in
>> there.
>>
>>
>> So that is what I split out from the previous patch,
>> which focused on collect2.
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
> 
> I don't think this is an improvement.  The files still
> will be (correctly) retained and now in addition to that
> there's temporary directories piling up?
> 

Well, the temp. directory has a known name,
in case the command line is

gcc -save-temps -lto -o test test.c

there are those 4 in a *known* place, test.lto_tmpdir:

test.lto_tmpdir:
insgesamt 24
drwxrwxr-x 2 ed ed 4096 Feb 20 16:14 .
drwxrwxr-x 3 ed ed 4096 Feb 20 16:14 ..
-rw--- 1 ed ed   15 Feb 20 16:14 cc8FwPQ1
-rw--- 1 ed ed  237 Feb 20 16:14 cchROrdh
-rw--- 1 ed ed  197 Feb 20 16:14 cclbBAUp
-rw--- 1 ed ed7 Feb 20 16:14 ccMlfh1g

plus
-rw-rw-r-- 1 ed ed   164 Feb 20 16:14 test.i
-rw-rw-r-- 1 ed ed50 Feb 20 16:14 test.lto_wrapper_args
-rw-rw-r-- 1 ed ed17 Feb 20 16:14 test.ltrans.out
-rw-rw-r-- 1 ed ed  1232 Feb 20 16:14 test.ltrans0.ltrans.o
-rw-rw-r-- 1 ed ed  2539 Feb 20 16:14 test.ltrans0.o
-rw-rw-r-- 1 ed ed   374 Feb 20 16:14 test.ltrans0.s
-rw-rw-r-- 1 ed ed52 Feb 20 16:14 test.res
-rw-rw-r-- 1 ed ed  4267 Feb 20 16:14 test.s

if the command line is
gcc -save-temps -lto test.c

there are a few more but also in a *known* place, a.out.lto_tmpdir:

a.out.lto_tmpdir/
total 36
drwxrwxr-x 2 ed ed 4096 Feb 20 16:18 .
drwxrwxr-x 3 ed ed 4096 Feb 20 16:18 ..
-rw--- 1 ed ed7 Feb 20 16:18 cc2hY8SH
-rw--- 1 ed ed  227 Feb 20 16:18 ccDafyit
-rw--- 1 ed ed  262 Feb 20 16:18 ccglzNAe
-rw--- 1 ed ed   36 Feb 20 16:18 ccnAU7NG
-rw--- 1 ed ed   38 Feb 20 16:18 ccoLFY2H.ltrans.out
-rw-rw-r-- 1 ed ed 1232 Feb 20 16:18 ccoLFY2H.ltrans0.ltrans.o
-rw-rw-r-- 1 ed ed 2560 Feb 20 16:18 ccoLFY2H.ltrans0.o

plus
-rw-rw-r--   1 ed ed50 Feb 20 16:18 a.out.lto_wrapper_args
-rw-rw-r--   1 ed ed   160 Feb 20 16:18 test.i
-rw-rw-r--   1 ed ed  3104 Feb 20 16:18 test.o
-rw-rw-r--   1 ed ed52 Feb 20 16:18 test.res
-rw-rw-r--   1 ed ed  4267 Feb 20 16:18 test.s


> A better improvement would be to selectively decide
> which files might not be needed to be preserved and/or
> give them names in the build directory in more cases.
> 

Ah, well, it just felt like that will probably need a
rather complicated patch which is probably not
worth it, since the are a lot of different
code pathes involved, (with -g or not, with -flto=jobserver
or not, flto_partition=none, or with offload or not, with -o
or not etc.) in two or more independent forked processes,
which will need to coordinate somehow, not to clobber each
other's tempfiles.


Bernd.


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

[PATCH] Fix -save-temp leaking lto files in /tmp

[Bernd Edlinger]

Hi,

this is the remaining issue that happens when -flto and -save-temps
is used together, it leaks several files in /tmp.

I try to give more background to how these temp files are
created, and in all likelihood the leaking of these
files is wanted, and certainly very helpful for debugging
lto issues, that's for sure.  It is just not helpful
that they need to be looked up in the /tmp folder, even
if you want to debug something with lto.

The short story is...

They are created here:

  if (parallel)
{
  makefile = make_temp_file (".mk");
  mstream = fopen (makefile, "w");

and here:

  /* Note: we assume argv contains at least one element; this is
 checked above.  */

  response_file = make_temp_file ("");

  f = fopen (response_file, "w");

And in a few other places as well, it depends a bit
if -o is used or not (i.e. linker_output != NULL or not).

and not removed here:


  if (response_file && !save_temps)
{
  unlink (response_file);
  response_file = NULL;
}

and here:

  do_wait (new_argv[0], pex);
  maybe_unlink (makefile);
  makefile = NULL;


the code with the response_file is executed both in
lto-wrapper and collect2, but in collect2 only when
if is invoked from lto-wrapper, triggered by the @file
argument list.

Therefore I figured that the best possible
solution is just let lto-wrapper create a temp-file
for those problem cases, and use TMPDIR to have
all make_temp_file that follow use that to folder to
place the those response files and other stuff in
there.


So that is what I split out from the previous patch,
which focused on collect2.


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


Thanks
Bernd.

From d6dc826c63dc881fe41dbf0c3a461008afdef8b3 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Mon, 17 Feb 2020 17:40:07 +0100
Subject: [PATCH] Fix -save-temp leaking lto files in /tmp

When linking with -flto and -save-temps, various
temporary files are created in /tmp.  They would normally
be deleted without -save-temps, but are retained
for debugging purposes, which is good.  So this just
creates a folder named as output-file.lto_tmpdir,
which makes this feature even more useful, as the
temporary files do not linger in the /tmp directoy
but instead are more easy to locate this way.

2020-02-20  Bernd Edlinger  

	* lto-wrapper.c (run_gcc): Create an lto tmpdir
	and use it when -save-temps is used.
---
 gcc/lto-wrapper.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index fe8f292..fdc9565 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -1423,6 +1423,17 @@ run_gcc (unsigned argc, char *argv[])
   fputc ('\n', stderr);
 }
 
+  if (save_temps)
+{
+  char *tmpdir = concat (linker_output ? linker_output : "a.out",
+			 ".lto_tmpdir", NULL);
+  /* Make directory if necessary, but expect no race here.  */
+  if (access (tmpdir, F_OK) == 0
+	  || mkdir (tmpdir, S_IRWXU | S_IRWXG | S_IRWXO) == 0)
+	setenv ("TMPDIR", tmpdir, 1);
+  free (tmpdir);
+}
+
   if (linker_output_rel)
 no_partition = true;
 
-- 
1.9.1

Re: [PATCH] Fix -save-temp leaking files in /tmp and possible data loss in signal handler

[Bernd Edlinger]

On 2/19/20 6:36 PM, Bernhard Reutner-Fischer wrote:
> Bernd,
> 
> On 18 February 2020 18:12:21 CET, Bernd Edlinger  
> wrote:
>> Hi,
> 
> +is not allocatted with calloc.  */
> 
> s/tt/t/
> 

Thanks yes,
fixed as obvious:

commit fd136f018e6d64bff08b7a0243ba34911792547c
Author: Bernd Edlinger 
Date:   Wed Feb 19 18:47:39 2020 +0100

Fix a typo in comment.
    
2020-02-19  Bernd Edlinger  

* collect2.c (maybe_run_lto_and_relink): Fix typo in
comment.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 757d05a..f5876a3 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2020-02-19  Bernd Edlinger  
+
+   * collect2.c (maybe_run_lto_and_relink): Fix typo in
+   comment.

[PATCH] Avoid collect2 calling signal unsafe functions and/or unlink, with uninitialized memory (for gcc-8 branch)

[Bernd Edlinger]

Hi,

this fixes the signal handler calling signal unsafe vfprintf and/or passing
uninitialized memory to unlink in signal handler.

This is the patch for the gcc-8 branch.


Bootstrapped and reg-tested with x86_64-pc-linux-gnu.
Is it OK for the gcc-8 branch?


Thanks
Bernd.
From dd98fe7c45c5096dfab9425dce6e0f88f5ccdcbe Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Mon, 17 Feb 2020 17:40:07 +0100
Subject: [PATCH] Avoid collect2 calling signal unsafe functions and/or unlink
 with uninitialized memory

2020-02-19  Bernd Edlinger  

	* collect2.c (tool_cleanup): Avoid calling not signal-safe
	functions.
	(maybe_run_lto_and_relink): Avoid possible signal handler
	access to unintialzed memory (lto_o_files).
---
 gcc/collect2.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gcc/collect2.c b/gcc/collect2.c
index a96af13..11e3a39 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -382,6 +382,10 @@ static void scan_prog_file (const char *, scanpass, scanfilter);
 void
 tool_cleanup (bool from_signal)
 {
+  /* maybe_unlink may call notice, which is not signal safe.  */
+  if (from_signal)
+debug = false;
+
   if (c_file != 0 && c_file[0])
 maybe_unlink (c_file);
 
@@ -741,7 +745,10 @@ maybe_run_lto_and_relink (char **lto_ld_argv, char **object_lst,
 	  ++num_files;
 	  }
 
-	lto_o_files = XNEWVEC (char *, num_files + 1);
+	/* signal handler may access uninitialized memory
+	   and delete whatever it points to, if lto_o_files
+	   is not allocatted with calloc.  */
+	lto_o_files = XCNEWVEC (char *, num_files + 1);
 	lto_o_files[num_files] = NULL;
 	start = XOBFINISH (_obstack, char *);
 	for (i = 0; i < num_files; ++i)
-- 
1.9.1

[PATCH] Fix -save-temp leaking files in /tmp and possible data loss in signal handler

[Bernd Edlinger]

Hi,

I noticed that my /tmp directory gets clobbered with many *.ld/*.le files 
whenever
the test suite runs.  I tracked that down to a bug in the collect2 and 
lto-wrapper
executable, which happens when -save-temps is used.  As I tunrs out, that these
.ld- and .le-files are no longer used, so I removed them altogether, including
the no longer used dump_ld_file.

But when I looked closer I found that the collect2 also calls the not signal 
safe
function vfprintf (via notice) and the signal safe unlink from a signal handler,
but since the argument for the unlink is potentially accessed before the file 
path is
initialized, we may call unlink with memory obtained directly from xmalloc, 
this might
end in removing arbitrary files on the hard disk, when the collect2 is 
interrupted
asynchronously by any signal handler.

Therefore thus this bug might even deserve a CVE number.


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


Thanks
Bernd.
From 0fc0c1453c59eb8709d56f7d817caa111eb6eeb7 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Mon, 17 Feb 2020 17:40:07 +0100
Subject: [PATCH] Fix -save-temp leaking files in /tmp

And avoid signal handler calling signal unsafe functions,
and/or calling unlink with uninitialized memory pointer.

2020-02-18  Bernd Edlinger  

	* collect2.c (c_file, o_file): Make const again.
	(ldout,lderrout, dump_ld_file): Remove.
	(tool_cleanup): Avoid calling not signal-safe functions.
	(maybe_run_lto_and_relink): Avoid possible signal handler
	access to unintialzed memory (lto_o_files).
	(main): Avoid leaking temp files in $TMPDIR.
	Initialize c_file/o_file with concat, which avoids exposing
	uninitialized memory to signal handler, which calls unlink(!).
	Avoid calling maybe_unlink when the main function returns,
	since the atexit handler is already doing this.
	* collect2.h (dump_ld_file, ldout, lderrout): Remove.
	* lto-wrapper.c (run_gcc): Create an lto tmpdir
	and use it when -save-temps is used.
---
 gcc/collect2.c| 130 +++---
 gcc/collect2.h|   4 --
 gcc/lto-wrapper.c |  11 +
 3 files changed, 27 insertions(+), 118 deletions(-)

diff --git a/gcc/collect2.c b/gcc/collect2.c
index 502d629..f7d9f10 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -205,14 +205,12 @@ bool helpflag;			/* true if --help */
 static int shared_obj;			/* true if -shared */
 static int static_obj;			/* true if -static */
 
-static char *c_file;		/* .c for constructor/destructor list.  */
-static char *o_file;		/* .o for constructor/destructor list.  */
+static const char *c_file;		/* .c for constructor/destructor list.  */
+static const char *o_file;		/* .o for constructor/destructor list.  */
 #ifdef COLLECT_EXPORT_LIST
 static const char *export_file;		/* .x for AIX export list.  */
 #endif
 static char **lto_o_files;		/* Output files for LTO.  */
-const char *ldout;			/* File for ld stdout.  */
-const char *lderrout;			/* File for ld stderr.  */
 static const char *output_file;		/* Output file for ld.  */
 static const char *nm_file_name;	/* pathname of nm */
 #ifdef LDD_SUFFIX
@@ -384,6 +382,10 @@ static void scan_prog_file (const char *, scanpass, scanfilter);
 void
 tool_cleanup (bool from_signal)
 {
+  /* maybe_unlink may call notice, which is not signal safe.  */
+  if (from_signal)
+verbose = false;
+
   if (c_file != 0 && c_file[0])
 maybe_unlink (c_file);
 
@@ -397,20 +399,6 @@ tool_cleanup (bool from_signal)
 
   if (lto_o_files)
 maybe_unlink_list (lto_o_files);
-
-  if (ldout != 0 && ldout[0])
-{
-  if (!from_signal)
-	dump_ld_file (ldout, stdout);
-  maybe_unlink (ldout);
-}
-
-  if (lderrout != 0 && lderrout[0])
-{
-  if (!from_signal)
-	dump_ld_file (lderrout, stderr);
-  maybe_unlink (lderrout);
-}
 }
 
 static void
@@ -476,77 +464,6 @@ extract_string (const char **pp)
   return XOBFINISH (_obstack, char *);
 }
 
-void
-dump_ld_file (const char *name, FILE *to)
-{
-  FILE *stream = fopen (name, "r");
-
-  if (stream == 0)
-return;
-  while (1)
-{
-  int c;
-  while (c = getc (stream),
-	 c != EOF && (ISIDNUM (c) || c == '$' || c == '.'))
-	obstack_1grow (_obstack, c);
-  if (obstack_object_size (_obstack) > 0)
-	{
-	  const char *word, *p;
-	  char *result;
-	  obstack_1grow (_obstack, '\0');
-	  word = XOBFINISH (_obstack, const char *);
-
-	  if (*word == '.')
-	++word, putc ('.', to);
-	  p = word;
-	  if (!strncmp (p, USER_LABEL_PREFIX, strlen (USER_LABEL_PREFIX)))
-	p += strlen (USER_LABEL_PREFIX);
-
-#ifdef HAVE_LD_DEMANGLE
-	  result = 0;
-#else
-	  if (no_demangle)
-	result = 0;
-	  else
-	result = cplus_demangle (p, DMGL_PARAMS | DMGL_ANSI | DMGL_VERBOSE);
-#endif
-
-	  if (result)
-	{
-	  int diff;
-	  fputs (result, to);
-
-	  diff = strlen (word) - strlen (result);
-	  while (diff > 0 && c == ' ')
-		--diff, putc (' ', to);
-	 

[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.
> 

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 "configure&qu

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.