Re: pass_stdarg problem when run after pass_lim

[Tom de Vries]

On 02-02-15 16:47, Michael Matz wrote:

Hi,

On Mon, 2 Feb 2015, Tom de Vries wrote:


I've minimized the vaarg-4a.c failure, and added it as testcase to the patch
series as gcc.target/x86_64/abi/callabi/vaarg-4.c.

The problem is in this code:
...
   e = va_arg (argp, char *);
   e = va_arg (argp, char *);
...

which is translated into:
...
   :
   argp.1 = argp_3(D);

   :
   argp.12_11 = &argp.1;
   _12 = *argp.12_11;
   _13 = _12 + 8;
   *argp.12_11 = _13;

   :
   argp.3 = argp_3(D);

   :
   argp.13_15 = &argp.3;
   _16 = *argp.13_15;
   _17 = _16 + 8;
   *argp.13_15 = _17;
   _19 = MEM[(char * *)_16];
   e_8 = _19;
...


That looks like non-x86-64 ABI code.  It builds with -mabi=ms, and it
seems the particular path taken therein doesn't write back to the aplist
if it's not locally created with va_start, but rather given as argument.
Or rather, if it is not addressible (like with x86-64 ABI, where it's
either addressible because of va_start, or is a pointer to struct due to
array decay).  The std_gimplify_va_arg_expr might need more changes.



I've managed to fix that, using these lines in std_gimplify_va_arg_expr:
...
  if (TREE_CODE (tmp) == ADDR_EXPR
  && TREE_OPERAND (tmp, 0) != valist)
{
  /* If we're passing the address of a temp, instead of the addres of
 valist, we need to copy back the value of the temp to valist.  */
  assign = gimple_build_assign (valist, TREE_OPERAND (tmp, 0));
  gimple_seq_add_stmt (pre_p, assign);
}
...
[ I've pushed the current state (now based on a current commit) to 
vries/expand-va-arg-at-pass-stdarg again. ]


Ironically, that fix breaks the va_list_gpr/fpr_size optimization, so I've 
disabled that by default for now.


I've done a non-bootstrap and bootstrap build using all languages.

The non-bootstrap test shows (at least) two classes of real failures:
- gcc.c-torture/execute/20020412-1.c, gcc.target/i386/memcpy-strategy-4.c and
  gcc.dg/lto/20090706-1_0.c.
  These are test-cases with vla as va_arg argument. It ICEs in
  force_constant_size with call stack
  gimplify_va_arg_expr -> create_tmp_var -> gimple_add_tmp_var ->
  force_constant_size
- most/all va_arg tests with flto, f.i. gcc.c-torture/execute/stdarg-1.c.
  It segfaults in lto1 during pass_stdarg, in gimplify_va_arg_internal when
  accessing have_va_type which is NULL_TREE after
  'have_va_type = targetm.canonical_va_list_type (have_va_type)'.

I don't think the flto issue is difficult to fix.  But the vla issue probably 
needs more time than I have available right now.


Thanks,
- Tom

Re: pass_stdarg problem when run after pass_lim

[Michael Matz]

Hi,

On Tue, 3 Feb 2015, Tom de Vries wrote:

> Ironically, that fix breaks the va_list_gpr/fpr_size optimization, so 
> I've disabled that by default for now.
> 
> I've done a non-bootstrap and bootstrap build using all languages.
> 
> The non-bootstrap test shows (at least) two classes of real failures:
> - gcc.c-torture/execute/20020412-1.c, gcc.target/i386/memcpy-strategy-4.c and
>   gcc.dg/lto/20090706-1_0.c.
>   These are test-cases with vla as va_arg argument. It ICEs in
>   force_constant_size with call stack
>   gimplify_va_arg_expr -> create_tmp_var -> gimple_add_tmp_var ->
>   force_constant_size

Hah, yeah, that's the issue I remembered with create_tmp_var.  This needs 
a change in how to represent the va_arg "call", because the LHS can't be a 
temporary that's copied to the real LHS afterwards.

> - most/all va_arg tests with flto, f.i. gcc.c-torture/execute/stdarg-1.c.
>   It segfaults in lto1 during pass_stdarg, in gimplify_va_arg_internal when
>   accessing have_va_type which is NULL_TREE after
>   'have_va_type = targetm.canonical_va_list_type (have_va_type)'.
> 
> I don't think the flto issue is difficult to fix.  But the vla issue 
> probably needs more time than I have available right now.

I'll think about this.


Ciao,
Michael.

Re: pass_stdarg problem when run after pass_lim

[Jakub Jelinek]

On Tue, Feb 03, 2015 at 02:36:53PM +0100, Michael Matz wrote:
> Hi,
> 
> On Tue, 3 Feb 2015, Tom de Vries wrote:
> 
> > Ironically, that fix breaks the va_list_gpr/fpr_size optimization, so 
> > I've disabled that by default for now.
> > 
> > I've done a non-bootstrap and bootstrap build using all languages.
> > 
> > The non-bootstrap test shows (at least) two classes of real failures:
> > - gcc.c-torture/execute/20020412-1.c, gcc.target/i386/memcpy-strategy-4.c 
> > and
> >   gcc.dg/lto/20090706-1_0.c.
> >   These are test-cases with vla as va_arg argument. It ICEs in
> >   force_constant_size with call stack
> >   gimplify_va_arg_expr -> create_tmp_var -> gimple_add_tmp_var ->
> >   force_constant_size
> 
> Hah, yeah, that's the issue I remembered with create_tmp_var.  This needs 
> a change in how to represent the va_arg "call", because the LHS can't be a 
> temporary that's copied to the real LHS afterwards.

It can be lowered during gimplification to some internal call.  What
arguments and return values will it have can be decided based on what will
be most suitable for the lowering.

Jakub

Re: pass_stdarg problem when run after pass_lim

[Michael Matz]

Hi,

On Tue, 3 Feb 2015, Jakub Jelinek wrote:

> It can be lowered during gimplification to some internal call.

That's what my patch does :)

> What arguments and return values will it have can be decided based on 
> what will be most suitable for the lowering.

And that as well, just the concrete choice I did doesn't work for all 
cases, so that needs some change.


Ciao,
Michael.

Re: gcc rodata regression

[Simon Glass]

Hi Segher,

On 2 February 2015 at 01:16, Segher Boessenkool
 wrote:
> On Sat, Jan 31, 2015 at 05:09:29PM -0700, Simon Glass wrote:
>> I have been fighting with a strange problem on ARM where gcc puts all
>> the .rodata from a number of files lumped into a single .rodata
>> section even when -fdata-sections is used.
>>
>> I searched and found a bug report here:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303
>>
>> which exactly describes the problem I see.
>
> You could try this patch.  I think there were still some problems with
> it, there must have been some reason I didn't submit it.  Cannot have
> been just laziness :-P

Thanks, I will give it a try and let you know what I find.

[snip]

Regards,
Simon

Re: ARM Linux EABI: unwinding through a segfault handler

[mads_bn]

Paul, do you know of any progress on this since 2011?

I cannot find any attempt to use your suggested ".personality
__gnu_personality_sigframe" in prologue for "__default_sa_restorer_v2".
I still need to learn more about this syntax...
I'm not building the glibc myself, but can probably let a friend try it if
we believe it is the right fix.

We hope to be able to make some poor man's backtrace's in syslog, when fatal
signals occurs in embedded systems (SIGSEGV, abort->SIGABRT etc).
This was quite useful on x86 targets in the past.

We are currently upgrading from EGLIBC 2.16 to 2.19 (yocto builds) and I
also tried to browse the regular GLIBC head.
With EGLIBC 2.16 I made a small test program and the backtrace always
stopped at gsignal(),
but if my signal_handler then triggered a coredump using raise(SIGQUIT) then
gdb was able to backtrace beyond the signal handler (see below).

http://www.eglibc.org/cgi-bin/viewvc.cgi/branches/eglibc-2_19/libc/ports/sysdeps/unix/sysv/linux/arm/sigrestorer.S?view=markup

  
https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/arm/sigrestorer.S;h=71f9e25804bedb58cb06396834e8cea05dedc191;hb=refs/heads/master

   

arm7$ ./test
# backtrace before signal raised
backtrace() returned 6 addresses
libdemo.so(_Z11doBacktracePKci+0x44) [0xb6f3ae38]
libdemo.so(_Z2f3v+0x1c) [0xb6f3af24]
libdemo.so(_Z2f2v+0x20) [0xb6f3af54]
libdemo.so(_Z2f1v+0x28) [0xb6f3af8c]
./test() [0x8740]
/lib/libc.so.6(__libc_start_main+0x110) [0x444b7ea8]
abort
# backtrace after signal raised, signal_handler dumps backtrace and raise
SIGQUIT to core dump
--8< Stack 8<--
Error: signal 6:
libdemo.so(_ZN14doBacktraceEi+0x30)[0xb6f3b4f8]
libdemo.so(_ZN14signal_handlerEi+0x134)[0xb6f3b3b4]
/lib/libc.so.6(__default_sa_restorer_v2+0x0)[0x444ce1d0]
/lib/libc.so.6(gsignal+0x3c)[0x444ccf28]
--8<---8<--
Quit (core dumped)
===
$ gdb test core
...
Program terminated with signal 3, Quit.
#0  0x444ccf28 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x444ccf28 in raise () from /lib/libc.so.6
#1  0xb6f3b488 in signal_handler (sig=6) at mysignalhandler.cpp:176
#2  
#3  0x444ccf28 in raise () from /lib/libc.so.6
#4  0x444d09a8 in abort () from /lib/libc.so.6
#5  0xb6f3afc0 in f1 () at foo.cpp:57
#6  0x8740 in main ()



--
View this message in context: 
http://gcc.1065356.n5.nabble.com/ARM-Linux-EABI-unwinding-through-a-segfault-handler-tp692287p1117716.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: ARM Linux EABI: unwinding through a segfault handler

[mads_bn]

Paul, do you know of any progress on this since 2011?

I cannot find any attempt to use your suggested ".personality
__gnu_personality_sigframe" in prologue for "__default_sa_restorer_v2".
I still need to learn more about this syntax...
I'm not building the glibc myself, but can probably let a friend try it if
we believe it is the right fix.

We hope to be able to make some poor man's backtrace's in syslog, when fatal
signals occurs in embedded systems (SIGSEGV, abort->SIGABRT etc).
This was quite useful on x86 targets in the past.

We are currently upgrading from EGLIBC 2.16 to 2.19 (yocto builds) and I
also tried to browse the regular GLIBC head.
With EGLIBC 2.16 I made a small test program and the backtrace always
stopped at gsignal(),
but if my signal_handler then triggered a coredump using raise(SIGQUIT) then
gdb was able to backtrace beyond the signal handler (see below).

http://www.eglibc.org/cgi-bin/viewvc.cgi/branches/eglibc-2_19/libc/ports/sysdeps/unix/sysv/linux/arm/sigrestorer.S?view=markup

  
https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/arm/sigrestorer.S;h=71f9e25804bedb58cb06396834e8cea05dedc191;hb=refs/heads/master

   

arm7$ ./test
# backtrace before signal raised
backtrace() returned 6 addresses
libdemo.so(_Z11doBacktracePKci+0x44) [0xb6f3ae38]
libdemo.so(_Z2f3v+0x1c) [0xb6f3af24]
libdemo.so(_Z2f2v+0x20) [0xb6f3af54]
libdemo.so(_Z2f1v+0x28) [0xb6f3af8c]
./test() [0x8740]
/lib/libc.so.6(__libc_start_main+0x110) [0x444b7ea8]
abort
# backtrace after signal raised, signal_handler dumps backtrace and raise
SIGQUIT to core dump
--8< Stack 8<--
Error: signal 6:
libdemo.so(_ZN14doBacktraceEi+0x30)[0xb6f3b4f8]
libdemo.so(_ZN14signal_handlerEi+0x134)[0xb6f3b3b4]
/lib/libc.so.6(__default_sa_restorer_v2+0x0)[0x444ce1d0]
/lib/libc.so.6(gsignal+0x3c)[0x444ccf28]
--8<---8<--
Quit (core dumped)
===
$ gdb test core
...
Program terminated with signal 3, Quit.
#0  0x444ccf28 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x444ccf28 in raise () from /lib/libc.so.6
#1  0xb6f3b488 in signal_handler (sig=6) at mysignalhandler.cpp:176
#2  
#3  0x444ccf28 in raise () from /lib/libc.so.6
#4  0x444d09a8 in abort () from /lib/libc.so.6
#5  0xb6f3afc0 in f1 () at foo.cpp:57
#6  0x8740 in main ()



--
View this message in context: 
http://gcc.1065356.n5.nabble.com/ARM-Linux-EABI-unwinding-through-a-segfault-handler-tp692287p1117717.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: Rename C files to .c in GCC source

[Jonny Grant]

On 02/02/15 21:18, Andrew Pinski wrote:

On Mon, Feb 2, 2015 at 1:11 PM, Jonny Grant  wrote:



On 01/02/15 16:34, Kevin Ingwersen (Ingwie Phoenix) wrote:




Am 01.02.2015 um 17:09 schrieb Eli Zaretskii :


Date: Sat, 31 Jan 2015 01:55:29 +
From: Jonathan Wakely 
Cc: Andrew Pinski , "gcc@gcc.gnu.org"
, Jonny Grant 

These files are only compiled by GCC's own build system, with GCC's
own makefiles, so we know we invoke the C++ compiler and so the
language isn't inferred from the file extension, and so we aren't
relying on case-sensitive file systems.



That is true for building GCC.  But what about editors and other
development tools?  They _will_ be affected.



Indeed. Atom keeps thinking .C is an actual „ANSI C“ thing. If I were to
make a suggestion to the GCC dev’s, then I probably could also swiftly word
it as:

$ find gcc-src -name "*.C“ | while read f; do mv $f $(echo $f | sed
's/\.C/\.cxx/g’); done

In other words; .cxx, .cpp or .cc seems like a solution that works across
platforms. Since .cc is already used at some places, I would recommend that
this is to be the extension to choose.

One does not neccessarily need to make a dev apply hacks all over just to
start development.



Hello

Is this a consensus agreement to rename those .C -> .cc ?


There are around 11k files that have the .C ending to them; all in the
testsuite.  I don't think it make sense to move them.


How many minutes labor is this task?

Regards, Jonny

Re: Rename C files to .c in GCC source

[Andreas Schwab]

Jonny Grant  writes:

> How many minutes labor is this task?

What does it fix?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Rename C files to .c in GCC source

[Joseph Myers]

On Tue, 3 Feb 2015, Jonny Grant wrote:

> > There are around 11k files that have the .C ending to them; all in the
> > testsuite.  I don't think it make sense to move them.
> 
> How many minutes labor is this task?

It's desirable for test names to be stable so that results can be compared 
over time, which means a presumption that renaming an existing testcase is 
bad unless the name is really, really confusing (a pair testname-1.c and 
testname_1.c might count as confusing, but not test.C unless there's 
another very similar test in the same directory, in which case the "test" 
part would need changing).

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

Re: Rename C files to .c in GCC source

[Kevin Ingwersen (Ingwie Phoenix)]

> Am 04.02.2015 um 00:20 schrieb Andreas Schwab :
> 
> Jonny Grant  writes:
> 
>> How many minutes labor is this task?
> 
> What does it fix?

How many hacks/workarounds can be avoided?

Re: Rename C files to .c in GCC source

[Andrew Pinski]

On Tue, Feb 3, 2015 at 4:22 PM, Kevin Ingwersen (Ingwie Phoenix)
 wrote:
>
>> Am 04.02.2015 um 00:20 schrieb Andreas Schwab :
>>
>> Jonny Grant  writes:
>>
>>> How many minutes labor is this task?
>>
>> What does it fix?
>
> How many hacks/workarounds can be avoided?


None.

building against a temporary install dir?

[DJ Delorie]

So here's what I'm trying to do...  I want to build gcc, binutils, and
newlib, run tests, and IF the tests pass, THEN install them all.
However, gcc needs an installed newlib to build it's libraries.

I tried installing newlib into $DESTDIR$PREFIX but gcc ignores
$DESTDIR during the compile.

Any ideas on how to do this, short of building and installing
everything (or at least gcc and newlib) twice?