On Tue, Jan 28, 2014 at 3:25 AM, Hans-Peter Nilsson 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! As fort
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
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
Hans-Peter Nilsson 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
>
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
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 ver
>> 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 ne
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,
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.
> >
>
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
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
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 p
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, skip
Hello,
I will try to produce a testcase for 4.8 and/or that doesn't involve OOP.
I come back to you later.
Thanks for the review.
Mikael
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 poin
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 s
17 matches
Mail list logo
