[Bug c/54708] library must be placed after source for gcc to see it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54708 --- Comment #3 from Andreas Schwab 2012-09-26 07:19:41 UTC --- Library arguments are position dependent, and must always be placed after the objects that reference them.
[Bug tree-optimization/54713] New: [4.8 Regression] error: non-trivial conversion at assignment in gcc.c-torture/compile/pr53410-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54713
Bug #: 54713
Summary: [4.8 Regression] error: non-trivial conversion at
assignment in gcc.c-torture/compile/pr53410-2.c
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com
Target: alpha-linux-gnu
Following testcase, derived from gcc.c-torture/compile/pr53410-2.c started to
ICE on alpha-linux-gnu recently.
--cut here--
typedef int V __attribute__((vector_size (4 * sizeof (int;
void
f6 (V *p, V *q, V *r)
{
*p = (*p & *r) == (*q & *r);
}
--cut here--
ICE can be triggered with a cross from x86_64-pc-linux-gnu:
~/gcc-build-alpha/gcc/cc1 -O2 -quiet tt.c
tt.c: In function ‘f6’:
tt.c:4:1: error: non-trivial conversion at assignment
f6 (V *p, V *q, V *r)
^
int
vector(2) int
_24 = _20;
tt.c:4:1: error: non-trivial conversion at assignment
int
vector(2) int
_26 = _23;
tt.c:4:1: internal compiler error: verify_gimple failed
Please submit a full bug report,
...
[Bug lto/54705] ICE during custom LTO bootstrap with Ada enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54705 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-09-26 CC||ebotcazou at gcc dot ||gnu.org Summary|Building gcc with ADA and |ICE during custom LTO |LTO results in an internal |bootstrap with Ada enabled |error | Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-09-26 08:27:44 UTC --- Well, fiddling with BOOT_CFLAGS is at your own risks, LTO bootstrap works if you use the right procedure: configure --with-build-config=bootstrap-lto and type 'make'. I suspect that the problem comes from the -O3 option. That being said, LTO indeed generates patterns that easily confuse the DWARF back-end. However, I cannot reproduce and this is expected: the reported error can only occur if -g is used during the bootstrap and your script doesn't have it... And ADA is the American with Disabilities Act; the programming language is called Ada, this is the first name of Lady Ada, Countless of Lovelace.
[Bug fortran/54714] New: ICE on invalid expression involving DT with allocatable components and constructor in I/O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54714 Bug #: 54714 Summary: ICE on invalid expression involving DT with allocatable components and constructor in I/O Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: xarthisius...@gmail.com Hi, following code: program foo type :: na_var integer, allocatable, dimension(:) :: x end type na_var write(*,*) na_var([2,2]) end gives ICE with xarth@janus01 ~ $ gfortran -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre/gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-pre/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.8.0_pre/work/gcc-4.8.0-/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/python --enable-checking=yes --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.0_pre' Thread model: posix gcc version 4.8.0-pre 20120922 (experimental) commit f09a218261ba473738ad45f2c643957523019a17 (Gentoo 4.8.0_pre) For the reference, this bug is a variation of PR41859
[Bug tree-optimization/54713] [4.8 Regression] error: non-trivial conversion at assignment in gcc.c-torture/compile/pr53410-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54713 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #1 from Richard Guenther 2012-09-26 08:58:49 UTC --- ISTR alpha has BLKmode vectors.
[Bug c++/54712] internal compiler error: in gimple_get_virt_method_for_binfo, at gimple-fold.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54712 Richard Guenther changed: What|Removed |Added Target||mingw32 Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Richard Guenther 2012-09-26 09:00:25 UTC --- Fixed in 4.7.1.
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #11 from Paolo Carlini 2012-09-26 09:00:49 UTC --- Created attachment 28279 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28279 Draft, sanity checked x86_64-linux
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #12 from Paolo Carlini 2012-09-26 09:01:58 UTC --- Kai, I attached a complete draft which passes a sanity check on Linux. Please let me know if it works for you and we can resolve this.
[Bug web/54711] Fix --target_board examples on test.html page
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54711
--- Comment #1 from Richard Guenther 2012-09-26
09:03:01 UTC ---
RUNTESTFLAGS="--target_board=unix/\{-m32,\}"
works for me as well. You say the elaborated list needs fixing? Care to
fix it yourself?
[Bug middle-end/54704] [4.8 Regression] three-fold increase in compile-time between r191483 and r191569
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54704 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Richard Guenther 2012-09-26 09:03:31 UTC --- Fixed.
[Bug c++/54710] moderately large tuple, with many gets, ballons compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #4 from Richard Guenther 2012-09-26 09:05:04 UTC --- That: --enable-checking=assert,misc,tree,gc,rtl,runtime will enable very compile-time intensive internal checking. Use --enable-checking=release or at most the default checking options (which are "yes"). If you compare with other compilers always use release checking.
[Bug fortran/54714] ICE on invalid expression involving DT with allocatable components and constructor in I/O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54714 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-26 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus 2012-09-26 09:08:45 UTC --- Invalid read of size 4 at 0x57EB174: __gmpz_sub (in /usr/lib64/libgmp.so.10.0.5) by 0x6540BE: transfer_array_component(tree_node*, gfc_component*, locus*) (trans-io.c:1963) by 0x653C0E: transfer_expr(gfc_se*, gfc_typespec*, tree_node*, gfc_code*) (trans-io.c:2168) by 0x6570E7: gfc_trans_transfer(gfc_code*) (trans-io.c:2308) But the actual problem is that it isn't already rejected at resolving time; the code is invalid. "If a list item of derived type in a formatted input/output statement is not processed by a defined input/output procedure, that list item is treated as if all of the components of the list item were specified in the list in component order; those components shall be accessible in the scoping unit containing the input/output statement and shall not be pointers or allocatable." (F2008, "9.6.3 Data transfer input/output list" paragraph 7, list item below "NOTE 9.34")
[Bug preprocessor/54694] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694 Richard Guenther changed: What|Removed |Added Target||i686-pc-linux-gnu --- Comment #3 from Richard Guenther 2012-09-26 09:10:23 UTC --- (In reply to comment #1) > Please attach preprocessed source and provide the output of the compiler > command with -v appended. The "compiler command". I cannot reproduce it with gcc -S t.i -m32 -march=i686 -fomit-frame-pointer -O2 -fPIE -fstack-protector-all but I have no idea what -march=native expands to. It would have told me if you _added_ "-v" to the command that produces the error (not only "gcc").
[Bug tree-optimization/54713] [4.8 Regression] error: non-trivial conversion at assignment in gcc.c-torture/compile/pr53410-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54713
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek 2012-09-26
09:19:55 UTC ---
I think this is a bug in fold_ternary_loc. The thing is that forwprop tries to
simplify_bitfield_ref, _24 = BIT_FIELD_REF <_9, 32, 0>, where _9 is TImode
4xint
vector, _24 is int, and _9 = { _20, _23 }; where _20 and _23 are V2SI vectors.
Fold then assumes that a vector CONSTRUCTOR will only contain scalars, not
shorter vectors, and returns the first vector as whole.
[Bug lto/54709] [4.8 Regression] r191713 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54709 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||lto Last reconfirmed||2012-09-26 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Target Milestone|--- |4.8.0 --- Comment #1 from Richard Guenther 2012-09-26 09:26:52 UTC --- Confirmed. I'll have a look.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #84 from Tobias Burnus 2012-09-26 09:37:57 UTC --- (In reply to comment #83) > any progress on this one? Well, the patch at http://gcc.gnu.org/ml/fortran/2012-08/msg00150.html solves several issues, but it still has issues, cf. http://gcc.gnu.org/ml/fortran/2012-08/msg00176.html > It would be great to have LTO work with Fortran in 4.8 Well, it does for many codes; also the issue is merely* a tree-checking issues thus it should work* when GCC is compiled with release checking. (* As the tree-checking failure is related to the "restrict" qualifier / pointer/target attribute, the issue of this PR might lead to wrong code. But seemingly, the issue doesn't surface in most codes.)
[Bug lto/54709] [4.8 Regression] r191713 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54709
--- Comment #2 from Richard Guenther 2012-09-26
10:10:42 UTC ---
Turns out the location changes broke streamer_handle_as_builtin_p (which
uses broken predicates). Testing
Index: tree-streamer.h
===
--- tree-streamer.h (revision 191756)
+++ tree-streamer.h (working copy)
@@ -57,10 +57,7 @@ struct streamer_tree_cache_d
static inline bool
streamer_handle_as_builtin_p (tree expr)
{
- return (TREE_CODE (expr) == FUNCTION_DECL
- && DECL_IS_BUILTIN (expr)
- && (DECL_BUILT_IN_CLASS (expr) == BUILT_IN_NORMAL
- || DECL_BUILT_IN_CLASS (expr) == BUILT_IN_MD));
+ return (TREE_CODE (expr) == FUNCTION_DECL && DECL_BUILT_IN (expr));
}
/* In tree-streamer-in.c. */
and reverting the original patch.
[Bug target/54703] _mm_sub_pd is incorrectly substituted with vandnps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54703 --- Comment #7 from Matthias Kretz 2012-09-26 10:52:38 UTC --- Thanks for the quick response! You guys are cool! :) The pattern here is for calculation with extended precision: xh = x & mask; xl = x - xh; yh = y & mask yl = y - yh; /* x * y + small = */ xh * yh + ((xh * yl + xl * yh) + (xl * yl + small)); Other than that, yes there's a lot of ANDPS is SSE code, just this pattern which gets miscompiled is not very common.
[Bug c++/53137] [4.7/4.8 Regression] g++ segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137
valery.bickov+gcc at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #8 from Jason Merrill 2012-06-20
07:22:00 UTC ---
Author: jason
Date: Wed Jun 20 07:21:55 2012
New Revision: 188810
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188810
Log:
Reapply:
PR c++/53137
* pt.c (instantiate_class_template_1): Set LAMBDA_EXPR_THIS_CAPTURE.
(instantiate_decl): Don't push_to_top_level for local class methods.
(instantiate_class_template_1): Or for local classes.
Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template5.C
Modified:
branches/gcc-4_7-branch/gcc/cp/ChangeLog
branches/gcc-4_7-branch/gcc/cp/pt.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
--- Comment #9 from valery.bickov+gcc at gmail dot com 2012-09-26 11:12:24 UTC
---
Slightly modified example still crashes on 4.7.2:
template
void getParent(STORE& tStore)
{
}
struct Store
{
template
void updateChildCommon(CheckParentFunc c)
{
c();
}
template
int& getStore();
template
void updateChild(const T& obj)
{
updateChildCommon([this] () { getParent(getStore()); });
}
void update(int obj);
};
void Store::update(int obj)
{
updateChild(obj);
}
$ /usr/local/gcc-4.7.2/bin/g++ -c gcc-4.7.2-crash.cpp -std=c++11
gcc-4.7.2-crash.cpp: In lambda function:
gcc-4.7.2-crash.cpp:29:1: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:1035
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
$ /usr/local/gcc-4.7.2/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.7.2/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7.2/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local/gcc-4.7.2 --enable-lto
--disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 4.7.2 (GCC)
It compiles ok if I remove c() call or move update(int) definition body into
class.
g++-4.6.3 works with it.
I changed status to reopened excuse me if I shouldn't do it.
[Bug c++/53137] [4.7/4.8 Regression] g++ segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137
--- Comment #10 from Richard Guenther 2012-09-26
11:34:49 UTC ---
Probably wants a new bugreport, but confirmed:
(gdb) call debug_gimple_stmt (stmt)
__this.0 = __this;
and __this is
unit size
eh, a bare FIELD_DECL?!
Store::updateChild(const T&) [with T = int]:: (const struct __lambda0
* const __closure)
{
struct Store * __this.0;
int & D.2050;
struct Store * const this [value-expr: ((const struct __lambda0 *)
__closure)->__this];
__this.0 = __this;
D.2050 = Store::getStore (__this.0);
possibly confused from this.
[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688
Eric Botcazou changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #3 from Eric Botcazou 2012-09-26
11:43:40 UTC ---
It's r191493, the transformation is applied to a %sp-based load, which is
invalid since the frame is destroyed, and the resulting offset is bogus:
In .split4:
(insn 52 41 43 4 (set (reg:SI 1 %g1 [orig:137 D.6097+8 ] [137])
(mem/c:SI (plus:SI (reg/f:SI 14 %sp)
(const_int 80 [0x50])) [23 D.6097+8 S4 A64]))
/home/eric/svn/gcc/gcc/ada/restrict.adb:1067 61 {*movsi_insn}
(expr_list:REG_EQUIV (mem/c:SI (plus:SI (reg/f:SI 14 %sp)
(const_int 80 [0x50])) [23 D.6097+8 S4 A64])
(nil)))
[...]
(note 60 43 61 4 NOTE_INSN_EPILOGUE_BEG)
(insn 61 60 62 4 (set (reg/f:SI 14 %sp)
(minus:SI (reg/f:SI 14 %sp)
(const_int -88 [0xffa8])))
/home/eric/svn/gcc/gcc/ada/restrict.adb:1068 183 {subsi3}
In .sched2:
(insn 61 64 52 4 (set (reg/f:SI 14 %sp)
(minus:SI (reg/f:SI 14 %sp)
(const_int -88 [0xffa8])))
/home/eric/svn/gcc/gcc/ada/restrict.adb:1068 183 {subsi3}
(nil))
(insn 52 61 43 4 (set (reg:SI 1 %g1 [orig:137 D.6097+8 ] [137])
(mem/c:SI (plus:SI (reg/f:SI 14 %sp)
(const_int 168 [0xa8])) [23 D.6097+8 S4 A64]))
/home/eric/svn/gcc/gcc/ada/restrict.adb:1067 61 {*movsi_insn}
(expr_list:REG_EQUIV (mem/c:SI (plus:SI (reg/f:SI 14 %sp)
(const_int 80 [0x50])) [23 D.6097+8 S4 A64])
(nil)))
[Bug fortran/54715] New: !$OMP SINGLE NOWAIT gives compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54715 Bug #: 54715 Summary: !$OMP SINGLE NOWAIT gives compiler error Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arn...@gmx.at Dear all, the following code produces a compiler error, although it should not: === program debug use omp_lib !$omp parallel !$omp single nowait write(*,*) 'bla' !$omp end single !$omp end parallel end program === Compiling: === $ gfortran -fopenmp -lgomp -o debug debug.f90 debug.f90:4.6: !$omp single nowait 1 Error: Unclassifiable OpenMP directive at (1) debug.f90:6.16: !$omp end single 1 Error: Unexpected !$OMP END SINGLE statement at (1) === Without the nowait everything works nicely. The same code (with nowait) works with C++ without any problems. I tried it on the following machines: 1.) Fedora 15 === $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.3/lto-wrapper Target: x86_64-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 --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --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_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC) === 2.) Debian (I think Wheezy) === $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.1-7' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.1 (Debian 4.7.1-7) === Best regards, Arno
[Bug lto/54709] [4.8 Regression] r191713 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54709 --- Comment #3 from Richard Guenther 2012-09-26 11:56:37 UTC --- Seems that doesn't work (yeah, the builtin defs issue ... bah). The following might (w/o reverting the previous change): Index: gcc/tree.h === --- gcc/tree.h (revision 191756) +++ gcc/tree.h (working copy) @@ -2617,7 +2617,7 @@ struct function; #define DECL_SOURCE_LINE(NODE) LOCATION_LINE (DECL_SOURCE_LOCATION (NODE)) #define DECL_SOURCE_COLUMN(NODE) LOCATION_COLUMN (DECL_SOURCE_LOCATION (NODE)) #define DECL_IS_BUILTIN(DECL) \ - (DECL_SOURCE_LOCATION (DECL) <= BUILTINS_LOCATION) + (LOCATION_LOCUS (DECL_SOURCE_LOCATION (DECL)) <= BUILTINS_LOCATION) /* For FIELD_DECLs, this is the RECORD_TYPE, UNION_TYPE, or QUAL_UNION_TYPE node that the field is a member of. For VAR_DECL,
[Bug fortran/54715] !$OMP SINGLE NOWAIT gives compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54715 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Jakub Jelinek 2012-09-26 12:32:56 UTC --- That is correct, what you are trying to compile is not valid OpenMP. You want !$omp single write(*,*) 'bla' !$omp end single nowait as in Fortran nowait is end_clause, not clause. See e.g. OpenMP 3.1, 2.5.3.
[Bug target/54716] New: Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716
Bug #: 54716
Summary: Select best typed instruction for bitwise operations
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Hello,
consider these 3 versions of OR:
#include
__m256d f(__m256d x,__m256d y){
return (__m256d)((__m256i)x|(__m256i)y);
}
__m256d g(__m256d x,__m256d y){
return _mm256_or_pd(x,y);
}
__m256i h(__m256i x,__m256i y){
return x|y;
}
With -mavx, they compile to vorps, vorpd, vorps.
With -mavx2, they compile to vpor, vorpd, vpor.
Functions g and h are fine, but for f (which is about the only way to write OR
using the C vector extensions, since | doesn't apply to floats) it would be
great to see vorpd in both cases.
[Bug lto/54709] [4.8 Regression] r191713 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54709 --- Comment #4 from Markus Trippelsdorf 2012-09-26 12:48:49 UTC --- (In reply to comment #3) > Seems that doesn't work (yeah, the builtin defs issue ... bah). The following > might (w/o reverting the previous change): > > Index: gcc/tree.h > === > --- gcc/tree.h (revision 191756) > +++ gcc/tree.h (working copy) > @@ -2617,7 +2617,7 @@ struct function; > #define DECL_SOURCE_LINE(NODE) LOCATION_LINE (DECL_SOURCE_LOCATION (NODE)) > #define DECL_SOURCE_COLUMN(NODE) LOCATION_COLUMN (DECL_SOURCE_LOCATION > (NODE)) > #define DECL_IS_BUILTIN(DECL) \ > - (DECL_SOURCE_LOCATION (DECL) <= BUILTINS_LOCATION) > + (LOCATION_LOCUS (DECL_SOURCE_LOCATION (DECL)) <= BUILTINS_LOCATION) > > /* For FIELD_DECLs, this is the RECORD_TYPE, UNION_TYPE, or > QUAL_UNION_TYPE node that the field is a member of. For VAR_DECL, Hmm, I've tested this one and it didn't fix this bug.
[Bug tree-optimization/54713] [4.8 Regression] error: non-trivial conversion at assignment in gcc.c-torture/compile/pr53410-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54713 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-09-26 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek 2012-09-26 12:51:45 UTC --- Created attachment 28280 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28280 gcc48-pr54713.patch Untested fix (with testcases that ICE even on x86_64).
[Bug c/54708] library must be placed after source for gcc to see it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54708 --- Comment #4 from Hubert 2012-09-26 12:52:49 UTC --- (In reply to comment #2) > This is not a bug as ubuntu uses --as-needed as the default. If this is ubuntu feature we would obtain the same results using gcc-4.4, whereas in this case the library can be placed either before or after source.
[Bug tree-optimization/54717] New: Runtime regression: polyhedron test "rnflow" degraded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717 Bug #: 54717 Summary: Runtime regression: polyhedron test "rnflow" degraded Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: sergos@gmail.com commit 024fee2c369096e6fe6cde620243df5843893004 Author: rguenth Date: Thu Sep 13 12:43:58 2012 + 2012-09-13 Richard Guenther * tree-ssa-sccvn.h (enum vn_kind): New. (vn_get_stmt_kind): Likewise. * tree-ssa-sccvn.c (vn_get_stmt_kind): New function, adjust ADDR_EXPR handling. (visit_use): Use it. * tree-ssa-pre.c (compute_avail): Likewise, simplify further. * gcc.dg/tree-ssa/ssa-fre-37.c: New testcase. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@191253 138bc75d-0d04-0410-961f-82ee72b054a4 caused a 20% degradation on polyhedron's "rnflow" commit 780bedc1ccae5ae85fb99afed8a1ac1cc598121b Geometric Mean Execution Time = 18.28 seconds commit 024fee2c369096e6fe6cde620243df5843893004 Geometric Mean Execution Time = 24.82 seconds compilation options used: gfortran -march=native -ffast-math -funroll-loops -O3 -ftree-vectorize %n.f90 -static -o %n
[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688 Rainer Orth changed: What|Removed |Added Target|sparc64-linux |sparc64-linux, ||sparc*-*-solaris2* CC||ro at gcc dot gnu.org --- Comment #4 from Rainer Orth 2012-09-26 12:56:37 UTC --- Same on Solaris/SPARC.
[Bug bootstrap/54718] New: [4.8 regression] ICE in remap_gimple_stmt, at tree-inline.c:1468
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54718 Bug #: 54718 Summary: [4.8 regression] ICE in remap_gimple_stmt, at tree-inline.c:1468 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: de...@gcc.gnu.org, ebotca...@gcc.gnu.org Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 Since 20120921 (r191613), go fails to bootstrap on Solaris 11.1/SPARC: /vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/expressions.cc: In member function 'virtual bool Type_conversion_expression::_ZNK26Type_conversion_expression24do_string_constant_valueEPSs.part.172(std::string*) const': /vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/expressions.cc:14226:1: internal compiler error: in remap_gimple_stmt, at tree-inline.c:1468 } ^ The failure can be reproduced with the attached expression.ii like this: cc1plus -fpreprocessed expressions.ii -quiet -mcpu=v9 -g -gtoggle -O2 -fno-exceptions -fno-rtti -fno-common -o expressions.s A reghunt revealed that this was caused by the following patch: The first bad revision is: changeset: 3438:f36a4197405d user:dehao@138bc75d-0d04-0410-961f-82ee72b054a4 date:Wed Sep 19 19:56:42 2012 + summary: Integrate lexical block into source_location. 2012-09-19 Dehao Chen * toplev.c (general_init): Init block_locations. [...] The strange thing is that the failure only occurs on Solaris 11.1, not 11.0 or 10, but can be reliably reproduced on the former. Maybe related to the VM system rewrite in 11.1 in some way? Rainer
[Bug bootstrap/54718] [4.8 regression] ICE in remap_gimple_stmt, at tree-inline.c:1468
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54718 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug bootstrap/54718] [4.8 regression] ICE in remap_gimple_stmt, at tree-inline.c:1468
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54718 --- Comment #1 from Rainer Orth 2012-09-26 13:06:56 UTC --- Created attachment 28281 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28281 preprocessed input file
[Bug lto/54709] [4.8 Regression] r191713 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54709
--- Comment #5 from Richard Guenther 2012-09-26
13:11:14 UTC ---
Ok, this bug won't be fixed and I'm not sure the reduced testcase handling is
a bug. With
void * memcpy (void *, void *, long);
bar ()
{
memcpy (0, 1, 1);
}
and -fvisibility=hidden the C frontend marks the memcpy builtin as having
hidden visibility (bug?). Then at LTRANS time we fail to "merge" it
with the implicit declaration of memcpy from the other TU (which didn't
get hidden visibility - bug?), so this unmerged declaration gets output
via default_elf_asm_output_external which emits (bug?)
.hidden memcpy
and the link fails.
In the TU that does not declare memcpy the memcpy is expanded inline.
With
void foo (void *p, void *q, unsigned s)
{
__builtin_memcpy (p, q, s);
}
---
void * memcpy (void *, void *, long);
void bar (void *p, void *q, unsigned s)
{
memcpy (p, q, s);
}
both calls remain (undefined, .hidden is still emitted), no warnings.
[Bug c++/54648] constexpr function rejected as non const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54648 --- Comment #2 from Leonid Volnitsky 2012-09-26 13:16:16 UTC --- Found bad commit. Quick recap: GCC says that expression sizeof()==1 is not constexpr. Commit is about template aliases and they are used in expression. Bad commit (as reported by git): 6423a93273627b3d1ff3a799d23baa7eae6e6cc9 is the first bad commit commit 6423a93273627b3d1ff3a799d23baa7eae6e6cc9 Author: jason Date: Tue Sep 18 03:47:35 2012 + PR c++/54575 * pt.c (instantiate_alias_template): New. (tsubst): Use it. (push_access_scope): Allow TYPE_DECL. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@191412 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 51d12d90281f31fa13167d674af17c710145c900 0f9f175917aa843c713a0415f542801bc391f0e0 M gcc
[Bug tree-optimization/54717] Runtime regression: polyhedron test "rnflow" degraded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717 Uros Bizjak changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||ubizjak at gmail dot com --- Comment #1 from Uros Bizjak 2012-09-26 13:17:15 UTC --- Adding CCs.
[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688
--- Comment #5 from Bernd Schmidt 2012-09-26
13:18:41 UTC ---
(In reply to comment #3)
> It's r191493, the transformation is applied to a %sp-based load, which is
> invalid since the frame is destroyed, and the resulting offset is bogus:
>
> In .split4:
>
> (insn 52 41 43 4 (set (reg:SI 1 %g1 [orig:137 D.6097+8 ] [137])
> (mem/c:SI (plus:SI (reg/f:SI 14 %sp)
> (const_int 80 [0x50])) [23 D.6097+8 S4 A64]))
> /home/eric/svn/gcc/gcc/ada/restrict.adb:1067 61 {*movsi_insn}
> (expr_list:REG_EQUIV (mem/c:SI (plus:SI (reg/f:SI 14 %sp)
> (const_int 80 [0x50])) [23 D.6097+8 S4 A64])
> (nil)))
>
> [...]
> (note 60 43 61 4 NOTE_INSN_EPILOGUE_BEG)
>
> (insn 61 60 62 4 (set (reg/f:SI 14 %sp)
> (minus:SI (reg/f:SI 14 %sp)
> (const_int -88 [0xffa8])))
> /home/eric/svn/gcc/gcc/ada/restrict.adb:1068 183 {subsi3}
>
> In .sched2:
>
> (insn 61 64 52 4 (set (reg/f:SI 14 %sp)
> (minus:SI (reg/f:SI 14 %sp)
> (const_int -88 [0xffa8])))
> /home/eric/svn/gcc/gcc/ada/restrict.adb:1068 183 {subsi3}
> (nil))
>
> (insn 52 61 43 4 (set (reg:SI 1 %g1 [orig:137 D.6097+8 ] [137])
> (mem/c:SI (plus:SI (reg/f:SI 14 %sp)
> (const_int 168 [0xa8])) [23 D.6097+8 S4 A64]))
> /home/eric/svn/gcc/gcc/ada/restrict.adb:1067 61 {*movsi_insn}
> (expr_list:REG_EQUIV (mem/c:SI (plus:SI (reg/f:SI 14 %sp)
> (const_int 80 [0x50])) [23 D.6097+8 S4 A64])
> (nil)))
I admit I don't quite see yet why this would be invalid (assuming that the
stack grows from high address to low ones). What do you mean by "the frame is
destroyed", is there something special about sparc?
[Bug fortran/54715] !$OMP SINGLE NOWAIT gives compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54715 --- Comment #2 from Arno M 2012-09-26 13:23:48 UTC --- Ah that's where the mistake is coming from. Thank you for your help.
[Bug lto/54709] [4.8 Regression] r191713 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54709 --- Comment #6 from Markus Trippelsdorf 2012-09-26 13:28:48 UTC --- (In reply to comment #5) > Ok, this bug won't be fixed and I'm not sure the reduced testcase handling is > a bug. It also only happens with -O0. Now -flto and -O0 are not commonly used together, so I think this bug isn't this important.
[Bug lto/54709] [4.8 Regression] r191713 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54709
Richard Guenther changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #7 from Richard Guenther 2012-09-26
13:33:07 UTC ---
For non-LTO binds_local_p says no to memcpy, for LTO it says yes.
else if (TREE_CODE (exp) == FUNCTION_DECL && TREE_PUBLIC (exp))
{
struct cgraph_node *node = cgraph_get_node (exp);
if (node
&& resolution_local_p (node->symbol.resolution))
resolved_locally = true;
makes the difference because we have a resolution recorded (resoved_ir) and
that makes us skip
/* Variables defined outside this object might not be local. */
else if (DECL_EXTERNAL (exp) && !resolved_locally)
local_p = false;
and fall into
/* If defined in this object and visibility is not default, must be
local. */
else if (DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT)
local_p = true;
which says "defined in this object" but doesn't check that (well,
the resolution is wrong).
The resolutions from the linker are just
2
t1.o 1
165 beb4fef7e77e8790 PREVAILING_DEF_IRONLY foo
t2.o 1
165 6eae315f149cc09b PREVAILING_DEF_IRONLY bar
but lto_symtab_resolve_symbols assigns LDPR_RESOLVED_IR :(
[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688 --- Comment #6 from Eric Botcazou 2012-09-26 13:37:25 UTC --- > I admit I don't quite see yet why this would be invalid (assuming that the > stack grows from high address to low ones). What do you mean by "the frame is > destroyed", is there something special about sparc? We go from g1 <- [sp+80] sp <- sp + 88 to sp <- sp + 88 g1 <- [sp + 168] so there is a double issue: the frame is destroyed after the %sp bump and the new offset is bogus (it should be -8). And the REG_EQUIV note isn't updated.
[Bug lto/54709] [4.8 Regression] r191713 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54709 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek 2012-09-26 13:38:51 UTC --- If you have a memcpy prototype and -fvisibility-hidden, without any pragmas around the prototype tweaking the visibility, then this is IMHO a user bug, as he promises then that memcpy is defined in the current shared library. To use -fvisibility-hidden with standard headers, one needs to surround them with pragmas.
[Bug target/54716] Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-26 CC||jakub at gcc dot gnu.org, ||rth at gcc dot gnu.org, ||uros at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/54716] Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716
--- Comment #1 from Jakub Jelinek 2012-09-26
13:46:25 UTC ---
Created attachment 28282
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28282
gcc48-pr54716.patch
Untested patch to optimize this.
Unfortunately it will also change generated code for:
__m256d
i (__m256d x, __m256d y)
{
return (__m256d) _mm256_or_si256 ((__m256i) x, (__m256i) y);
}
Not sure if that is an issue or not. If we wanted to emit what the user for
whatever reason asked for, the builtin expander could perhaps in those cases
copy one of the arguments into a temporary pseudo before expansion.
[Bug middle-end/54635] Add addr_space_t argument to TARGET_MODE_DEPENDENT_ADDRESS_P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54635 --- Comment #1 from Georg-Johann Lay 2012-09-26 13:46:36 UTC --- Author: gjl Date: Wed Sep 26 13:46:29 2012 New Revision: 191761 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191761 Log: PR middle-end/54635 * doc/tm.texi.in (TARGET_MODE_DEPENDENT_ADDRESS_P): Document new parameter addrspace. * doc/tm.texi: Regenerate. * target.def (mode_dependent_address_p): Add addr_space_t parameter. * targhooks.h (default_mode_dependent_address_p): Ditto. * targhooks.c (default_mode_dependent_address_p): Ditto. * expr.c (convert_move): Pass address space to mode_dependent_address_p. * combine.c (combine_simplify_rtx): Ditto. (make_extraction): Ditto. (simplify_shift_const_1): Ditto. (gen_lowpart_for_combine): Ditto. * lower-subreg.c (simple_move_operand): Ditto. * recog.c (simplify_while_replacing): Ditto. (offsettable_address_addr_space_p): Ditto. (mode_dependent_address_p): Ditto. * simplify-rtx.c (simplify_unary_operation_1): Ditto. (simplify_subreg): Ditto. * config/m68k/m68k.md: Ditto. * config/vax/vax.md: Ditto. * config/vax/constraints.md (Q): Ditto. * config/vax/predicates.md (indexed_memory_operand): Ditto. * config/alpha/alpha.c (alpha_mode_dependent_address_p): Add unused addr_space_t parameter. * config/avr/avr.c (avr_mode_dependent_address_p): Ditto. * config/h8300/h8300.c (h8300_mode_dependent_address_p): Ditto. * config/m32r/m32r.c (m32r_mode_dependent_address_p): Ditto. * config/rs6000/rs6000.c (rs6000_mode_dependent_address_p): Ditto. * config/rx/rx.c (rx_mode_dependent_address_p): Ditto. * config/sparc/sparc.c (sparc_mode_dependent_address_p): Ditto. * config/stormy16/stormy16.c (xstormy16_mode_dependent_address_p): Ditto. * config/vax/vax.c (vax_mode_dependent_address_p): Ditto. * config/xtensa/xtensa.c (xtensa_mode_dependent_address_p): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/config/alpha/alpha.c trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md trunk/gcc/config/h8300/h8300.c trunk/gcc/config/m32r/m32r.c trunk/gcc/config/m68k/m68k.md trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rx/rx.c trunk/gcc/config/sparc/sparc.c trunk/gcc/config/stormy16/stormy16.c trunk/gcc/config/vax/constraints.md trunk/gcc/config/vax/predicates.md trunk/gcc/config/vax/vax.c trunk/gcc/config/vax/vax.md trunk/gcc/config/xtensa/xtensa.c trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/expr.c trunk/gcc/lower-subreg.c trunk/gcc/recog.c trunk/gcc/recog.h trunk/gcc/simplify-rtx.c trunk/gcc/target.def trunk/gcc/targhooks.c trunk/gcc/targhooks.h
[Bug lto/54709] [4.8 Regression] r191713 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54709
--- Comment #9 from Richard Guenther 2012-09-26
13:47:02 UTC ---
Index: gcc/lto-symtab.c
===
--- gcc/lto-symtab.c(revision 191756)
+++ gcc/lto-symtab.c(working copy)
@@ -326,11 +326,7 @@ lto_symtab_resolve_symbols (symtab_node
for (e = first; e; e = e->symbol.next_sharing_asm_name)
{
if (!lto_symtab_resolve_can_prevail_p (e))
- {
- e->symbol.resolution = LDPR_RESOLVED_IR;
- set_resolution_guessed (e, true);
- continue;
- }
+ continue;
/* Set a default resolution - the final prevailing one will get
adjusted later. */
@@ -387,9 +383,25 @@ lto_symtab_resolve_symbols (symtab_node
}
if (!prevailing)
-return;
+{
+ /* There was no prevailing definition - adjust the symbol resolutions
+ according to that. */
+ for (e = first; e; e = e->symbol.next_sharing_asm_name)
+ e->symbol.resolution = LDPR_UNDEF;
+ return;
+}
found:
+ /* We found a prevailing definition - adjust the pre-empted symbols
+ resolutions. */
+ for (e = first; e; e = e->symbol.next_sharing_asm_name)
+{
+ if (!lto_symtab_resolve_can_prevail_p (e))
+ {
+ e->symbol.resolution = LDPR_RESOLVED_IR;
+ set_resolution_guessed (e, true);
+ }
+}
/* If current lto files represent the whole program,
it is correct to use LDPR_PREVALING_DEF_IRONLY.
If current lto files are part of whole program, internal
fixes the testcase for me.
[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688 --- Comment #7 from Bernd Schmidt 2012-09-26 13:50:06 UTC --- Oh, I missed that it was a MINUS rtx. This is noncanonical RTL, it should be (plus (sp) (negated constant)). Does the bug persist if you fix the sparc port in this way?
[Bug middle-end/54635] Add addr_space_t argument to TARGET_MODE_DEPENDENT_ADDRESS_P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54635 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Georg-Johann Lay 2012-09-26 13:51:12 UTC --- Done
[Bug bootstrap/54719] New: Bootstrap stuck in stage1 with message "checking for compiler with PCH support"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54719 Bug #: 54719 Summary: Bootstrap stuck in stage1 with message "checking for compiler with PCH support" Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: do...@gcc.gnu.org Bootstrap fails when running with MALLOC_CHECK_=3. The configure (actually config.log) of stage 1 in x86_64-unknown-linux-gnu/libstdc++-v3 says: configure:15104: checking for compiler with PCH support And it gets stuck there for ever. It seems like the PCH support is broken somehow. To reproduce: $ cat conftest.h: >8<-- extern int foo(); >8<-- $ cat conftest.cc: >8<-- #include "conftest.h" >8<-- $ export MALLOC_CHECK_=3 $ cc1plus -quiet conftest.h --output-pch=conftest.h.gch $ cc1plus -quiet conftest.cc The last command hangs for ever. gdb says: Program received signal SIGSEGV, Segmentation fault. 0x00306e07a30a in mem2chunk_check () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.15-56.fc17.x86_64 gmp-5.0.2-6.fc17.x86_64 libgcc-4.7.0-5.fc17.x86_64 libmpc-0.9-2.fc17.2.x86_64 libstdc++-4.7.0-5.fc17.x86_64 mpfr-3.1.0-2.fc17.x86_64 (gdb) bt #0 0x00306e07a30a in mem2chunk_check () from /lib64/libc.so.6 #1 0x00306e07e276 in free_check () from /lib64/libc.so.6 #2 0x01238d31 in location_adhoc_data_fini (set=0x1000176000) at /home/dodji/devel/git/gcc/bootstrap/libcpp/line-map.c:164 #3 0x00bcc803 in toplev_main (argc=4, argv=0x7fffe398) at /home/dodji/devel/git/gcc/bootstrap/gcc/toplev.c:1949 #4 0x0120b348 in main (argc=4, argv=0x7fffe398) at /home/dodji/devel/git/gcc/bootstrap/gcc/main.c:36 (gdb) The issues is that after loading the pch file, toplev_main invokes location_adhoc_data_fini which tries to free stuff in the location_adhoc_data_map member of the instance of line_maps. But these pointers have been 're-set' by the loading the pch file, in c_common_write_pch, AFAIU. And that triggers a sigsev, and then the process hangs. If that data is to be saved to disk as part of the PCH, why isn't it allocated in GCC memory? The other issue I don't quite understand is, why is the process hanging instead of just exiting after the sigsev?
[Bug bootstrap/54718] [4.8 regression] ICE in remap_gimple_stmt, at tree-inline.c:1468
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54718 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-09-26 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-09-26 13:54:35 UTC --- This means we have a stale gimple_block that is no longer contained in the BLOCK tree (DECL_INITIAL of the function inlined). Probably caused by remove_unused_block_scopes. Does the preprocessed source trigger the bug on all Solaris cc1plus'en? (it seems to work on x86_64). What's the last bad revision you tested?
[Bug target/43550] arm missing rev16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43550 christophe.lyon at st dot com changed: What|Removed |Added CC||christophe.lyon at st dot ||com --- Comment #1 from christophe.lyon at st dot com 2012-09-26 13:55:12 UTC --- Fixed in trunk, rev #191760.
[Bug target/54716] Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716 --- Comment #2 from Uros Bizjak 2012-09-26 13:55:28 UTC --- (In reply to comment #1) > Created attachment 28282 [details] > gcc48-pr54716.patch Does this patch also fix xfail in gcc.target/i386/xorps-sse2.c? IIRC, we generated correct instructions for float arguments, but deliberatly removed this functionality for some reason. I tried to look for the reason in the SVN history, but didn't found anything relevant.
[Bug bootstrap/54718] [4.8 regression] ICE in remap_gimple_stmt, at tree-inline.c:1468
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54718 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-09-26 13:58:58 UTC --- > --- Comment #2 from Richard Guenther 2012-09-26 > 13:54:35 UTC --- > This means we have a stale gimple_block that is no longer contained in the > BLOCK tree (DECL_INITIAL of the function inlined). Probably caused by > remove_unused_block_scopes. > > Does the preprocessed source trigger the bug on all Solaris cc1plus'en? No, only Solaris/SPARC 11.1, which let me suspect it could be related to the VM system rewrite, which can change the details of address space layout. > (it seems to work on x86_64). Right. > What's the last bad revision you tested? I don't have the build handy since I did a bootstrap without Go afterwards, but I'm pretty sure it still failed in r191695. Rainer
[Bug target/54716] Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716 --- Comment #3 from Uros Bizjak 2012-09-26 14:01:13 UTC --- Maybe also relevant: [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01546.html
[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688 --- Comment #8 from Eric Botcazou 2012-09-26 14:03:24 UTC --- > Oh, I missed that it was a MINUS rtx. This is noncanonical RTL, it should be > (plus (sp) (negated constant)). > > Does the bug persist if you fix the sparc port in this way? I'm not sure we want to change the SPARC port (this form is used because of the larger offset range). In any case, non-canonical RTL shouldn't result in wrong code, only in missed optimization.
[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688 --- Comment #9 from Bernd Schmidt 2012-09-26 14:13:31 UTC --- Created attachment 28283 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28283 Candidate patch. The offset range should not be an issue with the right constraints etc.; the port really ought to be changed. In the meantime, please try this patch.
[Bug lto/54709] [4.8 Regression] r191713 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54709 --- Comment #10 from Richard Guenther 2012-09-26 14:14:52 UTC --- Created attachment 28284 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28284 patch I am testing this.
[Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test "rnflow" degraded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-26 Target Milestone|--- |4.8.0 Summary|Runtime regression: |[4.8 Regression] Runtime |polyhedron test "rnflow"|regression: polyhedron test |degraded|"rnflow" degraded Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-09-26 14:17:04 UTC --- What's "-march=native" to you? Any help in reduction appreciated.
[Bug target/54716] Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716 Uros Bizjak changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #4 from Uros Bizjak 2012-09-26 14:19:35 UTC --- Based on claim in [1], AMD chips do not care at all, so we use *ps variants which are one byte shorter. Let's ask HJ about Intel. [1] http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01564.html
[Bug target/54716] Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716 --- Comment #5 from Jakub Jelinek 2012-09-26 14:23:29 UTC --- (In reply to comment #2) > (In reply to comment #1) > > Created attachment 28282 [details] > > gcc48-pr54716.patch > > Does this patch also fix xfail in gcc.target/i386/xorps-sse2.c? > > IIRC, we generated correct instructions for float arguments, but deliberatly > removed this functionality for some reason. I tried to look for the reason in > the SVN history, but didn't found anything relevant. It doesn't, the optimization is keyed there on the casts from vector float on both operands, not on the cast of results. And on that testcase one of the arguments is not a SUBREG from the floating vector. I think doing the optimization is questionable if both operands aren't float vectors, because then we could very well pessimize the generated code instead of improving it. If both are float vectors, then most likely we'll get rid of two reinterpretation penalties and perhaps worst case add one on the result. To fix up xorps-sse2.c, we could tweak the expander's predicates, from nonimmediate_operand to say "", and we could handle CONST_VECTOR as any kind of load for the purpose of the test, then of course force to register if not nonimmediate_operand.
[Bug lto/54709] [4.8 Regression] r191713 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54709 Richard Guenther changed: What|Removed |Added Attachment #28284|0 |1 is obsolete|| --- Comment #11 from Richard Guenther 2012-09-26 14:25:08 UTC --- Created attachment 28285 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28285 new patch Even better.
[Bug bootstrap/54719] Bootstrap stuck in stage1 with message "checking for compiler with PCH support"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54719 --- Comment #1 from Dehao Chen 2012-09-26 14:25:25 UTC --- Hi, Dodji, Could you help verify if this problem is solved by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191706 ? If yes, then it should be a duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645 Thanks, Dehao
[Bug bootstrap/54719] Bootstrap stuck in stage1 with message "checking for compiler with PCH support"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54719 --- Comment #2 from dodji at seketeli dot org 2012-09-26 14:41:43 UTC --- "dehao at google dot com" a écrit: > Could you help verify if this problem is solved by > > http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191706 ? If yes, then it > > should be a duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645 Yes it is fixed now. Sorry for not realizing that earlier. Thank you.
[Bug target/54716] Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716 Jakub Jelinek changed: What|Removed |Added Attachment #28282|0 |1 is obsolete|| --- Comment #6 from Jakub Jelinek 2012-09-26 14:57:15 UTC --- Created attachment 28286 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28286 gcc48-pr54716.patch Updated patch that fixes also xorps-sse2.c.
[Bug web/54711] Fix --target_board examples on test.html page
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54711
--- Comment #2 from Steve Ellcey 2012-09-26 15:10:21
UTC ---
Yes, RUNTESTFLAGS="--target_board=unix/\{-m32,\}" works fine but
RUNTESTFLAGS="--target_board=unix --target_board=unix/-m32" does not.
It should be RUNTESTFLAGS="--target_board='unix unix/-m32'".
I do not mind fixing it myself but I am not sure where the sources
for the web pages are. Are they in the GCC source tree somewhere?
I didn't see them. Should changes to the pages be sent to the
gcc-patches mailing list?
[Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test "rnflow" degraded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717 --- Comment #3 from Sergey Ostanevich 2012-09-26 15:11:38 UTC --- adding -### gives (in part of options) /export/users/syostane/pb11/gcc120914/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/f951 air.f90 "-march=corei7" -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx --param "l1-cache-size=32" --param "l1-cache-line-size=64" --param "l2-cache-size=12288" "-mtune=corei7" -quiet -dumpbase air.f90 -auxbase air -fintrinsic-modules-path /export/users/syostane/pb11/gcc120914/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/finclude -o /tmp/ccmW82c1.s
[Bug web/54711] Fix --target_board examples on test.html page
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54711 Hans-Peter Nilsson changed: What|Removed |Added CC||gerald at gcc dot gnu.org, ||hp at gcc dot gnu.org --- Comment #3 from Hans-Peter Nilsson 2012-09-26 15:21:24 UTC --- (In reply to comment #2) > I am not sure where the sources > for the web pages are. Are they in the GCC source tree somewhere? > I didn't see them. Weird, IIRC instructions used to be on the write-access page. Gerald? > Should changes to the pages be sent to the > gcc-patches mailing list? yes...
[Bug target/49423] [4.6/4.7/4.8 Regression] [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #15 from Dinar Temirbulatov 2012-09-26 15:38:33 UTC --- here is command and flags to reproduce the second testcase on 4.6 and 4.7 : cc1plus -mcpu=cortex-a15 -mfpu=neon -mfloat-abi=hard -ftree-vectorize -O3 cr_parse-reduced-fsf.ii -o /tmp/1.s
[Bug target/54716] Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716
--- Comment #7 from Jakub Jelinek 2012-09-26
15:40:53 UTC ---
On
#define vector __attribute__ ((vector_size (16)))
__attribute__((noinline, noclone))
vector float foo(vector float f, vector float h)
{
vector int g = { 0x8000, 0, 0x8000, 0 };
vector int f_int = (vector int) f;
return ((vector float) (f_int ^ g)) + h;
}
vector float a = { 1.0, 2.0, 3.0, 4.0 }, b = { 5.0, 6.0, 7.0, 8.0 }, c = { 9.0,
10.0, 11.0, 12.0 }, r;
int
main ()
{
int i;
for (i = 0; i < 10; i++)
{
asm volatile ("" : : : "memory");
r = foo(a + b, a + c) - a;
asm volatile ("" : : : "memory");
}
return 0;
}
I haven't noticed a measurable performance difference though on Intel SNB 2600
CPU though, so perhaps the patch isn't needed.
[Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test "rnflow" degraded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717 --- Comment #4 from Dominique d'Humieres 2012-09-26 15:41:05 UTC --- The slowdown is mostly hidden by -fno-tree-loop-if-convert.
[Bug target/54716] Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716 --- Comment #8 from Marc Glisse 2012-09-26 15:53:00 UTC --- (In reply to comment #7) > I haven't noticed a measurable performance difference though on Intel SNB 2600 > CPU though, so perhaps the patch isn't needed. Ah, I assumed they had a good reason for creating so many variants of the same instruction. If there is no difference (or even a difference in the wrong direction because of the instruction size), feel free to close the bug.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #85 from Mikael Morin 2012-09-26 16:06:59 UTC --- (In reply to comment #84) > (In reply to comment #83) > > any progress on this one? > > Well, the patch at http://gcc.gnu.org/ml/fortran/2012-08/msg00150.html solves > several issues, but it still has issues, cf. > http://gcc.gnu.org/ml/fortran/2012-08/msg00176.html And some of the remaining issues are not present on trunk, so the patch is not a complete improvement. I'm not actively working on this (nor anything else actually) any more.
[Bug testsuite/54622] gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 jules at gcc dot gnu.org changed: What|Removed |Added CC||jules at gcc dot gnu.org --- Comment #5 from jules at gcc dot gnu.org 2012-09-26 16:25:08 UTC --- Unfortunately (due to the reasons Richard outlined) lots of things don't work wrt. vectorization for Neon in big-endian mode, so are deliberately disabled in the backend. IMO, the right thing to do (at least until that is fixed) is to make the effective-target checks for vectorization features depend on little-endian ARM mode.
[Bug testsuite/54622] gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 --- Comment #6 from Janis Johnson 2012-09-26 16:45:25 UTC --- It's important to continue to run the vectorization tests with ARM big-endian to detect regressions in the execution tests, so I don't want to exclude it from all vect effective targets. I'll propose a set of effective targets used in the scans that should exclude ARM big-endian.
[Bug tree-optimization/54674] [4.8 Regression] ICE in build2_stat, at tree.c:3835
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674 --- Comment #11 from William J. Schmidt 2012-09-26 16:49:45 UTC --- Author: wschmidt Date: Wed Sep 26 16:49:32 2012 New Revision: 191765 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191765 Log: 2012-09-26 Bill Schmidt PR tree-optimization/54674 * gimple-ssa-strength-reduction.c (analyze_increments): Don't introduce a multiplication with a pointer operand. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-strength-reduction.c
[Bug tree-optimization/54674] [4.8 Regression] ICE in build2_stat, at tree.c:3835
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674 William J. Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from William J. Schmidt 2012-09-26 16:53:15 UTC --- Fixed.
[Bug preprocessor/54694] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694 --- Comment #4 from Toralf Förster 2012-09-26 17:18:53 UTC --- Created attachment 28287 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28287 cc -E -v attached the output of n22 /var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/i386-softmmu # i686-pc-linux-gnu-gcc -I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/slirp -I. -I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1 -I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/fpu -I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/linux-headers -I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/tcg -I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/tcg/i386 -fPIE -DPIE -m32 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -I/usr/include/libpng15 -DHAS_AUDIO -DHAS_AUDIO_CHOICE -DTARGET_PHYS_ADDR_BITS=64 -I../linux-headers -I.. -I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/target-i386 -DNEED_CPU_H -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/include -I/usr/include/libpng15 -fomit-frame-pointer -MMD -MP -MT op_helper.o -MF ./op_helper.d -O2 -O2 -march=native -pipe -c -v -E -o op_helper.o /var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/target-i386/op_helper.c Using built-in specs. COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.6.3/i686-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/lto-wrapper Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.6.3 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.6.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.6.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.6.3/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.6.3/python --enable-checking=release --disable-libgcj --with-arch=i686 --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 p1.6, pie-0.5.2' Thread model: posix gcc version 4.6.3 (Gentoo 4.6.3 p1.6, pie-0.5.2) COLLECT_GCC_OPTIONS='-I' '/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/slirp' '-I' '.' '-I' '/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1' '-I' '/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/fpu' '-I' '/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/linux-headers' '-I' '/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/tcg' '-I' '/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/tcg/i386' '-fPIE' '-DPIE' '-m32' '-D_FORTIFY_SOURCE=2' '-D_GNU_SOURCE' '-D_FILE_OFFSET_BITS=64' '-D_LARGEFILE_SOURCE' '-Wstrict-prototypes' '-Wredundant-decls' '-Wall' '-Wundef' '-Wwrite-strings' '-Wmissing-prototypes' '-fno-strict-aliasing' '-fstack-protector-all' '-Wendif-labels' '-Wmissing-include-dirs' '-Wempty-body' '-Wnested-externs' '-Wformat-security' '-Wformat-y2k' '-Winit-self' '-Wignored-qualifiers' '-Wold-style-declaration' '-Wold-style-definition' '-Wtype-limits' '-I' '/usr/include/libpng15' '-DHAS_AUDIO' '-DHAS_AUDIO_CHOICE' '-DTARGET_PHYS_ADDR_BITS=64' '-I' '../linux-headers' '-I' '..' '-I' '/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/target-i386' '-DNEED_CPU_H' '-pthread' '-I' '/usr/include/glib-2.0' '-I' '/usr/lib/glib-2.0/include' '-I' '/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/include' '-I' '/usr/include/libpng15' '-fomit-frame-pointer' '-MMD' '-MP' '-MT' 'op_helper.o' '-MF' './op_helper.d' '-O2' '-O2' '-march=native' '-pipe' '-c' '-v' '-E' '-o' 'op_helper.o' /usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/cc1 -E -quiet -v -I /var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/slirp -I . -I /var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1 -I /var/tmp/portage/app-emulation/qemu-
[Bug web/54711] Fix --target_board examples on test.html page
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54711 --- Comment #4 from Andrew Pinski 2012-09-26 17:53:48 UTC --- (In reply to comment #3) > (In reply to comment #2) > > I am not sure where the sources > > for the web pages are. Are they in the GCC source tree somewhere? > > I didn't see them. > > Weird, IIRC instructions used to be on the write-access page. > Gerald? They are on the cvs.html page: http://gcc.gnu.org/cvs.html I don't know if they are linked from anywhere though.
[Bug preprocessor/54694] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #5 from Markus Trippelsdorf
2012-09-26 17:58:44 UTC ---
gcc-4.7 and 4.8 are also affected.
Reduced:
markus@x4 tmp % cat test.i
typedef struct
{
}
floatx80;
register struct CPUX86State *env asm ("ebp");
floatx80 float64_to_floatx80 (int, int);
typedef struct
{
floatx80 d;
}
FPReg;
struct CPUX86State
{
FPReg fpregs[0];
};
void
helper_fldl_ST0 ()
{
env->fpregs[0].d = float64_to_floatx80 (0, 0);
}
markus@x4 tmp % gcc -mavx -m32 -c test.i
test.i: In function ‘helper_fldl_ST0’:
test.i:20:1: internal compiler error: in dwarf2out_frame_debug_expr, at
dwarf2out.c:2387
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug web/54711] Fix --target_board examples on test.html page
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54711 --- Comment #5 from Steve Ellcey 2012-09-26 18:18:05 UTC --- OK, I can check out wwwdocs but the page I am interested in doesn't seem to be there. On the web it is http://gcc.gnu.org/install/test.html, but I can't seem to find this page in a checked out version of wwwdocs. I did get an htdocs/install directory but it does not include any files (other than CVS and .cvsignore).
[Bug web/54711] Fix --target_board examples on test.html page
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54711 --- Comment #6 from Andrew Pinski 2012-09-26 18:20:04 UTC --- (In reply to comment #5) > OK, I can check out wwwdocs but the page I am interested in doesn't seem to be > there. On the web it is http://gcc.gnu.org/install/test.html, but I can't > seem > to find this page in a checked out version of wwwdocs. I did get an > htdocs/install directory but it does not include any files (other than CVS and > .cvsignore). That is generated from gcc/docs/install.texi in svn.
[Bug libstdc++/54102] generated html vs. utf8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54102 Benjamin Kosnik changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Benjamin Kosnik 2012-09-26 18:38:50 UTC --- Fixed in trunk, 4.7.3
[Bug libstdc++/54172] [4.7 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 Benjamin Kosnik changed: What|Removed |Added Status|NEW |RESOLVED CC||bkoz at gcc dot gnu.org Resolution||FIXED Target Milestone|4.7.3 |4.7.2 --- Comment #19 from Benjamin Kosnik 2012-09-26 18:40:33 UTC --- Fixed in trunk and 4.7.2.
[Bug c++/54383] Internal compiler error for lamba function using this-> with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54383 --- Comment #2 from 166291 at gmail dot com 2012-09-26 18:45:36 UTC --- Some more information is that this only seems to happen when the lambda captures variables, and it's in the global scope.
[Bug c++/54710] moderately large tuple, with many gets, ballons compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 --- Comment #5 from Larry Evans 2012-09-26 19:01:30 UTC --- (In reply to comment #4) > That: > > --enable-checking=assert,misc,tree,gc,rtl,runtime > > will enable very compile-time intensive internal checking. Use > --enable-checking=release or at most the default checking options > (which are "yes"). If you compare with other compilers always use > release checking. Thanks Richard. I've downloaded: ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120923/gcc-4.8-20120923.tar.bz2 and configured with --enable-checking=release. As a result, the gcc times to improve a lot; however, there's still the degredation of the time w.r.t. clang and the macro, LAST_LESS approaches TUPLE_SIZE: LAST_LESS gcc/clang times - --- 4 0.28 16 1.15 20 1.70 Certainly 1.70 is much better than 3.34. A new .zip file is attached. I don't know if this indicates there's still a problem. -regards, Larry
[Bug c++/54710] moderately large tuple, with many gets, ballons compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 Larry Evans changed: What|Removed |Added Attachment #28274|0 |1 is obsolete|| --- Comment #6 from Larry Evans 2012-09-26 19:04:14 UTC --- Created attachment 28288 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28288 newer gcc with --enable-checking=release still shows relative performance degradation wrt clang
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
Benjamin Kosnik changed:
What|Removed |Added
CC||bkoz at gcc dot gnu.org
--- Comment #13 from Benjamin Kosnik 2012-09-26
19:06:12 UTC ---
Hey P, I think you mean:
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
b/libstdc++-v3/config/abi/pre/g
index 5265b21..396feec 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1322,6 +1322,7 @@ GLIBCXX_3.4.17 {
} GLIBCXX_3.4.16;
GLIBCXX_3.4.18 {
+
global:
# Names inside the 'extern' block are demangled names.
@@ -1330,6 +1331,9 @@ GLIBCXX_3.4.18 {
std::random_device::*;
};
+# construction vtable
+_ZTCSt*;
+
} GLIBCXX_3.4.17;
# Symbols in the support library (libsupc++) have their own tag.
ie, not in CXXABI for std:: non-support things.
This is an interesting thread thanks for the info Kai, very informative. The
analysis looks good and patch looks correct, modulo above.
Anyway, i have to add this export to gnu-versioned as well, so if it's ok with
you I'll check in this modified patch along with the gnu-versioned-namespace
one.
best,
Benjamin
[Bug libobjc/54720] New: libobjc install-strip target not populated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720 Bug #: 54720 Summary: libobjc install-strip target not populated Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: gnu...@marino.st On versions 4.7.1 and 4.7.2: executing "make install" after the build will result in the installation of the libobjc.* files when objc is specified in --enable-langs However, "make install-strip" doesn't install the libobjc.* files in the library installation directory. It seems the libobjc/makefile has completely omitted this target although it references it. The fix is easy: Add the install-strip target to the libobjc/Makefile.in file.
[Bug target/54699] [4.8 Regression] [SH] gfortran.dg/class_array_9.f03 ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54699 --- Comment #2 from Oleg Endo 2012-09-26 20:05:47 UTC --- Hm, maybe implementing TARGET_MODE_DEPENDENT_ADDRESS_P would help this case?
[Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test "rnflow" degraded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717 --- Comment #5 from Sergey Ostanevich 2012-09-26 20:07:26 UTC --- for 093t.pre I see the following missing in cptrf2 function, first is good, second is degraded: *** *** 8947,8966 goto ; : - pretmp_325 = (integer(kind=8)) ival2_80; - pretmp_326 = pretmp_325 + -1; - pretmp_327 = *xxtrt_25(D)[pretmp_326]; : # ival2_136 = PHI # ival2_140 = PHI - # prephitmp_328 = PHI _137 = (integer(kind=8)) ival2_136; _138 = _137 + -1; _139 = *xxtrt_25(D)[_138]; _141 = (integer(kind=8)) ival2_140; _142 = _141 + -1; ! _143 = prephitmp_328; if (_139 < _143) goto ; else --- 8838,8853 goto ; : : # ival2_136 = PHI # ival2_140 = PHI _137 = (integer(kind=8)) ival2_136; _138 = _137 + -1; _139 = *xxtrt_25(D)[_138]; _141 = (integer(kind=8)) ival2_140; _142 = _141 + -1; ! _143 = *xxtrt_25(D)[_142]; if (_139 < _143) goto ; else *** but more surprising to me is that first diff is in 020t.inline_param1 *** *** 16790,16794 calls: dtrti2/26 function not considered for inlining ! loop depth: 0 freq:1000 size: 9 time: 18 callee size:82 stack:28 dtrsm/21 function not considered for inlining loop depth: 0 freq:1000 size:16 time: 25 callee size:324 stack: 4 --- 16790,16794 calls: dtrti2/26 function not considered for inlining ! loop depth: 0 freq:1000 size: 9 time: 18 callee size:81 stack:28 dtrsm/21 function not considered for inlining loop depth: 0 freq:1000 size:16 time: 25 callee size:324 stack: 4 ***
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #14 from Kai Tietz 2012-09-26 20:09:16
UTC ---
(In reply to comment #13)
> Hey P, I think you mean:
>
> diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
> b/libstdc++-v3/config/abi/pre/g
> index 5265b21..396feec 100644
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -1322,6 +1322,7 @@ GLIBCXX_3.4.17 {
> } GLIBCXX_3.4.16;
>
> GLIBCXX_3.4.18 {
> +
>global:
>
> # Names inside the 'extern' block are demangled names.
> @@ -1330,6 +1331,9 @@ GLIBCXX_3.4.18 {
>std::random_device::*;
> };
>
> +# construction vtable
> +_ZTCSt*;
> +
> } GLIBCXX_3.4.17;
>
> # Symbols in the support library (libsupc++) have their own tag.
>
>
> ie, not in CXXABI for std:: non-support things.
>
> This is an interesting thread thanks for the info Kai, very informative. The
> analysis looks good and patch looks correct, modulo above.
>
> Anyway, i have to add this export to gnu-versioned as well, so if it's ok with
> you I'll check in this modified patch along with the gnu-versioned-namespace
> one.
Sure, I am fine by your modified patch. Thanks to you Benjamin, and Paolo for
the patch.
[Bug target/54721] New: Generate arm/thumb interwork veneers at compile time?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54721 Bug #: 54721 Summary: Generate arm/thumb interwork veneers at compile time? Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: li...@horizon.com When using -mthumb-interwork, the linker generates calling veneers named __foo_from_arm and __bar_from_thumb on demand. These look like .arm __foo_from_arm ldrip, [pc]; <__foo_from_arm+0x8> bxip .wordfoo .thumb_func __bar_from_thumb: bxpc nop bbar It would be possible to shrink each of these by 4 bytes and some cycles if they were located before the beginning of the relevant function. I've tried the following in a .s file and the linker appears to DTRT with it: .arm .globalfoo .typefoo, %function __foo_from_arm: adrip, foo+1 bxip .thumb_func foo: addr0, r0, #1 bxlr .sizefoo, .-foo .globalbar .typebar, %function __bar_from_thumb: bxpc nop .arm bar: addr0, r0, #2 bxlr .sizebar, .-bar It would be nice if there were a function attribute to declare that a function is likely to be called from both ARM and thumb code, and so should generate the veneers in line. (It seems like a pretty ovvious feature, so my apologies if this exists already; my RTFM and google-fu has not managed to locate it.)
[Bug c/37303] const compound initializers in structs are written to .data instead of .rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37303 --- Comment #8 from Steve Ellcey 2012-09-26 20:33:32 UTC --- Author: sje Date: Wed Sep 26 20:33:28 2012 New Revision: 191772 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191772 Log: 2012-09-26 Steve Ellcey PR c/37303 * gcc.dg/pr37303.c: Check for rdata or rodata. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr37303.c
[Bug target/54716] Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716 --- Comment #9 from Uros Bizjak 2012-09-26 20:59:24 UTC --- (In reply to comment #8) > (In reply to comment #7) > > I haven't noticed a measurable performance difference though on Intel SNB > > 2600 > > CPU though, so perhaps the patch isn't needed. > > Ah, I assumed they had a good reason for creating so many variants of the same > instruction. If there is no difference (or even a difference in the wrong > direction because of the instruction size), feel free to close the bug. I think we should still go with the proposed patch. Insn size is handled by choosing *PS mode attribute for -Os in the insn pattern, and there is no size difference for AVX. If some target prefers *PS variants, there is always X86_TUNE_SSE_PACKED_SINGLE_INSN_OPTIMAL flag available. But please put the code into a helper function. Due to VI mode iterator, the code is emitted eight times!
[Bug target/54721] Generate arm/thumb interwork veneers at compile time?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54721 Andrew Pinski changed: What|Removed |Added Target||arm*-*-* --- Comment #1 from Andrew Pinski 2012-09-26 21:00:21 UTC --- IIRC interwork like this is only required for non-armv7 targets.
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #15 from Paolo Carlini 2012-09-26 21:06:28 UTC --- Ah, Ok. Benjamin, please handle this, because I don't want to make other mistakes here. Thanks!
[Bug testsuite/54622] gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 --- Comment #7 from Janis Johnson 2012-09-26 21:51:53 UTC --- I've tried requiring arm_little_endian for various vect_ effective targets, but the missing support isn't at all clear-cut. Lots of vectorization takes place so it's important to continue to pay attention to the execute tests, but for now I think we'll just handle big-endian expected failures locally.
[Bug middle-end/53476] [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53476 Steve Ellcey changed: What|Removed |Added Priority|P1 |P5 CC||sje at gcc dot gnu.org
[Bug middle-end/53476] [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53476 Steve Ellcey changed: What|Removed |Added Priority|P5 |P1 --- Comment #6 from Steve Ellcey 2012-09-26 22:04:12 UTC --- Woops, I did not intend to change this to P5.
[Bug web/54711] Fix --target_board examples on test.html page
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54711 --- Comment #7 from Steve Ellcey 2012-09-26 22:47:26 UTC --- Author: sje Date: Wed Sep 26 22:47:22 2012 New Revision: 191781 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191781 Log: 2012-09-26 Steve Ellcey PR web/54711 * doc/install.texi: Fix example. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
