Does it also fail at lower optimization levels?

As of r168294 C62002A:

-O0: PASS 
-O1: PASS
-O2: FAIL
-O3: FAIL

On gcc56 PATH=/home/guerby/install-trunk-168294/bin:$PATH
if you want access to a compiler, the test is gnatchopped in /home/guerby/tmp.

Investigating.

I can confirm the same thing on i386 OpenBSD.  I do NOT see it on x86_64 OpenBSD though.  Note that OpenBSD uses SJLJ exception handling.

O0 - passes
O1 - passes
O2 - fails
O3 - fails


Using built-in specs.
COLLECT_GCC=gnatgcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-aux-openbsd4.7/4.6.0/lto-wrapper
Target: i386-aux-openbsd4.7
Configured with: /home/marino/gnat_port/gen_5/work/gcc-4.6-20101221/configure --enable-languages=c,ada --build=i386-aux-openbsd4.7 --program-prefix=gnat --prefix=/usr/local --with-system-zlib --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --with-libiconv-prefix=/usr/local --enable-threads=yes --enable-shared --disable-bootstrap --disable-libgomp --disable-libssp --disable-nls
Thread model: posix
gcc version 4.6.0 20101221 (experimental) -=> GNAT AUX [OpenBSD] (GCC)

Reconfirm with an up-to-date tree, ACATS was clean on i586/SJLJ this morning.

The autotesters should pick this change within a day or two.

I confirm that test c62002a is still failing on OpenBSD i386 as of today (SVN 168458)

OK, fixing...

Author: ebotcazou
Date: Wed Jan  5 11:23:40 2011
New Revision: 168508

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168508
Log:
	PR tree-optimization/47005
	* tree-sra.c (struct access): Add 'non_addressable' bit.
	(create_access): Set it for a DECL_NONADDRESSABLE_P field.
	(decide_one_param_reduction): Return 0 if the parameter is passed by
	reference and one of the accesses in the group is non_addressable.

Added:
    trunk/gcc/testsuite/gnat.dg/opt14.adb
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-sra.c

Done.

I rebuilt OpenBSD i386 using then Jan 5 daily bump (SVN 168495) and patched it with tree-src.c file.

ACATS 62002a now passes, thanks.

> ACATS 62002a now passes, thanks.

Thanks for confirming.  ACATS is clean on both i386 and i586 Linux SJLJ now, are there any remaining failures on BSD platforms?

(In reply to comment #12)
> Thanks for confirming.  ACATS is clean on both i386 and i586 Linux SJLJ now,
> are there any remaining failures on BSD platforms?

There are no ACATS or gnat.dg failures on the ZCX platforms (FreeBSD, DragonFlyBSD, NetBSD: i386 and x86_64)

The regression tests just completed for OpenBSD i386.
There is one failure on ACATS (cb1010a timeout)* 
Between yesterday and today, the test sse_nolib result went from passing to "UNSUPPORTED"


Comments:
1) Between yesterday and today, test c390001 wouldn't even compile, but now it passes.
2)* I haven't investigated cb1010a timeout yet, but I think the problem is with OpenBSD, not gnat
3) the STACK_CHECK_STATIC_BUILTIN macro value has no effect on OpenBSD.  I was expecting failures on c5210[3x,4x,4y] and cb1010[a,b,c] but they don't fail.
4) Despite DWARF2_UNWIND_INFO being set to 0 (meaning MD_UNWIND_SUPPORT macro is ignored), the null_deref and stack_check gnat.dg tests pass.  in gdb, the segfault comes and then the program just exits normally.
5) I don't know if the behavior of 3) and 4) is normal for an SJLJ target, or if it's because apparently there's some missing support on OpenBSD for DWARF2 (if I try to set OpenBSD32 to ZCX handling the compile breaks with the unwind_context structure considered illegal), and commit commits also indicate something is missing for OpenBSD.

The summary is that the OpenBSD port is currently better then it has ever been, and one remaining ACATS failure is probably related to how OpenBSD handles their stack.  As of today, I don't have any errors to report, but that may change as I discover more about the issues I just outlined above.

> The regression tests just completed for OpenBSD i386.
> There is one failure on ACATS (cb1010a timeout)* 

This is a stack checking test.

> 3) the STACK_CHECK_STATIC_BUILTIN macro value has no effect on OpenBSD.  I was
> expecting failures on c5210[3x,4x,4y] and cb1010[a,b,c] but they don't fail.

The tests should pass w and w/o it on x86, but it's better to define it.

> 4) Despite DWARF2_UNWIND_INFO being set to 0 (meaning MD_UNWIND_SUPPORT macro
> is ignored), the null_deref and stack_check gnat.dg tests pass.  in gdb, the
> segfault comes and then the program just exits normally.

This is expected with SJLJ exceptions, you don't need MD_UNWIND_SUPPORT.

> The summary is that the OpenBSD port is currently better then it has ever been,
> and one remaining ACATS failure is probably related to how OpenBSD handles
> their stack.  As of today, I don't have any errors to report, but that may
> change as I discover more about the issues I just outlined above.

Great, thanks for the detailed report.

[off PR]

Hi Eric,
Can you clarify one statement?
Regarding the ten "stack-check" tests as I can them (c5210[3x,4x,4y], 
cb1010[a,c,d], null_deref[1,2], stack-check[1,2]), I now understand that 
it is expected that these tests pass on SJLJ targets.

Are these true passes meaning SJLJ targets are fully capable of handling 
stack overflow and segfaults?  Or are these results just false positives?

Thanks,
John


ebotcazou at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005
> 
> --- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-01-05 15:33:24 UTC ---
>> The regression tests just completed for OpenBSD i386.
>> There is one failure on ACATS (cb1010a timeout)* 
> 
> This is a stack checking test.
> 
>> 3) the STACK_CHECK_STATIC_BUILTIN macro value has no effect on OpenBSD.  I was
>> expecting failures on c5210[3x,4x,4y] and cb1010[a,b,c] but they don't fail.
> 
> The tests should pass w and w/o it on x86, but it's better to define it.
> 
>> 4) Despite DWARF2_UNWIND_INFO being set to 0 (meaning MD_UNWIND_SUPPORT macro
>> is ignored), the null_deref and stack_check gnat.dg tests pass.  in gdb, the
>> segfault comes and then the program just exits normally.
> 
> This is expected with SJLJ exceptions, you don't need MD_UNWIND_SUPPORT.
> 
>> The summary is that the OpenBSD port is currently better then it has ever been,
>> and one remaining ACATS failure is probably related to how OpenBSD handles
>> their stack.  As of today, I don't have any errors to report, but that may
>> change as I discover more about the issues I just outlined above.
> 
> Great, thanks for the detailed report.
>

> Regarding the ten "stack-check" tests as I can them (c5210[3x,4x,4y], 
> cb1010[a,c,d], null_deref[1,2], stack-check[1,2]), I now understand that 
> it is expected that these tests pass on SJLJ targets.

null_deref[1,2] are not really about stack checking, but I get the point.

> Are these true passes meaning SJLJ targets are fully capable of handling 
> stack overflow and segfaults?  Or are these results just false positives?

Stack checking per se is orthogonal to ZCX vs SJLJ.  What isn't orthogonal is the handling of segfaults (hence the connection to stack checking done with probes): SJLJ handles segfaults out of the box whereas ZCX needs MD_UNWIND_SUPPORT.  So, yes, the aforementioned 10 special tests are expected to pass on SJLJ targets out of the box, i.e. without additional target-specific support.

For reference ACATS is now clean on arm-linux as well:

http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00648.html

LAST_UPDATED: Fri Jan  7 00:49:12 UTC 2011 (revision 168562)
Native configuration is armv7l-unknown-linux-gnueabi
		=== acats Summary ===
# of expected passes		2321
# of unexpected failures	0

Thanks Eric :).

> For reference ACATS is now clean on arm-linux as well:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00648.html
> 
> LAST_UPDATED: Fri Jan  7 00:49:12 UTC 2011 (revision 168562)
> Native configuration is armv7l-unknown-linux-gnueabi
>         === acats Summary ===
> # of expected passes        2321
> # of unexpected failures    0
> 
> Thanks Eric :).

You're welcome.  Thanks for reporting the problem.