On Tue, Jan 28, 2014 at 3:25 AM, Hans-Peter Nilsson h...@bitrange.com wrote:
On Mon, 27 Jan 2014, Richard Biener wrote:
Huh, so we have C for cross-builds and C++ for bootstraps.
No, we use a C host compiler in both cases. Only stages 2 and 3 build with a
C++ compiler.
Tomatos potatoes!
On Mon, Jan 27, 2014 at 06:17:38PM +0100, Richard Biener wrote:
Huh, so we have C for cross-builds and C++ for bootstraps.
No, we use a C host compiler in both cases. Only stages 2 and 3 build with a
C++ compiler.
And even for stage{2,3} C can be optionally used by asking for it using a
Hans-Peter Nilsson h...@bitrange.com wrote:
On Mon, 27 Jan 2014, Mikael Morin wrote:
Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit :
On Sun, 26 Jan 2014, Mikael Morin wrote:
Le 18/01/2014 21:17, Mikael Morin a écrit :
Well, I guess that due to the touchy nature of the bug, there are
cases
Le 27/01/2014 09:49, Janus Weil a écrit :
Did you bootstrap test the 4.7 backport?
Yes, works like a charm here.
I also see the build problem (configuring with
--enable-languages=c,fortran --disable-bootstrap).
I have committed the following as http://gcc.gnu.org/r207152
I made sure it
On Mon, 27 Jan 2014, Richard Biener wrote:
Huh, so we have C for cross-builds and C++ for bootstraps.
No, we use a C host compiler in both cases. Only stages 2 and 3 build with a
C++ compiler.
Tomatos potatoes! As fortran isn't built until then, it'll be
built as C for cross-builds and C++
Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit :
On Sun, 26 Jan 2014, Mikael Morin wrote:
Le 18/01/2014 21:17, Mikael Morin a écrit :
Well, I guess that due to the touchy nature of the bug, there are cases
that work by luck on old versions and fail (by unluck) on newer ones.
Thus, I will
Did you bootstrap test the 4.7 backport?
Yes, works like a charm here.
I also see the build problem (configuring with
--enable-languages=c,fortran --disable-bootstrap).
Looks like you committed C++ code there, in module.c:
...
3867 static void
3868 skip_list (int nest_level = 0)
On Mon, 27 Jan 2014, Mikael Morin wrote:
Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit :
On Sun, 26 Jan 2014, Mikael Morin wrote:
Le 18/01/2014 21:17, Mikael Morin a écrit :
Well, I guess that due to the touchy nature of the bug, there are cases
that work by luck on old versions and
Le 18/01/2014 21:17, Mikael Morin a écrit :
Well, I guess that due to the touchy nature of the bug, there are cases
that work by luck on old versions and fail (by unluck) on newer ones.
Thus, I will backport in a few days to 4.8 and 4.7.
I added the following hardening to the patch on the 4.8
On Sun, 26 Jan 2014, Mikael Morin wrote:
Le 18/01/2014 21:17, Mikael Morin a écrit :
Well, I guess that due to the touchy nature of the bug, there are cases
that work by luck on old versions and fail (by unluck) on newer ones.
Thus, I will backport in a few days to 4.8 and 4.7.
I added
Hello,
Le 11/01/2014 22:48, Janus Weil a écrit :
Good, thanks for checking. As written before, the patch is ok for
trunk from my side.
I finally committed it as revision 206759 (with the second testcase and
a bit more comments).
In fact your test case fails with all versions I tried (4.4,
However, I don't quite see the necessity for changing the module
format (apart from the fact that it makes your patch slightly
simpler).
I think it should otherwise reading old module gives
Expected left parenthesis.
Cheers,
Dominique
Le 04/01/2014 16:35, Janus Weil a écrit :
Hi Mikael,
this patch fixes PR58007, where the compiler was not able to relate a
component pointer to any loaded derived type symbol.
The problem came from an optimization avoiding loading again a symbol
which had already been loaded, skipping by
Hi,
this patch fixes PR58007, where the compiler was not able to relate a
component pointer to any loaded derived type symbol.
The problem came from an optimization avoiding loading again a symbol
which had already been loaded, skipping by the way the association of
component pointers (if
Hi Mikael,
this patch fixes PR58007, where the compiler was not able to relate a
component pointer to any loaded derived type symbol.
The problem came from an optimization avoiding loading again a symbol
which had already been loaded, skipping by the way the association of
component pointers
Hello,
this patch fixes PR58007, where the compiler was not able to relate a
component pointer to any loaded derived type symbol.
The problem came from an optimization avoiding loading again a symbol
which had already been loaded, skipping by the way the association of
component pointers (if the
16 matches
Mail list logo
