[Bug preprocessor/57191] New: GCC cross-compilers built with MinGW do no include correct directory

[MatthewS.Grochowalski at ge dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57191



 Bug #: 57191

   Summary: GCC cross-compilers built with MinGW do no include

correct directory

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: preprocessor

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: matthews.grochowal...@ge.com





It appears MinGW always overrides the definition of NATIVE_SYSTEM_HEADER_DIR

given on the command line. Running:



echo "NATIVE_SYSTEM_HEADER_DIR" | cpp -DNATIVE_SYSTEM_HEADER_DIR=/usr/include



produces:



c:/MinGW2/msys/1.0/include



I believe this change was introduced as a fix for bug 52947.



When building gcc with the "--with-sysroot" config option,

NATIVE_SYSTEM_HEADER_DIR is supposed to be defined as the TARGET system's

default include directory in gcc/cppdefault.c. In my case, this would be

/usr/include as I'm targeting GNU/Linux.

"-DNATIVE_SYSTEM_HEADER_DIR=/usr/include" is being passed to the build system

gcc (i686-pc-mingw32-gcc).



Because of MinGW's silent changing of NATIVE_SYSTEM_HEADER_DIR, the resulting

cross-compiler tries to look in $SYSROOTc:/MinGW2/msys/1.0/include for the

target system includes instead of $SYSROOT/usr/include.

[Bug preprocessor/57191] GCC cross-compilers built with MinGW do no include correct directory

[MatthewS.Grochowalski at ge dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57191



Matt Grochowalski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

   See Also|http://gcc.gnu.org/bugzilla |

   |/show_bug.cgi?id=52947  |

 Resolution||INVALID



--- Comment #1 from Matt Grochowalski  
2013-05-06 22:26:29 UTC ---

Never mind, this is due to MSYS's path mangling.

[Bug bootstrap/66744] New: Bootstrap failure due to conflicting access() on i686-w64-mingw32

[MatthewS.Grochowalski at ge dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66744

Bug ID: 66744
   Summary: Bootstrap failure due to conflicting access() on
i686-w64-mingw32
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: MatthewS.Grochowalski at ge dot com
  Target Milestone: ---

Attempting to build trunk r225313 with --enable-languages=c,c++,ada
--enable-checking=release --disable-nls --disable-werror --disable-multilib
--build=i686-w64-mingw32 --host=i686-w64-mingw32
--with-gmp=/c/toolchain/prereqs --with-mpc=/c/toolchain/prereqs
--with-mpfr=/c/toolchain/prereqs --prefix=/c/toolchain/gcc-mingw
--target=i686-w64-mingw32 --disable-win32-registry --disable-shared
--with-sysroot=/c/toolchain/gcc-mingw --enable-version-specific-runtime-libs

Using gcc version 4.9.2 (i686-win32-dwarf-rev2, Built by MinGW-W64 project)

Stage1 fails with the following:
../../gcc/gcc/tree-sra.c:875:46: error: macro "access" requires 2 arguments,
but only 1 given
   struct access *access = new struct access ();
  ^
../../gcc/gcc/tree-sra.c:2410:46: error: macro "access" requires 2 arguments,
but only 1 given
   struct access *access = new struct access ();
  ^
Makefile:1071: recipe for target `tree-sra.o' failed
make[3]: *** [tree-sra.o] Error 1

It's conflicting with access macro definition in the mingw32-w64 C io.h header:
#ifdef __USE_MINGW_ACCESS
/*  Old versions of MSVCRT access() just ignored X_OK, while the version
shipped with Vista, returns an error code.  This will restore the
old behaviour  */
static inline int __mingw_access (const char *__fname, int __mode) {
  return  _access (__fname, __mode & ~X_OK);
}

#define access(__f,__m)  __mingw_access (__f, __m)
#endif

This appears to have been introduced by r223956.

[Bug bootstrap/66744] [6 Regression] Bootstrap failure due to conflicting access() on i686-w64-mingw32

[MatthewS.Grochowalski at ge dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66744

--- Comment #3 from Matt Grochowalski  ---
The bootstrap succeeds after applying the patch.

[Bug ada/66837] New: Non-Native Default_Scalar_Storage_Order Breaks Enum'Image

[MatthewS.Grochowalski at ge dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66837

Bug ID: 66837
   Summary: Non-Native Default_Scalar_Storage_Order Breaks
Enum'Image
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: MatthewS.Grochowalski at ge dot com
  Target Milestone: ---

Created attachment 35949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35949&action=edit
Test Case

Encountered with build of r225405 of the scalar-storage-order branch.

Attached test case dies with a STORAGE_ERROR when calling 'Image() on
enumeration values.

The values in the index array generated by
Exp_Imgv.Build_Enumeration_Image_Tables are being byte-swapped due to the
Default_Scalar_Storage_Order pragma.

System.Img_Enum_New.Image_Enumeration_16 (in this case) treats the index array
as native scalar storage order, causing things to blow up.

[Bug ada/66837] Non-Native Default_Scalar_Storage_Order Breaks Enum'Image

[MatthewS.Grochowalski at ge dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66837

--- Comment #2 from Matt Grochowalski  ---
Created attachment 36029
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36029&action=edit
Fix for this case

Barring a more general method, this seems to fix enumeration images.