Re: GCC 4.8.0 Status Report (2013-03-06)
On 07/03/2013 21:00, Andrew Haley wrote: > Either Anthony or I review libffi patches in gcc. Perhaps you two should list yourselves as such in MAINTAINERS, for the avoidance of doubt? > You're not going to get any more reviews. I committed it. Thanks for the clarification. cheers, DaveK
Tracking the source of an ARM miscompilation with gcc 4.6
Hi, At Mozilla, we've encountered a GCC 4.6 miscompilation in the ARMv6 build of Firefox for Android. We'd like to evaluate whether this bug is hitting us in more places than the one we spotted. To that end, we'd need to know what particular bug in GCC leads to this miscompilation. The attached file is the preprocessed source, slightly simplified. I was able to reproduce the miscompilation with both the GCC 4.6 from the Android NDK r8d and 4.6.3 from Debian unstable. It apparently happens for any -march, with -marm, but not -mthumb. It happens at -Os but not -O2. The problematic assembly looks like the following. It corresponds to the C code after the second call to DER_SetUInteger in sftk_mkPrivKey:: bl DER_SetUInteger(PLT) mov r3, #0 cmp sl, r3 movne r0, #2 moveq r0, r3 sl/r10 is never set anywhere in the function, so we're getting random behaviour. This doesn't happen with GCC 4.7, which suggests it may be a known bug. Any ideas? Cheers, Mike
Re: Tracking the source of an ARM miscompilation with gcc 4.6
On Thu, Mar 7, 2013 at 12:24 AM, Mike Hommey wrote: > Hi, > > At Mozilla, we've encountered a GCC 4.6 miscompilation in the ARMv6 > build of Firefox for Android. We'd like to evaluate whether this bug is > hitting us in more places than the one we spotted. To that end, we'd > need to know what particular bug in GCC leads to this miscompilation. > > The attached file is the preprocessed source, slightly simplified. I was > able to reproduce the miscompilation with both the GCC 4.6 from the > Android NDK r8d and 4.6.3 from Debian unstable. It apparently happens > for any -march, with -marm, but not -mthumb. It happens at -Os but not > -O2. No attached file. Also does -fno-strict-aliasing fix it? Thanks, Andrew > > The problematic assembly looks like the following. It corresponds to > the C code after the second call to DER_SetUInteger in sftk_mkPrivKey:: > > bl DER_SetUInteger(PLT) > mov r3, #0 > cmp sl, r3 > movne r0, #2 > moveq r0, r3 > > sl/r10 is never set anywhere in the function, so we're getting random > behaviour. > > This doesn't happen with GCC 4.7, which suggests it may be a known bug. > Any ideas? > > Cheers, > > Mike
Re: New definition of regression
On Wed, 6 Mar 2013, Andrew Pinski wrote: > I am not a fan of the new definition of a regression. Yes the new > definition helps out release managers but it does not help out our > users at all. In fact I think it hurts them more as some don't update > as fast as the release managers think they do. I still support a 4.3 > based GCC and only starting to roll out a 4.7 based GCC. I think it > is wrong to say memory/compile time hogs are not regressions any more > just for the fun of it. > > Also this was not discussed at all on the list or I did not see it > being discussed. This decision should not be taken lightly when it > comes to some users of the compiler. Compile-time/memory-hog regressions are still regressions. We just count them as a single regression if they are present on all actively maintained branches. Help us by analyzing the reason for the memory-hog / compile-time-hog and open a separate regression bug for the _cause_ of the hog. That way we can determine in a more precise way when a regression was introduced and we can even close such regressions at some point (we can't with compile-time regressions - you are always left with a few seconds "regression", no?). That said, a compile-time / memory-hog regression should have an analyzed algorithmic cause, not just "well, it's using more time overall" or "it uses more peak memory". Because that's not useful information. Just my 2 cents. Btw, now that we no longer block our release by "more than 100 regressions" but by "no P1 regressions" the original reason for introducing the catch-all bug is gone (other to make that P[23] regression list not grow indefinitely as our versions progress). Richard.
Re: Tracking the source of an ARM miscompilation with gcc 4.6
On Thu, Mar 7, 2013 at 12:33 AM, Mike Hommey wrote: > On Thu, Mar 07, 2013 at 12:28:22AM -0800, Andrew Pinski wrote: >> On Thu, Mar 7, 2013 at 12:24 AM, Mike Hommey wrote: >> > Hi, >> > >> > At Mozilla, we've encountered a GCC 4.6 miscompilation in the ARMv6 >> > build of Firefox for Android. We'd like to evaluate whether this bug is >> > hitting us in more places than the one we spotted. To that end, we'd >> > need to know what particular bug in GCC leads to this miscompilation. >> > >> > The attached file is the preprocessed source, slightly simplified. I was >> > able to reproduce the miscompilation with both the GCC 4.6 from the >> > Android NDK r8d and 4.6.3 from Debian unstable. It apparently happens >> > for any -march, with -marm, but not -mthumb. It happens at -Os but not >> > -O2. >> >> No attached file. > > Sent it afterwards. Still not on the list. I bet it was too big so it was rejected by the list. Try filing a bug report instead. Thanks, Andrew > >> Also does -fno-strict-aliasing fix it? > > It doesn't (in fact, the file was already built with > -fno-strict-aliasing in Firefox) > > Mike
Re: RFC: IPACP function cloning without LTO
On Wed, Mar 6, 2013 at 4:43 PM, Martin Jambor wrote:
> Hi,
>
> On Wed, Mar 06, 2013 at 04:00:52PM +0400, Dinar Temirbulatov wrote:
>> Hi,
>> The current implementation of IPACP doesn't allowed to clone function
>> if caller(s) to that function is located in another object.
>
> That is not exactly true. With -fipa-cp-clone (default at -O3),
> IPA-CP is happy to clone a function that is callable from outside of
> the current compilation unit. Of course, only calls from within the
> CU are redirected without LTO.
yes, but that still would require manually preparing of CU for
selected number of objects.
> And code size may grow significantly,
> which is why IPA-CP does this only if it deems the estimated
> cost/benefit ratio to still be quite good.
>
>> Of course,
>> no such problems if we could utilized LTO. And it is very interesting
>> to have such functionality of compiler even without LTO. It could be
>> changed, if for example we could call to the cloned instance of that
>> function from the original instance of function in the function
>> prolog:
>> Here is what I mean:
>>
>> int func(int a, .)
>> {
>> if (a==some_constant)
>> func.constprop.0();
>>
>> thanks, Dinar.
>
> well, you could just as well put the quick version right into the
> original function (and execute the original in the else branch). If
> it is small and you did this in an early pass, IPA-SPLIT might even
> help inliner to inline it into known callers.
yes, the function cloning is just one example here.
>
> The tough part, however, is determining when this is such a good idea.
> Do you have any particular situation in mind?
I don't have. But for function cloning for example
good_cloning_opportunity_p() is a good point to start.
>
> Thanks,
>
> Martin
Re: Suppress warning for conversion prototype (that is present) (Bug 6144)
2013/3/5 Jeffrey Walton :
> Hi All,
[...]
>
> void func (short);
> void short_test (void)
> { short x = 0;
>func(x);
> }
>
> From the bug report example above, the warning is telling me there
> would be a problem if `void func (short);` was not present since it
> would be assumed to be `void func (int)` (if I'm reading things
> correctly).
>
> How do I turn off warnings for missing prototype conversions that are
> not even present? The bug report does not list a workaround.
> -Wno-traditional-conversion was unrecognized. So I'm guessing it would
> be similar to -Wno-conversion-prototype, but I don't see it at
> http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html.
>
> Jeff
If I compile such code example:
void short_test (void)
{
short x = 0;
func(x);
}
I got following warning messages:
$ gcc -c test.c -Wall
test.c: In function ‘short_test’:
test.c:7:4: warning: implicit declaration of function ‘func’
[-Wimplicit-function-declaration]
So I turn the warning off by using
'-Wno-implicit-function-declaration' and it works.
I think '-Wno-implicit-function-declaration' is the option your are
looking for~ :)
Best regards,
jasonwucj
Re: RFC: IPACP function cloning without LTO
Hi,
On Thu, Mar 07, 2013 at 01:28:49PM +0400, Dinar Temirbulatov wrote:
> On Wed, Mar 6, 2013 at 4:43 PM, Martin Jambor wrote:
> > On Wed, Mar 06, 2013 at 04:00:52PM +0400, Dinar Temirbulatov wrote:
...
> >> Here is what I mean:
> >>
> >> int func(int a, .)
> >> {
> >> if (a==some_constant)
> >> func.constprop.0();
> >>
> >> thanks, Dinar.
> >
> > well, you could just as well put the quick version right into the
> > original function (and execute the original in the else branch). If
> > it is small and you did this in an early pass, IPA-SPLIT might even
> > help inliner to inline it into known callers.
> yes, the function cloning is just one example here.
Well, speculatively adding quick paths to functions might help some
but I am not sure the cloning infrastructure is well suited to be used
somehow directly. It also appears to be a rather completely
intra-procedural undertaking as well.
> >
> > The tough part, however, is determining when this is such a good idea.
> > Do you have any particular situation in mind?
> I don't have. But for function cloning for example
> good_cloning_opportunity_p() is a good point to start.
>
But that function requires frequency information which you do not have
(without profile info but if you insist on having that, you might as
well investigate improving value profiling). It is also meant to be
called to inquire about a particular value of a parameter, and without
seeing the calling CU you would not know which values are passed in
those parameters at all.
Martin
Re: Tracking the source of an ARM miscompilation with gcc 4.6
Mike Hommey writes: > On Thu, Mar 07, 2013 at 01:14:03AM -0800, Andrew Pinski wrote: > > On Thu, Mar 7, 2013 at 12:33 AM, Mike Hommey wrote: > > > On Thu, Mar 07, 2013 at 12:28:22AM -0800, Andrew Pinski wrote: > > >> On Thu, Mar 7, 2013 at 12:24 AM, Mike Hommey > > >> wrote: > > >> > Hi, > > >> > > > >> > At Mozilla, we've encountered a GCC 4.6 miscompilation in the ARMv6 > > >> > build of Firefox for Android. We'd like to evaluate whether this bug > > >> > is > > >> > hitting us in more places than the one we spotted. To that end, we'd > > >> > need to know what particular bug in GCC leads to this miscompilation. > > >> > > > >> > The attached file is the preprocessed source, slightly simplified. I > > >> > was > > >> > able to reproduce the miscompilation with both the GCC 4.6 from the > > >> > Android NDK r8d and 4.6.3 from Debian unstable. It apparently happens > > >> > for any -march, with -marm, but not -mthumb. It happens at -Os but not > > >> > -O2. > > >> > > >> No attached file. > > > > > > Sent it afterwards. > > > > Still not on the list. I bet it was too big so it was rejected by the > > list. Try filing a bug report instead. > > Let's try it gzipped. If it still doesn't work, I'll file a bug. This test case is not self-contained. Please file a proper bug report with a self-contained test case.
Re: Tracking the source of an ARM miscompilation with gcc 4.6
On Thu, Mar 07, 2013 at 11:12:40AM +0100, Mikael Pettersson wrote: > Mike Hommey writes: > > On Thu, Mar 07, 2013 at 01:14:03AM -0800, Andrew Pinski wrote: > > > On Thu, Mar 7, 2013 at 12:33 AM, Mike Hommey wrote: > > > > On Thu, Mar 07, 2013 at 12:28:22AM -0800, Andrew Pinski wrote: > > > >> On Thu, Mar 7, 2013 at 12:24 AM, Mike Hommey > wrote: > > > >> > Hi, > > > >> > > > > >> > At Mozilla, we've encountered a GCC 4.6 miscompilation in the ARMv6 > > > >> > build of Firefox for Android. We'd like to evaluate whether this > bug is > > > >> > hitting us in more places than the one we spotted. To that end, we'd > > > >> > need to know what particular bug in GCC leads to this > miscompilation. > > > >> > > > > >> > The attached file is the preprocessed source, slightly simplified. > I was > > > >> > able to reproduce the miscompilation with both the GCC 4.6 from the > > > >> > Android NDK r8d and 4.6.3 from Debian unstable. It apparently > happens > > > >> > for any -march, with -marm, but not -mthumb. It happens at -Os but > not > > > >> > -O2. > > > >> > > > >> No attached file. > > > > > > > > Sent it afterwards. > > > > > > Still not on the list. I bet it was too big so it was rejected by the > > > list. Try filing a bug report instead. > > > > Let's try it gzipped. If it still doesn't work, I'll file a bug. > > This test case is not self-contained. Please file a proper bug report > with a self-contained test case. It is, as long as you don't want to make a library or program out of it: $ arm-linux-androideabi-gcc -o pkcs11.o -c -marm -Os pkcs11.i Mike
Re: Tracking the source of an ARM miscompilation with gcc 4.6
Mike Hommey writes: > On Thu, Mar 07, 2013 at 11:12:40AM +0100, Mikael Pettersson wrote: > > Mike Hommey writes: > > > On Thu, Mar 07, 2013 at 01:14:03AM -0800, Andrew Pinski wrote: > > > > On Thu, Mar 7, 2013 at 12:33 AM, Mike Hommey > > wrote: > > > > > On Thu, Mar 07, 2013 at 12:28:22AM -0800, Andrew Pinski wrote: > > > > >> On Thu, Mar 7, 2013 at 12:24 AM, Mike Hommey > > wrote: > > > > >> > Hi, > > > > >> > > > > > >> > At Mozilla, we've encountered a GCC 4.6 miscompilation in the > > ARMv6 > > > > >> > build of Firefox for Android. We'd like to evaluate whether this > > bug is > > > > >> > hitting us in more places than the one we spotted. To that end, > > we'd > > > > >> > need to know what particular bug in GCC leads to this > > miscompilation. > > > > >> > > > > > >> > The attached file is the preprocessed source, slightly > > simplified. I was > > > > >> > able to reproduce the miscompilation with both the GCC 4.6 from > > the > > > > >> > Android NDK r8d and 4.6.3 from Debian unstable. It apparently > > happens > > > > >> > for any -march, with -marm, but not -mthumb. It happens at -Os > > but not > > > > >> > -O2. > > > > >> > > > > >> No attached file. > > > > > > > > > > Sent it afterwards. > > > > > > > > Still not on the list. I bet it was too big so it was rejected by the > > > > list. Try filing a bug report instead. > > > > > > Let's try it gzipped. If it still doesn't work, I'll file a bug. > > > > This test case is not self-contained. Please file a proper bug report > > with a self-contained test case. > > It is, as long as you don't want to make a library or program out of it: > > $ arm-linux-androideabi-gcc -o pkcs11.o -c -marm -Os pkcs11.i It's not practical to verify or bisect miscompilations by manual inspection of generated assembly or object code. We strongly prefer runtime tests, which requires that test cases can be compiled to executables.
Re: Tracking the source of an ARM miscompilation with gcc 4.6
On Thu, Mar 07, 2013 at 11:34:30AM +0100, Mikael Pettersson wrote: > > > This test case is not self-contained. Please file a proper bug report > > > with a self-contained test case. > > > > It is, as long as you don't want to make a library or program out of it: > > > > $ arm-linux-androideabi-gcc -o pkcs11.o -c -marm -Os pkcs11.i > > It's not practical to verify or bisect miscompilations by manual inspection > of generated assembly or object code. We strongly prefer runtime tests, > which requires that test cases can be compiled to executables. Filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561 Mike
Re: GCC 4.8.0 Status Report (2013-03-06)
On 06/03/2013 16:05, Jakub Jelinek wrote: > If no new P1 appears within a week, I may be about to file one. What priority would "Java doesn't compile on a secondary platform" count as? There's a trivial bug in libffi and I already posted a patch(*) to both -patches and upstream, but am waiting for a response. cheers, DaveK -- (*) - http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01030.html
Re: Confusion about delay slots and using condition-code register
> I emit (clobber (reg:CC CCreg)) with every instruction that can set > condition codes, but it appears that nearly all of them are removed before > we reach reorg where mark_referenced_resources() or mark_set_resources() > would detect a conflict of the CCreg's. Clobbers shouldn't be removed if they are needed for an insn to match so... > The define_expand pattern for add looks like > > (define_expand "add3" > [(set (match_operand:S 0 "nonimmediate_operand") > (plus:S (match_operand:S 1 "general_operand") > (match_operand:S 2 "general_operand"))) >(clobber (reg:CC CC_REGNUM))] > "" > . > }) > has corresponding define_insn's are > > > (define_insn "*addsi" > [(set (match_operand:SI 0 "nonimmediate_operand" "=rm,rm,rS,rm") >(plus:SI (match_operand:SI 1 "nonimmediate_operand" "%0, 0, 0,rm") > (match_operand:SI 2 "general_operand" "QI, K,i,rm")))] , > ) ... why is there no clobber in the pattern if the instruction clobbers CC? -- Eric Botcazou
Re: GCC 4.8.0 Status Report (2013-03-06)
On Thu, Mar 7, 2013 at 9:09 AM, Dave Korn wrote: > On 06/03/2013 16:05, Jakub Jelinek wrote: > >> If no new P1 appears within a week, > > I may be about to file one. What priority would "Java doesn't compile on a > secondary platform" count as? There's a trivial bug in libffi and I already > posted a patch(*) to both -patches and upstream, but am waiting for a > response. Libffi merges seem to be causing a lot of problems. What can be done to improve the situation? Thanks, David
Re: GCC 4.8.0 Status Report (2013-03-06)
On 03/07/2013 02:09 PM, Dave Korn wrote: > On 06/03/2013 16:05, Jakub Jelinek wrote: > >> If no new P1 appears within a week, > > I may be about to file one. What priority would "Java doesn't compile on a > secondary platform" count as? There's a trivial bug in libffi and I already > posted a patch(*) to both -patches and upstream, but am waiting for a > response. Anthony approved it already on Feb 21. Andrew.
Re: GCC 4.8.0 Status Report (2013-03-06)
On 07/03/2013 16:55, Andrew Haley wrote: > On 03/07/2013 02:09 PM, Dave Korn wrote: >> On 06/03/2013 16:05, Jakub Jelinek wrote: >> >>> If no new P1 appears within a week, >> I may be about to file one. What priority would "Java doesn't compile on a >> secondary platform" count as? There's a trivial bug in libffi and I already >> posted a patch(*) to both -patches and upstream, but am waiting for a >> response. > > Anthony approved it already on Feb 21. Ah, I may have missed a point there. Does AG's approval apply to gcc's copy of libffi? He said he thought I should commit to gcc/libffi independently, but I thought I would need someone else's approval for that. I see now that there is no gcc-specific libffi maintainer listed in MAINTAINERS, so I should just go ahead and commit? cheers, DaveK
Re: GCC 4.8.0 Status Report (2013-03-06)
On Thu, Mar 07, 2013 at 08:23:20PM +, Dave Korn wrote: > On 07/03/2013 16:55, Andrew Haley wrote: > > On 03/07/2013 02:09 PM, Dave Korn wrote: > >> On 06/03/2013 16:05, Jakub Jelinek wrote: > >> > >>> If no new P1 appears within a week, > >> I may be about to file one. What priority would "Java doesn't compile > >> on a > >> secondary platform" count as? There's a trivial bug in libffi and I > >> already > >> posted a patch(*) to both -patches and upstream, but am waiting for a > >> response. > > > > Anthony approved it already on Feb 21. > > Ah, I may have missed a point there. Does AG's approval apply to gcc's copy > of libffi? He said he thought I should commit to gcc/libffi independently, > but I thought I would need someone else's approval for that. I see now that > there is no gcc-specific libffi maintainer listed in MAINTAINERS, so I should > just go ahead and commit? Yes. Jakub
Re: GCC 4.8.0 Status Report (2013-03-06)
On 03/07/2013 08:23 PM, Dave Korn wrote: > On 07/03/2013 16:55, Andrew Haley wrote: >> On 03/07/2013 02:09 PM, Dave Korn wrote: >>> On 06/03/2013 16:05, Jakub Jelinek wrote: >>> If no new P1 appears within a week, >>> I may be about to file one. What priority would "Java doesn't compile on >>> a >>> secondary platform" count as? There's a trivial bug in libffi and I already >>> posted a patch(*) to both -patches and upstream, but am waiting for a >>> response. >> >> Anthony approved it already on Feb 21. > > Ah, I may have missed a point there. Does AG's approval apply to gcc's copy > of libffi? Yes. > He said he thought I should commit to gcc/libffi independently, but > I thought I would need someone else's approval for that. I see now > that there is no gcc-specific libffi maintainer listed in > MAINTAINERS, so I should just go ahead and commit? Either Anthony or I review libffi patches in gcc. The other thing that happens is that the back-end maintainers sometimes review libffi patches because those maintainers are the most knowledgeable. You're not going to get any more reviews. Andrew.
