this is independent of arch, OS version or m64/m32
note that Darwin is fPIC by default.
it's reproducible on a stage1, so should be possible on a cross (w/out needing 'binptils')

it looks like the Warray-bounds-8 is always producing:

"is above array bounds of"

and Wstringop-overflow-3.C is producing:

"writing 1 byte into a region of size 0"

sorry, not a regression - I guess the tests never passed.

I get the following error when running a cross-compiler for x86_64-apple-darwin:

xgcc: error: unrecognized command-line option '-asm_macosx_version_min=10.5'; did you mean '-asm_macosx_version_min='?

Is there a different target I should try or something else I can do to configure it to get around it?

(In reply to Martin Sebor from comment #3)
> I get the following error when running a cross-compiler for
> x86_64-apple-darwin:
> 
> xgcc: error: unrecognized command-line option
> '-asm_macosx_version_min=10.5'; did you mean '-asm_macosx_version_min='?
> 
> Is there a different target I should try or something else I can do to
> configure it to get around it?

what was the configuration line?
you can't expect to build more than cc1/cc1plus, unless you go through the process of build a Mach-O 'binptils' - which would be unnecessary here.

.. (if there's a problem - I can try something on gcc122 later)

(In reply to Iain Sandoe from comment #4)
> (In reply to Martin Sebor from comment #3)
> > I get the following error when running a cross-compiler for
> > x86_64-apple-darwin:
> > 
> > xgcc: error: unrecognized command-line option
> > '-asm_macosx_version_min=10.5'; did you mean '-asm_macosx_version_min='?
> > 
> > Is there a different target I should try or something else I can do to
> > configure it to get around it?
> 
> what was the configuration line?
> you can't expect to build more than cc1/cc1plus, unless you go through the
> process of build a Mach-O 'binptils' - which would be unnecessary here.
> 
> .. (if there's a problem - I can try something on gcc122 later)

../src/configure --prefix=/home/iains/gcc-trunk/darwin --target=x86_64-apple-darwin10 >conf.txt
make -j16 all-host >b.txt 2>e.txt

built working cc1 & cc1plus for me on gcc122.

new FAILs are a regression even if they never passed

Thanks, the trailing 10 in x86_64-apple-darwin10 makes the difference!

Here's a small test case copied from the one around line 335 in g++.dg/warn/Warray-bounds-8.C, and its output with the cross:

  void sink (void*);

  struct B0
  {
    char n;
    char a[0];                    // { dg-message "destination object declared here" }

    B0 () { a[0] = 0; }           // { dg-warning "\\\[-Wstringop-overflow" }
  };

  void gb0 (void)
  {
    struct B0 b0;
    sink (&b0);
  }

$ /build/x86_64-apple-darwin10/gcc-svn/gcc/xgcc -B /build/x86_64-apple-darwin10/gcc-svn/gcc -O2 -S -Wall -Wextra t.C
In constructor 'B0::B0()',
    inlined from 'void gb0()' at t.C:16:13:
t.C:10:16: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
   10 |   B0 () { a[0] = 0; }           // { dg-warning "\\\[-Wstringop-overflow" }
      |           ~~~~~^~~

and with a Linux native GCC:

$ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -S -Wall -Wextra t.C
t.C: In function ‘void gb0()’:
t.C:10:14: warning: array subscript 0 is above array bounds of ‘char [0]’ [-Warray-bounds]
   10 |   B0 () { a[0] = 0; }           // { dg-warning "\\\[-Wstringop-overflow" }
      |           ~~~^
t.C:8:8: note: while referencing ‘B0::a’
    8 |   char a[0];                    // { dg-message "destination object declared here" }
      |        ^


The difference between the two is that with the cross the store is a MEM_REF that the -Warray-bounds warning doesn't handle:

gb0 ()
{
  struct B0 b0;

  <bb 2> [local count: 1073741824]:
  MEM[(char *)&b0 + 1B] = 0;
  sink (&b0);
  b0 ={v} {CLOBBER};
  return;

}

while with the native GCC the store is an ARRAY_REF that -Warray-bounds does handle:

gb0 ()
{
  struct B0 b0;

  <bb 2> [local count: 1073741824]:
  b0 ={v} {CLOBBER};
  b0.a[0] = 0;
  sink (&b0);
  b0 ={v} {CLOBBER};
  return;

}

The MEM_REF is introduced during the early sra pass which the native compiler decides not to run because the B0 ctor doesn't pass the ipa_sra_preliminary_function_checks: it thinks the function cannot be local.  This is based on the result of cgraph_node_cannot_be_local_p_1, specifically the value of node->same_comdat_group which is null with the native GCC and non-null with darwin:

cgraph_node_cannot_be_local_p_1 (cgraph_node *node, void *)
{
  return !(!node->force_output
	   && ((DECL_COMDAT (node->decl)
		&& !node->forced_by_abi
		&& !node->used_from_object_file_p ()
		&& !node->same_comdat_group)
	       || !node->externally_visible));
}

I can't say I know why that is but the difference seems gratuitous.

That aside, ideally, both warnings would handle both forms of accesses but as they don't share code so they improve independently, leading to these kinds of inconsistencies.  I will look into improving -Warray-bounds to handle the MEM_REF case as well.

(In reply to Martin Sebor from comment #7)
> Thanks, the trailing 10 in x86_64-apple-darwin10 makes the difference!

hmm, something's odd then, 'x86_64-apple-darwin' works for me (I put a number out of habit more than necessity, in the host-only case***)

$ ./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=./gcc/xgcc
Target: x86_64-apple-darwin
Configured with: ../src/configure --prefix=/home/iains/gcc-trunk/darwin --target=x86_64-apple-darwin

*** having said that, I do recommend putting something between 10 and 18 there if you are building any libs, since some of them make dumb assumptions absent a darwin version.  However, I don't expect you're building any libs - since that would require the SDK headers and Mach-O 'binutils' neither of which you (probably) have.

====

Thanks for the explanation - I wonder what happens for Linux when you use -fpic -mcmodel=medium?

I'm enhancing -Warray-bounds as mentioned at the end of comment #6.  The patch I'm testing also includes a solution for pr91679.

Patch: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00425.html

with the path applied on x86_64-darwin16 (same results for c++98 / c++17

unless the line count in the test has changed, this is a progression - three fewer fails - but it seems 3 different ones)

XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 16)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 24)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 25)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 26)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 35)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 36)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 37)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 46)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 47)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 48)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 58)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 59)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 68)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 311)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 314)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings, line 318)
FAIL: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14  (test for warnings, line 336)
FAIL: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14  (test for warnings, line 352)
FAIL: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14  (test for warnings, line 366)

====  no change here

FAIL: g++.dg/warn/Wstringop-overflow-3.C  -std=gnu++14  (test for warnings, line 333)
FAIL: g++.dg/warn/Wstringop-overflow-3.C  -std=gnu++14  (test for warnings, line 349)
FAIL: g++.dg/warn/Wstringop-overflow-3.C  -std=gnu++14  (test for warnings, line 363)

this is now fixed on trunk

Author: msebor
Date: Fri Nov  1 21:09:20 2019
New Revision: 277728

URL: https://gcc.gnu.org/viewcvs?rev=277728&root=gcc&view=rev
Log:
PR middle-end/91679 - missing -Warray-bounds accessing a member array in a local buffer
PR middle-end/91647 - new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
PR middle-end/91463 - missing -Warray-bounds accessing past the end of a statically initialized flexible array member
PR middle-end/92312 - bogus -Wstringop-overflow storing into a trailing array backed by larger buffer

gcc/ChangeLog:

	PR middle-end/91679
	PR middle-end/91647
	PR middle-end/91463
	PR middle-end/92312
	* c-family/c-pretty-print.c (direct_abstract_declarator): Print
	bound in zero-length arrays.
	* gcc/c-family/c.opt (-Wzero-length-bounds): New option.
	* gcc/doc/invoke.texi (-Wzero-length-bounds): Document.
	* gimple-match-head.c (try_conditional_simplification): Use memcpy
	instead of a hand-rolled loop to avoid PR 92323.
	* tree-vrp.c (vrp_prop::check_array_ref): Handle trailing arrays
	with initializers.
	(vrp_prop::check_mem_ref): Handle declared struct objects.
	* tree.c (last_field): New function.
	(array_at_struct_end_p): Handle MEM_REF.
	(get_initializer_for): New helper.
	(component_ref_size): Add argument.  Rename locals.  Call
	get_initializer_for instead of fold_ctor_reference.  Correct handling
	of flexible array members.
	* wide-int.h (generic_wide_int <storage>::sign_mask): Assert invariant.

gcc/testsuite/ChangeLog:

	PR middle-end/91679
	PR middle-end/91647
	PR middle-end/91463
	PR middle-end/92312
	* c-c++-common/Warray-bounds-2.c: Disable VRP.  Adjust expected messages.
	* g++.dg/warn/Warray-bounds-8.C: Remove xfails.
	* gcc.dg/Warray-bounds-48.c: New test.
	* gcc.dg/Warray-bounds-49.c: New test.
	* gcc.dg/Wstringop-overflow-16.c: Adjust text of expected messages.
	* gcc.dg/Wstringop-overflow-21.c: New test.
	* gcc.dg/Wzero-length-array-bounds.c: New test.
	* gcc.dg/pr36902.c: Remove xfail.
	* gcc.dg/strlenopt-57.c: Add an expected warning.


Added:
    trunk/gcc/testsuite/gcc.dg/Warray-bounds-48.c
    trunk/gcc/testsuite/gcc.dg/Warray-bounds-49.c
    trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c
    trunk/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-family/c-pretty-print.c
    trunk/gcc/c-family/c.opt
    trunk/gcc/doc/invoke.texi
    trunk/gcc/gimple-match-head.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c
    trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-8.C
    trunk/gcc/testsuite/gcc.dg/Warray-bounds-46.c
    trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-16.c
    trunk/gcc/testsuite/gcc.dg/pr36902.c
    trunk/gcc/testsuite/gcc.dg/strlenopt-57.c
    trunk/gcc/tree-vrp.c
    trunk/gcc/tree.c
    trunk/gcc/tree.h
    trunk/gcc/wide-int.h

Both Warray-bounds-8 and Wstringop-overflow-3.C pass with the Darwin cross now.  Both the Darwin cross and a native GCC 10 now also issue the same warnings for the test case in comment #7.

With the cross I see a bunch of failures in a few other tests (below) but those should get their own bug(s).

c-c++-common/Warray-bounds-2.c
c-c++-common/Warray-bounds.c
gcc.dg/Warray-bounds-31.c
gcc.dg/Wstringop-overflow-13.c