[Bug lto/53337] [4.7.1 lto] produces warning: relocation refers to discarded section in linker (gold, binutil 2.22)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53337 --- Comment #1 from vincenzo Innocente 2012-05-14 07:39:45 UTC --- Created attachment 27397 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27397 preprocessed file (for those not having boost)
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #34 from vincenzo Innocente 2012-05-14 07:41:02 UTC --- I've created PR53337
[Bug debug/51564] [4.7 Regression] ICE in force_type_die, at dwarf2out.c:19288
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51564 --- Comment #8 from rguenther at suse dot de 2012-05-14 08:12:44 UTC --- On Fri, 11 May 2012, matt at use dot net wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51564 > > --- Comment #7 from Matt Hargett 2012-05-11 20:19:01 > UTC --- > Applying the patch does allow DWARF serialization to get further, but now it > dies here: > internal compiler error: in add_AT_specification, at dwarf2out.c:7536 > > It looks like this problem (hiding beneath the original) is related to > PR47839, > whose fix was fortran front-end specific. > > Should I just file a new bug and reference these other bugs? No, it just means that -g is (expected) somewhat broken still in GCC 4.6. Only with GCC 4.7 I spent considerable time trying to solve all ICEs in that area. It's not worth cherry-picking selcted fixes because they usually expose other bugs. Richard.
[Bug bootstrap/53331] [4.8 Regression] AIX bootstrap failure in tree-vect-data-ref compiling matmul_i4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331 Richard Guenther changed: What|Removed |Added Status|NEW |WAITING AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #4 from Richard Guenther 2012-05-14 08:14:53 UTC --- Mine. Can any of you attach preprocessed source please so I can reproduce with a cross? Thx.
[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338
Richard Guenther changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #3 from Richard Guenther 2012-05-14
08:39:03 UTC ---
After IVOPTs we lose the ability to stick the aligned markers at the memory
references. Before:
# PT = anything
# ALIGN = 16, MISALIGN = 0
vect_pa.21_35 = vect_pa.21_33 + 16;
MEM[(long int[10240] *)vect_pa.21_35] = vect_var_.20_31;
after:
MEM[symbol: a, index: ivtmp.29_19, step: 2, offset: 16B] = vect_var_.20_31;
but as ivtmp.29_19 is not of pointer type we do not have 'alignment'
information
for it - thus we do not exploit that it is { 0, +, 16 } in
get_object_alignment_1.
Previously we conservatively assumed "alignment" of TYPE_ALIGN but now we
have "known" alignment due to
if (TMR_INDEX (exp) && TMR_STEP (exp))
{
unsigned HOST_WIDE_INT step = TREE_INT_CST_LOW (TMR_STEP (exp));
align = MIN (align, (step & -step) * BITS_PER_UNIT);
known_alignment = true;
}
(but that results in alignment of 2 bytes based on step) and disregard type
information.
[Bug c++/53336] invalid types in nop conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53336
Nathan Ridge changed:
What|Removed |Added
CC||zeratul976 at hotmail dot
||com
--- Comment #1 from Nathan Ridge 2012-05-14
08:50:53 UTC ---
Reduced testcase:
bool foo();
struct C
{
C()
{
if (foo())
foo();
}
};
struct S
{
struct dummy
{
int i_;
};
typedef int dummy::*bool_type;
operator bool_type() const
{
return foo() ? &dummy::i_ : 0;
}
};
int x;
struct adaptor
{
C c;
virtual void bar()
{
if (S())
x = 0;
}
};
int main()
{
adaptor a;
}
Compile with -O2. Errors:
test.cpp: In member function 'virtual void adaptor::bar()':
test.cpp:32:18: error: invalid types in nop conversion
virtual void bar()
^
<<< Unknown tree: offset_type >>>
bool
D.2314_1 = (<<< Unknown tree: offset_type >>>) D.2313_9;
test.cpp:32:18: internal compiler error: verify_gimple failed
[Bug bootstrap/53331] [4.8 Regression] AIX bootstrap failure in tree-vect-data-ref compiling matmul_i4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331 --- Comment #5 from Dominique d'Humieres 2012-05-14 08:51:14 UTC --- Created attachment 27398 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27398 preprocessed source matmul_i8.i for powerpc-apple-darwin9
[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338 --- Comment #4 from Uros Bizjak 2012-05-14 09:03:20 UTC --- 20% runtime regression in rnflow [1] happened in this timeframe, perhaps it could be attributed to the patch, mentioned in Comment #2. [1] http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-summary.txt-2-0.html
[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338 --- Comment #5 from Dominique d'Humieres 2012-05-14 09:21:41 UTC --- > 20% runtime regression in rnflow [1] happened in this timeframe, perhaps it > could be attributed to the patch, mentioned in Comment #2. This slowdown is caused by revision 187092 in the proc cptrf2. A further slowdown (~5%) is caused by revision 187340 in the proc evlrnf. While tracking these slowdowns I also noticed that for any revision compiling rnflow.f90 is slower if I use -O3 only compared to the use of -O2 only (cptrf2 seems the culprit). The best timings I get are when I compile evlrnf with '-O3 -ffast-math -funroll-loops'. I am planning to open some PRs about these findings which do not seem related to this one (unless someone beat me).
[Bug target/53189] DImode and/or/not/xor optimized poorly in core-registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53189 Andrew Stubbs changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-14 AssignedTo|unassigned at gcc dot |ams at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Andrew Stubbs 2012-05-14 09:24:02 UTC --- I'm working on some patches for this.
[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338 --- Comment #6 from Richard Guenther 2012-05-14 09:32:31 UTC --- (In reply to comment #5) > > 20% runtime regression in rnflow [1] happened in this timeframe, perhaps it > > could be attributed to the patch, mentioned in Comment #2. > > This slowdown is caused by revision 187092 in the proc cptrf2. That patch was supposed to be a no-op on code generation. > A further > slowdown (~5%) is caused by revision 187340 in the proc evlrnf. While tracking > these slowdowns I also noticed that for any revision compiling rnflow.f90 is > slower if I use -O3 only compared to the use of -O2 only (cptrf2 seems the > culprit). The best timings I get are when I compile evlrnf with '-O3 > -ffast-math -funroll-loops'. > > I am planning to open some PRs about these findings which do not seem related > to this one (unless someone beat me).
[Bug target/53334] ICE in extract_insn, at recog.c:2131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53334 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-14 CC||rearnsha at gcc dot gnu.org Component|middle-end |target Ever Confirmed|0 |1 --- Comment #3 from Richard Earnshaw 2012-05-14 09:33:46 UTC --- The movsicc (and related) patterns are not validating the arguments to the comparison properly.
[Bug tree-optimization/53340] New: [4.8 Regression] rnflow.f90 is ~20% slower after revision 187092
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53340 Bug #: 53340 Summary: [4.8 Regression] rnflow.f90 is ~20% slower after revision 187092 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: rgue...@gcc.gnu.org, ubiz...@gmail.com On x86_64-apple-darwin10, rnflow.f90 is ~20% slower after revision 187092 [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187091/bin/gfortran -O3 -ffast-math -funroll-loops rnflow.f90 [macbook] test/dbg_rnflow% time a.out > /dev/null 22.038u 0.352s 0:22.52 99.3%0+0k 2+0io 0pf+0w [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187092/bin/gfortran -O3 -ffast-math -funroll-loops rnflow.f90 [macbook] test/dbg_rnflow% time a.out > /dev/null 27.480u 0.349s 0:27.83 99.9%0+0k 0+0io 0pf+0w The slowdown comes from the optimization of cptrf2 [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187092/bin/gfortran -c -O3 -ffast-math -funroll-loops timctr.f90 cmpcpt.f90 cptrf2.f90 dger.f90 dgetri.f90 dswap.f90 dtrsm.f90 evlrnf.f90 idamax.f90 main.f90 mattrs.f90 cmpmat.f90 dgemm.f90 dgetf2.f90 dlaswp.f90 dtrmm.f90 dtrti2.f90 extpic.f90 ilaenv.f90 matcnt.f90 reaseq.f90 xerbla.f90 cptrf1.f90 dgemv.f90 dgetrf.f90 dscal.f90 dtrmv.f90 dtrtri.f90 gentrs.f90 lsame.f90 matsim.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null27.567u 0.349s 0:27.92 99.9%0+0k 0+0io 0pf+0w[macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187091/bin/gfortran -c -O3 -ffast-math -funroll-loops cptrf2.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 22.136u 0.345s 0:22.48 99.9%0+0k 0+0io 0pf+0w [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187091/bin/gfortran -c -O2 cptrf2.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 21.453u 0.348s 0:21.80 99.9%0+0k 0+0io 0pf+0w
[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338 --- Comment #7 from Dominique d'Humieres 2012-05-14 09:39:20 UTC --- > That patch was supposed to be a no-op on code generation. I have opened pr53340.
[Bug tree-optimization/53340] [4.8 Regression] rnflow.f90 is ~20% slower after revision 187092
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53340 --- Comment #1 from Dominique d'Humieres 2012-05-14 09:44:33 UTC --- Created attachment 27399 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27399 source cptrf2.f90 extracted from rnflow.f90
[Bug tree-optimization/53340] [4.8 Regression] rnflow.f90 is ~20% slower after revision 187092
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53340 --- Comment #2 from Dominique d'Humieres 2012-05-14 09:49:22 UTC --- If I understand correctly the profiling, the slowdown comes from the first inlined function minlst. The fast assembly is L45: movss (%r10), %xmm10 leal-1(%rsi), %edi movss -4(%r10), %xmm11 comiss %xmm10, %xmm6 movss -8(%r10), %xmm12 minss %xmm10, %xmm6 movss -12(%r10), %xmm13 cmova %esi, %edx comiss %xmm11, %xmm6 minss %xmm11, %xmm6 cmova %edi, %edx comiss %xmm12, %xmm6 minss %xmm12, %xmm6 leal-2(%rsi), %edi cmova %edi, %edx comiss %xmm13, %xmm6 leal-3(%rsi), %edi minss %xmm13, %xmm6 cmova %edi, %edx subl$4, %esi subq$16, %r10 cmpl%r8d, %esi jne L45 while the slow one is L39: movslq %edx, %r9 movss -4(%rdi,%r9,4), %xmm9 leal-1(%r8), %r9d comiss (%rbx), %xmm9 cmova %r8d, %edx movslq %edx, %r14 movss -4(%rdi,%r14,4), %xmm10 comiss -4(%rbx), %xmm10 cmova %r9d, %edx leal-2(%r8), %r9d movslq %edx, %r14 movss -4(%rdi,%r14,4), %xmm11 comiss -8(%rbx), %xmm11 cmova %r9d, %edx leal-3(%r8), %r9d movslq %edx, %r14 movss -4(%rdi,%r14,4), %xmm12 comiss -12(%rbx), %xmm12 cmova %r9d, %edx subl$4, %r8d subq$16, %rbx cmpl%r10d, %r8d jne L39
[Bug bootstrap/53331] [4.8 Regression] AIX bootstrap failure in tree-vect-data-ref compiling matmul_i4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331
--- Comment #6 from Richard Guenther 2012-05-14
10:02:12 UTC ---
Can you try
Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c (revision 187449)
+++ gcc/tree-vect-data-refs.c (working copy)
@@ -1078,6 +1078,11 @@ vect_verify_datarefs_alignment (loop_vec
|| !STMT_VINFO_VECTORIZABLE (stmt_info))
continue;
+ /* Strided loads perform only component accesses, alignment is
+irrelevant for them. */
+ if (STMT_VINFO_STRIDE_LOAD_P (stmt_info))
+ continue;
+
supportable_dr_alignment = vect_supportable_dr_alignment (dr, false);
if (!supportable_dr_alignment)
{
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 187449)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -1032,10 +1030,14 @@ vect_model_load_cost (stmt_vec_info stmt
}
/* The loads themselves. */
- vect_get_load_cost (first_dr, ncopies,
- ((!STMT_VINFO_GROUPED_ACCESS (stmt_info)) || group_size > 1
- || slp_node),
- &inside_cost, &outside_cost);
+ if (STMT_VINFO_STRIDE_LOAD_P (stmt_info))
+inside_cost
+ += ncopies * TYPE_VECTOR_SUBPARTS (STMT_VINFO_VECTYPE (stmt_info));
+ else
+vect_get_load_cost (first_dr, ncopies,
+ ((!STMT_VINFO_GROUPED_ACCESS (stmt_info))
+|| group_size > 1 || slp_node),
+ &inside_cost, &outside_cost);
if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, "vect_model_load_cost: inside_cost = %d, "
[Bug c++/53341] New: overloaded operator delete(void *) appear in object file even when not directly used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53341
Bug #: 53341
Summary: overloaded operator delete(void *) appear in object
file even when not directly used
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mh+...@glandium.org
Consider the following program:
-8<--
#include
extern void moz_free(void *ptr);
__attribute__((always_inline)) inline
void operator delete(void* ptr) throw()
{
return moz_free(ptr);
}
int foo() {
return 42;
}
-8<--
g++ -std=c++0x will put two symbols in the resulting object:
_ZdlPv and _Z3foov. The former is operator delete(void *)
This doesn't happen when including instead of .
This doesn't happen without -std=c++0x.
This doesn't happen with operator new, operator new[], or operator delete[].
This doesn't happen when removing __attribute__((__externally_visible__)) from
/usr/include/c++/4.7/new. (added in bug 50594)
[Bug tree-optimization/53340] [4.8 Regression] rnflow.f90 is ~20% slower after revision 187092
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53340 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-14 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther 2012-05-14 10:38:51 UTC --- Ouch. Mine.
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 --- Comment #6 from Paolo Carlini 2012-05-14 10:52:28 UTC --- Can we avoid deriving from unary_function and binary_function, no big deal as an implementation detail, but are deprecated in C++11, I would rather *remove* uses. Also, did you run the testsuite? Because normally we want the operators to be templates because of some move semantics details.
[Bug tree-optimization/53336] [4.8 Regression] invalid types in nop conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53336 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-14 Component|c++ |tree-optimization Known to work||4.7.1 Target Milestone|--- |4.8.0 Summary|invalid types in nop|[4.8 Regression] invalid |conversion |types in nop conversion Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-05-14 10:54:01 UTC --- Caused by phiopt.
[Bug tree-optimization/53336] [4.8 Regression] invalid types in nop conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53336 Richard Guenther changed: What|Removed |Added CC||bonzini at gnu dot org --- Comment #3 from Richard Guenther 2012-05-14 10:55:42 UTC --- And the -1 handling code.
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 --- Comment #7 from Paolo Carlini 2012-05-14 10:59:15 UTC --- I really do believe that we want to leave the stuff in stl_function.h alone and have something very neat in namespace __detail, in hashtable_policy.h, probably a single overloaded templated operator taking a && would be enough.
[Bug ada/52362] gnat.dg/lto8.adb FAILs with gas/gld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52362
--- Comment #7 from Eric Botcazou 2012-05-14
11:14:28 UTC ---
When there are many files to link, gnatlink passes a file containing the file
names, instead of the file names directly, on the GCC link line. There is a
bad interaction with LTO:
eric@atlantis:~/build/gcc-4_7-branch/native32> cat t.c
int main (void) { return 0; }
eric@atlantis:~/build/gcc-4_7-branch/native32> gcc/xgcc -Bgcc -c t.c -flto
eric@atlantis:~/build/gcc-4_7-branch/native32> cat FILE
INPUT (./t.o)
eric@atlantis:~/build/gcc-4_7-branch/native32> gcc/xgcc -Bgcc -o t FILE
eric@atlantis:~/build/gcc-4_7-branch/native32> ./t
eric@atlantis:~/build/gcc-4_7-branch/native32> gcc/xgcc -Bgcc -o t FILE -flto
/tmp/ccTBohVP.ltrans0.ltrans.o: In function `main':
ccTBohVP.ltrans0.o:(.text+0x0): multiple definition of `main'
./t.o:t.c:(.text+0x0): first defined here
./t.o: In function `main':
t.c:(.text+0x0): multiple definition of `main'
./t.o:t.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
We should probably use a regular response file instead:
eric@atlantis:~/build/gcc-4_7-branch/native32> cat FILE2
./t.o
eric@atlantis:~/build/gcc-4_7-branch/native32> gcc/xgcc -Bgcc -o t -Wl,@FILE2
-flto
eric@atlantis:~/build/gcc-4_7-branch/native32> ./t
[Bug middle-end/37864] warning from fold looks at macro expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37864 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-14 Ever Confirmed|0 |1 --- Comment #3 from Manuel López-Ibáñez 2012-05-14 11:18:24 UTC --- This should be possible now that we track macro expansion. It only needs someone to implement it.
[Bug ada/52362] gnat.dg/lto8.adb FAILs with gas/gld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52362
--- Comment #8 from Richard Guenther 2012-05-14
11:22:45 UTC ---
(In reply to comment #7)
> When there are many files to link, gnatlink passes a file containing the file
> names, instead of the file names directly, on the GCC link line. There is a
> bad interaction with LTO:
>
> eric@atlantis:~/build/gcc-4_7-branch/native32> cat t.c
> int main (void) { return 0; }
> eric@atlantis:~/build/gcc-4_7-branch/native32> gcc/xgcc -Bgcc -c t.c -flto
> eric@atlantis:~/build/gcc-4_7-branch/native32> cat FILE
> INPUT (./t.o)
> eric@atlantis:~/build/gcc-4_7-branch/native32> gcc/xgcc -Bgcc -o t FILE
> eric@atlantis:~/build/gcc-4_7-branch/native32> ./t
> eric@atlantis:~/build/gcc-4_7-branch/native32> gcc/xgcc -Bgcc -o t FILE -flto
> /tmp/ccTBohVP.ltrans0.ltrans.o: In function `main':
> ccTBohVP.ltrans0.o:(.text+0x0): multiple definition of `main'
> ./t.o:t.c:(.text+0x0): first defined here
> ./t.o: In function `main':
> t.c:(.text+0x0): multiple definition of `main'
> ./t.o:t.c:(.text+0x0): first defined here
> collect2: error: ld returned 1 exit status
>
> We should probably use a regular response file instead:
> eric@atlantis:~/build/gcc-4_7-branch/native32> cat FILE2
> ./t.o
> eric@atlantis:~/build/gcc-4_7-branch/native32> gcc/xgcc -Bgcc -o t -Wl,@FILE2
> -flto
> eric@atlantis:~/build/gcc-4_7-branch/native32> ./t
Yes, we don't "understand" linker scripts. The linker plugin would need to
handle feeding additional inputs towards the link stage - and we'd need to
drop the original FILE input from the final link (which is where the multiple
references come from).
[Bug c++/39681] Compile error is not descriptive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39681 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic Target|i486-linux-gnu | Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-14 Host|i486-linux-gnu | Ever Confirmed|0 |1 Build|i486-linux-gnu | --- Comment #6 from Manuel López-Ibáñez 2012-05-14 11:22:43 UTC --- This is confirmed and the error should be exactly: error: ‘foo’ was not declared in this scope like it happens with "delete". Not working on it.
[Bug c++/11856] unsigned warning in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856 Manuel López-Ibáñez changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||paolo.carlini at oracle dot ||com --- Comment #31 from Manuel López-Ibáñez 2012-05-14 11:31:10 UTC --- Still a bug. The ideal fix would be to detect that the type is dependent and not warn. How to do this needs to be investigated. Paolo, Jason, any ideas?
[Bug ada/52494] s-taprop-dummy.adb does not define subpackage Specific used in s-tpoaal.sdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52494 --- Comment #2 from Andris Pavenis 2012-05-14 11:30:49 UTC --- Created attachment 27400 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27400 Add missing sub-package to s-taprop-dummy.adb
[Bug tree-optimization/53340] [4.8 Regression] rnflow.f90 is ~20% slower after revision 187092
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53340 --- Comment #4 from Richard Guenther 2012-05-14 11:37:02 UTC --- Author: rguenth Date: Mon May 14 11:36:58 2012 New Revision: 187457 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187457 Log: 2012-05-14 Richard Guenther PR tree-optimization/53340 * tree-ssa-pre.c (op_valid_in_sets): Fix error in last commit. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/53340] [4.8 Regression] rnflow.f90 is ~20% slower after revision 187092
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53340 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther 2012-05-14 11:37:18 UTC --- Fixed.
[Bug target/53241] Bad pre increment insn for ARM vfp store instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53241
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||ramana at gcc dot gnu.org
Resolution||FIXED
Target Milestone|--- |4.8.0
--- Comment #1 from Ramana Radhakrishnan 2012-05-14
11:40:08 UTC ---
Fixed on trunk by
http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00325.html
t0o:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add r0, r0, #16
mov r3, #0
.L3:
fldmiad r1!, {d17}
fldmiad r2!, {d16}
faddd d16, d17, d16
add r3, r3, #1
cmp r3, #10
fstmiad r0!, {d16}
bne .L3
bx lr
Ramana
[Bug tree-optimization/53342] New: [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 Bug #: 53342 Summary: [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: m...@gcc.gnu.org, rgue...@gcc.gnu.org, ubiz...@gmail.com Created attachment 27401 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27401 source evlrnf.f90 extracted from rnflow.f90 On x86_64-apple-darwin10, rnflow.f90 is ~5% slower after revision 187340 [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187339/bin/gfortran -O3 -ffast-math -funroll-loops rnflow.f90 [macbook] test/dbg_rnflow% time a.out > /dev/null 27.542u 0.348s 0:27.93 99.8%0+0k 0+0io 0pf+0w [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187340/bin/gfortran -O3 -ffast-math -funroll-loops rnflow.f90 [macbook] test/dbg_rnflow% time a.out > /dev/null 29.196u 0.348s 0:29.59 99.7%0+0k 0+0io 0pf+0w The slowdown comes from the optimization of evlrnf (compiled on top of the last last set in pr53340#c1) [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187339/bin/gfortran -c -O3 -ffast-math -funroll-loops evlrnf.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 21.168u 0.348s 0:21.52 99.9%0+0k 0+0io 0pf+0w [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187340/bin/gfortran -c -O3 -ffast-math -funroll-loops evlrnf.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 22.758u 0.347s 0:23.11 99.9%0+0k 0+0io 0pf+0w
[Bug rtl-optimization/52804] IRA/RELOAD allocate wrong register on ARM for cortex-m0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52804 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-14 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Ramana Radhakrishnan 2012-05-14 11:42:53 UTC --- Fixed on trunk so far. Any plans of backporting this to 4.7 branch ? ramana
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-14 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-05-14 11:44:42 UTC --- It should now be possible to fix PR53185 in a different way without disabling peeling for alignment.
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 Michael Matz changed: What|Removed |Added AssignedTo|unassigned at gcc dot |matz at gcc dot gnu.org |gnu.org | --- Comment #2 from Michael Matz 2012-05-14 11:49:15 UTC --- Yeah.
[Bug bootstrap/53331] [4.8 Regression] AIX bootstrap failure in tree-vect-data-ref compiling matmul_i4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331 --- Comment #7 from Dominique d'Humieres 2012-05-14 12:32:26 UTC --- > Can you try >From a clean bootstrap at revision 187401, updating gcc and rebuilding libgfortran has succeeded for 187402 with the patch in comment #6 (with libgfortran moved away),. Thanks for the patch.
[Bug bootstrap/53343] New: [4.8 regression] options.c:9944:1: error: no previous prototype for 'common_handle_option_auto' broke bootstrap on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53343 Bug #: 53343 Summary: [4.8 regression] options.c:9944:1: error: no previous prototype for 'common_handle_option_auto' broke bootstrap on sparc64-linux Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se An attempt to bootstrap gcc-4.8-20120513 on sparc64-linux failed with: /mnt/scratch/objdir48/./prev-gcc/xgcc -B/mnt/scratch/objdir48/./prev-gcc/ -B/mnt/scratch/install48/sparc64-unknown-linux-gnu/bin/ -B/mnt/scratch/install48/sparc64-unknown-linux-gnu/bin/ -B/mnt/scratch/install48/sparc64-unknown-linux-gnu/lib/ -isystem /mnt/scratch/install48/sparc64-unknown-linux-gnu/include -isystem /mnt/scratch/install48/sparc64-unknown-linux-gnu/sys-include-c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/mnt/scratch/gcc-4.8-20120513/gcc -I/mnt/scratch/gcc-4.8-20120513/gcc/. -I/mnt/scratch/gcc-4.8-20120513/gcc/../include -I/mnt/scratch/gcc-4.8-20120513/gcc/../libcpp/include -I/home/mikpe/pkgs/linux-sparc64/gmp-5.0.4/include -I/home/mikpe/pkgs/linux-sparc64/mpfr-3.1.0/include -I/home/mikpe/pkgs/linux-sparc64/mpc-0.9/include -I/mnt/scratch/gcc-4.8-20120513/gcc/../libdecnumber -I/mnt/scratch/gcc-4.8-20120513/gcc/../libdecnumber/dpd -I../libdecnumber options.c -o options.o options.c:9944:1: error: no previous prototype for 'common_handle_option_auto' [-Werror=missing-prototypes] common_handle_option_auto (struct gcc_options *opts, ^ cc1: all warnings being treated as errors make[3]: *** [options.o] Error 1 make[3]: *** Waiting for unfinished jobs rm cpp.pod gfdl.pod fsf-funding.pod gfortran.pod gcc.pod gcov.pod make[3]: Leaving directory `/mnt/scratch/objdir48/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir48' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir48' make: *** [bootstrap] Error 2 gcc-4.8-20120506 did bootstrap OK. Presumably caused by PR53063 patch. Configuration parameters: /mnt/scratch/gcc-4.8-20120513/configure --prefix=/mnt/scratch/install48 --with-gmp=/home/mikpe/pkgs/linux-sparc64/gmp-5.0.4 --with-mpfr=/home/mikpe/pkgs/linux-sparc64/mpfr-3.1.0 --with-mpc=/home/mikpe/pkgs/linux-sparc64/mpc-0.9 --with-cpu=v8 --enable-multilib --disable-plugin --disable-lto --disable-nls --enable-threads=posix --enable-checking=release --disable-libmudflap --enable-languages=c,c++,fortran,ada --disable-build-poststage1-with-cxx
[Bug c++/11856] unsigned warning in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856 --- Comment #32 from Jason Merrill 2012-05-14 12:56:09 UTC --- Seems like another job for c_inhibit_evaluation_warnings.
[Bug c++/11856] unsigned warning in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #33 from Paolo Carlini 2012-05-14 13:09:06 UTC --- Looking into it.
[Bug preprocessor/53229] macro unwinder for preprocessing errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53229 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-14 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 --- Comment #8 from Paolo Carlini 2012-05-14 13:12:38 UTC --- Created attachment 27402 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27402 Draft Something like this, very lightly tested so far.
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 Paolo Carlini changed: What|Removed |Added CC||jwakely.gcc at gmail dot ||com --- Comment #9 from Paolo Carlini 2012-05-14 13:13:54 UTC --- Jon, can we simplify __detail::_Identity and __detail::_Select1st?
[Bug lto/53337] 4.7.1 lto produces warning: relocation refers to discarded section in linker (gold, binutil 2.22)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53337 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from H.J. Lu 2012-05-14 13:28:56 UTC --- Have you tried gold and ld in binutils trunk?
[Bug c/53063] encode group options in the .opt files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063 --- Comment #3 from Manuel López-Ibáñez 2012-05-14 13:30:39 UTC --- Author: manu Date: Mon May 14 13:30:32 2012 New Revision: 187462 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187462 Log: 2012-05-14 Manuel López-Ibáñez PR 53063 c-family/ * c.opt (Wc++0X-compat,Wdelete-non-virtual-dtor,Wjump-misses-init, Wreorder): Use LangEnabledBy. * c-opts.c (c_common_handle_option): Do not enable them explicitly. Call lang-specific generated functions. (c_common_post_options): Do not set them here. gcc/ * doc/options.texi: (LangEnabledBy): Document it. * optc-gen.awk: Handle LangEnabledBy. * opth-gen.awk: Generate declaration for lang-specific functions. * opt-read.awk: Record lang numbers. * opt-functions.awk (flag_set_p): Ignore the arguments of flags. (lang_sanitized_name): New. ada/ * gcc-interface/misc.c: Include opts.h and options.h before tm.h. (gnat_handle_option): Call lang-specific generated function. fortran/ * options.c (gfc_handle_option): Call lang-specific generated function. Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/misc.c trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/c-family/c.opt trunk/gcc/doc/options.texi trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/options.c trunk/gcc/opt-functions.awk trunk/gcc/opt-read.awk trunk/gcc/optc-gen.awk trunk/gcc/opth-gen.awk
[Bug bootstrap/53331] [4.8 Regression] AIX bootstrap failure in tree-vect-data-ref compiling matmul_i4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331 Rainer Orth changed: What|Removed |Added Target|powerpc64-*-* |powerpc64-*-*, ||sparc-sun-solaris2.* CC||ro at gcc dot gnu.org Host|powerpc64-*-* |powerpc64-*-*, ||sparc-sun-solaris2.* Build|powerpc64-*-* |powerpc64-*-*, ||sparc-sun-solaris2.* --- Comment #8 from Rainer Orth 2012-05-14 13:32:59 UTC --- I'm seeing the same failure on Solaris/SPARC for the 64-bit multilib. If I drop your patch into the source tree and restart the build, it completes successfully. make check still running. Thanks. Rainer
[Bug bootstrap/53331] [4.8 Regression] AIX bootstrap failure in tree-vect-data-ref compiling matmul_i4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331 Richard Guenther changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #9 from Richard Guenther 2012-05-14 13:44:22 UTC --- Ok, I'm going to commit a slightly different variant after testing on x86_64 (with a more reasonable cost).
[Bug target/53344] New: Dont' emit an assembler warning when assembling 3-byte symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53344 Bug #: 53344 Summary: Dont' emit an assembler warning when assembling 3-byte symbols Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr avr-gcc compiles extern const __pgmx char foo; const __pgmx void * pointer = &foo; to the following assembler code: .globalpointer .data .typepointer, @object .sizepointer, 3 pointer: .wordfoo .warning"assembling 24-bit address needs binutils extension for hh8(foo)" .byte0 ; hh8(foo) Rationale is that the needed extension to assemble 3-byte symbols http://sourceware.org/bugzilla/show_bug.cgi?id=13503 is only available since binutils 2.23 The above assembler code should be changed to pointer: .bytelo8(foo) .bytehi8(foo) .bytehh8(foo) because the binutils are extended now and can handle this.
[Bug target/53344] Dont' emit an assembler warning when assembling 3-byte symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53344 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P4 Blocks||49868 Target Milestone|--- |4.8.0
[Bug lto/53337] 4.7.1 lto produces warning: relocation refers to discarded section in linker (gold, binutil 2.22)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53337 --- Comment #3 from vincenzo Innocente 2012-05-14 14:08:04 UTC --- I will try the trunk go binutils. Still I confirm that this warning does not appear at all (in real-life code, not just in the attached test case) with gcc 4.8
[Bug ada/52494] s-taprop-dummy.adb does not define subpackage Specific used in s-tpoaal.sdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52494 Eric Botcazou changed: What|Removed |Added Status|WAITING |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #3 from Eric Botcazou 2012-05-14 14:46:26 UTC --- Taking care of it.
[Bug objc/53345] New: some OPT_Wformat is enabled by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53345 Bug #: 53345 Summary: some OPT_Wformat is enabled by default Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@gcc.gnu.org If a warning is controlled by warn_format, then it is disabled by default. However, cl_options[OPT_Wformat] is initialized to -1 by optc-gen.awk, so anything not checking warn_format is enabled by default. What a mess... :-(
[Bug objc/53345] some OPT_Wformat is enabled by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53345 Manuel López-Ibáñez changed: What|Removed |Added CC||joseph at codesourcery dot ||com, mikestump at comcast ||dot net --- Comment #1 from Manuel López-Ibáñez 2012-05-14 14:55:04 UTC --- This affects in particular the objc FE: Executing on host: /home/manuel/test4/187442M/build/gcc/xgcc -B/home/manuel/test4/187442M/build/gcc/ /home/manuel/test4/src/gcc/testsuite/gcc.dg/warn-nsstring.c -fno-diagnostics-show-caret-ansi -pedantic-errors -S -m32 -o warn-nsstring.s(timeout = 300) FAIL: gcc.dg/warn-nsstring.c (test for warnings, line 4) FAIL: gcc.dg/warn-nsstring.c (test for warnings, line 5) PASS: gcc.dg/warn-nsstring.c (test for excess errors)
[Bug objc/53345] some OPT_Wformat is enabled by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53345 --- Comment #2 from Manuel López-Ibáñez 2012-05-14 15:00:32 UTC --- A relatively simple fix is a new option OPT_Wformat_pedantic that is enabled by default. Another option is to enable Wformat by default. That doesn't sound too bad.
[Bug bootstrap/53331] [4.8 Regression] AIX bootstrap failure in tree-vect-data-ref compiling matmul_i4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331 --- Comment #10 from Richard Guenther 2012-05-14 15:01:35 UTC --- Author: rguenth Date: Mon May 14 15:01:22 2012 New Revision: 187466 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187466 Log: 2012-05-14 Richard Guenther PR tree-optimization/53331 * tree-vect-data-refs.c (vect_verify_datarefs_alignment): Ignore strided loads. * tree-vect-stmts.c (vect_model_load_cost): Handle strided loads. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c
[Bug bootstrap/53331] [4.8 Regression] AIX bootstrap failure in tree-vect-data-ref compiling matmul_i4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Richard Guenther 2012-05-14 15:02:25 UTC --- Fixed.
[Bug tree-optimization/53346] New: [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 Bug #: 53346 Summary: [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: rgue...@gcc.gnu.org, ubiz...@gmail.com At revision 187457 (i.e., with pr53340 fixed) on x86_64-apple-darwin10, after [macbook] test/dbg_rnflow% gfc -c -O3 -ffast-math -funroll-loops timctr.f90 cmpcpt.f90 cptrf2.f90 dger.f90 dgetri.f90 dswap.f90 dtrsm.f90 evlrnf.f90 idamax.f90 main.f90 mattrs.f90 cmpmat.f90 dgemm.f90 dgetf2.f90 dlaswp.f90 dtrmm.f90 dtrti2.f90 extpic.f90 ilaenv.f90 matcnt.f90 reaseq.f90 xerbla.f90 cptrf1.f90 dgemv.f90 dgetrf.f90 dscal.f90 dtrmv.f90 dtrtri.f90 gentrs.f90 lsame.f90 matsim.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 23.872u 0.349s 0:24.22 99.9%0+0k 0+0io 0pf+0w[macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187339/bin/gfortran -c -O3 -ffast-math -funroll-loops evlrnf.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 22.259u 0.346s 0:22.61 99.9%0+0k 0+0io 0pf+0w [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187291/bin/gfortran -c -O3 -ffast-math -funroll-loops idamax.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 22.252u 0.345s 0:22.60 99.9%0+0k 0+0io 0pf+0w [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187102/bin/gfortran -c -O3 -ffast-math -funroll-loops idamax.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 22.121u 0.346s 0:22.47 99.9%0+0k 0+0io 0pf+0w (i.e., working around prpr53342 and a regression for idamax.f90, see below), the compilation of cptrf2.f90 (source attached to pr53340) with the following flags yiels optimization level 4.4.6 4.5.3 4.6.3 4.7.0 r187457 -O2 27.828.228.221.821.8 -O2 -ftree-vectorize 27.828.228.227.927.9 -O3 22.021.325.125.325.3 -O3 -fno-tree-vectorize 22.121.321.421.421.4 Note that 4.5/4.6/4.7 vectorize two loops (lines 21 and 29), while 4.8 vectorizes only the loop at line 21 (29: not vectorized: iteration count too small.). Looking at my archives I have found that a first regression appeared between revisions 162456 and 164728 optimization level 4.6-162456 4.6p-164728 -O2 28.228.3 -O2 -ftree-vectorize28.128.3 -O3 21.429.4 -O3 -fno-tree-vectorize 21.321.4 -O3 -ffast-math 21.422.3 -O3 -ffast-math -funroll-loops 21.922.4 For the record, as said above the compilation of idamax regressed between revisions 187102 and 187291 [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187291/bin/gfortran -c -O3 -ffast-math -funroll-loops idamax.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 22.252u 0.345s 0:22.60 99.9%0+0k 0+0io 0pf+0w [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187102/bin/gfortran -c -O3 -ffast-math -funroll-loops idamax.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 22.121u 0.346s 0:22.47 99.9%0+0k 0+0io 0pf+0w Although the regression is slightly above the noise margin at the level of rnflow.f90, it could be worth to investigate it because: (1) it is a LAPACK routine (may be slightly modified), (2) there equivalent intrinsics in F90, (3) the slowdown may be quite significant at the level of the proc itself.
[Bug middle-end/53347] New: Duplicated redundant condition in compare-elim.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53347 Bug #: 53347 Summary: Duplicated redundant condition in compare-elim.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com There's a duplicated redundant condition in compare-elim.c, line 148: if (REG_P (XEXP (src, 0)) && REG_P (XEXP (src, 0)) && (REG_P (XEXP (src, 1)) || CONSTANT_P (XEXP (src, 1 return src; This can be simplified: if (REG_P (XEXP (src, 0)) && (REG_P (XEXP (src, 1)) || CONSTANT_P (XEXP (src, 1 return src; I think care must be taken to ensure that this is indeed duplicated and that the developer didn't intend to write something else instead.
[Bug target/53344] Dont' emit an assembler warning when assembling 3-byte symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53344 --- Comment #1 from Georg-Johann Lay 2012-05-14 15:48:15 UTC --- Author: gjl Date: Mon May 14 15:47:52 2012 New Revision: 187470 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187470 Log: PR target/53344 * config/avr/avr.c (avr_const_address_lo16): Remove. (avr_assemble_integer): Print ".byte lo8(x)", ".byte hi8(x)", ".byte hh8(x)" instead of emit an assembler .warning if 3-byte address is assembled. * doc/extend.texi (AVR Named Address Spaces): Document that binutils 2.23 is needed to assemble 3-byte addresses. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/doc/extend.texi
[Bug target/53344] Dont' emit an assembler warning when assembling 3-byte symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53344 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Georg-Johann Lay 2012-05-14 15:50:36 UTC --- Implemented for 4.8.0
[Bug bootstrap/52700] lib* configure fails on --enable-symvers=gnu-versioned-namespace.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52700 Benjamin Kosnik changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-14 CC||bkoz at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Benjamin Kosnik 2012-05-14 15:59:56 UTC --- I'll look at this. libgomp got patched for this here: 2011-01-20 Benjamin Kosnik PR libstdc++/36104 * acinclude.m4 (LIBGOMP_ENABLE_SYMVERS): Accept gnu variants. http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01401.html
[Bug c++/39681] Compile error is not descriptive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39681 --- Comment #7 from Jonathan Wakely 2012-05-14 16:07:32 UTC --- I agree it should be better, but the analogy isn't great: "new foo" requires foo to be a type, "delete foo" requires foo to be a variable.
[Bug c++/39681] Compile error is not descriptive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39681 --- Comment #8 from Manuel López-Ibáñez 2012-05-14 16:42:44 UTC --- (In reply to comment #5) > Like, sorry about my naivete, by adding a cp_parser_skip_to_end_of_statement > or > something right after the error message?!? That may work and the result should be kind of ok. Anyway, g++ cannot do much else with 'foo' (no spell-corrector, no searching in enclosing namespaces, etc.).
[Bug fortran/51394] Rejects legal code involving an allocatable string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51394 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Tobias Burnus 2012-05-14 16:43:52 UTC --- (In reply to comment #0) > !This code generates an internal compiler error. That has been meanwhile fixed by printing a not-yet-implemented error when allocatable string in components of derived types are used. The implementation is tracked in PR 51976 *** This bug has been marked as a duplicate of bug 51976 ***
[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976 Tobias Burnus changed: What|Removed |Added CC||i.thompson at lboro dot ||ac.uk --- Comment #5 from Tobias Burnus 2012-05-14 16:43:52 UTC --- *** Bug 51394 has been marked as a duplicate of this bug. ***
[Bug fortran/53329] ICE with deferred-length module variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53329 --- Comment #1 from Tobias Burnus 2012-05-14 16:45:32 UTC --- Author: burnus Date: Mon May 14 16:45:16 2012 New Revision: 187472 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187472 Log: 2012-05-14 Tobias Burnus PR fortran/49110 PR fortran/51055 PR fortran/53329 * trans-expr.c (gfc_trans_assignment_1): Fix allocation handling for assignment of function results to allocatable deferred-length strings. * trans-decl.c (gfc_create_string_length): For deferred-length module variables, include module name in the assembler name. (gfc_get_symbol_decl): Don't override the assembler name. 2012-05-14 Tobias Burnus PR fortran/49110 PR fortran/51055 PR fortran/53329 * gfortran.dg/deferred_type_param_4.f90: New. * gfortran.dg/deferred_type_param_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/deferred_type_param_4.f90 trunk/gcc/testsuite/gfortran.dg/deferred_type_param_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/51055] deferred length character allocation: allocate(character(len=i)::s) rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51055 --- Comment #5 from Tobias Burnus 2012-05-14 16:45:31 UTC --- Author: burnus Date: Mon May 14 16:45:16 2012 New Revision: 187472 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187472 Log: 2012-05-14 Tobias Burnus PR fortran/49110 PR fortran/51055 PR fortran/53329 * trans-expr.c (gfc_trans_assignment_1): Fix allocation handling for assignment of function results to allocatable deferred-length strings. * trans-decl.c (gfc_create_string_length): For deferred-length module variables, include module name in the assembler name. (gfc_get_symbol_decl): Don't override the assembler name. 2012-05-14 Tobias Burnus PR fortran/49110 PR fortran/51055 PR fortran/53329 * gfortran.dg/deferred_type_param_4.f90: New. * gfortran.dg/deferred_type_param_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/deferred_type_param_4.f90 trunk/gcc/testsuite/gfortran.dg/deferred_type_param_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/49110] Deferred-length character result triggers (false positive) error for pure procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #17 from Tobias Burnus 2012-05-14 16:46:20 UTC --- The REPEAT issue has now also been FIXED on the trunk (4.8). Thanks for the patience.
[Bug fortran/49110] Deferred-length character result triggers (false positive) error for pure procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110 --- Comment #16 from Tobias Burnus 2012-05-14 16:45:31 UTC --- Author: burnus Date: Mon May 14 16:45:16 2012 New Revision: 187472 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187472 Log: 2012-05-14 Tobias Burnus PR fortran/49110 PR fortran/51055 PR fortran/53329 * trans-expr.c (gfc_trans_assignment_1): Fix allocation handling for assignment of function results to allocatable deferred-length strings. * trans-decl.c (gfc_create_string_length): For deferred-length module variables, include module name in the assembler name. (gfc_get_symbol_decl): Don't override the assembler name. 2012-05-14 Tobias Burnus PR fortran/49110 PR fortran/51055 PR fortran/53329 * gfortran.dg/deferred_type_param_4.f90: New. * gfortran.dg/deferred_type_param_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/deferred_type_param_4.f90 trunk/gcc/testsuite/gfortran.dg/deferred_type_param_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/53329] ICE with deferred-length module variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53329 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Tobias Burnus 2012-05-14 16:46:14 UTC --- FIXED on the trunk (4.8).
[Bug fortran/51055] deferred length character allocation: allocate(character(len=i)::s) rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51055 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-14 Ever Confirmed|0 |1 --- Comment #6 from Tobias Burnus 2012-05-14 16:48:06 UTC --- The REPEAT issue is now fixed. Thus, one can replace the work-around-around "(repeat(...))" by the work-around "repeat(...)". TODO: The issue shown in comment 0 and in the summary of this PR. (Which is the same as PR 45170 comment 14. For quotes from the standard, see that PR.)
[Bug target/53334] [4.8 Regression] ICE in extract_insn, at recog.c:2131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53334 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|ICE in extract_insn, at |[4.8 Regression] ICE in |recog.c:2131|extract_insn, at ||recog.c:2131 --- Comment #4 from Andrew Pinski 2012-05-14 16:55:55 UTC --- (In reply to comment #3) > The movsicc (and related) patterns are not validating the arguments to the > comparison properly. This latent bug was exposed by my patch which uses the mov*cc patterns during expanding rather than just during ifcvt (where the arguments are most likely already validated).
[Bug bootstrap/53348] New: Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 Bug #: 53348 Summary: Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: sk...@iskunk.org Host: powerpc-ibm-aix4.3.2.0 Target: powerpc-ibm-aix4.3.2.0 Build: powerpc-ibm-aix4.3.2.0 Bootstrapping 4.7.0 on AIX 4.3 fails with [...] Making all in include gmake[5]: Entering directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include' mkdir -p ./powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include-x c++-header -nostdinc++ -g -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h \ -o powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/bits/atomic_base.h:37:0, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/atomic:41, from /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:100: /tmp/gcc-build/./gcc/include/stdint.h:72:29: error: conflicting declaration 'typedef short int int_fast16_t' In file included from /tmp/gcc-build/./gcc/include-fixed/sys/types.h:64:0, from /usr/include/sys/lc_core.h:36, from /usr/include/sys/localedef.h:43, from /tmp/gcc-build/./gcc/include-fixed/ctype.h:131, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cctype:44, from /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:36: /usr/include/sys/inttypes.h:143:18: error: 'int_fast16_t' has a previous declaration as 'typedef int32_t int_fast16_t' In file included from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/bits/atomic_base.h:37:0, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/atomic:41, from /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:100: /tmp/gcc-build/./gcc/include/stdint.h:75:29: error: conflicting declaration 'typedef unsigned char uint_fast8_t' In file included from /tmp/gcc-build/./gcc/include-fixed/sys/types.h:64:0, from /usr/include/sys/lc_core.h:36, from /usr/include/sys/localedef.h:43, from /tmp/gcc-build/./gcc/include-fixed/ctype.h:131, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cctype:44, from /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:36: /usr/include/sys/inttypes.h:145:18: error: 'uint_fast8_t' has a previous declaration as 'typedef uint32_t uint_fast8_t' In file included from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/bits/atomic_base.h:37:0, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/atomic:41, from /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:100: /tmp/gcc-build/./gcc/include/stdint.h:76:30: error: conflicting declaration 'typedef short unsigned int uint_fast16_t' In file included from /tmp/gcc-build/./gcc/include-fixed/sys/types.h:64:0, from /usr/include/sys/lc_core.h:36, from /usr/include/sys/localedef.h:43, from /tmp/gcc-build/./gcc/include-fixed/ctype.h:131, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cctype:44, from /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:36: /usr/include/sys/inttypes.h:146:18: error: 'uint_fast16_t' has a previous declaration as 'typedef uint32_t uint_fast16_t' gmake[5]: *** [powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1 gmake[5]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2 gmake[2]: Leaving directory `/tmp/gcc-build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build' gmake: *
[Bug other/53317] Conversion from __int128 to __float128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53317 --- Comment #3 from ahakkas at gmail dot com 2012-05-14 18:07:50 UTC --- Created attachment 27403 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27403 testcase
[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46098 Uros Bizjak changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED | --- Comment #9 from Uros Bizjak 2012-05-14 18:13:50 UTC --- (In reply to comment #8) > Fixed. This fix is not optimal, for the testcase we generate: movsd (%rax), %xmm0 movhpd 8(%rax), %xmm0 movupd %xmm0, -16(%rbp) movapd -16(%rbp), %xmm0 So, we move (unaligned!) memory to a register, and then use movupd to store to aligned stack slot. Luckily, gcc figures that the load is from unaligned memory and generates movsd/movhpd combo. The intention was to generate: movupd (%rax), %xmm0 movapd %xmm0, -16(%rbp) movapd -16(%rbp), %xmm0 So, we don't want a fixup in the expander, but we should always load to a register for "load" builtin class. The patch should be reverted and following patch should be applied instead: Index: i386.c === --- i386.c (revision 187465) +++ i386.c (working copy) @@ -29472,8 +29472,8 @@ ix86_expand_special_args_builtin (const struct bui arg_adjust = 0; if (optimize || target == 0 - || GET_MODE (target) != tmode - || !insn_p->operand[0].predicate (target, tmode)) + || !register_operand (target, tmode) + || GET_MODE (target) != tmode) target = gen_reg_rtx (tmode); } I will undo the (arguably, small) damage in all release branches.
[Bug c/50606] gcc fails to detect obvious use of NULL pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50606 --- Comment #2 from dcb 2012-05-14 18:24:44 UTC --- (In reply to comment #1) > printf warnings are handled in the FE, so we would need constant-propagation > in > the FE. Clang implements it, so I know it is possible. I think my bug report wasn't clearly worded. printf was merely an example function. I am interested in having gcc track when it knows for certain that a pointer is NULL, so that it can detect uses that won't work and emit a warning. One use of a NULL pointer that won't work is to read what it's pointing at. > However, no current > contributor to GCC has enough time and interest to implement it, so unless > some > new contributors appear, don't expect this anytime soon. Righto.
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315 --- Comment #18 from Jakub Jelinek 2012-05-14 18:47:09 UTC --- Author: jakub Date: Mon May 14 18:47:05 2012 New Revision: 187477 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187477 Log: 2012-05-14 Andrew Pinski H.J. Lu Jakub Jelinek PR target/53315 * config/i386/i386.md (xbegin_1): Use + in constraint and match_dup. (xbegin): Updated. 2012-05-14 Andi Kleen Jakub Jelinek PR target/53315 * gcc.target/i386/i386.exp (check_effective_target_rtm): New. * gcc.target/i386/rtm-check.h: New file. * gcc.target/i386/pr53315.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr53315.c trunk/gcc/testsuite/gcc.target/i386/rtm-check.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/i386.exp
[Bug c/50606] gcc fails to detect obvious use of NULL pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50606
--- Comment #3 from Manuel López-Ibáñez 2012-05-14
18:47:01 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > printf warnings are handled in the FE, so we would need
> > constant-propagation in
> > the FE. Clang implements it, so I know it is possible.
>
> I think my bug report wasn't clearly worded.
> printf was merely an example function.
> I am interested in having gcc track when it knows
> for certain that a pointer is NULL, so that it
> can detect uses that won't work and emit a warning.
>
There are two ways to implement this in such a general way.
1) A new pass in the middle-end. You can look at the implementation of nonnull,
and try to figure out something similar. The advantage is that you can make
full use of middle-end capabilities. The disadvantage is that optimization
passes may hide obvious warnings, and the warnings will require optimization to
be enabled.
2) Purely in the FE. This will require substantially more work, since you have
to implement some kind of conditional constant propagation, but it will be far
more reliable and work without optimizations.
But any of the above would be better than nothing, so choose whatever seems
better for you. It is a bit of a shame that GCC doesn't warn even for very
simple cases:
void f( const char * p)
{
if (p == 0)
__builtin_printf(*p);
}
[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52428 --- Comment #9 from Janne Blomqvist 2012-05-14 19:39:27 UTC --- Author: jb Date: Mon May 14 19:39:23 2012 New Revision: 187478 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187478 Log: PR 52428 Range checking when reading integer values. gcc/fortran ChangeLog: 2012-05-14 Janne Blomqvist PR fortran/52428 * gfortran.texi: Update _gfortran_set_options documentation. * invoke.texi: Remove runtime behavior description of -fno-range-check. * trans-decl.c (create_main_function): Don't pass the range-check setting to the library. libgfortran ChangeLog: 2012-05-14 Janne Blomqvist PR fortran/52428 * io/io.h (max_value): Rename to si_max, remove second argument. * io/list_read.c (convert_integer): Use unsigned types when parsing the digits, set max value depending on the sign. * io/read.c (max_value): Rename to si_max, remove second argument, simplify. (read_decimal): Set max value depending on sign, always check overflow. (read_radix): Calculate max unsigned value directly. * libgfortran.h (struct compile_options_t): Remove range_check field. * runtime/compile_options.c (set_options): Skip handling options[7]. (init_compile_options): Don't set removed field. gcc/testsuite ChangeLog: 2012-05-14 Janne Blomqvist PR fortran/52428 * gfortran.dg/int_range_io_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/int_range_io_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/read.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/compile_options.c
[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52428 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Janne Blomqvist 2012-05-14 19:42:04 UTC --- Fixed on trunk. Thanks everyone.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 François Dumont changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from François Dumont 2012-05-14 19:49:52 UTC --- Avoiding the numerous debug checks when checking that ranges are heap seems to have resolve this issue. Fully removing useless debug checks in priority_queue will come later.
[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607 --- Comment #30 from Marc Glisse 2012-05-14 20:19:39 UTC --- Author: glisse Date: Mon May 14 20:19:30 2012 New Revision: 187479 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187479 Log: 2012-05-14 Marc Glisse PR target/52607 * config/i386/i386.c (ix86_expand_vec_perm_const): Move code to ... (canonicalize_perm): ... new function. (expand_vec_perm_2vperm2f128_vshuf): New function. (ix86_expand_vec_perm_const_1): Call it. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46098 --- Comment #10 from uros at gcc dot gnu.org 2012-05-14 21:28:11 UTC --- Author: uros Date: Mon May 14 21:28:07 2012 New Revision: 187481 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187481 Log: PR target/46098 * config/i386/i386.c (ix86_expand_special_args_builtin): Always generate target register for "load" class builtins. Revert: 2010-10-22 Uros Bizjak PR target/46098 * config/i386/sse.md (*avx_movu): Rename from avx_movu. (avx_movu): New expander. (*_movu): Rename from _movu. (_movu): New expander. (*avx_movdqu): Rename from avx_movdqu. (avx_movdqu): New expander. (*sse2_movdqu): Rename from sse2_movdqu. (sse2_movdqu): New expander. testsuite/ChangeLog: * gcc.target/i386/avx256-unaligned-load-[1234].c: Update scan strings. * gcc.target/i386/avx256-unaligned-store-[1234].c: Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-1.c trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-2.c trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-3.c trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-4.c trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-1.c trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-2.c trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-3.c trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-4.c
[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46098 --- Comment #11 from uros at gcc dot gnu.org 2012-05-14 21:30:27 UTC --- Author: uros Date: Mon May 14 21:30:23 2012 New Revision: 187482 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187482 Log: PR target/46098 * config/i386/i386.c (ix86_expand_special_args_builtin): Always generate target register for "load" class builtins. Revert: 2010-10-22 Uros Bizjak PR target/46098 * config/i386/sse.md (*avx_movu): Rename from avx_movu. (avx_movu): New expander. (*_movu): Rename from _movu. (_movu): New expander. (*avx_movdqu): Rename from avx_movdqu. (avx_movdqu): New expander. (*sse2_movdqu): Rename from sse2_movdqu. (sse2_movdqu): New expander. testsuite/ChangeLog: * gcc.target/i386/avx256-unaligned-load-[1234].c: Update scan strings. * gcc.target/i386/avx256-unaligned-store-[1234].c: Ditto. 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/sse.md branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-2.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-3.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-4.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-2.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-3.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-4.c
[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46098 --- Comment #12 from uros at gcc dot gnu.org 2012-05-14 21:32:35 UTC --- Author: uros Date: Mon May 14 21:32:29 2012 New Revision: 187483 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187483 Log: PR target/46098 * config/i386/i386.c (ix86_expand_special_args_builtin): Always generate target register for "load" class builtins. Revert: 2010-10-22 Uros Bizjak PR target/46098 * config/i386/sse.md (*avx_movu): Rename from avx_movu. (avx_movu): New expander. (*_movu): Rename from _movu. (_movu): New expander. (*avx_movdqu): Rename from avx_movdqu. (avx_movdqu): New expander. (*sse2_movdqu): Rename from sse2_movdqu. (sse2_movdqu): New expander. testsuite/ChangeLog: * gcc.target/i386/avx256-unaligned-load-[1234].c: Update scan strings. * gcc.target/i386/avx256-unaligned-store-[1234].c: Ditto. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/i386/i386.c branches/gcc-4_6-branch/gcc/config/i386/sse.md branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-1.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-2.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-3.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-4.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-1.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-2.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-3.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-4.c
[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46098 --- Comment #13 from uros at gcc dot gnu.org 2012-05-14 21:35:20 UTC --- Author: uros Date: Mon May 14 21:35:16 2012 New Revision: 187484 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187484 Log: PR target/46098 * config/i386/i386.c (ix86_expand_special_args_builtin): Always generate target register for "load" class builtins. Revert: 2010-10-22 Uros Bizjak PR target/46098 * config/i386/sse.md (*avx_movu): Rename from avx_movu. (avx_movu): New expander. (*_movu): Rename from _movu. (_movu): New expander. (*avx_movdqu): Rename from avx_movdqu. (avx_movdqu): New expander. (*sse2_movdqu): Rename from sse2_movdqu. (sse2_movdqu): New expander. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/i386.c branches/gcc-4_5-branch/gcc/config/i386/sse.md
[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46098 Uros Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-05/msg00951.htm ||l Resolution||FIXED --- Comment #14 from Uros Bizjak 2012-05-14 21:40:19 UTC --- Fixed again.
[Bug c++/53349] New: Internal compiler error with constexpr and recursive data type.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53349 Bug #: 53349 Summary: Internal compiler error with constexpr and recursive data type. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pk...@dcs.gla.ac.uk Created attachment 27404 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27404 The file which causes the internal error. Compiling the attached file will cause an internal compiler error in gcc 4.7.0 under 32-bit Ubuntu 12.04: g++-4.7 -std=c++11 rec_constexpr.cpp ... constfft.cpp:16:47: internal compiler error: in cxx_eval_indirect_ref, at cp/semantics.c:7400 If the copy constructor of Foo is removed, it is clang 3.2 (trunk 156580) which will then fail.
[Bug c++/53350] New: Internal compiler error when compiling boost/smart_ptr/intrusive_ptr.hpp 1.49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53350 Bug #: 53350 Summary: Internal compiler error when compiling boost/smart_ptr/intrusive_ptr.hpp 1.49 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rct+...@thompsonclan.org When compiling boost 1.49 on Ubuntu 11.10 wigh GCC version 4.6.1-9ubuntu3, I get an internal compiler error. The error happens when the following command is run in tools/quickbook: "g++" -ftemplate-depth-300 -O3 -finline-functions -Wno-inline -Wall -g -g0 -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"../.." -c -o "../../bin.v2/tools/quickbook/src/gcc-4.6.1/release/debug-symbols-on/link-static/id_manager.o" "src/id_manager.cpp" The error is: In file included from ../../boost/intrusive_ptr.hpp:16:0, from src/fwd.hpp:15, from src/values.hpp:20, from src/id_manager.hpp:14, from src/id_manager.cpp:9: ../../boost/smart_ptr/intrusive_ptr.hpp: In destructor ‘boost::intrusive_ptr::~intrusive_ptr() [with T = quickbook::file_info]’: ../../boost/smart_ptr/intrusive_ptr.hpp:94:5: internal compiler error: Segmentation fault I was building the boost library by downloading the sources from here: http://packages.ubuntu.com/source/quantal/boost1.49 and using the "debuild" tool to build installable packages. The build will fail at the above command, and the command can then be repeated to consistently produce the error I have attached the preprocessed source of the offending file, boost/smart_ptr/intrusive_ptr.hpp
[Bug bootstrap/53351] New: Missing integer types when bootstrapping on AIX 4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53351 Bug #: 53351 Summary: Missing integer types when bootstrapping on AIX 4.3 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: sk...@iskunk.org Host: powerpc-ibm-aix4.3.2.0 Target: powerpc-ibm-aix4.3.2.0 Build: powerpc-ibm-aix4.3.2.0 Bootstrapping 4.7.0 on AIX 4.3 fails with [...] Making all in c++11 gmake[6]: Entering directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/c++11' /opt/freeware/bin/bash ../../libtool --tag CXX --tag disable-shared --mode=compile /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include -I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=chrono.lo -std=gnu++11 -g -c -o chrono.lo /home/src/gcc-4.7.0/libstdc++-v3/src/c++11/chrono.cc libtool: compile: /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include -I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=chrono.lo -std=gnu++11 -g -c /home/src/gcc-4.7.0/libstdc++-v3/src/c++11/chrono.cc -DPIC -o chrono.o In file included from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/ratio:39:0, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/chrono:38, from /home/src/gcc-4.7.0/libstdc++-v3/src/c++11/chrono.cc:25: /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:65:11: error: '::int8_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:66:11: error: '::int16_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:67:11: error: '::int32_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:68:11: error: '::int64_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:70:11: error: '::int_fast8_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:71:11: error: '::int_fast16_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:72:11: error: '::int_fast32_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:73:11: error: '::int_fast64_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:75:11: error: '::int_least8_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:76:11: error: '::int_least16_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:77:11: error: '::int_least32_t' has not been declared [numerous cascaded errors elided] gmake[6]: *** [chrono.lo] Error 1 gmake[6]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/c++11' gmake[6]: Entering directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src' gmake[6]: *** No rule to make target `../src/c++98/libc++98convenience.la', needed by `libstdc++.la'. Stop. gmake[6]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src' gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2 gmake[2]: Leaving directory `/tmp/gcc-bui
[Bug rtl-optimization/53352] New: Incorrect CSE optimization on RTL expressions with a paradoxical subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352 Bug #: 53352 Summary: Incorrect CSE optimization on RTL expressions with a paradoxical subreg Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: mead...@codesourcery.com Host: GNU/Linux Target: arm-none-linux-gnueabi The attached reproduction case exhibits what I believe to be a bug in the CSE pass. The problem can be reproduced from the mainline at r187470. The compiler was built for arm-none-linux-gnueabi and the reproduction case was compiled with -O3. Out of the gate the expanded RTL of interest looks like: (insn 12 11 13 3 (set (reg:SI 140) (lshiftrt:SI (reg/v:SI 135 [ tmp1 ]) (const_int 16 [0x10]))) (nil)) (insn 13 12 14 3 (set (reg:QI 141) (subreg:QI (reg:SI 140) 0)) (nil)) (insn 14 13 15 3 (set (reg:SI 142) (subreg:SI (reg:QI 141) 0)) (nil)) (insn 15 14 16 3 (set (reg:SI 134 [ tmp1$2 ]) (and:SI (reg:SI 142) (const_int 255 [0xff]))) (nil)) ... (insn 29 28 30 3 (set (reg:SI 0 r0) (const_int 0 [0])) (nil)) after "cse1" things look like: (insn 12 11 13 2 (set (reg:SI 140) (const_int 65280 [0xff00])) (nil)) (insn 13 12 14 2 (set (reg:QI 141) (subreg:QI (reg:SI 140) 0)) (expr_list:REG_EQUAL (const_int 0 [0]) (nil))) ;; This is *not* equal to zero because the upper ;; two bytes are undefined. (insn 14 13 15 2 (set (reg:SI 142) (subreg:SI (reg:QI 141) 0)) (expr_list:REG_EQUAL (const_int 0 [0]) (nil))) (insn 15 14 16 2 (set (reg:SI 134 [ tmp1$2 ]) (reg:SI 142)) (expr_list:REG_EQUAL (const_int 0 [0]) (nil))) ... (insn 29 28 30 2 (set (reg:SI 0 r0) (reg:SI 142)) (expr_list:REG_EQUAL (const_int 0 [0]) (nil))) I believe the REG_EQUAL note on the set involving a paradoxical subreg is incorrect. It eventually causes 0xFF00 to be passed to the function 'foo'. I doesn't look like 'equiv_constant' handles the paradoxical subreg case correctly. I fixed it as follows and am testing the patch now: Index: gcc/cse.c === --- gcc/cse.c (revision 187470) +++ gcc/cse.c (working copy) @@ -3786,8 +3786,11 @@ } } - /* Otherwise see if we already have a constant for the inner REG. */ + /* Otherwise see if we already have a constant for the inner REG. +Don't bother with paradoxical subregs because we have no way +of knowing what the upper bytes are. */ if (REG_P (SUBREG_REG (x)) + && (GET_MODE_SIZE (mode) <= GET_MODE_SIZE (imode)) && (new_rtx = equiv_constant (SUBREG_REG (x))) != 0) return simplify_subreg (mode, new_rtx, imode, SUBREG_BYTE (x));
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 --- Comment #1 from Daniel Richard G. 2012-05-14 22:51:36 UTC --- *** Bug 47907 has been marked as a duplicate of this bug. ***
[Bug bootstrap/47907] Bootstrap failure: libiberty/hashtab.c: error: conflicting types for 'int_fast16_t'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47907 Daniel Richard G. changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Daniel Richard G. 2012-05-14 22:51:36 UTC --- This bug is a duplicate of bug 53348. The failure mode in comment 1 is a duplicate of bug 53351. (The linked bug reports are newer, but represent a clearer diagnosis of the problem, and are filed against version 4.7.0.) *** This bug has been marked as a duplicate of bug 53348 ***
[Bug rtl-optimization/53352] Incorrect CSE optimization on RTL expressions with a paradoxical subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352 --- Comment #1 from Meador Inge 2012-05-14 22:52:41 UTC --- Created attachment 27405 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27405 Reproduction case
[Bug bootstrap/47902] Bootstrap failure: libiberty/regex.c: error: two or more data types in declaration specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47902 Daniel Richard G. changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #5 from Daniel Richard G. 2012-05-14 22:54:02 UTC --- This bug appears to be a duplicate of bug 53348. (The linked bug report is newer, but represents a clearer diagnosis of the problem, and is filed against version 4.7.0.) *** This bug has been marked as a duplicate of bug 53348 ***
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 --- Comment #2 from Daniel Richard G. 2012-05-14 22:54:02 UTC --- *** Bug 47902 has been marked as a duplicate of this bug. ***
[Bug c++/53350] Internal compiler error when compiling boost/smart_ptr/intrusive_ptr.hpp 1.49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53350 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-14 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2012-05-14 23:25:20 UTC --- Nothing is attached.
[Bug c/53353] New: Missing error/warning when using __int128_t with incorrect asm register constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53353
Bug #: 53353
Summary: Missing error/warning when using __int128_t with
incorrect asm register constraints
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: svfue...@gmail.com
The following (nonsensical) code should give an error (or at least a warning)
about the 128 bit type not fitting into a register:
void foo(__int128_t x)
{
asm("mov %0, bar":: "r" (x));
}
Instead, the above compiles into an instruction that uses the 16 bit register
%ax.
(Compiled with -Wall -W)
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 Paolo Carlini changed: What|Removed |Added Attachment #27402|0 |1 is obsolete|| --- Comment #10 from Paolo Carlini 2012-05-15 01:04:30 UTC --- Created attachment 27406 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27406 Draft 2 This is my current best, uses std::get and std::tuple_element. Passes testing.
[Bug bootstrap/53351] Missing integer types when bootstrapping on AIX 4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53351 Paolo Carlini changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #1 from Paolo Carlini 2012-05-15 01:11:05 UTC --- David, I'm wondering if we shouldn't close as WONTFIX or something the PRs having to do with 4.3, which you always explaining is very old and unmaintained.
