[Bug fortran/53255] New: [OOP] With TYPE, wrong type-bound operator used: of parent instead of overridden one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53255 Bug #: 53255 Summary: [OOP] With TYPE, wrong type-bound operator used: of parent instead of overridden one Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Reported by Reinhold Bader. Expected: The following output: executing base executing override OK De-facto output: executing base executing base FAIL If one changes: type(ext) :: p to class(ext), allocatable :: p allocate(p) or class(base), allocatable :: p allocate(ext :: p) it works. Thus, it seems as if only the compile-time resolution of TYPE has the problem, while the vtable run-time version is correct. module mod_base implicit none private type, public :: base private real :: r(2,2) = reshape( (/ 1.0, 2.0, 3.0, 4.0 /), (/ 2, 2 /)) contains procedure, private :: trace generic :: operator(.tr.) = trace end type base contains complex function trace(this) class(base), intent(in) :: this trace = this%r(1,1) + this%r(2,2) end function trace end module mod_base module mod_ext use mod_base implicit none private public :: base type, public, extends(base) :: ext private real :: i(2,2) = reshape( (/ 1.0, 1.0, 1.0, 1.5 /), (/ 2, 2 /)) contains procedure, private :: trace = trace_ext end type ext contains complex function trace_ext(this) class(ext), intent(in) :: this ! the following should be executed through invoking .tr. p below write(*,*) 'executing override' trace_ext = .tr. this%base + (0.0, 1.0) * ( this%i(1,1) + this%i(2,2) ) end function trace_ext end module mod_ext program test_override use mod_ext implicit none type(base) :: o type(ext) :: p ! write(*,*) .tr. o ! write(*,*) .tr. p if (abs(.tr. o - 5.0 ) 1.0e-6 .and. abs( .tr. p - (5.0,2.5)) 1.0e-6) then write(*,*) 'OK' else write(*,*) 'FAIL' end if end program test_override
[Bug fortran/53255] [OOP] With TYPE, wrong type-bound operator used: of parent instead of overridden one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53255 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||janus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-06 08:54:29 UTC --- What happens is the call to resolve_compcall, which in turn calls resolve_typebound_generic_call. That procedure fails as e-value.compcall.tbp-is_generic == false. I think that's okay as only .tr. is generic, the trace is not. However, somewhere in resolve_compcall or resolve_typebound_static it should search for the overridden procedure. The following seems to work. Janus: Do you think that the patch makes sense? --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -5671,9 +5702,8 @@ resolve_typebound_static (gfc_expr* e, gfc_symtree** target, e-value.compcall.actual = NULL; /* If we find a deferred typebound procedure, check for derived types - that an over-riding typebound procedure has not been missed. */ - if (e-value.compcall.tbp-deferred -e-value.compcall.name + that an overriding typebound procedure has not been missed. */ + if (e-value.compcall.name !e-value.compcall.tbp-non_overridable e-value.compcall.base_object e-value.compcall.base_object-ts.type == BT_DERIVED)
[Bug fortran/52158] Regression on character function with gfortran 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52158 --- Comment #2 from Alessandro Fanfarillo fanfarillo.gcc at gmail dot com 2012-05-06 10:32:22 UTC --- Created attachment 27323 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27323 Patch for 52158 and 45170#19 Patch realized on gcc version 4.8.0 20120505
[Bug fortran/52158] Regression on character function with gfortran 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52158 Alessandro Fanfarillo fanfarillo.gcc at gmail dot com changed: What|Removed |Added CC||fanfarillo.gcc at gmail dot ||com --- Comment #3 from Alessandro Fanfarillo fanfarillo.gcc at gmail dot com 2012-05-06 10:38:12 UTC --- Hi all, with the Tobias support I realized this patch (which includes the Paul one) for PR 45170#19. I'm a newbie, so I'm waiting for comments before to send the patch to gcc-fortran and gcc-patches mailing lists. Regards.
[Bug target/53250] [4.8 Regression] [SH] ICE: in change_address_1, at emit-rtl.c:2018
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53250 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Target|sh4-unknown-linux-gnu |sh*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-06 Ever Confirmed|0 |1 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2012-05-06 10:42:34 UTC --- I've noticed this problem a while ago when building newlib. After a few revisions it went away but now it seems to be persistent. The following happens when building newlib: [...] VERSION=\1.19.0\ -DPACKAGE_STRING=\newlib\ 1.19.0\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -I. -I../../../../../../../newlib-1.19.0/newlib/libm/complex -I../../../../../../../newlib-1.19.0/newlib/libm/complex/../common -I../../../../../../../newlib-1.19.0/newlib/libm/complex/ -fno-builtin -g -O2 -ml -m2e -c -o lib_a-cacosh.o `test -f 'cacosh.c' || echo '../../../../../../../newlib-1.19.0/newlib/libm/complex/'`cacosh.c ../../../../../../../newlib-1.19.0/newlib/libm/complex/cacosh.c: In function 'cacosh': ../../../../../../../newlib-1.19.0/newlib/libm/complex/cacosh.c:93:1: internal compiler error: in change_address_1, at emit-rtl.c:2018 } ^ Please submit a full bug report
[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249 --- Comment #2 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-05-06 10:55:48 UTC --- Gah. Sorry for the breakage. This is caused by the x86_64 TLS code generating a DImode MEM address when Pmode == SImode. As you say here: http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01205.html that's wrong from a pure rtl semantics perspective: MEM addresses must have the mode given by targetm.addr_space.address_mode. Even if having a different mode happens to work most of the time, I think that's only by accident. Your original suggestion avoided this, of course. I don't understand the constraints you're working under well enough to suggest anything constructive here, sorry. I don't know whether it would be possible to model this as an address space or not.
[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219 --- Comment #7 from Martin Husemann martin at netbsd dot org 2012-05-06 10:59:19 UTC --- Created attachment 27324 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27324 gcc -S output for the miscompiled function The original report showed the disassembler output from gdb; here is the original compiler output (stripped to the function in question, I can provide the full output if needed). The crash happens in the section starting at line 521: .LLBB1732: .loc 1 4563 0 ldx [%i0+624], %g1 add %fp, 1695, %o0 mov 0, %o1 call__sigsetjmp14, 0 stx%g1, [%fp+1687] .LLVL2000: add %fp, 1687, %g1 st %o0, [%fp+1815] .LLBE1732: .loc 1 4567 0 andcc %o0, 0xff, %o1 .LLBB1733: .loc 1 4563 0 stx %g1, [%i0+624] on return from the sigsetjmp %i0 is zero and we crash in the last line cited above. I think the register %i0 is left as zero after (post first call to sigsetjmp) when going throught he code starting at line 77: .LLVL1968: .LL2453: .LLBB1694: .LLBB1695: .loc 3 77 0 ldx [%fp+2191], %i0 .LLVL1969: .LL2734: and %i0, 224, %g1 srl %g1, 5, %g1 .LLVL1970: .LLBE1695: .LLBE1694: .loc 1 4617 0 cmp %g1, 1 This register value later gets saved to the on-stack copy of the register window, from where it is restored on siglongjmp.
[Bug libstdc++/53248] std::arrayT,0 doesn't work when T is not default-constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53248
--- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-05-06 11:21:47 UTC ---
(In reply to comment #2)
Daniel, can you see other options besides adding a specialization? (which
would
be a straightforward task, I may even get around to do pretty soon when I will
do debug-mode std::array, already in my todo list)
I haven't implemented it completely, but an alternative to a partial
specialization could be something like the following:
template class T, size_t N
struct __array_data_traits
{
typedef T type[N];
};
template class T
struct __array_data_traitsT, 0
{
struct type {};
};
template class T, size_t N
struct array
{
typename __array_data_traitsT, N::type elems;
};
arrayint, 1 ai1 = {1};
arrayint, 1 ai1b = {};
arrayint, 0 ai0 = {};
The sole (?) disadvantage of this approach would be that
std::is_emptyarrayint, 0 does not evaluate to true. But all the
specialization-relevant logic could also be added to __array_data_traits in
terms of static (constexpr where possible) functions.
Technically the traits-based approach would be preferable, because otherwise I
see the risk that user-code that itself would try to specialize std::array with
some T for a user-provided type could notice the difference. Consider:
// Within Library:
template class T, size_t N
struct array
{
T elems[N];
};
template class T
struct arrayT, 0
{
};
// User world:
struct User {};
template size_t N
struct arrayUser, N
{
User elems[N 0 ? N : 1];
};
arrayUser, 0 au0 = {}; // Error, ambiguous
The problem with the current library wording is that it does not *explicitly*
allow a *specialization* for std::array (in contrast to vectorbool or to
numeric_limits for cv-variations of the actual type), therefore I believe that
from the current wording state a partial-specialization by the library is
borderline to invalid, at least a gray zone, because of the need to support
[namespace.std] p1.
If a library issue should be submitted, I would suggest to provide the library
the freedom for providing a special for the zero-size case.
[Bug target/53256] New: [avr] Attribute 'interrupt' shall override attribute 'signal'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53256 Bug #: 53256 Summary: [avr] Attribute 'interrupt' shall override attribute 'signal' Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: g...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org CC: j...@uriah.heep.sax.de Target: avr AVR-LibC offered attributes 'interrupt' and 'signal' as INTERRUPT and SIGNAL through its API. This changed at some point in time to ISR which may lead to code that adds attribute 'interrupt' and attribute 'signal' at the same time. This leads to code that is not IRQ-safe in the current implementation which is: 1) Attributes 'interrupt' and 'signal' are exclusive. Specifying both at the same time for the same function has not a well-defined behavior. 2) 'interrupt' emits a SEI instruction as the very first instruction of the function. 3) Neither attributes make assumptions on the function's worker code. In particular, they do *not* assume that interrupts are not (re-)enabled by the user code. Thus, it is safe to enable IRQs at any place in the function body. This safe covers only the generated code and IRQ-safeness of SP changes and the instructions themselves, it does *not* cover the IRQ and timing layout of the application. 4) The AVR hardware globally disables IRQs when an IRQ is raised. This allows more efficient code in 'signal' prologues compared to 'interrupt' prologues in cases where the stack pointer has to be written. Writing SP is not an atomic operation on all devices, and special precautions must be taken if SP is written and IRQs might be on. As of this extension request 1) shall be changed to: 1') Attribute 'interrupt' shall override attribute 'signal'. No warning should be issued in such a case. The documentation should be extended.
[Bug target/53256] [avr] Attribute 'interrupt' shall override attribute 'signal'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53256 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-06 Target Milestone|--- |4.7.1 Ever Confirmed|0 |1
[Bug c/39044] -Wformat warns on printf() with stringpointer as sole argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39044 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution||WONTFIX --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-06 12:26:36 UTC --- (In reply to comment #2) Ah, you're right. Gentoo enables -Wformat-security by default now. I'll bug them about this. On the other hand, this does not generate a warning. Why? printf(s) is always wrong. You should have used fputs(). To get a warning for printf(s,t), you need -Wformat=2 (or -Wformat-nonliteral). I guess the reason is that there is no real alternative if you need such a code. (In reply to comment #3) i'd reconstruct this report as gcc not properly handling constant strings with printf() when the string is readily available to it and clearly does not change In the examples here, the code is arguably safe, and GCC should not warn. But to reach that conclusion, the front ends would need to do constant propagation, and this is not implemented, and not likely to be ever implemented by existing contributors. I think it would be widely useful to have some sort of constant propagation in the FEs, but it would take someone extremely motivated and skilled to get it done properly. Unfortunately, I am not aware of any candidates. If you know of any, please let me know.
[Bug target/35294] iwmmxt intrinsics, internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294 junkmailnotread at yahoo dot com changed: What|Removed |Added CC||junkmailnotread at yahoo ||dot com --- Comment #15 from junkmailnotread at yahoo dot com 2012-05-06 12:28:25 UTC --- The previous attachment 25391 fixes it for me for gcc-4.5.3. It allowed me to build pixman-0.24.0 with the --enable-arm-iwmmxt configure option.
[Bug web/53257] New: GCC wiki takes a very, very long time to save a page
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53257 Bug #: 53257 Summary: GCC wiki takes a very, very long time to save a page Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org See thread beginning at http://gcc.gnu.org/ml/gcc/2012-04/msg00521.html and in particular the response at http://gcc.gnu.org/ml/gcc/2012-04/msg00677.html which identifies the problem and proposes a solution
[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com Target Milestone|--- |4.8.0 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-05-06 14:06:20 UTC --- On x32, Pmode can be either DImode or SImode. It is incorrect to say happens to work most of the time for x32. Can you add a target hook to restore the old behavior?
[Bug middle-end/52306] ICE in CSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #3 from Thorsten Glaser tg at mirbsd dot org 2012-05-06 14:16:07 UTC --- Created attachment 27325 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27325 preprocessed source of libxslt occurrence The same thing happens in libxslt-1.1.26 but even with PIC: /bin/bash ../libtool --tag=CC --mode=compile gcc -Wl,--as-needed -DHAVE_CONFIG_H -I. -I../../../libxslt -I.. -I../../.. -I../../../libxslt -I/usr/include/libxml2-g -O2 -Wall -c -o xslt.lo ../../../libxslt/xslt.c libtool: compile: gcc -Wl,--as-needed -DHAVE_CONFIG_H -I. -I../../../libxslt -I.. -I../../.. -I../../../libxslt -I/usr/include/libxml2 -g -O2 -Wall -c ../../../libxslt/xslt.c -fPIC -DPIC -o .libs/xslt.o ../../../libxslt/xslt.c: In function 'xsltParseStylesheetProcess': ../../../libxslt/xslt.c:6464:1: internal compiler error: in cselib_record_set, at cselib.c:2148 In the meantime, we’ve got 4.6.3 in Debian, and all patches recommended by Mikael Patterson are applied: (pbuild11307)root@ara3:~/libxslt-1.1.26/build/main/libxslt # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.6/lto-wrapper Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-4+m68k.1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --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.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp --enable-plugin --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu --target=m68k-linux-gnu Thread model: posix gcc version 4.6.3 (Debian 4.6.3-4+m68k.1) Lowering to -O1 allows the file to compile.
[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-05-06 14:28:55
UTC ---
A small testcase:
[hjl@gnu-6 pr53249]$ cat x.i
struct gomp_task
{
struct gomp_task *parent;
};
struct gomp_thread
{
int foo1;
struct gomp_task *task;
};
extern __thread struct gomp_thread gomp_tls_data;
void
__attribute__ ((noinline))
gomp_end_task (void)
{
struct gomp_thread *thr = gomp_tls_data;
struct gomp_task *task = thr-task;
thr-task = task-parent;
}
[hjl@gnu-6 pr53249]$
[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-05-06 14:35:26 UTC --- X32 is a 32bit environment for x86-64: https://sites.google.com/site/x32abi/ Since there is no x32 mode in hardware, x32 binaries run in pure 64-bit mode.
[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-05-06 14:54:10 UTC --- Can you just use GET_MODE (mem) instead of targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem)) when you change plus_constant (mem, offset)? At least, you should allow a backend to do plus_constant (GET_MODE (mem), mem, offset) instead of mode = targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem)) plus_constant (mode, mem, offset)
[Bug c++/53152] In no match for operatorXX error message gives the wrong column info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53152 --- Comment #7 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-05-06 15:06:35 UTC --- Author: paolo Date: Sun May 6 15:06:31 2012 New Revision: 187211 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187211 Log: 2012-05-06 Paolo Carlini paolo.carl...@oracle.com PR c++/53152 * call.c (op_error, build_new_op_1, build_new_op): Add location_t parameter. (build_conditional_expr_1): Adjust. * typeck.c (build_x_indirect_ref, build_x_binary_op, build_x_unary_op): Add location_t parameter. (rationalize_conditional_expr, build_x_array_ref, build_x_compound_expr, cp_build_modify_expr, build_x_modify_expr): Adjust. * typeck2.c (build_x_arrow): Add location_t parameter. * semantics.c (finish_unary_op_expr): Likewise. (finish_increment_expr, handle_omp_for_class_iterator): Adjust. * decl2.c (grok_array_decl): Add location_t parameter. * parser.c (cp_parser_postfix_open_square_expression, cp_parser_postfix_dot_deref_expression, cp_parser_unary_expression, cp_parser_binary_expression, cp_parser_builtin_offsetof, do_range_for_auto_deduction, cp_convert_range_for, cp_parser_template_argument, cp_parser_omp_for_cond): Pass the location, adjust. * pt.c (tsubst_copy_and_build): Adjust. * tree.c (maybe_dummy_object): Likewise. * cp-tree.h: Update declarations. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/cp/typeck2.c
[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-06 AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #7 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-05-06 15:06:34 UTC --- Testing a patch.
[Bug c++/53152] In no match for operatorXX error message gives the wrong column info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53152 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-06 15:09:02 UTC --- Done.
[Bug libstdc++/53248] std::arrayT,0 doesn't work when T is not default-constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53248 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-06 15:39:33 UTC --- Thanks Daniel. Since we had this issue for so much time, I guess we could as well wait a bit for the Committee to provide some feedback about the specialization option: in case there are no objections, just go with that. I would rather stay away from std::is_empty false, if we are fixing this.
[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED Ever Confirmed|1 |0 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2012-05-06 15:42:09 UTC --- get_address_mode in dwarf2out.c works for this testcase.
[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249 --- Comment #9 from rdsandiford at googlemail dot com rdsandiford at googlemail dot com 2012-05-06 15:56:09 UTC --- hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org writes: get_address_mode in dwarf2out.c works for this testcase. Yeah, that's what I was testing FWIW. If x32 wants to do this, then pretty much every instance of: targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem)) needs to use get_address_mode instead. So I'm trying to convert all of them. (There's a duplicate copy in var-tracking.c, so the patch consolidates them into a general rtl.h function.)
[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2012-05-06 16:00:35
UTC ---
(In reply to comment #9)
hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org writes:
get_address_mode in dwarf2out.c works for this testcase.
Yeah, that's what I was testing FWIW. If x32 wants to do this,
then pretty much every instance of:
targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem))
needs to use get_address_mode instead. So I'm trying to convert all of them.
This is the minimum one:
diff --git a/gcc/dse.c b/gcc/dse.c
index 0523757..964804c 100644
--- a/gcc/dse.c
+++ b/gcc/dse.c
@@ -1455,7 +1455,7 @@ record_store (rtx body, bb_info_t bb_info)
return 0;
}
- address_mode = targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem));
+ address_mode = get_address_mode (mem);
if (GET_MODE (mem) == BLKmode)
width = MEM_SIZE (mem);
@@ -2181,11 +2181,8 @@ check_mem_read_rtx (rtx *loc, void *data)
mem_addr = group-canon_base_addr;
}
if (offset)
-{
- enum machine_mode address_mode
-= targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem));
- mem_addr = plus_constant (address_mode, mem_addr, offset);
-}
+mem_addr = plus_constant (get_address_mode (mem),
+ mem_addr, offset);
}
/* We ignore the clobbers in store_info. The is mildly aggressive,
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 25c8ded..9d10bac 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2113,7 +2113,7 @@ adjust_address_1 (rtx memref, enum machine_mode mode,
HOST_WIDE_INT offset,
plus_constant (address_mode,
XEXP (addr, 1), offset));
else
-addr = plus_constant (address_mode, addr, offset);
+addr = plus_constant (get_address_mode (memref), addr, offset);
}
new_rtx = change_address_1 (memref, mode, addr, validate);
to build x32 run-time libraries for c,c++,fortran,objc,go.
[Bug middle-end/52306] ICE in CSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Known to fail||4.6.3 --- Comment #4 from Thorsten Glaser tg at mirbsd dot org 2012-05-06 17:04:12 UTC --- Luckily, -Os works in the libxslt case (not in the libvirt case, though), although, from the earlier comments, optimisation is just hiding the bug by changing control flow.
[Bug plugins/53258] New: Many symbols cannot lookup when loading plugin in configured with --enable-build-with-cxx.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53258 Bug #: 53258 Summary: Many symbols cannot lookup when loading plugin in configured with --enable-build-with-cxx. Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: plugins AssignedTo: unassig...@gcc.gnu.org ReportedBy: fl...@flast.jp Many symbols are exported as C++ symbol that GCC configured with --enable-build-with-cxx. Such symbols are used by plugins and will load plugin failed. I think it will impact to cxx-conversion branch also. I tested only GCC 4.7.1 20120428 .
[Bug c++/53236] using declaration and base function template overloading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53236
--- Comment #7 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-05-06 17:34:10 UTC ---
(In reply to comment #5)
Here is a simplified code - gcc_error_simple.cpp
Shows two facets of the error.
See the comments in the attached file.
Fixed and simplified that code we have:
//---
templatetypename, typename, typename
struct enable_same
{};
templatetypename T, typename U
struct enable_sameT, T, U
{
typedef U type;
};
template typename T
struct Base
{
T u;
template typename T2
typename enable_sameT, T2, T::type
get() { return u; }
};
template typename T
struct Derived : Baseint
{
typedef Baseint base;
#ifdef WITH_USING_DECLARATION
using base::get;
#endif
template typename T2
typename enable_sameT, T2, T::type
get() { return this-u;} // Line 32
};
int main()
{
Deriveddouble d;
d.getdouble();
d.getint(); // Line 39
}
//---
Using gcc 4.8.0 20120429 (experimental) I see different results (I see the same
thing with your unchanged code taking into account that a function returning
no-void is expected to be rejected):
a) #ifndef WITH_USING_DECLARATION: The code is accepted as it should.
b) #ifdef WITH_USING_DECLARATION: The code is rejected as it should:
In function 'int main()':|
39|error: no matching function for call to 'Deriveddouble::get()'|
39|note: candidate is:|
32|note: templateclass T2 typename enable_sameT, T2, T::type Derived::get()
[with T2 = T2; T = double]|
|32|note: template argument deduction/substitution failed:|
39| required from here|
32|error: no type named 'type' in 'struct enable_samedouble, int, double'|
Even though the third line of the diagnostics is a bit misleading it is
certainly correct the function call, because the base class get template is
hidden without the using-declaration.
Summarizing, it seems that the variadic code is broken, not the non-variadic
case.
[Bug web/53257] GCC wiki takes a very, very long time to save a page
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53257 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||overseers at gcc dot ||gnu.org --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-06 17:54:43 UTC --- Adding overseers@ to see what their input is.
[Bug plugins/53258] Many symbols cannot lookup when loading plugin in configured with --enable-build-with-cxx.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53258 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-06 17:55:52 UTC --- This is expected until GCC has a real stable API for plugins. There was a thread earlier this year exactly about this.
[Bug target/53250] [4.8 Regression] [SH] ICE: in change_address_1, at emit-rtl.c:2018
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53250
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org 2012-05-06 18:04:27
UTC ---
Created attachment 27326
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27326
Proposed patch
(In reply to comment #0)
On sh4-unknown-linux-gnu, there are many new failures after revision
187015. The typical example is gcc.c-torture/compile/20071102-1.c
which fails with
internal compiler error: in change_address_1, at emit-rtl.c:2018
It seems that rtls like
(subreg:SF (reg:DI ...) 4)
(subreg:SF (reg:V2SF ...) 4)
cause this error when regs are on stack. If my memory is correct,
the similar issue has popped up on oleg's work for QI/HImode addressing
with displacement.
Do you mean this wallpapering below?
sh.c (sh_cannot_change_mode_class) ...
/* This effectively disallows using GENERAL_REGS for SFmode vector subregs.
This can be problematic when SFmode vector subregs need to be accessed
on the stack with displacement addressing, as it happens with -O0.
Thus we disallow the mode change for -O0. */
if (to == SFmode VECTOR_MODE_P (from) GET_MODE_INNER (from) == SFmode)
return optimize ? (reg_classes_intersect_p (GENERAL_REGS, rclass)) : false;
I think this one is a different issue...
The above rtls are not illegal but problematic
when regs are on stack because SH has no load/store instructions
for FP registers and memory with displacement. Before lowering
subregs change in revision 187015, these subregs were decomposed
into subregs with zero byte count.
The trails of PR53716 say that the appropriate target-wise cost
computation is needed, though I can't find the way to enable
lowering the above subregs with adjusting SH's rtx cost computations.
I had a look at what's going on there.
The lower-subreg pass decides whether to do the splitting or not based on the
reg move costs of certain modes. These costs are initially collected by
querying the rtx cost for patterns like (set (reg:DI 154
virtual-incoming-args).
A simple stack trace ...
lower_subreg (compute_costs)
rtx = (set (reg:DI 154 virtual-incoming-args)
- insn_rtx_cost
- set_src_cost
- rtx_cost (x, SET, 1, speed_p)
switch (code)
{
case REG:
return 0;
}
The 'rtx_cost' function always returns 0 because 'code' is 'REG', so it never
reaches sh_rtx_costs. I wonder how this could have worked for other targets at
all.
The attached patch seems to fix the issue (at least newlib compiles for me
now).
However, I'm completely unaware of any consequences of the rtlanal.c hunk.
Maybe somebody else should have a look at it.
[Bug rtl-optimization/53227] [4.8 Regression] FAIL: gcc.target/i386/movbe-2.c scan-assembler-times movbe[ \t] 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2012-05-06 18:08:37 UTC --- Created attachment 27327 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27327 Patch that improves DImode swap sequeces Patch in testing.
[Bug rtl-optimization/53176] [4.8 Regression] gcc.dg/lower-subreg-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #18 from Oleg Endo olegendo at gcc dot gnu.org 2012-05-06 18:09:37 UTC --- On SH an issue popped up because lower-subreg would not split multi-word regs anymore. Could somebody please have a look at comment #2 and the proposed patch in PR 53250?
[Bug target/53227] [4.8 Regression] FAIL: gcc.target/i386/movbe-2.c scan-assembler-times movbe[ \t] 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Keywords|ra | Component|rtl-optimization|target --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2012-05-06 18:09:28 UTC --- Target issue.
[Bug c++/52900] Compile source using Boost header with -static -flto -std=c++11 breaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52900 --- Comment #5 from gccBugs at haatschii dot de 2012-05-06 18:34:41 UTC --- Could you reproduce the bug? Or do you need any more informations?
[Bug libstdc++/53248] std::arrayT,0 doesn't work when T is not default-constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53248 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-06 Ever Confirmed|0 |1 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-06 18:47:12 UTC --- By the way - I think we discussed this already, bu now I can't find anything - what should we take the begin() == end() == unique value exactly to mean? Don't tell me something like an ugly reinterpret_castT*(this), please
[Bug libstdc++/53248] std::arrayT,0 doesn't work when T is not default-constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53248 --- Comment #6 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-05-06 18:56:05 UTC --- (In reply to comment #5) By the way - I think we discussed this already, bu now I can't find anything - what should we take the begin() == end() == unique value exactly to mean? Don't tell me something like an ugly reinterpret_castT*(this), please My interpretation is that returning nullptr should be OK. I don't see any requirement that a unique value is something that cannot be returned by any other container (In a private communication with Howard he at least agreed with my interpretation). If this interpretation is unsafe, it should also be clarified by revised wording.
[Bug rtl-optimization/53176] [4.8 Regression] gcc.dg/lower-subreg-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176 --- Comment #19 from rdsandiford at googlemail dot com rdsandiford at googlemail dot com 2012-05-06 19:17:03 UTC --- olegendo at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org writes: --- Comment #18 from Oleg Endo olegendo at gcc dot gnu.org 2012-05-06 18:09:37 UTC --- On SH an issue popped up because lower-subreg would not split multi-word regs anymore. Could somebody please have a look at comment #2 and the proposed patch in PR 53250? Unfortunately I messed up the choice of cost routines in the original patch. I just committed the fix for that. The SH rtx_costs routine should now see (set (reg) (reg)) and (set (reg) (const_int 0)) rtxes, so you should be able to set the costs there. See: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00425.html for a similar MIPS patch.
[Bug fortran/53259] New: [OOP] virtual call to type bound procedure calls base, not extension?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53259 Bug #: 53259 Summary: [OOP] virtual call to type bound procedure calls base, not extension? Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dfra...@gcc.gnu.org CC: ja...@gcc.gnu.org The testcase below strangely calls a_hook, but I'd expect b_hook to be called? For what it's worth, an equivalent testcase in C++ calls b_hook ... $ gfortran hook.f90 ./a.out hook: a [gfortran 4.8 r186145; info provided by Andrew Benson] See also the thread started here: http://gcc.gnu.org/ml/fortran/2012-05/msg00029.html This may be related to PR53255 (but the workaround given there does not seem to work. Didn't test the patch yet). Testcase: $ cat hook.f90 MODULE m TYPE :: a CONTAINS PROCEDURE :: worker = a_worker PROCEDURE :: hook = a_hook END TYPE TYPE, extends(a) :: b CONTAINS PROCEDURE :: worker = b_worker PROCEDURE :: hook = b_hook END TYPE CONTAINS SUBROUTINE a_worker(this) CLASS(a), INTENT(in) :: this CALL this%hook() END SUBROUTINE SUBROUTINE a_hook(this) CLASS(a), INTENT(in) :: this print *, hook: a ! This is wrongly(?) called. END SUBROUTINE SUBROUTINE b_worker(this) CLASS(b), INTENT(in) :: this ! do some extra work, then call the worker of the base class, ! expect to come back to b_hook later ... CALL this%a%worker() END SUBROUTINE SUBROUTINE b_hook(this) CLASS(b), INTENT(in) :: this print *, hook: b END SUBROUTINE END MODULE USE m TYPE(b) :: obj CALL obj%worker() END
[Bug rtl-optimization/53176] [4.8 Regression] gcc.dg/lower-subreg-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176 --- Comment #20 from Oleg Endo olegendo at gcc dot gnu.org 2012-05-06 19:21:18 UTC --- (In reply to comment #19) olegendo at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org writes: --- Comment #18 from Oleg Endo olegendo at gcc dot gnu.org 2012-05-06 18:09:37 UTC --- On SH an issue popped up because lower-subreg would not split multi-word regs anymore. Could somebody please have a look at comment #2 and the proposed patch in PR 53250? Unfortunately I messed up the choice of cost routines in the original patch. I just committed the fix for that. The SH rtx_costs routine should now see (set (reg) (reg)) and (set (reg) (const_int 0)) rtxes, so you should be able to set the costs there. See: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00425.html for a similar MIPS patch. Yep, I just saw it on the patches list. I'm on it. Thanks.
[Bug rtl-optimization/53260] New: cse doesn't record REG_EQUAL notes for function invariants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53260 Bug #: 53260 Summary: cse doesn't record REG_EQUAL notes for function invariants Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rsand...@gcc.gnu.org CSE adds REG_EQUAL notes for constant equivalences that it finds: /* If this is a single SET, we are setting a register, and we have an equivalent constant, we want to add a REG_NOTE. We don't want to write a REG_EQUAL note for a constant pseudo since verifying that that pseudo hasn't been eliminated is a pain. Such a note also won't help anything. It might be worth extending this to function_invariant_p, so that reload has the option of eliminating registers that are equivalent to known frame addresses. A hacked-up patch to do this showed a surprising number of differences, but I haven't had chance to see whether they're good or bad.
[Bug libstdc++/53248] std::arrayT,0 doesn't work when T is not default-constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53248 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-06 19:27:56 UTC --- Good, good then. Personally, I find that unique value confusing.
[Bug target/53101] Recognize casts to sub-vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53101
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org 2012-05-06 19:55:58
UTC ---
Getting a BIT_FIELD_REF in gimple is simple enough. If I remember correctly,
the patch below was enough (it also fixes the fact the current code will
generate a BIT_FIELD_REF for true elements of the vector and one past the end,
but not further, and I am not sure why that one-past-the-end behavior would be
wanted).
I did it because I thought it would be easier to convince the compiler to
expand that to a vec_select, and I tried patching get_inner_reference and
extract_bit_field_1, but no luck, I give up for now.
--- gimplify.c(revision 187205)
+++ gimplify.c(working copy)
@@ -4262,11 +4262,16 @@ gimple_fold_indirect_ref (tree t)
else if (TREE_CODE (optype) == COMPLEX_TYPE
useless_type_conversion_p (type, TREE_TYPE (optype)))
return fold_build1 (REALPART_EXPR, type, op);
/* *(foo *)vectorfoo = BIT_FIELD_REFvectorfoo,... */
else if (TREE_CODE (optype) == VECTOR_TYPE
-useless_type_conversion_p (type, TREE_TYPE (optype)))
+(useless_type_conversion_p (type, TREE_TYPE (optype))
+ || (TREE_CODE (type) == VECTOR_TYPE
+useless_type_conversion_p (TREE_TYPE (type),
+ TREE_TYPE (optype))
+TYPE_VECTOR_SUBPARTS (type)
+ TYPE_VECTOR_SUBPARTS (optype
{
tree part_width = TYPE_SIZE (type);
tree index = bitsize_int (0);
return fold_build3 (BIT_FIELD_REF, type, op, part_width, index);
}
@@ -4283,22 +4288,29 @@ gimple_fold_indirect_ref (tree t)
STRIP_NOPS (addr);
addrtype = TREE_TYPE (addr);
/* ((foo*)vectorfoo)[1] - BIT_FIELD_REFvectorfoo,... */
if (TREE_CODE (addr) == ADDR_EXPR
- TREE_CODE (TREE_TYPE (addrtype)) == VECTOR_TYPE
- useless_type_conversion_p (type, TREE_TYPE (TREE_TYPE (addrtype)))
- host_integerp (off, 1))
+ host_integerp (off, 1)
+ ((TREE_CODE (TREE_TYPE (addrtype)) == VECTOR_TYPE
+useless_type_conversion_p (type,
+TREE_TYPE (TREE_TYPE (addrtype
+ || (TREE_CODE (type) == VECTOR_TYPE
+ useless_type_conversion_p (TREE_TYPE (type),
+ TREE_TYPE (TREE_TYPE (addrtype)))
+ TYPE_VECTOR_SUBPARTS (type)
+ TYPE_VECTOR_SUBPARTS (TREE_TYPE (addrtype)
{
unsigned HOST_WIDE_INT offset = tree_low_cst (off, 1);
tree part_width = TYPE_SIZE (type);
unsigned HOST_WIDE_INT part_widthi
-= tree_low_cst (part_width, 0) / BITS_PER_UNIT;
+= tree_low_cst (part_width, 0);
+ unsigned HOST_WIDE_INT orig_widthi
+= tree_low_cst (TYPE_SIZE (TREE_TYPE (addrtype)), 0);
unsigned HOST_WIDE_INT indexi = offset * BITS_PER_UNIT;
tree index = bitsize_int (indexi);
- if (offset / part_widthi
- = TYPE_VECTOR_SUBPARTS (TREE_TYPE (addrtype)))
+ if (indexi + part_widthi = orig_widthi)
return fold_build3 (BIT_FIELD_REF, type, TREE_OPERAND (addr, 0),
part_width, index);
}
/* ((foo*)complexfoo)[1] - __imag__ complexfoo */
[Bug fortran/41587] [OOP] ICE with ALLOCATABLE CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41587 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-06 20:30:13 UTC --- Author: burnus Date: Sun May 6 20:30:05 2012 New Revision: 187214 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187214 Log: 2012-05-06 Tobias Burnus bur...@net-b.de PR fortran/41587 * decl.c (build_struct): Don't ignore FAILED status. 2012-05-06 Tobias Burnus bur...@net-b.de PR fortran/41587 * gfortran.dg/class_array_13.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_array_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/41587] [OOP] ICE with ALLOCATABLE CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41587 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-06 20:32:55 UTC --- (In reply to comment #7) As of yesterday, the testcase in comment #1 compiles and runs successfully. We now just need the error message for the original problem. Which has now been FIXED on the 4.8 trunk. (The other issues were fixed on the 4.7 trunk.)
[Bug target/53227] [4.8 Regression] FAIL: gcc.target/i386/movbe-2.c scan-assembler-times movbe[ \t] 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227 --- Comment #7 from uros at gcc dot gnu.org 2012-05-06 20:48:03 UTC --- Author: uros Date: Sun May 6 20:47:59 2012 New Revision: 187215 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187215 Log: PR target/53227 * config/i386/i386.md (swapmode): Rename from *swapmode. (bswapdi2): Split from bswapmode2. Use nonnimediate_operand predicate for operand 1. Force operand 1 to register for TARGET_BSWAP. (bswapsi2): Ditto. (*bswapdi2_doubleword): New insn pattern. (*bswapmode2): Rename from *bswapmode2_1. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug target/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52999 --- Comment #12 from John David Anglin danglin at gcc dot gnu.org 2012-05-06 20:50:13 UTC --- Author: danglin Date: Sun May 6 20:50:06 2012 New Revision: 187216 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187216 Log: Backport from mainline: 2012-04-27 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR target/52999 * config/pa/pa.c (pa_legitimate_constant_p): Don't put function labels in constant pool. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/pa/pa.c
[Bug target/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52999 --- Comment #13 from John David Anglin danglin at gcc dot gnu.org 2012-05-06 20:59:14 UTC --- Author: danglin Date: Sun May 6 20:59:10 2012 New Revision: 187217 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187217 Log: PR target/52999 * config/pa/pa.h (LEGITIMATE_CONSTANT_P): Don't put function labels in constant pool. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/pa/pa.h
[Bug target/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52999 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #14 from John David Anglin danglin at gcc dot gnu.org 2012-05-06 21:00:41 UTC --- Fixed.
[Bug target/53227] [4.8 Regression] FAIL: gcc.target/i386/movbe-2.c scan-assembler-times movbe[ \t] 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-05/msg00430.htm ||l Resolution||FIXED --- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-05-06 21:00:49 UTC --- Fixed.
[Bug fortran/53259] [OOP] virtual call to type bound procedure calls base, not extension?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53259 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-06 21:39:05 UTC --- According to the comments at http://gcc.gnu.org/ml/fortran/2012-05/msg00041.html and http://gcc.gnu.org/ml/fortran/2012-05/msg00037.html, the result seems to be correct. Also ifort (v11.1), pgf95 (v11.11-0) and Cray cce 8.02 give the same result as gfortran 4.6 to 4.8. Thus, I close the bug as INVALID. (If you find an indication that the PR is not invalid, feel free to reopen it.)
[Bug bootstrap/52391] [4.7/4.8 regression] genattrtab almost 5X slower for m68k than in 4.6 and earlier releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52391 --- Comment #14 from Steven Bosscher steven at gcc dot gnu.org 2012-05-06 21:40:18 UTC --- Created attachment 27328 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27328 Remove unused sched_branch_type stuff from m68k Patch speaks for itself. Without patch, trunk r186902, run time for genattrtab is 9m03s. With the m68k-specific pieces of this patch, genattrtab run time is 1m53s.
[Bug c++/53261] New: [4.8 Regression] ICE in tree_strip_nop_conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53261 Bug #: 53261 Summary: [4.8 Regression] ICE in tree_strip_nop_conversions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa*-*-* (32-bit) Target: hppa*-*-* (32-bit) Build: hppa*-*-* (32-bit) Created attachment 27329 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27329 Preprocessed source /home/dave/gnu/gcc/objdir/./prev-gcc/g++ -B/home/d ave/gnu/gcc/objdir/./prev-gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.7.0/hppa-linux-gnu /bin/ -nostdinc++ -B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/s rc/.libs -B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/ .libs -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa- linux-gnu -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include - I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -L/home/dave/gnu/gcc/objdir/prev- hppa-linux-gnu/libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir/prev-hppa-linu x-gnu/libstdc++-v3/libsupc++/.libs -I../../gcc/libcpp -I. -I../../gcc/libcpp/.. /include -I../../gcc/libcpp/include -g -O2 -W -Wall -Wno-narrowing -Wwrite-stri ngs -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -fno-exceptions -fno-rtti -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcp p/include -c -o files.o -MT files.o -MMD -MP -MF .deps/files.Tpo ../../gcc/libc pp/files.c ../../gcc/libcpp/files.c: In function ‘bool pch_open_file(cpp_reader*, _cpp_file *, bool*)’: ../../gcc/libcpp/files.c:288:43: internal compiler error: Segmentation fault if (file-name[0] == '\0' || !pfile-cb.valid_pch) Program received signal SIGSEGV, Segmentation fault. tree_strip_nop_conversions (exp=0x0) at ../../gcc/gcc/tree.c:11211 11211 while (tree_nop_conversion (exp)) (gdb) bt #0 tree_strip_nop_conversions (exp=0x0) at ../../gcc/gcc/tree.c:11211 #1 0x00954b9c in integer_zerop (expr=optimized out) at ../../gcc/gcc/tree.c:1731 #2 0x002d6f2c in warn_logical_operator (location=1226970, code=optimized out, type=0x40f4e660, code_left=optimized out, op_left=0x4130f260, code_right=EQ_EXPR, op_right=0x4130f2e0) at ../../gcc/gcc/c-family/c-common.c:1647 #3 0x00096944 in build_new_op_1 (loc=1226970, code=TRUTH_ORIF_EXPR, flags=3, arg1=0x4130f260, arg2=0x4130f2e0, arg3=optimized out, overload=0xfbf02df8, complain=3) at ../../gcc/gcc/cp/call.c:5261 #4 0x00096aa4 in build_new_op (loc=1093726944, code=TRUTH_ORIF_EXPR, flags=1089803568, arg1=0x0, arg2=0x4130f2e0, arg3=0x0, overload=0xfbf02df8, complain=3) at ../../gcc/gcc/cp/call.c:5326 #5 0x001f4568 in build_x_binary_op (loc=1089803568, code=TRUTH_ORIF_EXPR, arg1=0x0, arg1_code=1226970, arg2=0x4130f260, arg2_code=ERROR_MARK, overload=0xfbf02df8, complain=3) at ../../gcc/gcc/cp/typeck.c:3608 #6 0x001d1f54 in cp_parser_binary_expression (parser=0x4130f2e0, cast_p=optimized out, no_toplevel_fold_p=optimized out, prec=PREC_INCLUSIVE_OR_EXPRESSION, pidk=0x0) at ../../gcc/gcc/cp/parser.c:7399 #7 0x001d2168 in cp_parser_assignment_expression (parser=0x4102e460, cast_p=optimized out, pidk=0x0) at ../../gcc/gcc/cp/parser.c:7504 #8 0x001d8b34 in cp_parser_expression (parser=0x4102e460, ---Type return to continue, or q return to quit--- cast_p=optimized out, pidk=0x0) at ../../gcc/gcc/cp/parser.c:7650 #9 0x001db68c in cp_parser_condition (parser=0x4102e460) at ../../gcc/gcc/cp/parser.c:9281 #10 0x001c2cb0 in cp_parser_selection_statement (if_p=0x0, parser=0x4102e460) at ../../gcc/gcc/cp/parser.c:9058 #11 cp_parser_statement (parser=0x4102e460, in_statement_expr=0x0, in_compound=optimized out, if_p=0x0) at ../../gcc/gcc/cp/parser.c:8645 #12 0x001c434c in cp_parser_statement_seq_opt (parser=0x0, in_statement_expr=0x4f) at ../../gcc/gcc/cp/parser.c:9004 #13 0x001c45a8 in cp_parser_compound_statement (parser=0x0, in_statement_expr=0x12b8c0, in_try=optimized out, function_body=optimized out) at ../../gcc/gcc/cp/parser.c:8958 #14 0x001dfd2c in cp_parser_function_body (parser=0x4102e460) at ../../gcc/gcc/cp/parser.c:17422 #15 cp_parser_ctor_initializer_opt_and_function_body (parser=0x4102e460) at ../../gcc/gcc/cp/parser.c:17456 #16 0x001e0408 in cp_parser_function_definition_after_declarator (parser=0x0, inline_p=optimized out) at ../../gcc/gcc/cp/parser.c:21069 #17 0x001e09ac in cp_parser_function_definition_from_specifiers_and_declarator (declarator=0xd6d370, attributes=0x0, decl_specifiers=optimized out, parser=0x4102e460) at ../../gcc/gcc/cp/parser.c:20989 #18 cp_parser_init_declarator (parser=0x4102e460, decl_specifiers=optimized out, checks=0x0, ---Type return to continue, or q return
[Bug target/53250] [4.8 Regression] [SH] ICE: in change_address_1, at emit-rtl.c:2018
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53250 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org 2012-05-06 22:39:01 UTC --- Author: olegendo Date: Sun May 6 22:38:57 2012 New Revision: 187218 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187218 Log: PR target/53250 * config/sh/sh.c (sh_rtx_costs): Handle SET. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c
[Bug rtl-optimization/53176] [4.8 Regression] gcc.dg/lower-subreg-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176 --- Comment #21 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-06 23:25:40 UTC --- All this should be taken care of by the default rtx costs; I don't think any target patches should be needed for these targets at least not for this case. The default should be N*natural_set_cost, where natural_set_cost is the cost of setting a register (possibly the default) and N is the number of UNITS_PER_WORD for the rtx. And, the target rtx cost hook should only need to handle rtxes that are valid for the target; no phony insns in larger modes for which there is no named pattern (not documented as such but inferring from only valid addresses needing to be handled by TARGET_ADDRESS_COST).
[Bug rtl-optimization/53176] [4.8 Regression] gcc.dg/lower-subreg-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176 --- Comment #22 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-06 23:28:55 UTC --- (In reply to comment #21) Hopefully it was obvious, but: ... where natural_set_cost is the cost of setting a register (possibly the default) ... for the UNITS_PER_WORD case ...
[Bug other/29442] insn-attrtab has grown too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #15 from Steven Bosscher steven at gcc dot gnu.org 2012-05-06 23:39:46 UTC --- While looking for ways to speed up genattrtab itself, I found this patch, which doesn't speed up genattrtab, but would make the insn-*tab.c files smaller: http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00316.html Micha, this appears to have been dropped. Any reason why you never asked for an OK to commit this patch?
[Bug c++/52672] internal compiler error: in cxx_eval_indirect_ref, at cp/semantics.c:6766
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52672 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.7.1, 4.8.0 Resolution||FIXED Target Milestone|--- |4.7.1 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-07 00:19:25 UTC --- Closing as fixed.
[Bug middle-end/53239] [4.7 Regression] VRP vs named value return opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53239 --- Comment #6 from proski at gnu dot org 2012-05-07 02:50:04 UTC --- Created attachment 27330 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27330 Self-contained test case Run the compile script. The output would be: return = 2/1 return = 1/1 It means that the output depends on whether -fno-tree-vrp is used.
[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 Hin-Tak Leung htl10 at users dot sourceforge.net changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Known to fail||4.6.2 --- Comment #15 from Hin-Tak Leung htl10 at users dot sourceforge.net 2012-05-07 03:21:20 UTC --- /home/htl10/tmp-build/gcc-4.6.2-build' Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1obj-checksum.o differs Bootstrap comparison failure! gcc/java/win32-host.o differs gcc/build/version.o differs gcc/build/min-insn-modes.o differs gcc/c-lang.o differs gcc/insn-peep.o differs gcc/insn-enums.o differs gcc/graphite-blocking.o differs gcc/graphite-clast-to-gimple.o differs gcc/graphite-cloog-util.o differs gcc/graphite-dependences.o differs gcc/graphite-flattening.o differs gcc/graphite-poly.o differs gcc/graphite-interchange.o differs gcc/graphite-ppl.o differs gcc/graphite-scop-detection.o differs gcc/graphite-sese-to-poly.o differs gcc/hwint.o differs gcc/loop-doloop.o differs gcc/target-globals.o differs gcc/version.o differs gcc/vmsdbgout.o differs gcc/xcoffout.o differs gcc/collect2-aix.o differs intl/osdep.o differs libiberty/safe-ctype.o differs File sizes seems crazy: # ls -l */cc*-checksum.o -rw-r--r-- 1 root system 592 May 7 02:38 stage2-gcc/cc1-checksum.o -rw-r--r-- 1 root system 600 May 7 03:07 stage2-gcc/cc1obj-checksum.o -rw-r--r-- 1 root system 600 May 7 02:49 stage2-gcc/cc1plus-checksum.o -rw-r--r-- 1 root system 22928 May 7 03:33 stage3-gcc/cc1-checksum.o -rw-r--r-- 1 root system 22928 May 7 03:40 stage3-gcc/cc1obj-checksum.o -rw-r--r-- 1 root system 22936 May 7 03:36 stage3-gcc/cc1plus-checksum.o
