[Bug middle-end/51233] [ipa-iterations] running multiple passes of early IPA on zlib produces more optimal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233 --- Comment #6 from richard.guenther at gmail dot com 2012-12-05 09:23:56 UTC --- On Tue, Dec 4, 2012 at 9:35 PM, matt at use dot net wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233 > > --- Comment #5 from Matt Hargett 2012-12-04 20:35:09 > UTC --- > ping? if you're more comfortable with relegating multiple passes to LTO, I > think that's a good starting point. we can wait for a per-unit C++ template > case to come up after that's in. Yes, multiple LTO passes is what I think should be done (or alternatively if one really dislikes this better processing of cgraph SCCs during early optimizations like I outlined in some e-mail response to the original patches). But the LTO approach should be more powerful anyway. > is there anything you'd like me to do to get this moving again? Produce patches for review? ;)
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #49 from richard.guenther at gmail dot com 2013-01-09 08:52:21 UTC --- On Tue, Jan 8, 2013 at 8:52 PM, dominiq at lps dot ens.fr wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 > > --- Comment #48 from Dominique d'Humieres > 2013-01-08 19:52:39 UTC --- > From comment #40: > >> with -ffast-math, so for example >> >> if (x != 0) >> tem = y / x; >> else >> tem = 0.; >> ... do sth with tem ... >> >> will execute y / x unconditionally based on the fact that it cannot trap. > > This optimization generates an exception trapped when using -ffpe-trap=invalid > along with -ffast-math. > This unfortunately prevents any debugging based -ffpe-trap=invalid for > miscompilations occurring with -ffast-math. Well - that's maybe unfortunate but expected. You can't have both ;) > One thing I hope, though I am not > sure about it, is that the above block is still compiled as > > tem=y/x > if (x==0) tem=0. Yes, it's basically turned into an unconditional divide plus a conditional move based on the fact that we cannot vectorize non-straight-line-code (so it's really only a vectorization enabler). > My original report was for '-O3 -funsafe-math-optimizations > -ffinite-math-only' > without -ffpe-trap=invalid. The segmentation fault resulted from the fact that > some variables were used to access a table and were out of bound when the > miscompilation generated some NAN (see comment #13). Yes, that's another common issue - with FP indexing even slight rounding differences can cause bogus accesses (consider producing a[0.99] instead of a[1.0]). That mostly happens with FP loop induction variables that are also used for indexing (a really bad practice the frontend should warn about - at least when -funsafe-math-optimizations is in effect). Richard. > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #26 from richard.guenther at gmail dot com 2013-01-16 16:05:01 UTC ---
On Wed, Jan 16, 2013 at 5:02 PM, jakub at gcc dot gnu.org
wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
>
> --- Comment #25 from Jakub Jelinek 2013-01-16
> 16:02:35 UTC ---
> The actual merging of target attribute isn't that important, what would be
> more
> important is that other attributes are merged together in that case and the
> decls treated as the same thing.
>
> Anyway, with target("any") attribute, what would happen for
> void foo () __attribute__((target ("avx")));
> void foo () __attribute__((target ("any")));
IMHO the re-declaration with a different target attribute should be an error.
A proper "forward" declaration for a function with MV applied shouldn't have
any target attribute.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #31 from richard.guenther at gmail dot com 2013-01-18 09:49:11 UTC ---
On Thu, Jan 17, 2013 at 11:45 PM, xinliangli at gmail dot com
wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
>
> --- Comment #30 from davidxl 2013-01-17
> 22:45:22 UTC ---
> (In reply to comment #26)
>> On Wed, Jan 16, 2013 at 5:02 PM, jakub at gcc dot gnu.org
>> wrote:
>> >
>> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
>> >
>> > --- Comment #25 from Jakub Jelinek 2013-01-16
>> > 16:02:35 UTC ---
>> > The actual merging of target attribute isn't that important, what would be
>> > more
>> > important is that other attributes are merged together in that case and the
>> > decls treated as the same thing.
>> >
>> > Anyway, with target("any") attribute, what would happen for
>> > void foo () __attribute__((target ("avx")));
>> > void foo () __attribute__((target ("any")));
>>
>> IMHO the re-declaration with a different target attribute should be an error.
>
> This can be a clean way to handle declarations. The definition should have
> either 'default' attribute or a matching target attribute.
>
>> A proper "forward" declaration for a function with MV applied shouldn't have
>> any target attribute.
>
> What does this sentence mean?
I think it would require to list all MV variants in the single declaration
void foo () __attribute__ ((target ("avx"), target ("any")));
but I suppose this goes against the idea of treating MV variants as regular
overloads which you can all declare.
Of course the issue whether / how to "merge" target attributes then returns.
I didn't pay too close attention, but if you settled on using a different
attribute name and then never perform merging of that attribute that would
indeed work.
Richard.
>
> David
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
[Bug c/45834] Redundant inter-loop edges in DDG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45834 --- Comment #2 from richard.guenther at gmail dot com 2010-10-18 11:38:03 UTC --- On Mon, Oct 18, 2010 at 1:33 PM, bmei at broadcom dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45834 > > Bingfeng Mei changed: > > What |Removed |Added > > CC| |richard.guenther at gmail > | |dot com > > --- Comment #1 from Bingfeng Mei 2010-10-18 > 11:33:23 UTC --- > Before using rtx_refs_may_alias_p in may_alias_p, following statement is > executed. > > > /* We cannot use aliases_everything_p to test MEM, since we must look > at MEM_ADDR, rather than XEXP (mem, 0). */ > if (GET_MODE (mem) == QImode || GET_CODE (mem_addr) == AND) > return 1; > > Basically, it means that the memory access of a QImode always aliases > everything else. That explains why char data type doesn't work here. The code > in may_alias_p is mostly copied from true_dependence_1. The comment is not > very > clear to me. Richard, could you cast a light on this? Why do we need to treat > QImode differently? I think it tries to work around bugs (it looks like char accesses or maybe memcpy/string inline expansion). You can try searching the history for this code, but I wouldn't be surprised if it pre-dates the use of even CVS ;) Richard. > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug. >
[Bug c/45834] Redundant inter-loop edges in DDG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45834 --- Comment #4 from richard.guenther at gmail dot com 2010-10-18 13:42:33 UTC --- On Mon, Oct 18, 2010 at 2:17 PM, bmei at broadcom dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45834 > > --- Comment #3 from Bingfeng Mei 2010-10-18 > 12:16:59 UTC --- > I think that standard specifies that char * may refer to an alias of any > object, that's why QImode is different here. Sure, but we have other means of dealing with that (MEM_ALIAS_SET == 0). > But I am not sure whether a > restrict qualifier will override that rule. restrict is a different concept from type-based aliasing. > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug. >
[Bug c/45834] Redundant inter-loop edges in DDG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45834 --- Comment #6 from richard.guenther at gmail dot com 2010-10-18 13:57:19 UTC --- On Mon, Oct 18, 2010 at 3:53 PM, bmei at broadcom dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45834 > > --- Comment #5 from Bingfeng Mei 2010-10-18 > 13:53:37 UTC --- >> >> Sure, but we have other means of dealing with that (MEM_ALIAS_SET == 0). > > Do you mean this check is redundant here ? I dig out the ancient code (from > 1997) > > /* If both references are struct references, or both are not, nothing > is known about aliasing. > > If either reference is QImode or BLKmode, ANSI C permits aliasing. > > If both addresses are constant, or both are not, nothing is known > about aliasing. */ > if (MEM_IN_STRUCT_P (x) == MEM_IN_STRUCT_P (mem) > || mem_mode == QImode || mem_mode == BLKmode > || GET_MODE (x) == QImode || GET_MODE (mem) == BLKmode > || varies (x_addr) == varies (mem_addr)) > return 1; > > The comment indicates that the check for QImode is for meeting aliasing rule > of > char type. I just say that we have other means to test for "char", the check for QImode is bogus. But it might well be that removing it exposes bugs. >> >> > But I am not sure whether a >> > restrict qualifier will override that rule. >> >> restrict is a different concept from type-based aliasing. >> > Sure, but in this example, on one hand, char type pointer is supposed to alias > any other data type, on the other hand, all the char pointers have restrict > qualifiers. What is correct behaviour, alias or not? char aliases all types. accesses through two different restrict qualified pointers do not alias. I don't see any conflict here. > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug. >
[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191
--- Comment #1 from richard.guenther at gmail dot com 2011-05-27 13:53:57 UTC ---
On Fri, May 27, 2011 at 3:50 PM, ro at gcc dot gnu.org
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191
>
> Summary: gcc.dg/memcpy-3.c FAILs on SPARC
> Product: gcc
> Version: 4.7.0
> Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: middle-end
> AssignedTo: unassig...@gcc.gnu.org
> ReportedBy: r...@gcc.gnu.org
> CC: ebotca...@gcc.gnu.org, richard.guent...@gmail.com
> Host: sparc-sun-solaris2.*
> Target: sparc-sun-solaris2.*
> Build: sparc-sun-solaris2.*
>
>
> The new gcc.dg/memcpy-3.c test FAILs on Solaris/SPARC:
>
> FAIL: gcc.dg/memcpy-3.c scan-tree-dump-not optimized "memcpy"
> FAIL: gcc.dg/memcpy-3.c scan-tree-dump-times optimized "MEM" 1
>
> The dump looks like this:
>
> ;; Function get_int (get_int)
>
> get_int (const void * p)
> {
> int w;
> int D.1980;
>
> :
> __builtin_memcpy (&w, p_1(D), 4);
> D.1980_2 = w;
> return D.1980_2;
Is sparc a strict-alignment target? Then that's expected.
Hmm. Not sure we have a dg-effective-target strict-align ...
so you probably have to add some xfails.
