Re: [patch win32]: fix for PR target/41943

Re: [patch win32]: fix for PR target/41943

[Ozkan Sezer]

>> That's right and therefore I dislike this patch and would prefer to
>> have that one Ozkan mentioned already. The issue is that sysroot &
>> cross- includes come after gcc's internal header, which is causing the
>> pain that it isn't absolutely predicatable, if system-headers are
>> reached or not.
>> By changing the order of gcc's internal to the end of the include
>> chain, it would be solved for all cases.
>
> Well, I think moving gcc headers to the end of the include chain is
> just wrong. ?They are supposed to override host ones (which is
> why they are called "fixincludes"). ?Why not fixinclude mingw?
>
> Richard.
>

The message that is referred to is this :
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01450.html
... and its subject line is wrong/misleading: The patch contained there
(http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01450/do_fixinclude_later.diff)
moves the gcc-private headers and not the fixed headers.

--
Ozkan

Re: [patch win32]: fix for PR target/41943

[Richard Henderson]

On 07/22/2010 06:27 AM, Ozkan Sezer wrote:
>>> That's right and therefore I dislike this patch and would prefer to
>>> have that one Ozkan mentioned already. The issue is that sysroot &
>>> cross- includes come after gcc's internal header, which is causing the
>>> pain that it isn't absolutely predicatable, if system-headers are
>>> reached or not.
>>> By changing the order of gcc's internal to the end of the include
>>> chain, it would be solved for all cases.
>>
>> Well, I think moving gcc headers to the end of the include chain is
>> just wrong. ?They are supposed to override host ones (which is
>> why they are called "fixincludes"). ?Why not fixinclude mingw?
>>
>> Richard.
>>
> 
> The message that is referred to is this :
> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01450.html
> ... and its subject line is wrong/misleading: The patch contained there
> (http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01450/do_fixinclude_later.diff)
> moves the gcc-private headers and not the fixed headers.

We're not going to do that either.  The include order for all gcc is
gcc-private > fixincludes > system.


r~

Re: [patch win32]: fix for PR target/41943

[Ozkan Sezer]

On Thu, Jul 22, 2010 at 7:00 PM, Richard Henderson <rth@redhat.com> wrote:
> On 07/22/2010 06:27 AM, Ozkan Sezer wrote:
>>>> That's right and therefore I dislike this patch and would prefer to
>>>> have that one Ozkan mentioned already. The issue is that sysroot &
>>>> cross- includes come after gcc's internal header, which is causing the
>>>> pain that it isn't absolutely predicatable, if system-headers are
>>>> reached or not.
>>>> By changing the order of gcc's internal to the end of the include
>>>> chain, it would be solved for all cases.
>>>
>>> Well, I think moving gcc headers to the end of the include chain is
>>> just wrong. ?They are supposed to override host ones (which is
>>> why they are called "fixincludes"). ?Why not fixinclude mingw?
>>>
>>> Richard.
>>>
>>
>> The message that is referred to is this :
>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01450.html
>> ... and its subject line is wrong/misleading: The patch contained there
>> (http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01450/do_fixinclude_later.diff)
>> moves the gcc-private headers and not the fixed headers.
>
> We're not going to do that either.  The include order for all gcc is
> gcc-private > fixincludes > system.
>
>
> r~
>

That patch doesn't change the order unconditionally. Why is a
target option is unacceptable?

--
Ozkan

Re: [patch win32]: fix for PR target/41943

[Richard Henderson]

On 07/22/2010 09:02 AM, Ozkan Sezer wrote:
>> We're not going to do that either.  The include order for all gcc is
>> gcc-private > fixincludes > system.
>>
> 
> That patch doesn't change the order unconditionally. Why is a
> target option is unacceptable?

Because I think it's conceptually flawed.

The few headers that are in gcc-private contain that which may be
considered internal to the compiler.  Thus it should have the 
highest priority.


r~

Re: [patch win32]: fix for PR target/41943

[Ozkan Sezer]

On Thu, Jul 22, 2010 at 7:05 PM, Richard Henderson <rth@redhat.com> wrote:
> On 07/22/2010 09:02 AM, Ozkan Sezer wrote:
>>> We're not going to do that either.  The include order for all gcc is
>>> gcc-private > fixincludes > system.
>>>
>>
>> That patch doesn't change the order unconditionally. Why is a
>> target option is unacceptable?
>
> Because I think it's conceptually flawed.
>
> The few headers that are in gcc-private contain that which may be
> considered internal to the compiler.  Thus it should have the
> highest priority.
>
>
> r~
>

Kai, then this leaves us with the option of providing a USER_H in
our target, even if we don't like it.

--
Ozkan

Re: [patch win32]: fix for PR target/41943

[Kai Tietz]

2010/7/22 Richard Henderson <rth@redhat.com>:
> On 07/22/2010 09:02 AM, Ozkan Sezer wrote:
>>> We're not going to do that either.  The include order for all gcc is
>>> gcc-private > fixincludes > system.
>>>
>>
>> That patch doesn't change the order unconditionally. Why is a
>> target option is unacceptable?
>
> Because I think it's conceptually flawed.
>
> The few headers that are in gcc-private contain that which may be
> considered internal to the compiler.  Thus it should have the
> highest priority.
>
>
> r~
>

Hmm, internal and private? Well, AFAICS are most just standard
C-runtime headers. When gcc's internal headers have to come first in
priority - as you say - then the gcc-include-dir and the
fixed-include-dir should come also before the local-include-dir and
prefix-include-dir, as those directories are contain for native
compilers the system-headers.
Here we have an inconsitency IMHO for cross-compilers and
sysroot-buidls, as here the system-headers are (as you described
above) coming after gcc's internal headers and fix-include.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [patch win32]: fix for PR target/41943

[NightStrike]

On Thu, Jul 22, 2010 at 12:05 PM, Richard Henderson <rth@redhat.com> wrote:
> On 07/22/2010 09:02 AM, Ozkan Sezer wrote:
>>> We're not going to do that either.  The include order for all gcc is
>>> gcc-private > fixincludes > system.
>>>
>>
>> That patch doesn't change the order unconditionally. Why is a
>> target option is unacceptable?
>
> Because I think it's conceptually flawed.

Isn't it conceptually flawed to have a fixinclude header system that
is broken for a target platform?

Re: [patch win32]: fix for PR target/41943

[Richard Henderson]

On 07/22/2010 12:36 PM, NightStrike wrote:
> On Thu, Jul 22, 2010 at 12:05 PM, Richard Henderson <rth@redhat.com> wrote:
>> On 07/22/2010 09:02 AM, Ozkan Sezer wrote:
>>>> We're not going to do that either.  The include order for all gcc is
>>>> gcc-private > fixincludes > system.
>>>>
>>>
>>> That patch doesn't change the order unconditionally. Why is a
>>> target option is unacceptable?
>>
>> Because I think it's conceptually flawed.
> 
> Isn't it conceptually flawed to have a fixinclude header system that
> is broken for a target platform?

Not conceptually, no.  That's a mere bug.


r~

Re: [patch win32]: fix for PR target/41943

[NightStrike]

On Thu, Jul 22, 2010 at 4:06 PM, Richard Henderson <rth@redhat.com> wrote:
> On 07/22/2010 12:36 PM, NightStrike wrote:
>> On Thu, Jul 22, 2010 at 12:05 PM, Richard Henderson <rth@redhat.com> wrote:
>>> On 07/22/2010 09:02 AM, Ozkan Sezer wrote:
>>>>> We're not going to do that either.  The include order for all gcc is
>>>>> gcc-private > fixincludes > system.
>>>>>
>>>>
>>>> That patch doesn't change the order unconditionally. Why is a
>>>> target option is unacceptable?
>>>
>>> Because I think it's conceptually flawed.
>>
>> Isn't it conceptually flawed to have a fixinclude header system that
>> is broken for a target platform?
>
> Not conceptually, no.  That's a mere bug.

Then can we fix gcc's headers to work with Win64?

Re: [patch win32]: fix for PR target/41943

[Richard Henderson]

On 07/22/2010 01:25 PM, NightStrike wrote:
>> Not conceptually, no.  That's a mere bug.
> 
> Then can we fix gcc's headers to work with Win64?

Isn't that what this thread is trying to do?


r~

Re: [patch win32]: fix for PR target/41943

[Kai Tietz]

2010/7/22 NightStrike <nightstrike@gmail.com>:
> On Thu, Jul 22, 2010 at 4:06 PM, Richard Henderson <rth@redhat.com> wrote:
>> On 07/22/2010 12:36 PM, NightStrike wrote:
>>> On Thu, Jul 22, 2010 at 12:05 PM, Richard Henderson <rth@redhat.com> wrote:
>>>> On 07/22/2010 09:02 AM, Ozkan Sezer wrote:
>>>>>> We're not going to do that either.  The include order for all gcc is
>>>>>> gcc-private > fixincludes > system.
>>>>>>
>>>>>
>>>>> That patch doesn't change the order unconditionally. Why is a
>>>>> target option is unacceptable?
>>>>
>>>> Because I think it's conceptually flawed.
>>>
>>> Isn't it conceptually flawed to have a fixinclude header system that
>>> is broken for a target platform?
>>
>> Not conceptually, no.  That's a mere bug.
>
> Then can we fix gcc's headers to work with Win64?
>

NightStrike,

the headers aren't the issue. As you see they are working nicely with
native compilers (see Danny's comment). But the flaw begins with
sysroot and cross-compilers, as here suddenly the internal gcc-headers
simply override the system-headers (to mark this explicit: not for
native). So this means that the gcc headers would be in need to know,
if they are used by native toolchain and therefore don't have to
forward, or if they are part of a sysrooted or a cross-compiler
toolchain, where they need to do this.
So I heard now pretty often that to change cross-compiler/sysroot
include order here is a flaw. But I would really like to know what is
the reason for the current behavior (not a meaning, a reason please)
especially in respect to native/cross.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [patch win32]: fix for PR target/41943

[Richard Henderson]

On 07/22/2010 01:36 PM, Kai Tietz wrote:
> the headers aren't the issue. As you see they are working nicely with
> native compilers (see Danny's comment). But the flaw begins with
> sysroot and cross-compilers, as here suddenly the internal gcc-headers
> simply override the system-headers (to mark this explicit: not for
> native). So this means that the gcc headers would be in need to know,
> if they are used by native toolchain and therefore don't have to
> forward, or if they are part of a sysrooted or a cross-compiler
> toolchain, where they need to do this.
> So I heard now pretty often that to change cross-compiler/sysroot
> include order here is a flaw. But I would really like to know what is
> the reason for the current behavior (not a meaning, a reason please)
> especially in respect to native/cross.

Err.. I'm not sure quite what you're talking about.

native:
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
 /usr/include
End of search list.

cross+sysroot:
#include "..." search starts here:
#include <...> search starts here:
 /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include
 /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include-fixed
 /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/../../../../alphaev67-linux/include
 /local/rth/gcc/run-axp/alphaev67-linux/sys-root/usr/include
End of search list.

In both cases gcc-include preceeds the system-include dir.
The only difference is that native also searches local-include
(although I can't tell you why that preceeds gcc-include).

Are you guys installing stuff in local-include by default,
rather than a system-include path?


r~

Re: [patch win32]: fix for PR target/41943

[Kai Tietz]

2010/7/22 Richard Henderson <rth@redhat.com>:
> On 07/22/2010 01:36 PM, Kai Tietz wrote:
>> the headers aren't the issue. As you see they are working nicely with
>> native compilers (see Danny's comment). But the flaw begins with
>> sysroot and cross-compilers, as here suddenly the internal gcc-headers
>> simply override the system-headers (to mark this explicit: not for
>> native). So this means that the gcc headers would be in need to know,
>> if they are used by native toolchain and therefore don't have to
>> forward, or if they are part of a sysrooted or a cross-compiler
>> toolchain, where they need to do this.
>> So I heard now pretty often that to change cross-compiler/sysroot
>> include order here is a flaw. But I would really like to know what is
>> the reason for the current behavior (not a meaning, a reason please)
>> especially in respect to native/cross.
>
> Err.. I'm not sure quite what you're talking about.

Thank you posting it. Here I can exactly show what we mean and what
cause us troubles.

> native:
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
^^^^^^ Here you have your system-header location before the gcc
include (line below)
>  /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
>  /usr/include
> End of search list.
>
> cross+sysroot:
> #include "..." search starts here:
> #include <...> search starts here:
>  /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include
^^^^ Here as you see comes the gcc include folder first.
>  /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include-fixed
>  /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/../../../../alphaev67-linux/include
>  /local/rth/gcc/run-axp/alphaev67-linux/sys-root/usr/include
> End of search list.
>
> In both cases gcc-include preceeds the system-include dir.
> The only difference is that native also searches local-include
> (although I can't tell you why that preceeds gcc-include).
>
> Are you guys installing stuff in local-include by default,
> rather than a system-include path?

I don't get you for cross?

As you can see easily is (as example) the header 'float.h' taken from
'/usr/local/include' and then - if not found or by include_next' from
'/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include'.

For cross-compiler it will be always taken from
'/local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include' and the
other system-directories will be never searched.

This is exactly the difference which makes us troubles, that for cross
the behavior of gcc is different then it is possible for an native
compiler.

Regards,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [patch win32]: fix for PR target/41943

[Richard Henderson]

On 07/22/2010 02:19 PM, Kai Tietz wrote:
> 2010/7/22 Richard Henderson <rth@redhat.com>:
>> On 07/22/2010 01:36 PM, Kai Tietz wrote:
>>> the headers aren't the issue. As you see they are working nicely with
>>> native compilers (see Danny's comment). But the flaw begins with
>>> sysroot and cross-compilers, as here suddenly the internal gcc-headers
>>> simply override the system-headers (to mark this explicit: not for
>>> native). So this means that the gcc headers would be in need to know,
>>> if they are used by native toolchain and therefore don't have to
>>> forward, or if they are part of a sysrooted or a cross-compiler
>>> toolchain, where they need to do this.
>>> So I heard now pretty often that to change cross-compiler/sysroot
>>> include order here is a flaw. But I would really like to know what is
>>> the reason for the current behavior (not a meaning, a reason please)
>>> especially in respect to native/cross.
>>
>> Err.. I'm not sure quite what you're talking about.
> 
> Thank you posting it. Here I can exactly show what we mean and what
> cause us troubles.
> 
>> native:
>> #include "..." search starts here:
>> #include <...> search starts here:
>>  /usr/local/include
> ^^^^^^ Here you have your system-header location before the gcc
> include (line below)
>>  /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
>>  /usr/include
>> End of search list.

And here is the source of confusion.

/usr/local/include = local-include
/usr/lib/gcc/**/include = gcc-include
/usr/include = system-include.

So your statement above is false -- or at least not strictly accurate -- and
implies that yall are installing your system headers into the wrong directory.


r~

Re: [patch win32]: fix for PR target/41943

[Kai Tietz]

2010/7/22 Richard Henderson <rth@redhat.com>:
> On 07/22/2010 02:19 PM, Kai Tietz wrote:
>> 2010/7/22 Richard Henderson <rth@redhat.com>:
>>> On 07/22/2010 01:36 PM, Kai Tietz wrote:
>>>> the headers aren't the issue. As you see they are working nicely with
>>>> native compilers (see Danny's comment). But the flaw begins with
>>>> sysroot and cross-compilers, as here suddenly the internal gcc-headers
>>>> simply override the system-headers (to mark this explicit: not for
>>>> native). So this means that the gcc headers would be in need to know,
>>>> if they are used by native toolchain and therefore don't have to
>>>> forward, or if they are part of a sysrooted or a cross-compiler
>>>> toolchain, where they need to do this.
>>>> So I heard now pretty often that to change cross-compiler/sysroot
>>>> include order here is a flaw. But I would really like to know what is
>>>> the reason for the current behavior (not a meaning, a reason please)
>>>> especially in respect to native/cross.
>>>
>>> Err.. I'm not sure quite what you're talking about.
>>
>> Thank you posting it. Here I can exactly show what we mean and what
>> cause us troubles.
>>
>>> native:
>>> #include "..." search starts here:
>>> #include <...> search starts here:
>>>  /usr/local/include
>> ^^^^^^ Here you have your system-header location before the gcc
>> include (line below)
>>>  /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
>>>  /usr/include
>>> End of search list.
>
> And here is the source of confusion.
>
> /usr/local/include = local-include
> /usr/lib/gcc/**/include = gcc-include
> /usr/include = system-include.
>
> So your statement above is false -- or at least not strictly accurate -- and
> implies that yall are installing your system headers into the wrong directory.
>
>
> r~
>

Well, mingw-w64 doesn't install headers into /usr/local/include, but
as you see by Danny's post above, mingw.org does this for native
compiler. And here the reason comes up, why this patch made troubles
for him.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [patch win32]: fix for PR target/41943

[Richard Henderson]

On 07/22/2010 02:39 PM, Kai Tietz wrote:
> Well, mingw-w64 doesn't install headers into /usr/local/include, but
> as you see by Danny's post above, mingw.org does this for native
> compiler. And here the reason comes up, why this patch made troubles
> for him.

So... that's a bug too.

Where does that leave us?


r~

Re: [patch win32]: fix for PR target/41943

[Kai Tietz]

2010/7/22 Richard Henderson <rth@redhat.com>:
> On 07/22/2010 02:39 PM, Kai Tietz wrote:
>> Well, mingw-w64 doesn't install headers into /usr/local/include, but
>> as you see by Danny's post above, mingw.org does this for native
>> compiler. And here the reason comes up, why this patch made troubles
>> for him.
>
> So... that's a bug too.
>
> Where does that leave us?
>
>
> r~
>

To the point that gcc intends that gcc's internal headers should be
used by default. And so it would be wise to put even
/usr/local/include behind at least fixinclude, as this would be
strict.
And secondly, that this patch to add #include_next should be the
solution. Also it means that Danny has to think about a different
place mingw.org hasto put the runtime headers into.

Did I read you correct?

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [patch win32]: fix for PR target/41943

[Richard Henderson]

On 07/22/2010 02:51 PM, Kai Tietz wrote:
> To the point that gcc intends that gcc's internal headers should be
> used by default. And so it would be wise to put even
> /usr/local/include behind at least fixinclude, as this would be
> strict.
> And secondly, that this patch to add #include_next should be the
> solution. Also it means that Danny has to think about a different
> place mingw.org hasto put the runtime headers into.
> 
> Did I read you correct?

I believe all that is correct.

In order to make process on the second part above, it would seem
that your include_next patch is going to have to be backported to
whatever compiler version mingw.org is using.

That's a bit of release management I'm not sure how best to coordinate.


r~

Re: [patch win32]: fix for PR target/41943

[Kai Tietz]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

2010/7/22 Richard Henderson <rth@redhat.com>:
> On 07/22/2010 02:51 PM, Kai Tietz wrote:
>> To the point that gcc intends that gcc's internal headers should be
>> used by default. And so it would be wise to put even
>> /usr/local/include behind at least fixinclude, as this would be
>> strict.
>> And secondly, that this patch to add #include_next should be the
>> solution. Also it means that Danny has to think about a different
>> place mingw.org hasto put the runtime headers into.
>>
>> Did I read you correct?
>
> I believe all that is correct.
>
> In order to make process on the second part above, it would seem
> that your include_next patch is going to have to be backported to
> whatever compiler version mingw.org is using.
>
> That's a bit of release management I'm not sure how best to coordinate.
>
>
> r~
>

So here comes a patch which keeps the mingw.org variant untouched for
now, but allows the include_next patch for mingw-w64 triplets.

Ok for apply to trunk? And possible also back-merge to branches?

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

[-- Attachment #2: mdsim.diff --]
[-- Type: application/octet-stream, Size: 4733 bytes --]

Index: gcc/gcc/Makefile.in
===================================================================
--- gcc.orig/gcc/Makefile.in	2010-07-21 20:09:20.471160100 +0200
+++ gcc/gcc/Makefile.in	2010-07-21 23:18:06.082953500 +0200
@@ -366,6 +366,9 @@ USER_H = $(srcdir)/ginclude/float.h \
 	 $(srcdir)/ginclude/stdfix.h \
 	 $(EXTRA_HEADERS)
 
+USER_H_INC_NEXT_PRE = @user_headers_inc_next_pre@
+USER_H_INC_NEXT_POST = @user_headers_inc_next_post@
+
 UNWIND_H = $(srcdir)/unwind-generic.h
 
 # The GCC to use for compiling crt*.o.
@@ -4014,6 +4017,21 @@ stmp-int-hdrs: $(STMP_FIXINC) $(USER_H)
 	    chmod a+r include/$$realfile; \
 	  fi; \
 	done
+	for file in .. $(USER_H_INC_NEXT_PRE); do \
+	  if [ X$$file != X.. ]; then \
+            mv include/$$file include/x_$$file; \
+            echo "#include_next <$$file>" >include/$$file; \
+            cat include/x_$$file >>include/$$file; \
+            rm -f include/x_$$file; \
+	    chmod a+r include/$$file; \
+	  fi; \
+	done
+	for file in .. $(USER_H_INC_NEXT_POST); do \
+	  if [ X$$file != X.. ]; then \
+	    echo "#include_next <$$file>" >>include/$$file; \
+	    chmod a+r include/$$file; \
+	  fi; \
+	done
 	rm -f include/unwind.h
 	cp $(UNWIND_H) include/unwind.h
 	chmod a+r include/unwind.h
Index: gcc/gcc/config.gcc
===================================================================
--- gcc.orig/gcc/config.gcc	2010-07-21 20:09:20.376160100 +0200
+++ gcc/gcc/config.gcc	2010-07-22 19:23:06.257833100 +0200
@@ -101,6 +101,12 @@
 #  extra_headers	List of used header files from the directory
 #			config/${cpu_type}.
 #
+#  user_headers_inc_next_pre
+#			List of header file names of internal gcc header
+#			files, which should be prefixed by an include_next.
+#  user_headers_inc_next_post
+#			List of header file names of internal gcc header
+#			files, which should be postfixed by an include_next.
 #  use_gcc_tgmath	If set, add tgmath.h to the list of used header
 #			files.
 #
@@ -171,6 +177,8 @@
 out_file=
 tmake_file=
 extra_headers=
+user_headers_inc_next_pre=
+user_headers_inc_next_post=
 use_gcc_tgmath=yes
 use_gcc_stdint=none
 extra_passes=
@@ -1379,6 +1387,8 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
 	# This makes the logic if mingw's or the w64 feature set has to be used
 	case ${target} in
 		*-w64-*)
+			user_headers_inc_next_post="${user_headers_inc_next_post} float.h"
+			user_headers_inc_next_pre="${user_headers_inc_next_pre} stddef.h stdarg.h"
 			tm_file="${tm_file} i386/mingw-w64.h"
 			if test x$enable_targets = xall; then
 				tm_defines="${tm_defines} TARGET_BI_ARCH=1"
Index: gcc/gcc/configure
===================================================================
--- gcc.orig/gcc/configure	2010-07-21 20:09:20.412160100 +0200
+++ gcc/gcc/configure	2010-07-21 23:05:41.027338800 +0200
@@ -646,6 +646,8 @@ extra_passes
 extra_parts
 extra_objs
 extra_headers_list
+user_headers_inc_next_post
+user_headers_inc_next_pre
 extra_gcc_objs
 TM_MULTILIB_EXCEPTIONS_CONFIG
 TM_MULTILIB_CONFIG
@@ -10263,6 +10265,12 @@ then tm_file=$cpu_type/$cpu_type.h; fi
 if test x"$extra_headers" = x
 then extra_headers=; fi
 
+if test x"$user_headers_inc_next_pre" = x
+then user_headers_inc_next_pre=; fi
+
+if test x"$user_headers_inc_next_post" = x
+then user_headers_inc_next_post=; fi
+
 if test x$md_file = x
 then md_file=$cpu_type/$cpu_type.md; fi
 
@@ -17107,7 +17115,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17110 "configure"
+#line 17118 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -17213,7 +17221,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17216 "configure"
+#line 17224 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -25394,6 +25402,8 @@ fi
 
 
 
+
+
 
 
 
Index: gcc/gcc/configure.ac
===================================================================
--- gcc.orig/gcc/configure.ac	2010-07-21 20:09:20.413160100 +0200
+++ gcc/gcc/configure.ac	2010-07-21 23:04:25.994047100 +0200
@@ -1235,6 +1235,12 @@ then tm_file=$cpu_type/$cpu_type.h; fi
 if test x"$extra_headers" = x
 then extra_headers=; fi
 
+if test x"$user_headers_inc_next_pre" = x
+then user_headers_inc_next_pre=; fi
+
+if test x"$user_headers_inc_next_post" = x
+then user_headers_inc_next_post=; fi
+
 if test x$md_file = x
 then md_file=$cpu_type/$cpu_type.md; fi
 
@@ -4499,6 +4505,8 @@ AC_SUBST(TM_ENDIAN_CONFIG)
 AC_SUBST(TM_MULTILIB_CONFIG)
 AC_SUBST(TM_MULTILIB_EXCEPTIONS_CONFIG)
 AC_SUBST(extra_gcc_objs)
+AC_SUBST(user_headers_inc_next_pre)
+AC_SUBST(user_headers_inc_next_post)
 AC_SUBST(extra_headers_list)
 AC_SUBST(extra_objs)
 AC_SUBST(extra_parts)

Re: [patch win32]: fix for PR target/41943

[Richard Henderson]

On 07/23/2010 10:55 AM, Kai Tietz wrote:
> +if test x"$user_headers_inc_next_pre" = x
> +then user_headers_inc_next_pre=; fi
> +
> +if test x"$user_headers_inc_next_post" = x
> +then user_headers_inc_next_post=; fi

This hunk should not be needed.

Otherwise ok for head.  Branches should be ok too after
this settles down.


r~

Re: [patch win32]: fix for PR target/41943

[Kai Tietz]

2010/7/23 Richard Henderson <rth@redhat.com>:
> On 07/23/2010 10:55 AM, Kai Tietz wrote:
>> +if test x"$user_headers_inc_next_pre" = x
>> +then user_headers_inc_next_pre=; fi
>> +
>> +if test x"$user_headers_inc_next_post" = x
>> +then user_headers_inc_next_post=; fi
>
> This hunk should not be needed.
>
> Otherwise ok for head.  Branches should be ok too after
> this settles down.
>
>
> r~
>

Ok, committed to trunk at revision 162479.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [patch win32]: fix for PR target/41943

[Richard Guenther]

On Thu, Jul 22, 2010 at 11:11 PM, Richard Henderson <rth@redhat.com> wrote:
> On 07/22/2010 01:36 PM, Kai Tietz wrote:
>> the headers aren't the issue. As you see they are working nicely with
>> native compilers (see Danny's comment). But the flaw begins with
>> sysroot and cross-compilers, as here suddenly the internal gcc-headers
>> simply override the system-headers (to mark this explicit: not for
>> native). So this means that the gcc headers would be in need to know,
>> if they are used by native toolchain and therefore don't have to
>> forward, or if they are part of a sysrooted or a cross-compiler
>> toolchain, where they need to do this.
>> So I heard now pretty often that to change cross-compiler/sysroot
>> include order here is a flaw. But I would really like to know what is
>> the reason for the current behavior (not a meaning, a reason please)
>> especially in respect to native/cross.
>
> Err.. I'm not sure quite what you're talking about.
>
> native:
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
>  /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
>  /usr/include
> End of search list.
>
> cross+sysroot:
> #include "..." search starts here:
> #include <...> search starts here:
>  /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include
>  /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include-fixed
>  /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/../../../../alphaev67-linux/include
>  /local/rth/gcc/run-axp/alphaev67-linux/sys-root/usr/include
> End of search list.
>
> In both cases gcc-include preceeds the system-include dir.
> The only difference is that native also searches local-include
> (although I can't tell you why that preceeds gcc-include).

I wondered about this myself, but it is even documented this way
in cpp.texi ...

It seems that there is no local include dir for cross+sysroot.

I'm sure Joseph knows why?

Richard.

Re: [patch win32]: fix for PR target/41943

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2214 bytes --]

On Fri, 23 Jul 2010, Richard Guenther wrote:

> > Err.. I'm not sure quite what you're talking about.
> >
> > native:
> > #include "..." search starts here:
> > #include <...> search starts here:
> >  /usr/local/include
> >  /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
> >  /usr/include
> > End of search list.
> >
> > cross+sysroot:
> > #include "..." search starts here:
> > #include <...> search starts here:
> >  /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include
> >  /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include-fixed
> >  /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/../../../../alphaev67-linux/include
> >  /local/rth/gcc/run-axp/alphaev67-linux/sys-root/usr/include
> > End of search list.
> >
> > In both cases gcc-include preceeds the system-include dir.
> > The only difference is that native also searches local-include
> > (although I can't tell you why that preceeds gcc-include).
> 
> I wondered about this myself, but it is even documented this way
> in cpp.texi ...
> 
> It seems that there is no local include dir for cross+sysroot.
> 
> I'm sure Joseph knows why?

My guess would be that the ordering predates the separation of include and 
include-fixed.  /usr/local/include was meant to be headers that are known 
to work with GCC (as opposed to /usr/include, the headers originally for 
use with a proprietary non-GNU compiler) and so (a) didn't need fixed 
versions of headers and (b) was meant to go before system headers and 
override them in the case of local GNU libraries replacing pieces of 
system functionality.

Now, I'd think what's logical would be the GCC include directory, then 
system headers including both /usr/local/include and /usr/include and 
putting fixed versions of a directory immediately before that directory.  
But since we only have fixed headers for /usr/include, that means include, 
/usr/local/include, include-fixed, /usr/include.  In a sysroot 
configuration, $sysroot/usr/local/include ought to be searched; I see no 
reason for it not to be and searching it improves consistency with what is 
searched in the native case.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [patch win32]: fix for PR target/41943

[Kai Tietz]

2010/7/27 Joseph S. Myers <joseph@codesourcery.com>:
> On Fri, 23 Jul 2010, Richard Guenther wrote:
>
>> > Err.. I'm not sure quite what you're talking about.
>> >
>> > native:
>> > #include "..." search starts here:
>> > #include <...> search starts here:
>> >  /usr/local/include
>> >  /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
>> >  /usr/include
>> > End of search list.
>> >
>> > cross+sysroot:
>> > #include "..." search starts here:
>> > #include <...> search starts here:
>> >  /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include
>> >  /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include-fixed
>> >  /local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/../../../../alphaev67-linux/include
>> >  /local/rth/gcc/run-axp/alphaev67-linux/sys-root/usr/include
>> > End of search list.
>> >
>> > In both cases gcc-include preceeds the system-include dir.
>> > The only difference is that native also searches local-include
>> > (although I can't tell you why that preceeds gcc-include).
>>
>> I wondered about this myself, but it is even documented this way
>> in cpp.texi ...
>>
>> It seems that there is no local include dir for cross+sysroot.
>>
>> I'm sure Joseph knows why?
>
> My guess would be that the ordering predates the separation of include and
> include-fixed.  /usr/local/include was meant to be headers that are known
> to work with GCC (as opposed to /usr/include, the headers originally for
> use with a proprietary non-GNU compiler) and so (a) didn't need fixed
> versions of headers and (b) was meant to go before system headers and
> override them in the case of local GNU libraries replacing pieces of
> system functionality.
>
> Now, I'd think what's logical would be the GCC include directory, then
> system headers including both /usr/local/include and /usr/include and
> putting fixed versions of a directory immediately before that directory.
> But since we only have fixed headers for /usr/include, that means include,
> /usr/local/include, include-fixed, /usr/include.  In a sysroot
> configuration, $sysroot/usr/local/include ought to be searched; I see no
> reason for it not to be and searching it improves consistency with what is
> searched in the native case.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

So a patch to change the include-order here in the following way

...
...
GCC_INCLUDE_DIR
LOCAL_INCLUDE_DIR
PREFIX_INCLUDE_DIR
CROSS_INCLUDE_DIR
TOOL_INCLUDE_DIR
SYSTEM_INCLUDE_DIR
FIXED_INCLUDE_DIR
STANDARD_INCLUDE_DIR

would be ok?

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [patch win32]: fix for PR target/41943

[Ozkan Sezer]

>>> 	(i[34567]86-*-mingw* | x86_64-*-mingw*): Use
>>> 	for float.h post, and for w64 targets stddef.h/stdarg.h pre
>>> 	fixing by include_next.
>> The mingw323 float.h is alrewady prefixed with
>>
>> #include_next<float.h>
>>
>> #ifndef _MINGW_FLOAT_H_
>> #define _MINGW_FLOAT_H_
>>
>> ....
>>
>> Postfixing  #include_next <float.h> onto gcc's float.h causes:
>>
>> gcc -H -Wall f.c
>> . c:\mingw\bin\../lib/gcc/mingw32/4.6.0/../../../../include/float.h
>> .. c:\mingw\bin\../lib/gcc/mingw32/4.6.0/include/float.h
>> In file included from c:\mingw\bin\../lib/gcc/mingw32/4.6.0/../../../../include/
>> float.h:19:0,
>>                  from f.c:1:
>> c:\mingw\bin\../lib/gcc/mingw32/4.6.0/include/float.h:278:24: fatal error: float
>> .h: No such file or directory
>> compilation terminated.
>>
>> Danny
>>
>
> I know. But as the float.h from gcc's internal header always comes
> first in include order, this next_include in system-headers is wrong.
> I tried to move the order of includes, but this patch was rejected. So
> the way to solve this is by pre/post-fixing those headers to make sure
> that by default the system-header is included, too.
> If you prefer to have this change just for w64, I am fine.
>
> Regards,
> Kai

What is in the way for the formerly suggested solution for this,
ie. this one:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01450.html
Which seems like a much cleaner solution to me (my opinion, of
course.)

--
Ozkan

[patch win32]: fix for PR target/41943

[Kai Tietz]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

Hello Richard,

caused by a recent discussion we had on IRC I implemented this
header-fix by configure/make. By the two new options
user_headers_inc_next_pre and user_headers_inc_next_post it is
possible to specify that internal gcc headers should be decorated by a
prefix/postfix of include_next<header-name>.

As mingw.org don't provide own versions of stddef.h and stdarg.h, I
added those two fixups just for the w64 case.

2010-07-21  Kai Tietz

	PR target/41943
	* Makefile.in (USER_H_INC_NEXT_PRE,
	USER_H_INC_NEXT_POST): New.
	(stmp-int-hdrs): Prefix/postfix headers by include_next.
	* config.gcc (user_headers_inc_next_pre): New.
	(user_headers_inc_next_post): Likewise.
	(i[34567]86-*-mingw* | x86_64-*-mingw*): Use
	for float.h post, and for w64 targets stddef.h/stdarg.h pre
	fixing by include_next.
	* configure.ac (user_headers_inc_next_post): New.
	(user_headers_inc_next_pre): New.
	(user_headers_inc_next_pre_list): New.
	(user_headers_inc_next_post_list): New.
	* configure: Regenerated.

Tested for i686-pc-mingw32, i686-w64-mingw32, and x86_64-w64-mingw32.
Ok for apply?

Regards,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

[-- Attachment #2: mdsim.diff --]
[-- Type: application/octet-stream, Size: 6056 bytes --]

Index: gcc/gcc/Makefile.in
===================================================================
--- gcc.orig/gcc/Makefile.in	2010-07-21 20:09:20.471160100 +0200
+++ gcc/gcc/Makefile.in	2010-07-21 21:19:04.099455400 +0200
@@ -366,6 +366,9 @@ USER_H = $(srcdir)/ginclude/float.h \
 	 $(srcdir)/ginclude/stdfix.h \
 	 $(EXTRA_HEADERS)
 
+USER_H_INC_NEXT_PRE = @user_headers_inc_next_pre_list@
+USER_H_INC_NEXT_POST = @user_headers_inc_next_post_list@
+
 UNWIND_H = $(srcdir)/unwind-generic.h
 
 # The GCC to use for compiling crt*.o.
@@ -4014,6 +4017,21 @@ stmp-int-hdrs: $(STMP_FIXINC) $(USER_H)
 	    chmod a+r include/$$realfile; \
 	  fi; \
 	done
+	for file in .. $(USER_H_INC_NEXT_PRE); do \
+	  if [ X$$file != X.. ]; then \
+            mv include/$$file include/x_$$file; \
+            echo "#include_next <$$file>" >include/$$file; \
+            cat include/x_$$file >>include/$$file; \
+            rm -f include/x_$$file; \
+	    chmod a+r include/$$file; \
+	  fi; \
+	done
+	for file in .. $(USER_H_INC_NEXT_POST); do \
+	  if [ X$$file != X.. ]; then \
+	    echo "#include_next <$$file>" >>include/$$file; \
+	    chmod a+r include/$$file; \
+	  fi; \
+	done
 	rm -f include/unwind.h
 	cp $(UNWIND_H) include/unwind.h
 	chmod a+r include/unwind.h
Index: gcc/gcc/config.gcc
===================================================================
--- gcc.orig/gcc/config.gcc	2010-07-21 20:09:20.376160100 +0200
+++ gcc/gcc/config.gcc	2010-07-21 20:33:43.484845200 +0200
@@ -101,6 +101,12 @@
 #  extra_headers	List of used header files from the directory
 #			config/${cpu_type}.
 #
+#  user_headers_inc_next_pre
+#			List of header file names of internal gcc header
+#			files, which should be prefixed by an include_next.
+#  user_headers_inc_next_post
+#			List of header file names of internal gcc header
+#			files, which should be postfixed by an include_next.
 #  use_gcc_tgmath	If set, add tgmath.h to the list of used header
 #			files.
 #
@@ -171,6 +177,8 @@
 out_file=
 tmake_file=
 extra_headers=
+user_headers_inc_next_pre=
+user_headers_inc_next_post=
 use_gcc_tgmath=yes
 use_gcc_stdint=none
 extra_passes=
@@ -1376,9 +1384,11 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
 		*)
 			;;
 	esac
+	user_headers_inc_next_post="${user_headers_inc_next_post} float.h"
 	# This makes the logic if mingw's or the w64 feature set has to be used
 	case ${target} in
 		*-w64-*)
+			user_headers_inc_next_pre="${user_headers_inc_next_pre} stddef.h stdarg.h"
 			tm_file="${tm_file} i386/mingw-w64.h"
 			if test x$enable_targets = xall; then
 				tm_defines="${tm_defines} TARGET_BI_ARCH=1"
Index: gcc/gcc/configure
===================================================================
--- gcc.orig/gcc/configure	2010-07-21 20:09:20.412160100 +0200
+++ gcc/gcc/configure	2010-07-21 20:36:04.899933600 +0200
@@ -646,6 +646,8 @@ extra_passes
 extra_parts
 extra_objs
 extra_headers_list
+user_headers_inc_next_post_list
+user_headers_inc_next_pre_list
 extra_gcc_objs
 TM_MULTILIB_EXCEPTIONS_CONFIG
 TM_MULTILIB_CONFIG
@@ -10263,6 +10265,12 @@ then tm_file=$cpu_type/$cpu_type.h; fi
 if test x"$extra_headers" = x
 then extra_headers=; fi
 
+if test x"$user_headers_inc_next_pre" = x
+then user_headers_inc_next_pre=; fi
+
+if test x"$user_headers_inc_next_post" = x
+then user_headers_inc_next_post=; fi
+
 if test x$md_file = x
 then md_file=$cpu_type/$cpu_type.md; fi
 
@@ -11003,6 +11011,16 @@ if test x"$use_gcc_tgmath" = xyes
 then extra_headers_list="${extra_headers_list} \$(srcdir)/ginclude/tgmath.h"
 fi
 
+# Expand user_headers_inc_next_pre to user_headers_inc_next_pre_list
+for file in ${user_headers_inc_next_pre} ; do
+  user_headers_inc_next_pre_list="${user_headers_inc_next_pre_list} ${file}"
+done
+
+# Expand user_headers_inc_next_post to user_headers_inc_next_post_list
+for file in ${user_headers_inc_next_post} ; do
+  user_headers_inc_next_post_list="${user_headers_inc_next_post_list} ${file}"
+done
+
 # Define collect2 in Makefile.
 case $host_can_use_collect2 in
   no) collect2= ;;
@@ -17107,7 +17125,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17110 "configure"
+#line 17128 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -17213,7 +17231,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17216 "configure"
+#line 17234 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -25394,6 +25412,8 @@ fi
 
 
 
+
+
 
 
 
Index: gcc/gcc/configure.ac
===================================================================
--- gcc.orig/gcc/configure.ac	2010-07-21 20:09:20.413160100 +0200
+++ gcc/gcc/configure.ac	2010-07-21 20:29:56.109840100 +0200
@@ -1235,6 +1235,12 @@ then tm_file=$cpu_type/$cpu_type.h; fi
 if test x"$extra_headers" = x
 then extra_headers=; fi
 
+if test x"$user_headers_inc_next_pre" = x
+then user_headers_inc_next_pre=; fi
+
+if test x"$user_headers_inc_next_post" = x
+then user_headers_inc_next_post=; fi
+
 if test x$md_file = x
 then md_file=$cpu_type/$cpu_type.md; fi
 
@@ -1823,6 +1829,16 @@ if test x"$use_gcc_tgmath" = xyes
 then extra_headers_list="${extra_headers_list} \$(srcdir)/ginclude/tgmath.h"
 fi
 
+# Expand user_headers_inc_next_pre to user_headers_inc_next_pre_list
+for file in ${user_headers_inc_next_pre} ; do
+  user_headers_inc_next_pre_list="${user_headers_inc_next_pre_list} ${file}"
+done
+
+# Expand user_headers_inc_next_post to user_headers_inc_next_post_list
+for file in ${user_headers_inc_next_post} ; do
+  user_headers_inc_next_post_list="${user_headers_inc_next_post_list} ${file}"
+done
+
 # Define collect2 in Makefile.
 case $host_can_use_collect2 in
   no) collect2= ;;
@@ -4499,6 +4515,8 @@ AC_SUBST(TM_ENDIAN_CONFIG)
 AC_SUBST(TM_MULTILIB_CONFIG)
 AC_SUBST(TM_MULTILIB_EXCEPTIONS_CONFIG)
 AC_SUBST(extra_gcc_objs)
+AC_SUBST(user_headers_inc_next_pre_list)
+AC_SUBST(user_headers_inc_next_post_list)
 AC_SUBST(extra_headers_list)
 AC_SUBST(extra_objs)
 AC_SUBST(extra_parts)

Re: [patch win32]: fix for PR target/41943

[Richard Henderson]

On 07/21/2010 12:38 PM, Kai Tietz wrote:
> +if test x"$user_headers_inc_next_pre" = x
> +then user_headers_inc_next_pre=; fi
> +
> +if test x"$user_headers_inc_next_post" = x
> +then user_headers_inc_next_post=; fi
...
> +# Expand user_headers_inc_next_pre to user_headers_inc_next_pre_list
> +for file in ${user_headers_inc_next_pre} ; do
> +  user_headers_inc_next_pre_list="${user_headers_inc_next_pre_list} ${file}"
> +done
> +
> +# Expand user_headers_inc_next_post to user_headers_inc_next_post_list
> +for file in ${user_headers_inc_next_post} ; do
> +  user_headers_inc_next_post_list="${user_headers_inc_next_post_list} ${file}"
> +done

I don't understand the point of these.  As far as I can tell this 
just assigns the contents of foo to foo_list, but in a complicated
and confusing way.

This is unlike the code immediately above that creates extra_headers_list
which in fact prepends a path to each of the entries in the list.


r~

Re: [patch win32]: fix for PR target/41943

[Kai Tietz]

[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

2010/7/21 Richard Henderson <rth@redhat.com>:
> On 07/21/2010 12:38 PM, Kai Tietz wrote:
>> +if test x"$user_headers_inc_next_pre" = x
>> +then user_headers_inc_next_pre=; fi
>> +
>> +if test x"$user_headers_inc_next_post" = x
>> +then user_headers_inc_next_post=; fi
> ...
>> +# Expand user_headers_inc_next_pre to user_headers_inc_next_pre_list
>> +for file in ${user_headers_inc_next_pre} ; do
>> +  user_headers_inc_next_pre_list="${user_headers_inc_next_pre_list} ${file}"
>> +done
>> +
>> +# Expand user_headers_inc_next_post to user_headers_inc_next_post_list
>> +for file in ${user_headers_inc_next_post} ; do
>> +  user_headers_inc_next_post_list="${user_headers_inc_next_post_list} ${file}"
>> +done
>
> I don't understand the point of these.  As far as I can tell this
> just assigns the contents of foo to foo_list, but in a complicated
> and confusing way.
>
> This is unlike the code immediately above that creates extra_headers_list
> which in fact prepends a path to each of the entries in the list.

Thanks for the catch. I had in front a patch with folders and missed
to remove those unnecessary ..._list variables.

2010-07-21  Kai Tietz

	PR target/41943
	* Makefile.in (USER_H_INC_NEXT_PRE,
	USER_H_INC_NEXT_POST): New.
	(stmp-int-hdrs): Prefix/postfix headers by include_next.
	* config.gcc (user_headers_inc_next_pre): New.
	(user_headers_inc_next_post): Likewise.
	(i[34567]86-*-mingw* | x86_64-*-mingw*): Use
	for float.h post, and for w64 targets stddef.h/stdarg.h pre
	fixing by include_next.
	* configure.ac (user_headers_inc_next_post): New.
	(user_headers_inc_next_pre): New.
	* configure: Regenerated.

Updated and retested patch attached. Ok for apply?

Regards,
Kai



-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

[-- Attachment #2: mdsim.diff --]
[-- Type: application/octet-stream, Size: 4752 bytes --]

Index: gcc/gcc/Makefile.in
===================================================================
--- gcc.orig/gcc/Makefile.in	2010-07-21 20:09:20.471160100 +0200
+++ gcc/gcc/Makefile.in	2010-07-21 23:18:06.082953500 +0200
@@ -366,6 +366,9 @@ USER_H = $(srcdir)/ginclude/float.h \
 	 $(srcdir)/ginclude/stdfix.h \
 	 $(EXTRA_HEADERS)
 
+USER_H_INC_NEXT_PRE = @user_headers_inc_next_pre@
+USER_H_INC_NEXT_POST = @user_headers_inc_next_post@
+
 UNWIND_H = $(srcdir)/unwind-generic.h
 
 # The GCC to use for compiling crt*.o.
@@ -4014,6 +4017,21 @@ stmp-int-hdrs: $(STMP_FIXINC) $(USER_H)
 	    chmod a+r include/$$realfile; \
 	  fi; \
 	done
+	for file in .. $(USER_H_INC_NEXT_PRE); do \
+	  if [ X$$file != X.. ]; then \
+            mv include/$$file include/x_$$file; \
+            echo "#include_next <$$file>" >include/$$file; \
+            cat include/x_$$file >>include/$$file; \
+            rm -f include/x_$$file; \
+	    chmod a+r include/$$file; \
+	  fi; \
+	done
+	for file in .. $(USER_H_INC_NEXT_POST); do \
+	  if [ X$$file != X.. ]; then \
+	    echo "#include_next <$$file>" >>include/$$file; \
+	    chmod a+r include/$$file; \
+	  fi; \
+	done
 	rm -f include/unwind.h
 	cp $(UNWIND_H) include/unwind.h
 	chmod a+r include/unwind.h
Index: gcc/gcc/config.gcc
===================================================================
--- gcc.orig/gcc/config.gcc	2010-07-21 20:09:20.376160100 +0200
+++ gcc/gcc/config.gcc	2010-07-21 20:33:43.484845200 +0200
@@ -101,6 +101,12 @@
 #  extra_headers	List of used header files from the directory
 #			config/${cpu_type}.
 #
+#  user_headers_inc_next_pre
+#			List of header file names of internal gcc header
+#			files, which should be prefixed by an include_next.
+#  user_headers_inc_next_post
+#			List of header file names of internal gcc header
+#			files, which should be postfixed by an include_next.
 #  use_gcc_tgmath	If set, add tgmath.h to the list of used header
 #			files.
 #
@@ -171,6 +177,8 @@
 out_file=
 tmake_file=
 extra_headers=
+user_headers_inc_next_pre=
+user_headers_inc_next_post=
 use_gcc_tgmath=yes
 use_gcc_stdint=none
 extra_passes=
@@ -1376,9 +1384,11 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
 		*)
 			;;
 	esac
+	user_headers_inc_next_post="${user_headers_inc_next_post} float.h"
 	# This makes the logic if mingw's or the w64 feature set has to be used
 	case ${target} in
 		*-w64-*)
+			user_headers_inc_next_pre="${user_headers_inc_next_pre} stddef.h stdarg.h"
 			tm_file="${tm_file} i386/mingw-w64.h"
 			if test x$enable_targets = xall; then
 				tm_defines="${tm_defines} TARGET_BI_ARCH=1"
Index: gcc/gcc/configure
===================================================================
--- gcc.orig/gcc/configure	2010-07-21 20:09:20.412160100 +0200
+++ gcc/gcc/configure	2010-07-21 23:05:41.027338800 +0200
@@ -646,6 +646,8 @@ extra_passes
 extra_parts
 extra_objs
 extra_headers_list
+user_headers_inc_next_post
+user_headers_inc_next_pre
 extra_gcc_objs
 TM_MULTILIB_EXCEPTIONS_CONFIG
 TM_MULTILIB_CONFIG
@@ -10263,6 +10265,12 @@ then tm_file=$cpu_type/$cpu_type.h; fi
 if test x"$extra_headers" = x
 then extra_headers=; fi
 
+if test x"$user_headers_inc_next_pre" = x
+then user_headers_inc_next_pre=; fi
+
+if test x"$user_headers_inc_next_post" = x
+then user_headers_inc_next_post=; fi
+
 if test x$md_file = x
 then md_file=$cpu_type/$cpu_type.md; fi
 
@@ -17107,7 +17115,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17110 "configure"
+#line 17118 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -17213,7 +17221,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17216 "configure"
+#line 17224 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -25394,6 +25402,8 @@ fi
 
 
 
+
+
 
 
 
Index: gcc/gcc/configure.ac
===================================================================
--- gcc.orig/gcc/configure.ac	2010-07-21 20:09:20.413160100 +0200
+++ gcc/gcc/configure.ac	2010-07-21 23:04:25.994047100 +0200
@@ -1235,6 +1235,12 @@ then tm_file=$cpu_type/$cpu_type.h; fi
 if test x"$extra_headers" = x
 then extra_headers=; fi
 
+if test x"$user_headers_inc_next_pre" = x
+then user_headers_inc_next_pre=; fi
+
+if test x"$user_headers_inc_next_post" = x
+then user_headers_inc_next_post=; fi
+
 if test x$md_file = x
 then md_file=$cpu_type/$cpu_type.md; fi
 
@@ -4499,6 +4505,8 @@ AC_SUBST(TM_ENDIAN_CONFIG)
 AC_SUBST(TM_MULTILIB_CONFIG)
 AC_SUBST(TM_MULTILIB_EXCEPTIONS_CONFIG)
 AC_SUBST(extra_gcc_objs)
+AC_SUBST(user_headers_inc_next_pre)
+AC_SUBST(user_headers_inc_next_post)
 AC_SUBST(extra_headers_list)
 AC_SUBST(extra_objs)
 AC_SUBST(extra_parts)

Re: [patch win32]: fix for PR target/41943

[Danny Smith]

>        (i[34567]86-*-mingw* | x86_64-*-mingw*): Use
>        for float.h post, and for w64 targets stddef.h/stdarg.h pre
>        fixing by include_next.
The mingw323 float.h is alrewady prefixed with

#include_next<float.h>

#ifndef _MINGW_FLOAT_H_
#define _MINGW_FLOAT_H_

....

Postfixing  #include_next <float.h> onto gcc's float.h causes:

gcc -H -Wall f.c
. c:\mingw\bin\../lib/gcc/mingw32/4.6.0/../../../../include/float.h
.. c:\mingw\bin\../lib/gcc/mingw32/4.6.0/include/float.h
In file included from c:\mingw\bin\../lib/gcc/mingw32/4.6.0/../../../../include/
float.h:19:0,
                 from f.c:1:
c:\mingw\bin\../lib/gcc/mingw32/4.6.0/include/float.h:278:24: fatal error: float
.h: No such file or directory
compilation terminated.

Danny

Re: [patch win32]: fix for PR target/41943

[Kai Tietz]

2010/7/22 Danny Smith <dansmister@gmail.com>:
>>        (i[34567]86-*-mingw* | x86_64-*-mingw*): Use
>>        for float.h post, and for w64 targets stddef.h/stdarg.h pre
>>        fixing by include_next.
> The mingw323 float.h is alrewady prefixed with
>
> #include_next<float.h>
>
> #ifndef _MINGW_FLOAT_H_
> #define _MINGW_FLOAT_H_
>
> ....
>
> Postfixing  #include_next <float.h> onto gcc's float.h causes:
>
> gcc -H -Wall f.c
> . c:\mingw\bin\../lib/gcc/mingw32/4.6.0/../../../../include/float.h
> .. c:\mingw\bin\../lib/gcc/mingw32/4.6.0/include/float.h
> In file included from c:\mingw\bin\../lib/gcc/mingw32/4.6.0/../../../../include/
> float.h:19:0,
>                 from f.c:1:
> c:\mingw\bin\../lib/gcc/mingw32/4.6.0/include/float.h:278:24: fatal error: float
> .h: No such file or directory
> compilation terminated.
>
> Danny
>

I know. But as the float.h from gcc's internal header always comes
first in include order, this next_include in system-headers is wrong.
I tried to move the order of includes, but this patch was rejected. So
the way to solve this is by pre/post-fixing those headers to make sure
that by default the system-header is included, too.
If you prefer to have this change just for w64, I am fine.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [patch win32]: fix for PR target/41943

[Danny Smith]

>> c:\mingw\bin\../lib/gcc/mingw32/4.6.0/include/float.h:278:24: fatal error: float
>> .h: No such file or directory
>> compilation terminated.
>>
>> Danny
>>
>
> I know. But as the float.h from gcc's internal header always comes
> first in include order, this next_include in system-headers is wrong.


mingw CRT and winapi headers have long been placed in the
LOCAL_INCLUDE_DIR on window's hosts, since Windows doesn't really have
a system include directory.  This local include dir is defined as
being relative to exec_prefix in x-mingw32.

The local include dir is included before gcc's internal headers.

Danny

Re: [patch win32]: fix for PR target/41943

[Kai Tietz]

2010/7/22 Danny Smith <dansmister@gmail.com>:
>>> c:\mingw\bin\../lib/gcc/mingw32/4.6.0/include/float.h:278:24: fatal error: float
>>> .h: No such file or directory
>>> compilation terminated.
>>>
>>> Danny
>>>
>>
>> I know. But as the float.h from gcc's internal header always comes
>> first in include order, this next_include in system-headers is wrong.
>
>
> mingw CRT and winapi headers have long been placed in the
> LOCAL_INCLUDE_DIR on window's hosts, since Windows doesn't really have
> a system include directory.  This local include dir is defined as
> being relative to exec_prefix in x-mingw32.
>
> The local include dir is included before gcc's internal headers.
>
> Danny
>

That's right and therefore I dislike this patch and would prefer to
have that one Ozkan mentioned already. The issue is that sysroot &
cross- includes come after gcc's internal header, which is causing the
pain that it isn't absolutely predicatable, if system-headers are
reached or not.
By changing the order of gcc's internal to the end of the include
chain, it would be solved for all cases.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [patch win32]: fix for PR target/41943

[Richard Guenther]

On Thu, Jul 22, 2010 at 1:42 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2010/7/22 Danny Smith <dansmister@gmail.com>:
>>>> c:\mingw\bin\../lib/gcc/mingw32/4.6.0/include/float.h:278:24: fatal error: float
>>>> .h: No such file or directory
>>>> compilation terminated.
>>>>
>>>> Danny
>>>>
>>>
>>> I know. But as the float.h from gcc's internal header always comes
>>> first in include order, this next_include in system-headers is wrong.
>>
>>
>> mingw CRT and winapi headers have long been placed in the
>> LOCAL_INCLUDE_DIR on window's hosts, since Windows doesn't really have
>> a system include directory.  This local include dir is defined as
>> being relative to exec_prefix in x-mingw32.
>>
>> The local include dir is included before gcc's internal headers.
>>
>> Danny
>>
>
> That's right and therefore I dislike this patch and would prefer to
> have that one Ozkan mentioned already. The issue is that sysroot &
> cross- includes come after gcc's internal header, which is causing the
> pain that it isn't absolutely predicatable, if system-headers are
> reached or not.
> By changing the order of gcc's internal to the end of the include
> chain, it would be solved for all cases.

Well, I think moving gcc headers to the end of the include chain is
just wrong.  They are supposed to override host ones (which is
why they are called "fixincludes").  Why not fixinclude mingw?

Richard.

Re: [patch win32]: fix for PR target/41943

[Kai Tietz]

2010/7/22 Richard Guenther <richard.guenther@gmail.com>:
> On Thu, Jul 22, 2010 at 1:42 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
>> 2010/7/22 Danny Smith <dansmister@gmail.com>:
>>>>> c:\mingw\bin\../lib/gcc/mingw32/4.6.0/include/float.h:278:24: fatal error: float
>>>>> .h: No such file or directory
>>>>> compilation terminated.
>>>>>
>>>>> Danny
>>>>>
>>>>
>>>> I know. But as the float.h from gcc's internal header always comes
>>>> first in include order, this next_include in system-headers is wrong.
>>>
>>>
>>> mingw CRT and winapi headers have long been placed in the
>>> LOCAL_INCLUDE_DIR on window's hosts, since Windows doesn't really have
>>> a system include directory.  This local include dir is defined as
>>> being relative to exec_prefix in x-mingw32.
>>>
>>> The local include dir is included before gcc's internal headers.
>>>
>>> Danny
>>>
>>
>> That's right and therefore I dislike this patch and would prefer to
>> have that one Ozkan mentioned already. The issue is that sysroot &
>> cross- includes come after gcc's internal header, which is causing the
>> pain that it isn't absolutely predicatable, if system-headers are
>> reached or not.
>> By changing the order of gcc's internal to the end of the include
>> chain, it would be solved for all cases.
>
> Well, I think moving gcc headers to the end of the include chain is
> just wrong.  They are supposed to override host ones (which is
> why they are called "fixincludes").  Why not fixinclude mingw?
>
> Richard.
>

Because gcc's internal headers aren't the fixed-include ones. Secondly
the fixed-include headers coming after gcc's internal headers, so
using fixinclude leads nowhere and doesn't solve anything here.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination