[Bug c/53784] Scalar vector binary operation - compilation fails with -std=c90/c99/c11 (-fexcess-precision=standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53784 Dag Lem dag at nimrod dot no changed: What|Removed |Added Target||i686-redhat-linux --- Comment #3 from Dag Lem dag at nimrod dot no 2012-08-01 06:29:30 UTC --- The bug can not be reproduced on x86_64, only on i386. gcc -v from Fedora 17 i386: Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-redhat-linux/4.7.0/lto-wrapper Target: i686-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i686 --build=i686-redhat-linux Thread model: posix gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)
[Bug tree-optimization/54143] [4.8 Regression] Bytemark ASSIGNMENT 8% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54143 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-* Target Milestone|--- |4.8.0
[Bug c++/54145] [4.7/4.8 Regression] no symbol generated for `void QMailThreadSortKey::deserializeQDataStream(QDataStream)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54145 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Target Milestone|--- |4.7.2 Summary|[4.6/4.7 Regression] no |[4.7/4.8 Regression] no |symbol generated for `void |symbol generated for `void |QMailThreadSortKey::deseria |QMailThreadSortKey::deseria |lizeQDataStream(QDataStre |lizeQDataStream(QDataStre |am)' |am)'
[Bug plugins/54148] FAIL: gcc.dg/plugin/selfassign.c compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54148 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-01 07:47:05 UTC --- I don't see any error in that?
[Bug rtl-optimization/54133] regrename introduces additional dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133
--- Comment #2 from amker.cheng amker.cheng at gmail dot com 2012-08-01
07:49:51 UTC ---
I measured this kind of regression in benchmark CSiBE on
arm-none-eabi/cortex-m0 with Os optimization. Turns out most of the them are
relate to paramter/return register moving, like the reported case.
The logic is:
STEP1: At prologue or after call_insn, gcc saves parameter(or return) registers
in pseudos, then load it from the pseudo when need to use it(like calling
another function with the paramter).
For example:
{
rx - r0
...
...
r0 - rx
call another function
}
If instructions between saving and using do not clobber paramter register, the
hard register can be propagated to remove one redundant move instruction.
STEP2: copy propagation before IRA just ignore hard registers, so usually these
can only be done in regcprop.c after IRA.
BUT,
STEP3: register renaming does not honor any propagation opportunities and may
using r0 to rename, which introduces additional dependencies. It's a common
regression because regrename always select renaming register from 0 to
FIRST_PSEUOD_REG.
In experiment, if I disable r0/r1 from renaming, most regressions observed in
CSiBE are gone.
So how should this be fixed? Thanks.
[Bug c/54149] New: write introduction incorrect wrt the C11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54149
Bug #: 54149
Summary: write introduction incorrect wrt the C11 memory model
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: francesco.zappa.narde...@gmail.com
[ possibly related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 ]
Consider this program:
int g_13 = 1;
void main () {
int l_245;
for (l_245 = 0; l_245 = 1; l_245 += 1)
for (; g_13 = 0; g_13 = 1);
}
If I compile it with
gcc --param allow-store-data-races=0 -S -O1
(I am running gcc (GCC) 4.8.0 20120627 (experimental) on Linux - x86_64 -- the
same applies to -O2 and -O3 and compilation with g++ -std=c++11 -O1)
I get the following optimised assembler (I just hand removed some noise):
main:
movlg_13(%rip), %eax
testl %eax, %eax
movl$1, %edx
cmovle %edx, %eax
movl%eax, g_13(%rip)
ret
g_13:
.long 1
which always performs a write to g_13 and executes with this memory trace (I am
tracing only the accesses to the global - potentially shared - variables):
g_131 4Init
g_131 4Load
g_131 4 Store
However the reference trace for the C11 program above never performs a write to
g_13:
g_131 4Init
g_131 4Load
g_131 4Load
This looks related to the problem I reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 , as the optimiser introduces
a memory write which should not be there (and in turn performs an optimisation
not correct wrt the C11 or the C++11 memory model). The same discriminating
context of bug 52558 applies.
For reference:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/yquem/moscova/zappa/source/gcc-svn-bin/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure
--prefix=/home/yquem/moscova/zappa/source/gcc-svn-bin/
Thread model: posix
gcc version 4.8.0 20120627 (experimental) (GCC)
[Bug c++/54130] Recognize builtins with bool return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130 --- Comment #9 from Marc Glisse glisse at gcc dot gnu.org 2012-08-01 09:22:37 UTC --- I realize that several (not all) of the things discussed here assume that functions returning bool and int are binary compatible, which is likely true on most platforms but there might be exceptions.
[Bug c++/54130] Recognize builtins with bool return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-01 09:26:53 UTC --- (In reply to comment #9) I realize that several (not all) of the things discussed here assume that functions returning bool and int are binary compatible, which is likely true on most platforms but there might be exceptions. It's not true on x86_64 - return values are not extended to word_mode thus you may have garbage in the upper parts of %eax for bool.
[Bug c++/54130] Recognize builtins with bool return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130
--- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-01
09:28:43 UTC ---
(In reply to comment #10)
(In reply to comment #9)
I realize that several (not all) of the things discussed here assume that
functions returning bool and int are binary compatible, which is likely
true on
most platforms but there might be exceptions.
It's not true on x86_64 - return values are not extended to word_mode thus
you may have garbage in the upper parts of %eax for bool.
Testcase:
_Bool foo (_Bool *p)
{
return *p;
}
compile at -Os and get
foo:
.LFB0:
.cfi_startproc
movb(%rdi), %al
ret
which I believe at least preserves %ah (not sure about bits 16 .. 32).
[Bug c++/54074] [C++0x] [DR 1270] initializer list accepts incorrect nested input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54074 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-01 09:33:33 UTC --- WONTFIX means it is a bug, but we're not going to fix it, so it's not the right resolution. This isn't a bug if G++ agrees with the standard (assuming DR 1270 moves to DR status, which is why I'd left this suspended)
[Bug fortran/54147] [F03] Interface checks for PPCs deferred TBPs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54147 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-08-01 AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Summary|[F03] Interface checks for |[F03] Interface checks for |PPCs TBPs |PPCs deferred TBPs Ever Confirmed|0 |1 --- Comment #3 from janus at gcc dot gnu.org 2012-08-01 09:34:15 UTC --- (In reply to comment #0) After fixing PR 42418, I realized that the constraints in F08:C1216 apply also to 1) procedure-pointer components and 2) type-bound procedures, to be precise, they only apply to *deferred* TBPs, since 'regular' ones do not have an interface specification. I'm working on a patch ...
[Bug c++/54130] Recognize builtins with bool return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130 --- Comment #12 from Marc Glisse glisse at gcc dot gnu.org 2012-08-01 09:49:12 UTC --- (In reply to comment #10) (In reply to comment #9) I realize that several (not all) of the things discussed here assume that functions returning bool and int are binary compatible, which is likely true on most platforms but there might be exceptions. It's not true on x86_64 - return values are not extended to word_mode thus you may have garbage in the upper parts of %eax for bool. Ok thanks, that seems to put the nail in the coffin for these techniques. I guess I should close this bug, and file the only part that remains (the missed optimization at the end of Comment 8) separately.
[Bug c++/54130] Recognize builtins with bool return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130 --- Comment #13 from Marc Glisse glisse at gcc dot gnu.org 2012-08-01 09:52:19 UTC --- (In reply to comment #10) (In reply to comment #9) I realize that several (not all) of the things discussed here assume that functions returning bool and int are binary compatible, which is likely true on most platforms but there might be exceptions. It's not true on x86_64 - return values are not extended to word_mode thus you may have garbage in the upper parts of %eax for bool. Wait, actually, it only requires compatibility in one direction, that a function returning int (isnan for instance) can be used as a function returning bool, which seems ok in that case (there could still be other counter-examples).
[Bug rtl-optimization/54133] regrename introduces additional dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2012-08-01 10:13:32 UTC --- With GCC: (GNU) 4.8.0 20120731 (experimental) [trunk revision 190015] the dumps look slightly different. I'm using the -fdump-rtl-all-slim dumps (with a local patch to dump SEQUENCEs also) and have this dump, showing the same problem: BEFORE REGRENAME (.207r.ce3) AFTER REGRENAME (.208r.rnreg) 154 r4:SI=r0:SI = 154 r4:SI=r0:SI REG_DEAD: r0:SI = REG_DEAD: r0:SI 155 r5:SI=r1:SI = 155 r5:SI=r1:SI REG_DEAD: r1:SI = REG_DEAD: r1:SI 144 r2:DF=[sp:SI+0x28] | 144 r0:DF=[sp:SI+0x28] 80 [sp:SI]=r2:DF|80 [sp:SI]=r0:DF REG_DEAD: r2:DF = REG_DEAD: r2:DF 145 r2:DF=[sp:SI+0x38] = 145 r2:DF=[sp:SI+0x38] 81 [sp:SI+0x8]=r2:DF=81 [sp:SI+0x8]=r2:DF REG_DEAD: r2:DF = REG_DEAD: r2:DF 146 r2:DF=[sp:SI+0x48] | 146 r1:DF=[sp:SI+0x48] 82 [sp:SI+0x10]=r2:DF |82 [sp:SI+0x10]=r1:DF REG_DEAD: r2:DF = REG_DEAD: r2:DF 156 r0:SI=r4:SI = 156 r0:SI=r4:SI 157 r1:SI=r5:SI = 157 r1:SI=r5:SI 84 r2:DF=[sp:SI+0x18] =84 r2:DF=[sp:SI+0x18] 85 r0:DF=call [`bar'] argc:0x18 =85 r0:DF=call [`bar'] argc:0x18 REG_DEAD: r2:DF = REG_DEAD: r2:DF REG_UNUSED: r0:DF= REG_UNUSED: r0:DF 147 r2:DF=[sp:SI+0x30] | 147 r0:DF=[sp:SI+0x30] 86 [sp:SI]=r2:DF|86 [sp:SI]=r0:DF REG_DEAD: r2:DF = REG_DEAD: r2:DF 148 r2:DF=[sp:SI+0x40] = 148 r2:DF=[sp:SI+0x40] 87 [sp:SI+0x8]=r2:DF=87 [sp:SI+0x8]=r2:DF REG_DEAD: r2:DF = REG_DEAD: r2:DF 149 r2:DF=[sp:SI+0x50] | 149 r1:DF=[sp:SI+0x50] 88 [sp:SI+0x10]=r2:DF |88 [sp:SI+0x10]=r1:DF REG_DEAD: r2:DF = REG_DEAD: r2:DF 158 r0:SI=r4:SI = 158 r0:SI=r4:SI REG_DEAD: r4:SI = REG_DEAD: r4:SI 159 r1:SI=r5:SI = 159 r1:SI=r5:SI REG_DEAD: r5:SI = REG_DEAD: r5:SI 90 r2:DF=[sp:SI+0x20] =90 r2:DF=[sp:SI+0x20] 91 r0:DF=call [`bar'] argc:0x18 =91 r0:DF=call [`bar'] argc:0x18 REG_DEAD: r2:DF = REG_DEAD: r2:DF REG_UNUSED: r0:DF= REG_UNUSED: r0:DF The sets of r4 and r5 are actually not used for anything other than preserving/reloading the values of r0 and r1 for the second call to bar. To understand how the sets of r4 and r5 come into existence to begin with, we need to look at the pre-regalloc dumps, e.g. the .191r.asmcons dump: 77 r0:DF=call [`__aeabi_ddiv'] argc:0 REG_DEAD: r2:DF REG_EH_REGION: 0x8000 78 r177:DF=r0:DF REG_DEAD: r0:DF 80 [sp:SI]=r166:DF 81 [sp:SI+0x8]=r168:DF 82 [sp:SI+0x10]=r170:DF 83 r0:DF=r177:DF 84 r2:DF=r164:DF 85 r0:DF=call [`bar'] argc:0x18 REG_DEAD: r2:DF REG_UNUSED: r0:DF 86 [sp:SI]=r167:DF 87 [sp:SI+0x8]=r169:DF 88 [sp:SI+0x10]=r171:DF 89 r0:DF=r177:DF REG_DEAD: r177:DF In insn 78, r177 is used to memoize the call result from __aeabi_ddiv (which is the variable t in the source code). IRA goes to work on this and finds: Reg 177: local to bb 4 def dominates all uses has unique first use Found def insn 78 for 177 to be not moveable (insn 78 is not moveable because a hard register is involved in the SET_SRC) Insn 78(l0): point = 37 Insn 89(l0): point = 17 Insn 88(l0): point = 19 ;; a5(r177,l0) conflicts: ;; subobject 0: a1(r159,l0) a2(r172,l0) a3(r163,l0) a4(r165,w0,l0) a4(r165,w1,l0) a6(r171,w0,l0) a6(r171,w1,l0) a7(r169,w0,l0) a7(r169,w1,l0) a8(r167,w0,l0) a8(r167,w1,l0) a9(r164,w0,l0) a9(r164,w1,l0) a10(r170,w0,l0) a10(r170,w1,l0) a11(r168,w0,l0) a11(r168,w1,l0) a12(r166,w0,l0) a12(r166,w1,l0) a0(r175,l0) ;; total conflict hard regs: 0-3 12 ;; conflict hard regs: 0-3 12 So r177 conflicts with r0 and can't be coalesced, and r177 ends up allocated to the first available hard register, which is r4. In .198r.split2, the DFmode set in insn 78 is split to set r4 and r5. This issue can in theory be fixed before reload: You'd have to copy-propagate the hard-register set of r177 in insn 78 to its use in insn 83. There is a risk that this won't work in general because you can't know before reload whether r0 will be needed for reloads in the interlying insns and you may end up increasing register pressure and spoiling the code. Therefore you'd want to propagate as late as possible. That would be the regmove pass. I'm trying something, will post later today...
[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48820 --- Comment #19 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-01 10:35:28 UTC --- (In reply to comment #17) TODO: 1. Remaining issues of assumed-rank, e.g. shape/ubound/lbound, class-to-type handling, contiguous attribute. And INTENT(OUT) handling, cf. http://gcc.gnu.org/ml/fortran/2012-08/msg0.html Patch for shape/ubound/lbound: http://gcc.gnu.org/ml/fortran/2012-07/msg00132.html 2. Update/relax checking for various C interop functions such as c_loc and c_f_pointer. Cf. also PR48858 (!) and PR47023 but also PR40963, PR38829, PR39288, PR38813. Currently, some valid F2003 is also rejected; F2008 and TS 29113 relaxed constraints are unimplemented. Meta bug: PR32630 See also http://gcc.gnu.org/ml/fortran/2012-07/msg00115.html for some TODO items. [c_funloc, c_f_procpointer has been fixed with Rev. 190003.] 4. Implement the new array descriptor (cf. PR 37577, PR 48820)
[Bug tree-optimization/54077] [4.7/4.8 Regression] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #8 from wbrana wbrana at gmail dot com 2012-08-01 10:59:46 UTC --- If I didn't make mistake it seems big slow down is caused by revision 175752 Date: Fri Jul 1 10:00:25 2011 + 2011-07-01 Kai Tietz kti...@redhat.com * tree-ssa-forwprop.c (simplify_bitwise_binary): Fix typo. 2011-07-01 Kai Tietz kti...@redhat.com * gcc.dg/tree-ssa/bitwise-sink.c: New test. 175751 FP EMULATION: 318.76 : 152.96 : 35.29 175752 FP EMULATION: 227.68 : 109.25 : 25.21
[Bug rtl-optimization/54133] regrename introduces additional dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133 --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-08-01 11:58:00 UTC --- Created attachment 27918 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27918 Hack regmove to do limited propagation of hard regs I have a patch to make the propagation happen in regmove, resulting in the following RTL in the IRA dump: 78 r177:DF=r0:DF 80 [sp:SI]=r166:DF 81 [sp:SI+0x8]=r168:DF 82 [sp:SI+0x10]=r170:DF 84 r2:DF=r164:DF 85 r0:DF=call [`bar'] argc:0x18 REG_DEAD: r2:DF REG_UNUSED: r0:DF 86 [sp:SI]=r167:DF 87 [sp:SI+0x8]=r169:DF 88 [sp:SI+0x10]=r171:DF 89 r0:DF=r177:DF REG_DEAD: r177:DF 90 r2:DF=r165:DF 91 r0:DF=call [`bar'] argc:0x18 But now IRA decides to spill r177 to memory: Allocno a5r177 of GENERAL_REGS(9) has 4 avail. regs 4-7, node: 4-7 obj 0 (confl regs = 0-3 8-102), obj 1 (confl regs = 0-3 8-102) Pushing a5(r177,l0)(potential spill: pri=469, cost=38000) Making a1(r159,l0) colorable Making a2(r172,l0) colorable Making a3(r163,l0) colorable Pushing a1(r159,l0)(cost 32000) Pushing a3(r163,l0)(cost 4) Pushing a2(r172,l0)(cost 88000) Popping a2(r172,l0) -- assign reg 4 Popping a3(r163,l0) -- assign reg 5 Popping a1(r159,l0) -- assign reg 6 Popping a5(r177,l0) -- (memory is more profitable 32000 vs 2147483647) spill Popping a0(r175,l0) -- assign reg 7 This makes the inner loop 2 instructions smaller, but I haven't investigated whether that's an improvement or not.
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2012-08-01
12:22:29 UTC ---
With my patch applied, and with a couple of lines commented out at the bottom:
// checkCGAL::QuotientCGAL::Gmpz ();
// checkCGAL::Lazy_exact_ntCGAL::Gmpq ();
// checkCORE::BigInt();
// checkCORE::BigRat();
// checkCORE::BigFloat();
// checkCORE::Expr();
and with the compiler patched with the patch from comment #5 and configured as:
$ cat configargs.h
/* Generated automatically. */
static const char configuration_arguments[] = ../trunk/configure
--with-mpfr=/opt/cfarm/mpfr-latest --with-gmp=/opt/cfarm/gmp-latest
--with-mpc=/opt/cfarm/mpc-latest --with-isl=/opt/cfarm/isl-latest
--with-cloog=/opt/cfarm/cloog-latest --enable-languages=c,c++ --disable-nls
--disable-libmudflap --disable-libssp --disable-libitm --disable-multilib
--disable-bootstrap --enable-checking=release;
static const char thread_model[] = posix;
static const struct {
const char *name, *value;
} configure_default_options[] = { { cpu, generic }, { arch, x86-64 } };
I have TOTAL :8223.99 seconds compile time. Top 10 big spenders:
inline heuristics :6393.58 (78%) usr 175699 kB (27%) ggc
tree loop init : 270.76 ( 3%) usr 242922 kB (37%) ggc
if-conversion : 220.55 ( 3%) usr 3774 kB ( 1%) ggc
integrated RA : 199.12 ( 2%) usr 593696 kB (90%) ggc
reload : 128.67 ( 2%) usr 52399 kB ( 8%) ggc
tree SSA incremental: 195.26 ( 2%) usr 160581 kB (24%) ggc
tree SSA rewrite: 112.87 ( 1%) usr 39761 kB ( 6%) ggc
df live regs: 79.90 ( 1%) usr 0 kB ( 0%) ggc
df liveinitialized regs: 77.14 ( 1%) usr 0 kB ( 0%) ggc
out of ssa : 63.59 ( 1%) usr661 kB ( 0%) ggc
The inline heuristics stuff is probably also due to stack-vars handling, I will
look into that.
The loop init stuff is something for Richi.
IRA produces the most garbage, by far, and in fact causes OOM if I do not
comment out those last few lines.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #75 from Mikael Morin mikael at gcc dot gnu.org 2012-08-01 12:22:03 UTC --- Created attachment 27919 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27919 rough patch (In reply to comment #74) For variable to be type compatible for assignment, they shall be variants of the same type, and thus have the same TYPE_FIELDS. If they shall have the same TYPE_FIELDS, they shall have the same components, the same components have the same types, so that one cannot be restrict qualified. The types should not be variant types ;) (see my hack patch in this or another bug) Ah OK, I thought it was just a hack. nor does it address the original issue of supporting INTENT IN/OUT properly. Ah? Isn't a restricted type variable (resp. component, etc) merely one that has its own alias set? So if it works with restrict, it works with alias sets? No, alias-sets and restrict are different beasts. It's important to have the data member restrict qualified for INTENT IN/OUT. Ah. I have attached a (very rough) patch which is already in the testsuite past the first failing cases reported by Dominique. About your fix: (In reply to comment #64) Index: gcc/fortran/trans-types.c === --- gcc/fortran/trans-types.c (revision 184203) +++ gcc/fortran/trans-types.c (working copy) @@ -2042,7 +2042,8 @@ gfc_nonrestricted_type (tree t) } if (!field) break; - ret = build_variant_type_copy (t); + ret = build_distinct_type_copy (t); + TYPE_CANONICAL (ret) = TYPE_CANONICAL (t); TYPE_FIELDS (ret) = NULL_TREE; /* Here we make sure that as soon as we know we have to copy there is another call to build_variant_type_copy before about array types. Should the same fix by applied or are variants OK there?
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #76 from rguenther at suse dot de rguenther at suse dot de
2012-08-01 12:28:10 UTC ---
On Wed, 1 Aug 2012, mikael at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #75 from Mikael Morin mikael at gcc dot gnu.org 2012-08-01
12:22:03 UTC ---
Created attachment 27919
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27919
rough patch
(In reply to comment #74)
For variable to be type compatible for assignment, they shall be variants
of
the same type, and thus have the same TYPE_FIELDS.
If they shall have the same TYPE_FIELDS, they shall have the same
components,
the same components have the same types, so that one cannot be restrict
qualified.
The types should not be variant types ;) (see my hack patch in
this or another bug)
Ah OK, I thought it was just a hack.
nor does it address the original
issue of supporting INTENT IN/OUT properly.
Ah? Isn't a restricted type variable (resp. component, etc) merely one
that has
its own alias set? So if it works with restrict, it works with alias sets?
No, alias-sets and restrict are different beasts. It's important to
have the data member restrict qualified for INTENT IN/OUT.
Ah.
I have attached a (very rough) patch which is already in the testsuite past
the
first failing cases reported by Dominique.
About your fix:
(In reply to comment #64)
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c (revision 184203)
+++ gcc/fortran/trans-types.c (working copy)
@@ -2042,7 +2042,8 @@ gfc_nonrestricted_type (tree t)
}
if (!field)
break;
- ret = build_variant_type_copy (t);
+ ret = build_distinct_type_copy (t);
+ TYPE_CANONICAL (ret) = TYPE_CANONICAL (t);
TYPE_FIELDS (ret) = NULL_TREE;
/* Here we make sure that as soon as we know we have to copy
there is another call to build_variant_type_copy before about array types.
Should the same fix by applied or are variants OK there?
You mean
case ARRAY_TYPE:
{
tree elemtype = gfc_nonrestricted_type (TREE_TYPE (t));
if (elemtype == TREE_TYPE (t))
ret = t;
else
{
ret = build_variant_type_copy (t);
? Yes, that also should be build_distinct_type_copy.
Richard.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #77 from Mikael Morin mikael at gcc dot gnu.org 2012-08-01 12:37:45 UTC --- (In reply to comment #75) Created attachment 27919 [details] rough patch About the patch: The failures are mostly(all?) due to structure constructors. Structure constructors use components' backend_decl which are of restricted types. however, if the lhs is a target, one should use the non-restricted components. I tried fixing the constructor using gfc_convert (see the patch). However, it doesn't work with scalarization, as the constructor is evaluated outside the loop into a variable (which gets the restricted type). So, this patch adds a flag restricted to gfc_conv_structure. the flag propagates to gfc_conv_expr, and gfc_conv_initializer, gfc_conv_initializer, etc. To know whether we need to call gfc_conv_expr with the restricted flag set or not in the scalarizer, a new flag field is added to the scalarizer's gfc_ss_info structures to tell whether we want a non-restricted expression. For it to be set appropriately, a flag is propagated to the gfc_walk_* functions.
[Bug tree-optimization/46556] Code size regression in struct access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556 --- Comment #9 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-08-01 13:02:46 UTC --- Author: wschmidt Date: Wed Aug 1 13:02:38 2012 New Revision: 190037 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190037 Log: gcc: PR tree-optimization/46556 * gimple-ssa-strength-reduction.c (enum cand_kind): Add CAND_REF. (base_cand_map): Change to hash table. (base_cand_hash): New function. (base_cand_free): Likewise. (base_cand_eq): Likewise. (lookup_cand): Change base_cand_map to hash table. (find_basis_for_candidate): Likewise. (base_cand_from_table): Exclude CAND_REF. (restructure_reference): New function. (slsr_process_ref): Likewise. (find_candidates_in_block): Call slsr_process_ref. (dump_candidate): Handle CAND_REF. (base_cand_dump_callback): New function. (dump_cand_chains): Change base_cand_map to hash table. (replace_ref): New function. (replace_refs): Likewise. (analyze_candidates_and_replace): Call replace_refs. (execute_strength_reduction): Change base_cand_map to hash table. gcc/testsuite: PR tree-optimization/46556 * testsuite/gcc.dg/tree-ssa/slsr-27.c: New. * testsuite/gcc.dg/tree-ssa/slsr-28.c: New. * testsuite/gcc.dg/tree-ssa/slsr-29.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/slsr-27.c trunk/gcc/testsuite/gcc.dg/tree-ssa/slsr-28.c trunk/gcc/testsuite/gcc.dg/tree-ssa/slsr-29.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-strength-reduction.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/46556] Code size regression in struct access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-08-01 13:02:46 UTC --- Author: wschmidt Date: Wed Aug 1 13:02:38 2012 New Revision: 190037 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190037 Log: gcc: PR tree-optimization/46556 * gimple-ssa-strength-reduction.c (enum cand_kind): Add CAND_REF. (base_cand_map): Change to hash table. (base_cand_hash): New function. (base_cand_free): Likewise. (base_cand_eq): Likewise. (lookup_cand): Change base_cand_map to hash table. (find_basis_for_candidate): Likewise. (base_cand_from_table): Exclude CAND_REF. (restructure_reference): New function. (slsr_process_ref): Likewise. (find_candidates_in_block): Call slsr_process_ref. (dump_candidate): Handle CAND_REF. (base_cand_dump_callback): New function. (dump_cand_chains): Change base_cand_map to hash table. (replace_ref): New function. (replace_refs): Likewise. (analyze_candidates_and_replace): Call replace_refs. (execute_strength_reduction): Change base_cand_map to hash table. gcc/testsuite: PR tree-optimization/46556 * testsuite/gcc.dg/tree-ssa/slsr-27.c: New. * testsuite/gcc.dg/tree-ssa/slsr-28.c: New. * testsuite/gcc.dg/tree-ssa/slsr-29.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/slsr-27.c trunk/gcc/testsuite/gcc.dg/tree-ssa/slsr-28.c trunk/gcc/testsuite/gcc.dg/tree-ssa/slsr-29.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-strength-reduction.c trunk/gcc/testsuite/ChangeLog --- Comment #10 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-08-01 13:03:44 UTC --- Fixed.
[Bug tree-optimization/46556] Code size regression in struct access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-08-01 13:03:44 UTC --- Fixed.
[Bug other/54150] New: [4.8 Regression] gimple dumps no longer honor -blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54150 Bug #: 54150 Summary: [4.8 Regression] gimple dumps no longer honor -blocks Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org CC: stevenb@gmail.com gimple dumps now by default dump a RTL-like bb header: ;; basic block 2, loop depth 0 ;;pred: ENTRY D.1602_12 = (sizetype) m_5(D); D.1603_13 = D.1602_12 * 4; goto bb 6; ;;succ: 6 previously TDF_blocks was required for that (and I'd like to have that back). Also notice the extra newline before ;; succ: which seems to be caused by pp_base_flush which does not only flush but also prints a newline, and that independent on whether pp_needs_newline is set. That said, the tree dumps still look remarkably ugly by default now.
[Bug plugins/54148] FAIL: gcc.dg/plugin/selfassign.c compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54148 --- Comment #2 from dave.anglin at bell dot net 2012-08-01 13:10:36 UTC --- On 1-Aug-12, at 3:47 AM, rguenth at gcc dot gnu.org wrote: I don't see any error in that? Test just fails with no message. -- John David Anglindave.ang...@bell.net
[Bug other/54150] [4.8 Regression] gimple dumps no longer honor -blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54150
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
Target Milestone|--- |4.8.0
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-01
13:12:36 UTC ---
IMHO pp_base_flush should not output a newline ever and instead look like
/* Flush the content of BUFFER onto the attached stream. */
void
pp_base_flush (pretty_printer *pp)
{
pp_write_text_to_stream (pp);
pp_clear_state (pp);
fflush (pp-buffer-stream);
}
which co-incidentially does not need any documentation adjustments.
[Bug c++/54151] New: Comparing if float is equal to decimal constant on Microblaze with mhard-float results in internal compiler error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54151
Bug #: 54151
Summary: Comparing if float is equal to decimal constant on
Microblaze with mhard-float results in internal
compiler error.
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cyberwizzard+...@gmail.com
Created attachment 27920
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27920
Test case triggering the internal compiler error
When determining if a floating point variable is equal to a decimal constant
(without float typing) the Microblaze GCC with 'mhard-float' throws an internal
error: test.cc:1:5: internal compiler error: in prepare_float_lib_cmp, at
optabs.c:4272
Host sytem used to build GCC 4.7.1 for Microblaze: Ubuntu 12.04 64-bit.
The example compiles fine on x86_64 and on Microblaze without 'mhard-float'.
Example triggering the internal error:
int main(){
float a;
if(a==1.0) { return 1; }
return 0;
}
Output of g++ for Microblaze:
mb-g++ -v -save-temps -mhard-float 'test.cc'
Using built-in specs.
COLLECT_GCC=/home/cyberwizzard/Documents/gcc/install/bin/mb-g++
COLLECT_LTO_WRAPPER=/home/cyberwizzard/Documents/gcc/install/libexec/gcc/microblaze-xilinx-elf/4.7.1/lto-wrapper
Target: microblaze-xilinx-elf
Configured with: ../configure --target=microblaze-xilinx-elf
--program-prefix=mb- --prefix=/home/cyberwizzard/Documents/gcc/install
--enable-languages=c --disable-nls --without-headers --disable-libssp
--with-newlib : (reconfigured) ../configure --target=microblaze-xilinx-elf
--program-prefix=mb- --prefix=/home/cyberwizzard/Documents/gcc/install
--enable-languages=c,c++ --disable-nls --without-headers --disable-libssp
--with-newlib
Thread model: single
gcc version 4.7.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mhard-float'
/home/cyberwizzard/Documents/gcc/install/libexec/gcc/microblaze-xilinx-elf/4.7.1/cc1plus
-E -quiet -v test.cc -mhard-float -fpch-preprocess -o test.ii
ignoring nonexistent directory
/home/cyberwizzard/Documents/gcc/install/lib/gcc/microblaze-xilinx-elf/4.7.1/../../../../microblaze-xilinx-elf/sys-include
#include ... search starts here:
#include ... search starts here:
/home/cyberwizzard/Documents/gcc/install/lib/gcc/microblaze-xilinx-elf/4.7.1/../../../../microblaze-xilinx-elf/include/c++/4.7.1
/home/cyberwizzard/Documents/gcc/install/lib/gcc/microblaze-xilinx-elf/4.7.1/../../../../microblaze-xilinx-elf/include/c++/4.7.1/microblaze-xilinx-elf
/home/cyberwizzard/Documents/gcc/install/lib/gcc/microblaze-xilinx-elf/4.7.1/../../../../microblaze-xilinx-elf/include/c++/4.7.1/backward
/home/cyberwizzard/Documents/gcc/install/lib/gcc/microblaze-xilinx-elf/4.7.1/include
/home/cyberwizzard/Documents/gcc/install/lib/gcc/microblaze-xilinx-elf/4.7.1/include-fixed
/home/cyberwizzard/Documents/gcc/install/lib/gcc/microblaze-xilinx-elf/4.7.1/../../../../microblaze-xilinx-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mhard-float'
/home/cyberwizzard/Documents/gcc/install/libexec/gcc/microblaze-xilinx-elf/4.7.1/cc1plus
-fpreprocessed test.ii -quiet -dumpbase test.cc -mhard-float -auxbase test
-version -o test.s
GNU C++ (GCC) version 4.7.1 (microblaze-xilinx-elf)
compiled by GNU C version 4.6.3, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.7.1 (microblaze-xilinx-elf)
compiled by GNU C version 4.6.3, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4290bd7345f2e2cf3d0e24567cded0ba
test.cc: In function 'int main()':
test.cc:1:5: internal compiler error: in prepare_float_lib_cmp, at
optabs.c:4272
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug other/54150] [4.8 Regression] gimple dumps no longer honor -blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54150 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-08-01 Ever Confirmed|0 |1 --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2012-08-01 13:18:06 UTC --- (In reply to comment #0) That said, the tree dumps still look remarkably ugly by default now. That is a debate of taste that I don't think we ought to get into. I had technical reasons why I made this so: Various scripts that do CFG analysis can now parse GIMPLE and RTL dumps without modification. The dumper should honor TDF_BLOCKS, and I'll take care of fixing that.
[Bug c++/54151] Comparing if float is equal to decimal constant on Microblaze with mhard-float results in internal compiler error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54151 --- Comment #1 from cyberwizzard cyberwizzard+gnu at gmail dot com 2012-08-01 13:18:15 UTC --- Created attachment 27921 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27921 Compiler result when using '-save-temps'
[Bug testsuite/54152] New: add Bytemark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54152 Bug #: 54152 Summary: add Bytemark Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz Bytemark could be added to tests to search for performance regressions. Its code has less than 400 kB.
[Bug rtl-optimization/54133] regrename introduces additional dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133 --- Comment #5 from amker.cheng amker.cheng at gmail dot com 2012-08-01 13:48:50 UTC --- Thanks for your patch, IMHO, I don't think the problem could be fixed in this way, because: 1. 78 r177:DF=r0:DF 80 [sp:SI]=r166:DF 81 [sp:SI+0x8]=r168:DF 82 [sp:SI+0x10]=r170:DF 84 r2:DF=r164:DF 85 r0:DF=call [`bar'] argc:0x18 REG_DEAD: r2:DF REG_UNUSED: r0:DF 86 [sp:SI]=r167:DF 87 [sp:SI+0x8]=r169:DF 88 [sp:SI+0x10]=r171:DF 89 r0:DF=r177:DF REG_DEAD: r177:DF 90 r2:DF=r165:DF 91 r0:DF=call [`bar'] argc:0x18 The propagation actually increases register pressure from insn 78 to insn 85, since r177 and r0 are both alive now. Maybe IRA makes a better decision in this case by spilling r177, I double the common results. 2.The reported case is some kind of special with all related insns limited in one basic block. In other cases like described in comment 2, the saving of hard register is in prologue, so the propagation crosses basic blocks. Anyway, one thing is clear that the problem is closely connected with parameter/return register moving.
[Bug tree-optimization/54153] New: [4.8 Regression] Bytemark IDEA 6% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54153 Bug #: 54153 Summary: [4.8 Regression] Bytemark IDEA 6% slower Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz 4.7.1 IDEA:9492 : 145.18 : 43.10 4.8 20120408 IDEA:9444 : 144.44 : 42.89 4.8 20120415 IDEA:8916 : 136.37 : 40.49 4.8 20120729 IDEA:8928 : 136.55 : 40.54
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2012-08-01 14:08:01 UTC --- (In reply to comment #6) The inline heuristics stuff is probably also due to stack-vars handling, I will look into that. Turns out this is due to the use of attribute((flatten)) on gebp_kernel.
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2012-08-01 14:14:11 UTC --- With the attribute((flatten)) removed, the full test case compiles in less than a minute.
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 --- Comment #19 from dave.anglin at bell dot net 2012-08-01 14:20:49 UTC --- On 31-Jul-12, at 10:25 PM, rth at gcc dot gnu.org wrote: The cross-compile *ought* not to affect costs, which means that we ought to be making the same algorithm choices. Which suggests that -- if this is a fully bootstrapped pa compiler -- you're looking at some part of expand_mult itself being mis-compiled. I was afraid this might be the case. However, I built a non bootstrap compiler this morning with -g -O1. The testcase still fails at -O0 and O1, and works at -O2. The compiler was configured as follows: dave@mx3210:~/gnu/gcc/objdir/gcc$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa-linux-gnu Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable- shared --enable-multiarch --with-multiarch-defaults=hppa-linux-gnu -- enable-linker-build-id --build=hppa-linux-gnu --host=hppa-linux-gnu -- target=hppa-linux-gnu --prefix=/home/dave/opt/gnu/gcc/gcc-4.7.0 --with- local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable- __cxa_atexit --build=hppa-linux-gnu --enable-clocale=gnu --enable-java- gc=boehm --enable-languages=c --disable-bootstrap Thread model: posix gcc version 4.8.0 20120801 (experimental) [trunk revision 190037] (GCC) You probably would need to add --with-arch=1.1 to duplicate the default native settings with a cross. The difference in extracts and deposits may not be the problem. The - O2 code appears to have the same extracts as the -O1 code. I'll see if I can find where the real difference arises. -- John David Anglindave.ang...@bell.net
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 2012-08-01 14:24:48 UTC --- clang compiles the test case with attribute((flatten)) because it doesn't support that attribute (http://llvm.org/bugs/show_bug.cgi?id=7559). I'm beginning to think this is one of those cases of Doctor it hurts if I ... that should be closed as WONTFIX. Marc, do you know where the use of the flatten attribute comes from in your code?
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 --- Comment #20 from dave.anglin at bell dot net 2012-08-01 14:27:30 UTC --- On 1-Aug-12, at 10:20 AM, dave.anglin at bell dot net wrote: The difference in extracts and deposits may not be the problem. The - O2 code appears to have the same extracts as the -O1 code. I'll see if I can find where the real difference arises. Doh, the correct result is inlined at -O2. foo is still mis-compiled. -- John David Anglindave.ang...@bell.net
[Bug testsuite/54152] add Bytemark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54152 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-01 14:30:14 UTC --- We do not have performance tests, so we cannot simply add it. It's run regularly by autotestes though, see for example http://gcc.opensuse.org/c++bench-frescobaldi/nbench/ for individual transforms that now no longer happen we can add reduced testcases.
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-01 14:32:15 UTC --- (In reply to comment #9) clang compiles the test case with attribute((flatten)) because it doesn't support that attribute (http://llvm.org/bugs/show_bug.cgi?id=7559). I'm beginning to think this is one of those cases of Doctor it hurts if I ... that should be closed as WONTFIX. Marc, do you know where the use of the flatten attribute comes from in your code? indeed flatten will override any inlining heuristic that avoids creating gigant function bodies. Still eventually improving worst-case performance of some of our algorithms sounds good, even if it will never fix all issues that pop up when you for example put flatten on main () ;)
[Bug middle-end/54154] New: cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154
Bug #: 54154
Summary: cprop_hardreg generates redundant instructions
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paulo.ma...@csr.com
Created attachment 27922
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27922
Before cprop_hardreg
Hello,
I have touched this subject before:
* http://gcc.gnu.org/ml/gcc/2010-08/msg00347.html
* http://gcc.gnu.org/ml/gcc/2011-03/msg00214.html
and it looks like a long standing issue so I am wary of reporting a bug but I
think I did find the culprit code. So, unless you consider this a feature
somehow I reckon it's a bug.
cprop_hardreg grabs an insn chain and through forward propagation of registers
ends up generating redundant passes where the src and dest are the same (same
regnumber, same mode).
Consider the program (obtained using creduce):
int a;
int fn1 ();
void fn2 ();
int fn3 ();
int
fn4 ()
{
if (fn1 ())
return 0;
a = fn3 ();
if (a != (1 (32 - (9 + 9))) - 1)
fn2 (0, a);
return (1 (32 - (9 + 9))) - 1;
}
Now, after compiling for my backend with -Os I get before cprop_hardreg (after
ce3) [real logs attached]:
#8 reg AL - call fn1
#50/51 if_then_else AL != 0
goto label 34
#12AL - call fn3
#13AH - AL
#14mem sym a - AH
#48/49 if_then_else AH == 16383
goto label 38
#17AL - 0
#19call fn2
#4 AL - 16383
#43jump label 20
label 34:
#3 AL - 0
#45jump label 20
label 38:
#5 AL - AH
label 20:
return
the number after '#' is the insn number.
cprop_hardreg decided to replace AH with AL so the top of cprop_hardreg shows:
rescanning insn with uid = 14.
deleting insn with uid = 14.
insn 14: replaced reg 0 with 1
insn 48: replaced reg 0 with 1
rescanning insn with uid = 48.
deleting insn with uid = 48.
rescanning insn with uid = 5.
deleting insn with uid = 5.
insn 5: replaced reg 0 with 1
reg 0 is AH and reg 1 is AL.
When you replace in insn 5, AH by AL you get the insn AL - AL and that's #5
after cprop_hardreg.
I find it strange that there's no code checking if set dest is equal to
replacement and if it is, simply remove insn.
I think this is a bug and should be fixed.
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154 --- Comment #1 from Paulo J. Matos Paulo.Matos at csr dot com 2012-08-01 14:34:48 UTC --- Created attachment 27923 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27923 After cprop_hardreg
[Bug c++/54155] New: Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54155
Bug #: 54155
Summary: Newly compiled GCC 4.4.4 on Solaris sparc gives
problem with -m32/-m64 flags
Classification: Unclassified
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dsha...@gmail.com
This issue has kept me busy all day long. It started off with openssl
compilation which was giving linking error with following message:
/usr/local/bin/ld: target elf32-sparc not found
collect2: ld returned 1 exit status
I tried every step possible thing that I could think of but was not able to
resolve the issue. Although I came to know that specifying -m32/-m64 flag with
my newly built gcc has started reporting this issue. I have tried to provide
all necessary details below including the test program which when I try to
compile gives the same issue.
Note: I am using GNU binaries(bintuils 2.21)
#
bash-3.2# uname -a
SunOS CSAPI-DEV-SOL3 5.10 Generic_147440-01 sun4u sparc SUNW,Sun-Fire-V240
#
bash-3.2# gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.4/configure --prefix=/usr/local/gcc-4.4.4
--program-suffix=-4.4.4 --enable-threads=posix --enable-shared
--enable-languages=c,c++ --with-gnu-as --with-as=/usr/local/bin/as
--with-gnu-ld --with-ld=/usr/local/bin/ld
Thread model: posix
gcc version 4.4.4 (GCC)
#
Content of test.cpp
#include iostream
int main()
{
std::cout hello world\n;
}
#
/*** COMPILATION OUTPUT ***/
bash-3.2# gcc -o test1 test.cpp -m32 -mcpu=ultrasparc -lstdc++
/usr/local/bin/ld: target elf32-sparc not found
collect2: ld returned 1 exit status
#
If I eliminate the -m32/-m64 flag output file is successfully generated.
#
bash-3.2# file test1
test1: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required,
dynamically linked, not stripped
#
Is it something that has gone wrong during configuration due to which the
compiler does not recognize the -m option?
Please help!
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154 --- Comment #2 from Paulo J. Matos Paulo.Matos at csr dot com 2012-08-01 14:37:53 UTC --- Created attachment 27924 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27924 Add debug info when redundant insn is going to be generated Looking at the gcc log header after running cprop_hardreg shows: rescanning insn with uid = 14. deleting insn with uid = 14. insn 14: replaced reg 0 with 1 insn 48: replaced reg 0 with 1 rescanning insn with uid = 48. deleting insn with uid = 48. rescanning insn with uid = 5. deleting insn with uid = 5. oops, substitution makes dest same as src insn 5: replaced reg 0 with 1
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154
Paulo J. Matos Paulo.Matos at csr dot com changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #3 from Paulo J. Matos Paulo.Matos at csr dot com 2012-08-01
15:00:34 UTC ---
OK, so I just noted this is not really a bug but a missed optimization:
/* Assert that SRC has been copied to DEST. Adjust the data structures to
reflect that SRC contains an older copy of the shared value. */
static void
copy_value (rtx dest, rtx src, struct value_data *vd)
{
unsigned int dr = REGNO (dest);
unsigned int sr = REGNO (src);
unsigned int dn, sn;
unsigned int i;
/* ??? At present, it's possible to see noop sets. It'd be nice if this were
cleaned up beforehand... */
if (sr == dr)
return;
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154 --- Comment #4 from Paulo J. Matos Paulo.Matos at csr dot com 2012-08-01 15:01:29 UTC --- Due to my last comment I marked this as a request for enhancement.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #78 from Mikael Morin mikael at gcc dot gnu.org 2012-08-01 15:01:59 UTC --- (In reply to comment #76) You mean [...] ? Yes, that also should be build_distinct_type_copy. Even without that, the patch regtests cleanly (including the pr45586 tests), apart for typebound_proc_20.f90. That one fail in the following line from the `calc' subroutine: this%y = this%find_y() ! FAILS the lhs is a target, and the rhs is NOT a target, so that the middle-end types are different. :-(
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #79 from rguenther at suse dot de rguenther at suse dot de 2012-08-01 15:05:22 UTC --- On Wed, 1 Aug 2012, mikael at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #78 from Mikael Morin mikael at gcc dot gnu.org 2012-08-01 15:01:59 UTC --- (In reply to comment #76) You mean [...] ? Yes, that also should be build_distinct_type_copy. Even without that, the patch regtests cleanly (including the pr45586 tests), apart for typebound_proc_20.f90. That one fail in the following line from the `calc' subroutine: this%y = this%find_y() ! FAILS the lhs is a target, and the rhs is NOT a target, so that the middle-end types are different. :-( But how can this be a valid fortran program? You assign something that is not aliased to something that suddenly makes it aliased? If that's valid then you can make the middle-end happy by wrapping the RHS inside a VIEW_CONVERT_EXPR with the LHS type.
[Bug target/54156] New: New fail on AVX target: gcc.dg/vect/pr53773.c. 190010 vs revision 189996
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54156 Bug #: 54156 Summary: New fail on AVX target: gcc.dg/vect/pr53773.c. 190010 vs revision 189996 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: kirill.yuk...@intel.com Hi, we've got new fails on AVX-enabled machine FAIL: gcc.dg/vect/pr53773.c -flto scan-tree-dump-times vect \\* 10 4 FAIL: gcc.dg/vect/pr53773.c -flto scan-tree-dump-times vect \\* 10 4 FAIL: gcc.dg/vect/pr53773.c scan-tree-dump-times vect \\* 10 4 FAIL: gcc.dg/vect/pr53773.c scan-tree-dump-times vect \\* 10 4 http://gcc.gnu.org/ml/gcc-regression/2012-07/msg00276.html
[Bug target/54156] [4.8 Regression] New fail on AVX target: gcc.dg/vect/pr53773.c. 190010 vs revision 189996
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54156 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|New fail on AVX target: |[4.8 Regression] New fail |gcc.dg/vect/pr53773.c. |on AVX target: |190010 vs revision 189996 |gcc.dg/vect/pr53773.c. ||190010 vs revision 189996
[Bug c++/54130] Recognize builtins with bool return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130
--- Comment #14 from joseph at codesourcery dot com joseph at codesourcery dot
com 2012-08-01 15:41:01 UTC ---
On Wed, 1 Aug 2012, glisse at gcc dot gnu.org wrote:
may also break stuff if the C library uses isnan. I could also ask glibc to
not
declare the isnan function at all in C++, but that's a bit strange and other C
libraries may define an isnan function.
The isnan function declaration is for compatibility with some old
standards such as Unix98 that had such a function instead of the
type-generic macro. It would seem reasonable to disable it for C++, just
as the glibc headers allow for C++ requirements for overloads in string.h,
for example. It is, however, really for the libstdc++ maintainers to work
with the glibc maintainers regarding any changes to C headers that would
be helpful for meeting C++ standard requirements; we can't make such a
change in isolation without knowing it fits in with the libstdc++
maintainer plans.
Note also that in C, we are currently failing to optimize this to a constant:
#include math.h
int f(){return isnan(3);}
The isnan macro definition is an old one, maybe predating GCC's
type-generic __builtin_isnan, that calls functions such as __isnan, so
effectively preventing such constant folding. It would seem reasonable,
given recent enough GCC versions, for it to use the type-generic built-in
function instead, and likewise for various other such macros in glibc
(maybe not fpclassify because of code size, and for isinf you have the
complication of glibc providing additional semantics beyond the standard
version). If making such a change, it would seem appropriate also to
change the internal calls to functions such as __isnan to call the macros
instead, letting the compiler generate the most appropriate code.
[Bug target/54156] [4.8 Regression] New fail on AVX target: gcc.dg/vect/pr53773.c. 190010 vs revision 189996
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54156 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-08-01 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-08-01 15:49:52 UTC --- Which checkin caused this?
[Bug target/54156] [4.8 Regression] New fail on AVX target: gcc.dg/vect/pr53773.c. 190010 vs revision 189996
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54156 --- Comment #2 from Igor Zamyatin izamyatin at gmail dot com 2012-08-01 15:57:42 UTC --- Author: wschmidt wschmidt@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Tue Jul 31 12:25:04 2012 + gcc: 2012-07-31 Bill Schmidt wschm...@linux.ibm.com PR tree-optimization/53773 * tree-vectorizer.h (struct _loop_vec_info): Add operands_swapped. (LOOP_VINFO_OPERANDS_SWAPPED): New macro. * tree-vect-loop.c (new_loop_vec_info): Initialize LOOP_VINFO_OPERANDS_SWAPPED field. (destroy_loop_vec_info): Restore canonical form. (vect_is_slp_reduction): Set LOOP_VINFO_OPERANDS_SWAPPED field. (vect_is_simple_reduction_1): Likewise. gcc/testsuite: 2012-07-31 Bill Schmidt wschm...@linux.ibm.com PR tree-optimization/53773 * testsuite/gcc.dg/vect/pr53773.c: New test Seems for x86 output is different
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #11 from Marc Glisse glisse at gcc dot gnu.org 2012-08-01 15:59:43 UTC --- (In reply to comment #9) I'm beginning to think this is one of those cases of Doctor it hurts if I ... that should be closed as WONTFIX. Indeed, might even call it INVALID. Thanks a lot for the investigation and sorry for the bad example. Hopefully the patches you wrote are still useful. Marc, do you know where the use of the flatten attribute comes from in your code? Comes from the Eigen library, I'll talk to them about it and see if they can comment. They mostly deal with simple number types (double, float), so the behavior with heavy types might have been unnoticed.
[Bug target/54087] __atomic_fetch_add does not use xadd instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54087
--- Comment #3 from Ulrich Drepper drepper.fsp at gmail dot com 2012-08-01
16:06:33 UTC ---
(In reply to comment #2)
(In reply to comment #1)
Use __atomic_add_fetch and __atomic_fetch_sub in the testcase, and you will
Eh, __atomic_fetch_add.
Yes, but the compiler should automatically do this. The extreme case is this:
int v;
int a(void)
{
return __sync_sub_and_fetch(v, 5);
}
int b(void)
{
return __sync_add_and_fetch(v, -5);
}
The second function does compile as expected. The first doesn't, it uses
cmpxchg.
Shouldn't this be easy enough to fix by adding patterns for atomic_fetch_sub
and atomic_sub_fetch which match if the second parameter is a constant? If
it's not a constant a bit more code is needed but that should be no problem
either.
[Bug rtl-optimization/54157] New: [x32] -maddress-mode=long failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54157 Bug #: 54157 Summary: [x32] -maddress-mode=long failures Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: ubiz...@gmail.com Target: x86_64-linux [hjl@gnu-32 gcc]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c -fno-diagnostics-show-caret -msse2 -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -fno-section-anchors -lm -mx32 -o ./no-section-anchors-vect-69.exe -maddress-mode=short [hjl@gnu-32 gcc]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c -fno-diagnostics-show-caret -msse2 -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -fno-section-anchors -lm -mx32 -o ./no-section-anchors-vect-69.exe -maddress-mode=long /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c: In function ‘main1’: /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c:106:1: internal compiler error: in plus_constant, at explow.c:88 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [hjl@gnu-32 gcc]$ [hjl@gnu-32 gfortran]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite/gfortran/../../gfortran -B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite/gfortran/../../ -B/export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-unknown-linux-gnu/x32/libgfortran/ /export/gnu/import/git/gcc/gcc/testsuite/gfortran.dg/vect/pr32380.f -fno-diagnostics-show-caret -O -O2 -ftree-vectorize -fno-vect-cost-model -ftree-vectorizer-verbose=4 -fdump-tree-vect-stats -msse2 -O3 -fcray-pointer -S -mx32 -o pr32380.s -maddress-mode=short [hjl@gnu-32 gfortran]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite/gfortran/../../gfortran -B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite/gfortran/../../ -B/export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-unknown-linux-gnu/x32/libgfortran/ /export/gnu/import/git/gcc/gcc/testsuite/gfortran.dg/vect/pr32380.f -fno-diagnostics-show-caret -O -O2 -ftree-vectorize -fno-vect-cost-model -ftree-vectorizer-verbose=4 -fdump-tree-vect-stats -msse2 -O3 -fcray-pointer -S -mx32 -o pr32380.s -maddress-mode=long /export/gnu/import/git/gcc/gcc/testsuite/gfortran.dg/vect/pr32380.f: In function ‘trnfbt’: /export/gnu/import/git/gcc/gcc/testsuite/gfortran.dg/vect/pr32380.f:260:0: internal compiler error: in plus_constant, at explow.c:88 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [hjl@gnu-32 gfortran]$
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #80 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-01
16:22:52 UTC ---
(In reply to comment #79)
this%y = this%find_y() ! FAILS
the lhs is a target, and the rhs is NOT a target, so that the middle-end
types
are different. :-(
But how can this be a valid fortran program? You assign something
that is not aliased to something that suddenly makes it aliased?
If that's valid then you can make the middle-end happy by wrapping
the RHS inside a VIEW_CONVERT_EXPR with the LHS type.
I have not closely looked at the dump, however,
this%y = this%find_y()
means that one assigns component-wise the values from the RHS to the LHS; if
there are pointer components, the pointer address is assigned; if there are
allocatable components, those are - if needed - first (re)allocated and then
(element-wise) assigned.
Thus, one only assigns the values and no pointers - and, hence, the RHS can be
a nontarget while the LHS can be a target.
In this example, this%y is a derived type with an allocatable-array
component. I think the current algorithm is something like:
*dst = *src;
if (src-data)
{
(re)allocate dst-data
memcpy (dst-data, src-data);
}
Thus, one first transfers the pointer address [besides the array bounds], but
if data is not NULL, the data is copied. Thus, it should be safe - but an
ARRAY_RANGE_REF could be nicer than a memcpy, and the VIEW_CONVERT_EXPR could
be inserted.
[Bug rtl-optimization/54157] [x32] -maddress-mode=long failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54157
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-08-01 16:25:15
UTC ---
[hjl@gnu-32 gcc]$ cat /tmp/x.i
struct s2{
int n[24 -1][24 -1][24 -1];
};
struct test2{
struct s2 e;
};
struct test2 tmp2[4];
void main1 ()
{
int i,j;
for (i = 0; i 24 -4; i++)
for (j = 0; j 24 -4; j++)
tmp2[2].e.n[1][i][j] = 8;
}
[hjl@gnu-32 gcc]$ ./xgcc -B./ -O2 -mx32 -maddress-mode=long -S /tmp/x.i
-ftree-vectorize
/tmp/x.i: In function ‘main1’:
/tmp/x.i:18:1: internal compiler error: in plus_constant, at explow.c:88
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[hjl@gnu-32 gcc]$
[Bug c++/54130] Recognize builtins with bool return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130 --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-01 16:30:54 UTC --- (In reply to comment #14) The isnan function declaration is for compatibility with some old standards such as Unix98 that had such a function instead of the type-generic macro. It would seem reasonable to disable it for C++, just as the glibc headers allow for C++ requirements for overloads in string.h, for example. It is, however, really for the libstdc++ maintainers to work with the glibc maintainers regarding any changes to C headers that would be helpful for meeting C++ standard requirements; we can't make such a change in isolation without knowing it fits in with the libstdc++ maintainer plans. There are several areas I'd like to see more cooperation between glibc and libstdc++, I keep meaning to make a list, but haven't. Maybe we should start a page on the GCC wiki where suggestions can be noted until we have something concrete enough to discuss.
[Bug rtl-optimization/54157] [x32] -maddress-mode=long failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54157 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-08-01 16:49:53 UTC --- Created attachment 27925 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27925 A patch
[Bug tree-optimization/46556] Code size regression in struct access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556 --- Comment #11 from Steven Bosscher steven at gcc dot gnu.org 2012-08-01 17:51:55 UTC --- (In reply to comment #10) Fixed. Is it still your plan to also do something with the patch to expose target addressing modes earlier?
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #81 from Mikael Morin mikael at gcc dot gnu.org 2012-08-01 18:37:55 UTC --- (In reply to comment #79) If that's valid then you can make the middle-end happy by wrapping the RHS inside a VIEW_CONVERT_EXPR with the LHS type. OK. will try. I don't know yet though how to limit that to the very cases where it is necessary. (In reply to comment #80) I have not closely looked at the dump, however, this%y = this%find_y() means that one assigns component-wise the values from the RHS to the LHS; if there are pointer components, the pointer address is assigned; if there are allocatable components, those are - if needed - first (re)allocated and then (element-wise) assigned. Thus, one only assigns the values and no pointers - and, hence, the RHS can be a nontarget while the LHS can be a target. Actually, there is a wrong-code bug about exactly this line (see bugs #47455 and #47586). But I think that even if there wasn't, the middle-end wouldn't be happy about it. The values are assigned component-wise, and that's the only way the middle-end would accept it.
[Bug tree-optimization/46556] Code size regression in struct access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556 --- Comment #12 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-08-01 18:42:16 UTC --- (In reply to comment #11) (In reply to comment #10) Fixed. Is it still your plan to also do something with the patch to expose target addressing modes earlier? No, I'm afraid not. I spent more time than I like to remember investigating that possibility. My conclusion was that we lose too much structural aliasing information when we lower to MEM_REFs indiscriminately, resulting in unnecessary instruction scheduling constraints that harm performance. If this is to be done at some point in the future, there needs to be more infrastructure to allow the structural aliasing information to be retained throughout GIMPLE.
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 --- Comment #21 from John David Anglin danglin at gcc dot gnu.org 2012-08-01 18:44:04 UTC --- The issue is with the handling of negative constants. In this bit of code, max_cost = (set_src_cost (gen_rtx_MULT (mode, fake_reg, op1), speed) - neg_cost(speed, mode)); if (max_cost 0 choose_mult_variant (mode, -coeff, algorithm, variant, max_cost)) max_cost is computed to be 24 and choose_mult_variant returns 0. This causes the following hunk to be executed: max_cost = set_src_cost (gen_rtx_MULT (mode, fake_reg, op1), speed); if (choose_mult_variant (mode, coeff, algorithm, variant, max_cost)) return expand_mult_const (mode, op0, coeff, target, algorithm, variant); max_cost is now 32 and choose_mult_variant succeeds. However, expand_mult_const generates incorrect code when coeff is negative. I hacked the max_cost in the negative case to be 32, and this produces the correct result and code similar to your cross-compiled output. If I remember correctly, the xmpyu instruction was introduced in PA 1.1 and this results in different costs for PA 1.0 and 1.1.
[Bug tree-optimization/54077] [4.7/4.8 Regression] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||ktietz at gcc dot gnu.org, ||ubizjak at gmail dot com --- Comment #9 from Uros Bizjak ubizjak at gmail dot com 2012-08-01 18:46:34 UTC --- Adding CC.
[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530
--- Comment #12 from uros at gcc dot gnu.org 2012-08-01 19:15:04 UTC ---
Author: uros
Date: Wed Aug 1 19:14:59 2012
New Revision: 190048
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190048
Log:
Backport from mainline
2012-03-09 Uros Bizjak ubiz...@gmail.com
PR target/52530
* config/i386/i386.c (ix86_print_operand): Handle 'E' operand modifier.
(ix86_print_operand_address): Handle UNSPEC_LEA_ADDR. Do not fallback
to set code to 'q'.
* config/i386/i386.md (UNSPEC_LEA_ADDR): New unspec.
(*movdi_internal_rex64): Use %E operand modifier for lea.
(*movsi_internal): Ditto.
(*lea_1): Ditto.
(*leamode_2): Ditto.
(*lea_{3,4,5,6}_zext): Ditto.
(*tls_global_dynamic_32_gnu): Ditto.
(*tls_global_dynamic_64): Ditto.
(*tls_dynamic_gnu2_lea_32): Ditto.
(*tls_dynamic_gnu2_lea_64): Ditto.
(pro_epilogue_adjust_stack_mode_add): Ditto.
testsuite/ChangeLog:
Backport from mainline
2012-03-11 Uros Bizjak ubiz...@gmail.com
PR target/52530
* gcc.dg/torture/pr52530.c: New test.
Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr52530.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/i386/i386.c
branches/gcc-4_7-branch/gcc/config/i386/i386.md
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/50672] [4.7 Regression] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #14 from David Binderman dcb314 at hotmail dot com 2012-08-01 19:35:27 UTC --- This seems to have broken again with 4.8 trunk, dated 20120801. It seemed ok about a week ago, so probably some recent breakage.
[Bug tree-optimization/50672] [4.7 Regression] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672
--- Comment #15 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-08-01 20:11:15 UTC ---
markus@x4 tmp % cat test.ii
struct A
{
bool isHint();
};
class B
{
void makeLine( int *) const;
void drawLine() const; A* to() const;
void _print() const;
};
A a;
void B::makeLine(int *p1) const
{
if (a.isHint() to()-isHint()) ;
else {
if (p1) B::drawLine(); else B::_print();
return;
}
if (p1) B::drawLine(); else B::_print();
}
markus@x4 tmp % gdb g++
Reading symbols from /usr/bin/g++...(no debugging symbols found)...done.
(gdb) run -c -O2 test.ii
Starting program: /usr/bin/g++ -c -O2 test.ii
process 7858 is executing new program:
/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0/g++
[New process 7861]
process 7861 is executing new program:
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/cc1plus
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 7861]
walk_aliased_vdefs_1 (ref=ref@entry=0x0, vdef=0x773f4870, walker=0x896fe0
mark_all_reaching_defs_necessary_1, data=0x0, visited=0x101e040,
cnt=0) at ../../gcc/gcc/tree-ssa-alias.c:2182
2182 if (gimple_nop_p (def_stmt))
(gdb) bt
#0 walk_aliased_vdefs_1 (ref=ref@entry=0x0, vdef=0x773f4870,
walker=0x896fe0 mark_all_reaching_defs_necessary_1, data=0x0,
visited=0x101e040, cnt=0) at ../../gcc/gcc/tree-ssa-alias.c:2182
#1 0x0088ce8e in walk_aliased_vdefs (ref=ref@entry=0x0,
vdef=optimized out,
walker=walker@entry=0x896fe0 mark_all_reaching_defs_necessary_1,
data=data@entry=0x0, visited=visited@entry=0x101e040)
at ../../gcc/gcc/tree-ssa-alias.c:2217
#2 0x00896e25 in mark_all_reaching_defs_necessary
(stmt=stmt@entry=0x773e5e40) at ../../gcc/gcc/tree-ssa-dce.c:664
#3 0x00898a44 in propagate_necessity (el=el@entry=0x10ea0e0) at
../../gcc/gcc/tree-ssa-dce.c:909
...
[Bug middle-end/34548] GCC generates too many alignment adds for alloca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34548 --- Comment #5 from Richard Henderson rth at gcc dot gnu.org 2012-08-01 20:41:25 UTC --- Author: rth Date: Wed Aug 1 20:41:16 2012 New Revision: 190051 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190051 Log: PR 34548 * function.h (struct rtl_data): Add max_dynamic_stack_alignment. * cfgexpand.c (gimple_expand_cfg): Initialise it. * explow.c (allocate_dynamic_stack_space): Set it. Simplify alignment requirements given the known alignment of dynamic_offset. * function.c (instantiate_virtual_regs): Align dtnamic_offset. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/explow.c trunk/gcc/function.c trunk/gcc/function.h
[Bug tree-optimization/50672] [4.7 Regression] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 --- Comment #16 from vries at gcc dot gnu.org 2012-08-01 21:19:36 UTC --- With the example from comment 15 and r190039, I don't see a segmentation fault, but this: ... $ g++ test.C -O2 test.C: In member function ‘void B::makeLine(int*) const’: test.C:12:7: error: no immediate_use list void B::makeLine(int *p1) const ^ for SSA_NAME: .MEM_20 in statement: # .MEM_13 = VDEF .MEM_20 B::drawLine (this_7(D)); test.C:12:7: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. ... The example passes with -fno-tree-tail-merge.
[Bug fortran/54033] gfortran: Passing file as include directory - add diagnostic and ICE with -cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54033 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-01 21:43:54 UTC --- Author: tkoenig Date: Wed Aug 1 21:43:50 2012 New Revision: 190054 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190054 Log: 2012-08-01 Thomas König tkoe...@gcc.gnu.org PR fortran/54033 * scanner.c (add_path_to_list): Emit warning if an error occurs for an include path, if it is not present or if it is not a directory. Do not add the path in these cases. 2012-08-01 Thomas König tkoe...@gcc.gnu.org PR fortran/54033 * gfortran.dg/include_6.f90: New test case. * gfortran.dg/include_7.f90: New test case. * gfortran.dg/include_3.f90: Add dg-warning for missing directory. Added: trunk/gcc/testsuite/gfortran.dg/include_6.f90 trunk/gcc/testsuite/gfortran.dg/include_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/include_3.f95
[Bug fortran/54033] gfortran: Passing file as include directory - add diagnostic and ICE with -cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54033 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-01 21:45:49 UTC --- Fixed on trunk, closing. Thanks for the bug report!
[Bug rtl-optimization/54157] [x32] -maddress-mode=long failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54157
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-08-01 21:47:59
UTC ---
make_extraction in combine generates:
7474 inner = force_to_mode (inner, wanted_inner_mode,
7475 pos_rtx
7476 || len + orig_pos =
HOST_BITS_PER_WIDE_INT
7477 ? ~(unsigned HOST_WIDE_INT) 0
7478 : unsigned HOST_WIDE_INT) 1 len) -
1)
(gdb) call debug_rtx (inner)
(plus:SI (reg:SI 109 [ D.1765 ])
(const:SI (plus:SI (symbol_ref:SI (tmp2) var_decl 0x70f06140 tmp2)
(const_int 99452 [0x1847c]
(gdb) p wanted_inner_mode
$2 = DImode
(gdb)
When combines see
(and:SI (lshiftrt:SI (plus:SI (reg:SI 109 [ D.1765 ])
(const:SI (plus:SI (symbol_ref:SI (tmp2) var_decl 0x70f06140
tmp2)
(const_int 99452 [0x1847c]
(const_int 2 [0x2]))
(const_int 3 [0x3]))
(gdb)
it calls make_extraction:
if (! in_dest unsignedp
mode_for_extraction (EP_extzv, -1) != MAX_MACHINE_MODE)
{
wanted_inner_reg_mode = mode_for_extraction (EP_extzv, 1);
pos_mode = mode_for_extraction (EP_extzv, 3);
extraction_mode = mode_for_extraction (EP_extzv, 0);
}
mode_for_extraction:
/* Everyone who uses this function used to follow it with
if (result == VOIDmode) result = word_mode; */
if (data-operand[opno].mode == VOIDmode)
return word_mode;
and i386.md:
(define_expand extzv
[(set (match_operand:SI 0 register_operand)
(zero_extract:SI (match_operand 1 ext_register_operand)
(match_operand:SI 2 const8_operand)
(match_operand:SI 3 const8_operand)))]
[Bug rtl-optimization/54157] [x32] -maddress-mode=long failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54157 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-08-01 22:12:00 UTC --- This patch: diff --git a/gcc/expmed.c b/gcc/expmed.c index 1fe0034..2780164 100644 --- a/gcc/expmed.c +++ b/gcc/expmed.c @@ -380,7 +380,7 @@ mode_for_extraction (enum extraction_pattern pattern, int opno) /* Everyone who uses this function used to follow it with if (result == VOIDmode) result = word_mode; */ if (data-operand[opno].mode == VOIDmode) -return word_mode; +return ptr_mode; return data-operand[opno].mode; } also works on the testcase.
[Bug tree-optimization/54077] [4.7/4.8 Regression] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #10 from wbrana wbrana at gmail dot com 2012-08-01 22:35:29 UTC --- Reversion of 175752 on latest 4.7 branch improved FP EMU by 41%, but made ASSIGNMENT worse by 8%. with 175752 NUMERIC SORT: 1562.9 : 40.08 : 13.16 STRING SORT : 730.08 : 326.22 : 50.49 BITFIELD: 5.956e+08 : 102.17 : 21.34 FP EMULATION: 232.96 : 111.79 : 25.79 FOURIER : 36191 : 41.16 : 23.12 ASSIGNMENT : 63.469 : 241.51 : 62.64 IDEA:9512 : 145.48 : 43.20 HUFFMAN : 3475.8 : 96.38 : 30.78 NEURAL NET : 80.296 : 128.99 : 54.26 LU DECOMPOSITION: 2696.9 : 139.71 : 100.89 without 175752 NUMERIC SORT: 1526.9 : 39.16 : 12.86 STRING SORT : 724.96 : 323.93 : 50.14 BITFIELD: 5.962e+08 : 102.27 : 21.36 FP EMULATION: 328.32 : 157.54 : 36.35 FOURIER : 36275 : 41.26 : 23.17 ASSIGNMENT : 58.37 : 222.11 : 57.61 IDEA:9480 : 144.99 : 43.05 HUFFMAN : 3453.1 : 95.75 : 30.58 NEURAL NET : 79.128 : 127.11 : 53.47 LU DECOMPOSITION: 2733.4 : 141.60 : 102.25
[Bug tree-optimization/50672] [4.7 Regression] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 --- Comment #17 from vries at gcc dot gnu.org 2012-08-01 23:14:36 UTC --- The test-case from comment 15 passes with r190033, and fails with r190034. block 10 contains: ... # .MEMD.2233_20 = PHI .MEMD.2233_5(11), .MEMD.2233_10(12) ... and is replaced by block 9 by tail-merge. Quoted from http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00977.html: ... Whoever unlinks the vuse (by removing its definition) has to replace it with something valid, which is either the bare symbol .MEM, or the VUSE associated with the removed VDEF (thus, as unlink_stmt_vdef does). ... So the def of _20 is removed, and it's uses need to be handled. That is done by release_last_vdef which was part of the fix for this bug, and is removed in r190034.
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664
--- Comment #14 from Janis Johnson janis at gcc dot gnu.org 2012-08-01
23:35:12 UTC ---
Ramana, chunks of regular expressions within parentheses are matched and added
to the returned expression that is used in scan-assembler-times. To avoid
returning parenthesized bits you need to replace (regexp) with (?:regexp).
Here's what works in vst4Qu8.c (cut and pasted, so tabs are wrong):
/* { dg-final { scan-assembler-times vst4\.8\[
\]+\\\{(?:(?:\[dD\]\[0-9\]+-\[dD\]\[0-9\]+)|(?:\[dD\]\[0-9\]+, \[dD\]\[0-9\]+,
\[dD\]\[0-9\]+, \[dD\]\[0-9\]+))\\\},
\\\[\[rR\]\[0-9\]+\(?::\[0-9\]+\)?\\\]!?\(?:\[ \]+@\[a-zA-Z0-9 \]+\)?\n 2
} } */
I haven't tried modifying the test generator.
[Bug rtl-optimization/52983] [4.8 Regression] internal compiler error: in df_uses_record, at df-scan.c:3243
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52983 --- Comment #12 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-08-02 00:34:15 UTC --- Author: aoliva Date: Thu Aug 2 00:34:11 2012 New Revision: 190061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190061 Log: PR debug/52983 * valtrack.h, valtrack.c: New. * Makefile.in (VALTRACK_H): New. (OBJS): Add valtrack.o. (valtrack.o): New. (cselib.o, dce.o, df-problems.o, combine.o): Add VALTRACK_H. * combine.c: Include valtrack.h. (make_compound_operation): Publish. (cleanup_auto_inc_dec): Move to valtrack.c. (struct rtx_subst_pair, propagate_for_debug_subst): Likewise. (propagate_for_debug): Likewise. Add this_basic_block parameter. Adjust all callers. * cselib.c: Include valtrack.h. * dce.c: Likewise. * df-problems.c: Likewise. (dead_debug_init, dead_debug_reset_uses): Move to valtrack.c. (dead_debug_finish, dead_debug_add): Likewise. (dead_debug_insert_temp): Likewise. * df.h (struct dead_debug_use): Move to valtrack.h. (struct dead_debug, enum debug_temp_where): Likewise. (dead_debug_init, dead_debug_reset_uses): Move to valtrack.h. (dead_debug_finish, dead_debug_add): Likewise. (dead_debug_insert_temp): Likewise. * rtl.h (make_compound_operation): Declare. Added: trunk/gcc/valtrack.c trunk/gcc/valtrack.h Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/combine.c trunk/gcc/cselib.c trunk/gcc/dce.c trunk/gcc/df-problems.c trunk/gcc/df.h trunk/gcc/rtl.h
[Bug rtl-optimization/52983] [4.8 Regression] internal compiler error: in df_uses_record, at df-scan.c:3243
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52983 --- Comment #12 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-08-02 00:34:15 UTC --- Author: aoliva Date: Thu Aug 2 00:34:11 2012 New Revision: 190061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190061 Log: PR debug/52983 * valtrack.h, valtrack.c: New. * Makefile.in (VALTRACK_H): New. (OBJS): Add valtrack.o. (valtrack.o): New. (cselib.o, dce.o, df-problems.o, combine.o): Add VALTRACK_H. * combine.c: Include valtrack.h. (make_compound_operation): Publish. (cleanup_auto_inc_dec): Move to valtrack.c. (struct rtx_subst_pair, propagate_for_debug_subst): Likewise. (propagate_for_debug): Likewise. Add this_basic_block parameter. Adjust all callers. * cselib.c: Include valtrack.h. * dce.c: Likewise. * df-problems.c: Likewise. (dead_debug_init, dead_debug_reset_uses): Move to valtrack.c. (dead_debug_finish, dead_debug_add): Likewise. (dead_debug_insert_temp): Likewise. * df.h (struct dead_debug_use): Move to valtrack.h. (struct dead_debug, enum debug_temp_where): Likewise. (dead_debug_init, dead_debug_reset_uses): Move to valtrack.h. (dead_debug_finish, dead_debug_add): Likewise. (dead_debug_insert_temp): Likewise. * rtl.h (make_compound_operation): Declare. Added: trunk/gcc/valtrack.c trunk/gcc/valtrack.h Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/combine.c trunk/gcc/cselib.c trunk/gcc/dce.c trunk/gcc/df-problems.c trunk/gcc/df.h trunk/gcc/rtl.h --- Comment #13 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-08-02 00:34:30 UTC --- Author: aoliva Date: Thu Aug 2 00:34:26 2012 New Revision: 190062 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190062 Log: PR debug/52983 * valtrack.c (cleanup_auto_inc_dec): Implement unconditionally, falling back to copy_rtx on non-autoinc machines. (propagate_for_debug_subst): Always use cleanup_auto_inc_dec. Modified: trunk/gcc/ChangeLog trunk/gcc/valtrack.c
[Bug rtl-optimization/52983] [4.8 Regression] internal compiler error: in df_uses_record, at df-scan.c:3243
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52983 --- Comment #12 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-08-02 00:34:15 UTC --- Author: aoliva Date: Thu Aug 2 00:34:11 2012 New Revision: 190061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190061 Log: PR debug/52983 * valtrack.h, valtrack.c: New. * Makefile.in (VALTRACK_H): New. (OBJS): Add valtrack.o. (valtrack.o): New. (cselib.o, dce.o, df-problems.o, combine.o): Add VALTRACK_H. * combine.c: Include valtrack.h. (make_compound_operation): Publish. (cleanup_auto_inc_dec): Move to valtrack.c. (struct rtx_subst_pair, propagate_for_debug_subst): Likewise. (propagate_for_debug): Likewise. Add this_basic_block parameter. Adjust all callers. * cselib.c: Include valtrack.h. * dce.c: Likewise. * df-problems.c: Likewise. (dead_debug_init, dead_debug_reset_uses): Move to valtrack.c. (dead_debug_finish, dead_debug_add): Likewise. (dead_debug_insert_temp): Likewise. * df.h (struct dead_debug_use): Move to valtrack.h. (struct dead_debug, enum debug_temp_where): Likewise. (dead_debug_init, dead_debug_reset_uses): Move to valtrack.h. (dead_debug_finish, dead_debug_add): Likewise. (dead_debug_insert_temp): Likewise. * rtl.h (make_compound_operation): Declare. Added: trunk/gcc/valtrack.c trunk/gcc/valtrack.h Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/combine.c trunk/gcc/cselib.c trunk/gcc/dce.c trunk/gcc/df-problems.c trunk/gcc/df.h trunk/gcc/rtl.h --- Comment #13 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-08-02 00:34:30 UTC --- Author: aoliva Date: Thu Aug 2 00:34:26 2012 New Revision: 190062 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190062 Log: PR debug/52983 * valtrack.c (cleanup_auto_inc_dec): Implement unconditionally, falling back to copy_rtx on non-autoinc machines. (propagate_for_debug_subst): Always use cleanup_auto_inc_dec. Modified: trunk/gcc/ChangeLog trunk/gcc/valtrack.c --- Comment #14 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-08-02 00:34:45 UTC --- Author: aoliva Date: Thu Aug 2 00:34:41 2012 New Revision: 190063 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190063 Log: PR debug/52983 * valtrack.c (dead_debug_insert_temp): Use cleanup_auto_inc_dec. Modified: trunk/gcc/ChangeLog trunk/gcc/valtrack.c
[Bug rtl-optimization/52983] [4.8 Regression] internal compiler error: in df_uses_record, at df-scan.c:3243
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52983 --- Comment #13 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-08-02 00:34:30 UTC --- Author: aoliva Date: Thu Aug 2 00:34:26 2012 New Revision: 190062 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190062 Log: PR debug/52983 * valtrack.c (cleanup_auto_inc_dec): Implement unconditionally, falling back to copy_rtx on non-autoinc machines. (propagate_for_debug_subst): Always use cleanup_auto_inc_dec. Modified: trunk/gcc/ChangeLog trunk/gcc/valtrack.c --- Comment #14 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-08-02 00:34:45 UTC --- Author: aoliva Date: Thu Aug 2 00:34:41 2012 New Revision: 190063 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190063 Log: PR debug/52983 * valtrack.c (dead_debug_insert_temp): Use cleanup_auto_inc_dec. Modified: trunk/gcc/ChangeLog trunk/gcc/valtrack.c
[Bug rtl-optimization/52983] [4.8 Regression] internal compiler error: in df_uses_record, at df-scan.c:3243
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52983 --- Comment #14 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-08-02 00:34:45 UTC --- Author: aoliva Date: Thu Aug 2 00:34:41 2012 New Revision: 190063 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190063 Log: PR debug/52983 * valtrack.c (dead_debug_insert_temp): Use cleanup_auto_inc_dec. Modified: trunk/gcc/ChangeLog trunk/gcc/valtrack.c
[Bug rtl-optimization/52983] [4.8 Regression] internal compiler error: in df_uses_record, at df-scan.c:3243
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52983 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-08-02 02:26:17 UTC --- Fixed
[Bug c++/54158] New: Silently accepts sizeof to non-static member without object in C++03 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54158
Bug #: 54158
Summary: Silently accepts sizeof to non-static member without
object in C++03 mode
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
The following code is not well-formed in C++03.
/
struct Class
{
int Member;
};
int i[sizeof(Class::Member)];
/
However, GCC 4.6.4 20120727, 4.7.2 20120728 and 4.8.0 20120729 accept this code
without any warning, even with `-std=c++03', `-Wall' and `-pedantic'.
[Bug c++/54111] function return type template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54111 --- Comment #1 from Leonid Volnitsky leonid at volnitsky dot com 2012-08-02 04:02:27 UTC --- I've just tested with gcc-463.It accept/reject exactly the same as gcc-453.
