[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469
Igor Zamyatin izamyatin at gmail dot com changed:
What|Removed |Added
CC||izamyatin at gmail dot com
--- Comment #2 from Igor Zamyatin izamyatin at gmail dot com ---
ICE could be seen even for
void foo() { asm( ::: memory); }
#define ALEN 1024
int main(int argc, char* argv[])
{
int b[ALEN];
b[:] = 100;
_Cilk_spawn foo();
return 0;
}
The bad VAR_DECL here is the initial variable for the loop that is created
during array annotation expression expanding. The problem seems to be in the
way how this var_decl is created.
For C++ case create_temp_var is used where DECL_CONTEXT is set up. For C case
build_decl is used where no DECL_CONTEXT is filled
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763
--- Comment #11 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org
---
(In reply to David Edelsohn from comment #10)
I'm not questioning the analysis, I'm questioning the solution. Directly
generating a register and jamming in the REGNO in this pattern seems sort of
crude.
gen_rtx_REG (DImode, REGNO (op0));
I don't doubt that this is the RTL that eventually is produced, I am
surprised that there is no existing wrapper function in simplify-rtx.c or
rtlanal.c that can be used.
If this is the necessary implementation, I think it deserves some, brief
comment.
I think the reason there's no wrapper function is that it's very dangerous
to change the mode of a register when the target has explicitly said that
that shouldn't happen.
Maybe it's an easier sell if I say that this op0_di is really a secondary
temporary value that just happens to use the same register as the output.
I think:
(define_insn_and_split reload_vsx_from_gprsf
[(set (match_operand:SF 0 register_operand =wa)
(unspec:SF [(match_operand:SF 1 register_operand r)]
UNSPEC_P8V_RELOAD_FROM_GPR))
(clobber (match_operand:DI 2 register_operand =r))
(clobber (match_operand:DI 3 register_operand =wa))]
TARGET_POWERPC64 TARGET_DIRECT_MOVE
#
reload_completed
[(const_int 0)]
{
rtx op0 = operands[0];
rtx op1 = operands[1];
rtx op2 = operands[2];
rtx op3 = operands[3];
rtx op1_di = simplify_gen_subreg (DImode, op1, SFmode, 0);
/* Move SF value to upper 32-bits for xscvspdpn. */
emit_insn (gen_ashldi3 (op2, op1_di, GEN_INT (32)));
emit_move_insn (op3, op2);
emit_insn (gen_vsx_xscvspdpn_directmove (op0, op3));
DONE;
}
[(set_attr length 8)
(set_attr type two)])
would work too. The difference is that the above would always allocate
two separate FPRs, which is wasteful, so the pattern is trying to use
the same register for both the temporary value and the final result.
But I suppose it just doesn't seem that crude to me.
[Bug c/60784] Spurious -Wmissing-field-initializers warning for anonymous structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60784 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-08 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. .b = X is designated initializer and -Wmissing-field-initializers shouldn't warn for them.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #208 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Both issues from Comment 201 were fixed by: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00338.html
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Tue Apr 8 08:23:56 2014 New Revision: 209210 URL: http://gcc.gnu.org/viewcvs?rev=209210root=gccview=rev Log: PR ada/60411 * gcc-interface/Makefile.in (arm% linux-android): Switch to EHABI. * s-linux-android.ads: New file. * s-intman-android.adb: Likewise. Added: trunk/gcc/ada/s-intman-android.adb trunk/gcc/ada/s-linux-android.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in
[Bug tree-optimization/60785] [4.9 Regression] ICE in gsi_for_stmt w/ -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60785 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-08 Component|other |tree-optimization Target Milestone|--- |4.9.0 Summary|ICE in gsi_for_stmt w/ -O2 |[4.9 Regression] ICE in |-ftree-loop-linear |gsi_for_stmt w/ -O2 ||-ftree-loop-linear Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, I'll have a look.
[Bug lto/60779] -fcx-fortran-rules ignored when using -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60779 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto, missed-optimization Status|RESOLVED|ASSIGNED Last reconfirmed||2014-04-08 Component|c++ |lto Resolution|INVALID |--- Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Well, LTO unconditionally sets flag_complex_method to 2 currently. It does not yet conservatively merge TU choices and complex lowering happens too late. Thus, confirmed and mine.
[Bug target/60778] shift not folded into shift on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60778
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-04-08
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Confirmed. A bit difficult since
(insn 7 6 8 2 (parallel [
(set (reg:DI 89 [ D.1754 ])
(ashiftrt:DI (reg/v:DI 86 [ x ])
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) t.i:3 532 {*ashrdi3_1}
(nil))
(insn 8 7 9 2 (set (reg:DF 90)
(mem:DF (plus:DI (mult:DI (reg:DI 89 [ D.1754 ])
(const_int 8 [0x8]))
(reg/f:DI 88)) [2 mem S8 A64])) t.i:3 128 {*movdf_internal}
(nil))
don't combine well (and:DI is not valid inside the MEM), but a
define-insn-and-split may be able to handle this.
[Bug tree-optimization/60785] [4.9 Regression] ICE in gsi_for_stmt w/ -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60785 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I have a patch.
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Tue Apr 8 09:03:42 2014 New Revision: 209211 URL: http://gcc.gnu.org/viewcvs?rev=209211root=gccview=rev Log: PR ada/60411 * sigtramp-armdroid.c: New file. Added: trunk/gcc/ada/sigtramp-armdroid.c Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in
[Bug fortran/60781] cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781 --- Comment #5 from Laura C lauraelcomeau at yahoo dot co.uk --- Yes, I type ./JIM_exenamelist.txt to run the executable. The executable appears to read the files under the 'grids' section of the namelist successfully, but produces this error when reading the met_file under the 'drive' section. The filename is correct and the met_file exists (a different error is produced if the file is missing or the name is incorrect). I can attach the executable if that helps?
[Bug lto/60779] -fcx-fortran-rules ignored when using -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60779 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Note this applies to the case where you don't specify any -fcx-* flag on the linker command-line (or on any of the input TUs, but merging conflicting flags there doesn't work).
[Bug libstdc++/60594] std::function of a type with a declared (but not defined) return type fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60594 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Mitsuru Kariya from comment #5) FYI, the BUG2 above is compiled successfully by gcc 4.7.3. Yes, but std::function in 4.7.3 fails other, more important tests.
[Bug fortran/60781] cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Curly quotes in met_file = ‘met_04270_62_65.txt’ The following code implicit none character(len=70) :: dem_file='', ! Elevation file name met_file='', ! Driving data file name vegf_file='', ! Vegetation fraction file name vegh_file='', ! Vegetation height file name wind_file='', ! Wind distribution file name RunID='' ! Run identifier integer :: Nsmax,Nsoil,noff, d, ! Discretized wind direction (1 = NE, 2 = E, ..., 8 = N) i,j, ! Grid indices is,js, ! Grid location of met station dayout(12),monthout(12) real :: dt,lat,windir,zT,zU, sx,sy, ! Coordinates of met station (m) Waws, ! Wind speed at met station xlo,ylo, ! Grid SW corner coordinates (m) xhi,yhi ! Grid NE corner coordinates (m) real, allocatable :: dzdx(:,:), ! Partial derivative dzdy(:,:) ! Partial derivative namelist /grids/ dem_file,vegf_file,vegh_file,wind_file,Nsmax,Nsoil,sx,sy namelist /drive/ dt,lat,met_file,noff,windir,zT,zU namelist /output/ RunID,dayout,monthout read(5, grids) read(5, drive) read(5, output) print *, dem_file,vegf_file,vegh_file,wind_file,Nsmax,Nsoil,sx,sy print *, dt,lat,met_file,noff,windir,zT,zU print *, RunID,dayout,monthout end reads the namelist once the curly quotes have replaced with '.
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to David Edelsohn from comment #10) I'm not questioning the analysis, I'm questioning the solution. Directly generating a register and jamming in the REGNO in this pattern seems sort of crude. gen_rtx_REG (DImode, REGNO (op0)); I think this idiom is very commonly used in other backends for this purpose, and is simple enough not to need any kind of extra wrapper. Just look e.g. at grep gen_rtx_REG' '.*REGNO gcc/config/i386/*.md Perhaps a one line comment would be useful, but other than that the #c7 patch looks just fine to me.
[Bug target/60602] gcc.c-torture/compile/pr28865.c FAILs on Solaris 9/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60602 --- Comment #4 from Rainer Orth ro at gcc dot gnu.org --- Author: ro Date: Tue Apr 8 10:56:04 2014 New Revision: 209213 URL: http://gcc.gnu.org/viewcvs?rev=209213root=gccview=rev Log: XFAIL gcc.c-torture/compile/pr28865.c on Solaris 9/SPARC (PR target/60602) PR target/60602 * gcc.c-torture/compile/pr28865.c: XFAIL on sparc*-*-solaris2.9* with as at -O0. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr28865.c
[Bug tree-optimization/60785] [4.9 Regression] ICE in gsi_for_stmt w/ -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60785 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/60785] [4.9 Regression] ICE in gsi_for_stmt w/ -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60785 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Apr 8 10:59:40 2014 New Revision: 209214 URL: http://gcc.gnu.org/viewcvs?rev=209214root=gccview=rev Log: 2014-04-08 Richard Biener rguent...@suse.de PR tree-optimization/60785 * graphite-sese-to-poly.c (rewrite_phi_out_of_ssa): Treat default defs properly. * gcc.dg/graphite/pr60785.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr60785.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-sese-to-poly.c trunk/gcc/testsuite/ChangeLog
[Bug target/60602] gcc.c-torture/compile/pr28865.c FAILs on Solaris 9/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60602 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #5 from Rainer Orth ro at gcc dot gnu.org --- I've now commited the patch to XFAIL the testcase for Solaris 9/SPARC/-O0/as. Rainer
[Bug fortran/60500] [4.7/4.8/4.9 Regression] Spurious warning on derived type initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60500 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- I haven't had enough time to work on this one but in the interest of getting this sorted for 4.9, I'm handling this as suggested by Jakub in the backend under targetm.const_not_ok_for_debug_p and disallowing anything that is minus (..) (sym_ref) except for minus (sym_ref) (sym_ref) where the DECL_SECTION_NAMEs are identical including null. Hopefully that will sort out the problem for 4.9 but we still need this investigated properly for later. ramana
[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60653 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|2014-03-31 00:00:00 |2014-04-08 Ever confirmed|0 |1 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Works for me with a cross to arm-linux-gnueabi and -O -mhard-float -march=armv7-a -mthumb -mfpu=vfpv3-d16 (not sure if that replicates gnueabihf). Also works with a cross to arm-linux-gnueabihf for me: rguenther@murzim:/abuild/rguenther/obj-arm-g/gcc ./f951 -quiet t.f90 -O rguenther@murzim:/abuild/rguenther/obj-arm-g/gcc ./gfortran -v Using built-in specs. COLLECT_GCC=./gfortran Target: arm-suse-linux-gnueabihf Configured with: /space/rguenther/src/svn/trunk/configure --target=arm-suse-linux-gnueabihf --enable-languages=c,c++,lto,fortran --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb Thread model: posix gcc version 4.9.0 20140408 (experimental) (GCC) thus, fixed?
[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 --- Comment #12 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Created attachment 32564 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32564action=edit patch... Fix so far tested just on the reduced and the full testcase. No issues. Now bootstrapping and regression testing on armhf. regards Ramana
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
4.8 prints
t.ii: In function ‘void _Z3fooi.constprop.0()’:
t.ii:14:8: warning: array subscript is above array bounds [-Warray-bounds]
z[i] = i;
^
which isn't perfect either. Is there a way for the C++ FE to get at the
original function decl that was cloned? Like with
Index: gcc/cp/error.c
===
--- gcc/cp/error.c (revision 209210)
+++ gcc/cp/error.c (working copy)
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.
#include pointer-set.h
#include c-family/c-objc.h
#include ubsan.h
+#include cgraph.h
#include new// For placement-new.
@@ -1145,7 +1146,17 @@ dump_decl (cxx_pretty_printer *pp, tree
case FUNCTION_DECL:
if (! DECL_LANG_SPECIFIC (t))
- pp_string (pp, M_(built-in));
+ {
+ cgraph_node *node;
+ if ((node = cgraph_get_node (t))
+ node-former_clone_of)
+ {
+ dump_decl (pp, node-former_clone_of, flags);
+ pp_string (pp, M_( clone));
+ }
+ else
+ pp_string (pp, M_(built-in));
+ }
else if (DECL_GLOBAL_CTOR_P (t) || DECL_GLOBAL_DTOR_P (t))
dump_global_iord (pp, t);
else
which prints
t.ii: In function 'void foo(int) clone':
t.ii:14:13: warning: iteration 3u invokes undefined behavior
[-Waggressive-loop-optimizations]
z[i] = i;
^
t.ii:13:3: note: containing loop
for (int i = 0; i s; i++)
^
t.ii:14:8: warning: array subscript is above array bounds [-Warray-bounds]
z[i] = i;
^
does former_clone_of apply recursively? Thus can we have a clone of a clone?
Is there a way to pretty-print the kind of clone? That is, say
clone with foo = 1 for a ipa-cp clone with parameter foo replaced by 1?
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Looks quite some usability regression to me, compared to 4.8. Making P1.
[Bug c++/60786] New: In C++11 an explicit instantiation with an unqualified name must be in the right namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60786
Bug ID: 60786
Summary: In C++11 an explicit instantiation with an unqualified
name must be in the right namespace
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
This should not be accepted in C++11 mode:
namespace A {
templatetypename T struct B { };
}
using A::B;
template class Bint;
[temp.explicit] p3:
An explicit instantiation shall appear in an enclosing namespace of its
template. If the name declared in the explicit instantiation is an unqualified
name, the explicit instantiation shall appear in the namespace where its
template is declared or, if that namespace is inline (7.3.1), any namespace
from its enclosing namespace set.
This is a change from C++03:
A definition of a class template or class member template shall be in scope at
the point of the explicit instantiation of the class template or class member
template.
[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32565 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32565action=edit gcc49-pr60655.patch Alternate fix, the issue on the non-fdata-sections testcase is that we have (note 226 225 227 (var_location rx (plus:SI (plus:SI (reg:SI 3 r3 [orig:192 ivtmp.37 ] [192]) (symbol_ref:SI (*.LANCHOR0) [flags 0x182])) (const:SI (minus:SI (const_int 323 [0x143]) (symbol_ref:SI (*.LANCHOR0) [flags 0x182]) NOTE_INSN_VAR_LOCATION) which hasn't been simplified into %r3+323. I think this patch is the right thing to do, but it is probably too risky for 4.9 now, too many targets do too weird things, especially for -fpic. Perhaps if we had a flag (global for 4.9) we are in var-tracking pass (guess current_pass strcmp (current_pass-name, vartrack) == 0 would be way too ugly), it might be safe to do that only for var-tracking and for 5.0 enable it unconditionally.
[Bug libfortran/60706] FAIL: gfortran.dg/size_kind_2.f90 -O scan-tree-dump original var2 = 42949673 00;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60706 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Apr 8 12:57:07 2014 New Revision: 209216 URL: http://gcc.gnu.org/viewcvs?rev=209216root=gccview=rev Log: 2014-04-08 Richard Biener rguent...@suse.de PR middle-end/60706 * tree-pretty-print.c (pp_double_int): For HWI32 hosts with a 64bit widest int print double-int similar to on HWI64 hosts. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-pretty-print.c
[Bug libfortran/60706] FAIL: gfortran.dg/size_kind_2.f90 -O scan-tree-dump original var2 = 42949673 00;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60706 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300 --- Comment #3 from Matthijs Kooijman matthijs at stdin dot nl --- Hmm, I don't think the gcc sources support that. AFAICT, they attempt to just find the shortest approach, without caring for speed. For example, look at avr.c, around line 1265, where it says: / Use shortest method / emit_insn (get_sequence_length (sp_plus_insns) get_sequence_length (fp_plus_insns) ? sp_plus_insns : fp_plus_insns); https://github.com/mirrors/gcc/blob/c2e306f5efb32b7eed856a1844487cff09aa86ac/gcc/config/avr/avr.c#L1265-L1270
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Richard Biener from comment #5) does former_clone_of apply recursively? Thus can we have a clone of a clone? Is there a way to pretty-print the kind of clone? That is, say clone with foo = 1 for a ipa-cp clone with parameter foo replaced by 1? Why would you want to do that? At least for diagnostics to the users (not debug dumps), that the function is a clone is an internal implementation detail.
[Bug middle-end/60787] New: [4.7 Regression] ICE in expand_builtin_eh_common, at except.c:1953
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60787 Bug ID: 60787 Summary: [4.7 Regression] ICE in expand_builtin_eh_common, at except.c:1953 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: EH, ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Created attachment 32566 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32566action=edit autoreduced testcase g++ -S -O bug-872323_bug.3.3.3.3.cpp bug-872323_bug.3.3.3.3.cpp: In member function ‘void JobMultiWaiter::add(JobHandle)’: bug-872323_bug.3.3.3.3.cpp:229:6: internal compiler error: in expand_builtin_eh_common, at except.c:1953 Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions.
[Bug middle-end/60787] [4.7 Regression] ICE in expand_builtin_eh_common, at except.c:1953
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60787 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.4, 4.8.0, 4.9.0 Version|4.9.0 |4.7.3 Target Milestone|--- |4.7.4 Known to fail||4.7.0, 4.7.3
[Bug middle-end/60787] [4.7 Regression] ICE in expand_builtin_eh_common, at except.c:1953
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60787 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Maybe latent on 4.8/4.9, different inlining happens there.
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761
--- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
which isn't perfect either. Is there a way for the C++ FE to get at the
original function decl that was cloned? Like with
Index: gcc/cp/error.c
===
--- gcc/cp/error.c (revision 209210)
+++ gcc/cp/error.c (working copy)
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.
#include pointer-set.h
#include c-family/c-objc.h
#include ubsan.h
+#include cgraph.h
#include new// For placement-new.
@@ -1145,7 +1146,17 @@ dump_decl (cxx_pretty_printer *pp, tree
case FUNCTION_DECL:
if (! DECL_LANG_SPECIFIC (t))
- pp_string (pp, M_(built-in));
+ {
+ cgraph_node *node;
+ if ((node = cgraph_get_node (t))
+ node-former_clone_of)
+ {
+ dump_decl (pp, node-former_clone_of, flags);
+ pp_string (pp, M_( clone));
+ }
+ else
+ pp_string (pp, M_(built-in));
+ }
else if (DECL_GLOBAL_CTOR_P (t) || DECL_GLOBAL_DTOR_P (t))
dump_global_iord (pp, t);
else
Wouldn't it be better for the middle end to provide its own diagnostic_starter
function, which in turn calls the FE one and override
current_function_declaration around the call to the FE one by the original
function?
This will also allow in the future the middle-end to override other stuff that
it doesn't want the FE to deal with.
[Bug middle-end/60787] [4.7 Regression] ICE in expand_builtin_eh_common, at except.c:1953
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60787
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-04-08
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
This is what creduce came up with:
template class T void destroy (T *);
template class FI struct ArrayFill
{
ArrayFill (FI, FI p2) : tgt_start_ (), tgt_end_ (p2) {}
template class Val void m_fn1 (Val , int )
{
while (tgt_cur_ != tgt_end_)
++tgt_cur_;
}
~ArrayFill () throw()
{
if (tgt_cur_ != tgt_end_)
while (tgt_cur_ != tgt_start_)
{
--tgt_cur_;
destroy (*tgt_cur_);
}
}
const FI tgt_start_, tgt_end_;
FI tgt_cur_;
};
template class FI, class Val
inline FI uninitialized_fill (FI p1, FI p2, Val p3, int p4)
{
ArrayFillFI a (p1, p2);
a.m_fn1 (p3, p4);
}
template class, typename struct A
{
typedef int *pointer;
typedef int const_reference;
template class Val2 int m_fn1 (const AVal2, int p1)
{
return cur_ == p1.cur_;
}
const_reference operator*() {}
void operator++()
{
if (last_)
cur_ = first_;
}
void operator--() { --cur_; }
pointer cur_;
pointer first_;
pointer last_;
};
template class Val, class Val2, typename BufSize
inline int operator==(AVal, BufSize p1, const AVal2, BufSize p2)
{
return p1.m_fn1 (p2);
}
template class Val, class Val2, typename BufSize
inline int operator!=(AVal, BufSize p1, const AVal2, BufSize p2)
{
return !(p1 == p2);
}
struct B
{
typedef Aint, int::const_reference const_reference;
};
class C
{
public:
typedef B::const_reference const_reference;
int *p_ma_;
struct MapCreator
{
~MapCreator ();
};
struct MultiNodeCreator
{
MultiNodeCreator (Aint, int::pointer *, Aint, int::pointer *, int p3)
: ma_ (p3)
{
}
~MultiNodeCreator () throw();
void m_fn1 ();
int ma_;
};
void m_fn1 (Aint, int::pointer *, Aint, int::pointer *, int )
{
MultiNodeCreator b (0, 0, *p_ma_);
b.m_fn1 ();
}
C::MapCreator initialize_map__new_map;
int m_fn2_p3;
void m_fn2 (int, int)
{
m_fn1 (0, 0, m_fn2_p3);
this-finish_.cur_ = this-finish_.first_;
}
C (int );
Aint, int start_;
Aint, int finish_;
};
class G : C
{
void m_fn3 (const_reference p1, const int )
{
this-m_fn2 (0, 0);
uninitialized_fill (this-start_, this-finish_, p1, *this-p_ma_);
}
public:
G (int, const_reference p2, int p3) : C (p3) { m_fn3 (p2, 0); }
void m_fn4 (const_reference p1) { G (0, p1, *this-p_ma_); }
};
class F
{
void m_fn1 (int );
G m_jobs;
};
void F::m_fn1 (int p1) { m_jobs.m_fn4 (p1); }
[Bug rtl-optimization/60776] [4.9 Regression] FAIL gcc.dg/builtin-bswap-6.c and gcc.dg/builtin-bswap-7.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60776 --- Comment #3 from Andreas Krebbel krebbel at gcc dot gnu.org --- Author: krebbel Date: Tue Apr 8 14:18:46 2014 New Revision: 209221 URL: http://gcc.gnu.org/viewcvs?rev=209221root=gccview=rev Log: 2014-04-08 Andreas Krebbel andreas.kreb...@de.ibm.com PR rtl-optimization/60776 * gcc.dg/builtin-bswap-6.c: Use -mbranch-cost=0 for s390. * gcc.dg/builtin-bswap-7.c: Likewise. * gcc.dg/builtin-bswap-6a.c: New testcase. * gcc.dg/builtin-bswap-7a.c: New testcase. Revert 2014-04-04 Andreas Krebbel andreas.kreb...@de.ibm.com * gcc.dg/builtin-bswap-6.c: Adjust return value to disable GCC optimization. * gcc.dg/builtin-bswap-7.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/builtin-bswap-6a.c trunk/gcc/testsuite/gcc.dg/builtin-bswap-7a.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/builtin-bswap-6.c trunk/gcc/testsuite/gcc.dg/builtin-bswap-7.c
[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60653 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- This has been fixed by the r208926 fix (PR60697), the backtrace is the same as well. CCing Vlad whether we want to just add the testcase to the testsuite and close, or close without testcase, or whether this PR was just a different bug that just went latent with that fix.
[Bug rtl-optimization/60776] [4.9 Regression] FAIL gcc.dg/builtin-bswap-6.c and gcc.dg/builtin-bswap-7.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60776 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed, thanks.
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #13 from David Edelsohn dje at gcc dot gnu.org --- Gentlemen, I really do not understand this discussion. I used the term crude and receive a response that it is not crude, but it is dangerous. WTF? Why is anyone trying to sell the patch when I repeatedly have said that I do not disagree with it in principle? I only am trying to ensure that this is the right use of the GCC API. i386 uses this idiom a lot; rs6000 does not. I see multiple responses trying to convince me of a patch with which I already agree and no one writing a one line comment.
[Bug middle-end/58101] Wrong out-of-bounds warning under -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58101 Mikhail Veltishchev dichlofos-mv at yandex dot ru changed: What|Removed |Added CC||dichlofos-mv at yandex dot ru --- Comment #4 from Mikhail Veltishchev dichlofos-mv at yandex dot ru --- Luis, why do you state that rcu_num_levels is never larger than 1, this cannot be proved as this variable is not const and can change its value (e.g. in another thread).
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761
--- Comment #9 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
4.8 prints
t.ii: In function ‘void _Z3fooi.constprop.0()’:
t.ii:14:8: warning: array subscript is above array bounds [-Warray-bounds]
z[i] = i;
^
I think that we can perhaps get closest to that with something like:
pp_string (pp, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (t)));
which prints
zz.C: In function ‘_Z3fooi.constprop.0’:
by using DECL_NAME instead of DECL_ASSEMBLER_NAME we can get
avoid mangling:
zz.C: In function ‘foo.constprop’:
does former_clone_of apply recursively?
I believe that (at least currently) former_clone_of will always be the
original front-end declaration, i.e. the same as DECL_ABSTRACT_ORIGIN,
despite that...
Thus can we have a clone of a clone?
...yes, the infrastructure allows that, although currently only such
clones are inline clones and thus not posing this problem.
Is there a way to pretty-print the kind of clone? That is, say
clone with foo = 1 for a ipa-cp clone with parameter foo replaced by 1?
Hm, it would require changes elsewhere to do for aggregate
replacements (we'd need to remember the old decl and we remember only
offsets, not expressions), for scalar replacements it is already
apparently quite possible:
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 454feb5..bb8db31 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3. If not see
#include pointer-set.h
#include c-family/c-objc.h
#include ubsan.h
+#include cgraph.h
#include new// For placement-new.
@@ -1144,7 +1145,35 @@ dump_decl (cxx_pretty_printer *pp, tree t, int flags)
/* Fall through. */
case FUNCTION_DECL:
- if (! DECL_LANG_SPECIFIC (t))
+ if (DECL_ABSTRACT_ORIGIN (t))
+ {
+ dump_decl (pp, DECL_ABSTRACT_ORIGIN (t), flags);
+
+ cgraph_node *node = cgraph_get_node (t);
+ if (node node-clone.tree_map)
+ {
+ struct ipa_replace_map *rmap;
+ unsigned i;
+ bool first = true;
+ pp_string (pp, M_( clone with ));
+
+ FOR_EACH_VEC_ELT (*node-clone.tree_map, i, rmap)
+ {
+ if (first)
+ first = false;
+ else
+ pp_string (pp, (, ));
+
+ dump_expr (pp, rmap-new_tree, flags);
+ pp_string (pp, M_( for ));
+ dump_expr (pp, rmap-old_tree, flags);
+ }
+ pp_string (pp, );
+ }
+ else
+ pp_string (pp, M_( clone));
+ }
+ else if (! DECL_LANG_SPECIFIC (t))
pp_string (pp, M_(built-in));
else if (DECL_GLOBAL_CTOR_P (t) || DECL_GLOBAL_DTOR_P (t))
dump_global_iord (pp, t);
gives:
zz.C: In function ‘void foo(int) clone with 4 for s’:
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #14 from Michael Meissner meissner at linux dot vnet.ibm.com --- On Tue, Apr 08, 2014 at 03:21:13PM +, dje at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #13 from David Edelsohn dje at gcc dot gnu.org --- Gentlemen, I really do not understand this discussion. I used the term crude and receive a response that it is not crude, but it is dangerous. WTF? Why is anyone trying to sell the patch when I repeatedly have said that I do not disagree with it in principle? I only am trying to ensure that this is the right use of the GCC API. i386 uses this idiom a lot; rs6000 does not. I see multiple responses trying to convince me of a patch with which I already agree and no one writing a one line comment. When you are doing a subreg type operation, before reload, you must NOT use the register number directly. This is the dangerous part that was mentioned. Hence using gen_highpart, gen_lowpart, or simplify_gen_subreg is the appropriate solution. If you are doing splits after reload, and are dealing with whole registers, the preferred solution is to create a new REG with the appropriate register number. In particular, gen_highpart and gen_lowpart must not be used after reload. However, up until the patch to add more checking, simplify_gen_subreg could be used after reload. The alpha, arm, i386, ia64, iq2000, m32k, m68k, mips, msp430, pa, pdp11, picochip, rl78, rs6000, s390, sh, sparc, spu, and xtensa all generate a call to gen_rtx_REG using REGNO of an operand to change types. Out of force of habit, I've tended to use simplify_gen_subreg when doing splitting, no matter whether it is before or after reload. I thought with 'simplify' in the name, it would do the right thing after reload, but evidently it does not.
[Bug libstdc++/60037] SIGFPE in std::generate_canonicalunsigned int...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- clang's ubsan finds two errors /home/jwakely/src/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3478: runtime error: value 4.29497e+09 is outside the range of representable values of type 'unsigned int' /home/jwakely/src/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3480:20: runtime error: division by zero
[Bug target/60788] New: Miscompilation of __builtin_clz with -mlzcnt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60788 Bug ID: 60788 Summary: Miscompilation of __builtin_clz with -mlzcnt Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: linux at carewolf dot com Created attachment 32567 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32567action=edit Test case If you compile the attached program with -O0 and -mlzcnt on x86, it will produce wrong results. As long as optimization is greater than 0 or the lzcnt instruction is not available, it will produce correct results. Somehow log2 is returned for __builtin_clz instead of leading zero count. It almost looks like a wrong optimization except it only happens without optimizations. $ /opt/gcc/bin/g++-4.9 lzcnt_tst.cpp -O1 -g -mlzcnt -o lzcnt_tst $ ./lzcnt_tst nextPowerOfTwo(0) = 0 nextPowerOfTwo(1) = 1 nextPowerOfTwo(2) = 2 nextPowerOfTwo(17) = 32 $ /opt/gcc/bin/g++-4.9 lzcnt_tst.cpp -O0 -g -mlzcnt -o lzcnt_tst $ ./lzcnt_tst nextPowerOfTwo(0) = 0 nextPowerOfTwo(1) = 1 nextPowerOfTwo(2) = 1 nextPowerOfTwo(17) = 268435456 $ /opt/gcc/bin/g++-4.9 lzcnt_tst.cpp -O0 -o lzcnt_tst $ ./lzcnt_tst nextPowerOfTwo(0) = 0 nextPowerOfTwo(1) = 1 nextPowerOfTwo(2) = 2 nextPowerOfTwo(17) = 32
[Bug target/60788] Miscompilation of __builtin_clz with -mlzcnt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60788 --- Comment #1 from Allan Jensen linux at carewolf dot com --- Sorry. The optimization has nothing to do with it, it just causes the constant expressions used for testing to be evaluated at compile time. The real issue is that the lzcnt instruction does not return the number of leading zeroes, but the bitwidth minus the number of leading zeroes. So the mapping of _builtin_clz to lzcnt is simply naïve and incorrect.
[Bug target/60459] Crash seen in _Unwind_VRS_Pop() for ARM platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60459 Murali murali.marimekala at gmail dot com changed: What|Removed |Added CC||murali.marimekala at gmail dot com --- Comment #5 from Murali murali.marimekala at gmail dot com --- Hi Ramana, I am working with Raghu and looking into the same crash issue. Thanks for your suggestions till now. Due to some constraints , we cant move to a new toolchain. We are looking forward to fix this issue in ARM9 toolchain 4.2.1. Though we got a fix for this issue online, we need your expertise to port it to our toolchain. When we were searching for inputs, we came across following article. https://sourceware.org/ml/libc-ports/2011-03/msg00045.html In this article, Ryosei Takagi was facing the same issue (at exact location) and has provided a fix for it in __longjump.S. This particular __longjump.S is not available in toolchain 4.2.1. I searched for relevant code and couldnt find it. Since we are not much familiar with this toolchain code, its taking more time than expected to understand and port the code. So, need your valuable advise to find the relevant location to port this fix. If you need additional information, please let me know. Thank you, Murali
[Bug c/51088] undefined label with statement expression and cond expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51088
--- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org ---
Patch to give an error if taking an address of a label defined in ({}):
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00381.html
[Bug target/60788] Miscompilation of __builtin_clz with -mlzcnt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60788 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- LZCNT is encoded as F3 BSR: 0:f3 0f bd c0 lzcnt %eax,%eax 4:0f bd c0 bsr%eax,%eax Since your processor doesn't support LZCNT, F3 prefix is ignored and f3 0f bd c0 is treated as BSR. Before you use LZCNT, you need to check if your processor support it or not.
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Attachment #32557|0 |1 is obsolete|| --- Comment #15 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Created attachment 32568 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32568action=edit Patch with changelog and comment. Here's a version of the patch with a comment explaining the gen_rtx_REG.
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #16 from David Edelsohn dje at gcc dot gnu.org --- Comment on attachment 32568 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32568 Patch with changelog and comment. Okay. Thanks for the clarification.
[Bug sanitizer/60745] Many ICEs running libstdc++ testsuite with ubsan, maybe due to PCH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60745 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Apr 8 17:23:26 2014 New Revision: 209222 URL: http://gcc.gnu.org/viewcvs?rev=209222root=gccview=rev Log: PR sanitizer/60745 * c-ubsan.c: Include asan.h. (ubsan_instrument_return): Call initialize_sanitizer_builtins. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-ubsan.c
[Bug sanitizer/60745] Many ICEs running libstdc++ testsuite with ubsan, maybe due to PCH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60745 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #17 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- I'm just saying this for the record, and also to justify why I think the other use of simplify_gen_subreg is correct. (In reply to Michael Meissner from comment #14) When you are doing a subreg type operation, before reload, you must NOT use the register number directly. This is the dangerous part that was mentioned. David was quoting me with the dangerous thing, so for what it's worth, I meant that it would be dangerous to have a version of simplify_gen_subreg that ignored CANNOT_CHANGE_MODE_CLASS. And as long as simplify_gen_subreg honours CANNOT_CHANGE_MODE_CLASS, a DImode subreg of an SFmode FPR is going to return a subreg rather than a plain reg. I definitely agree that using gen_rtx_REG before reload is dangerous too of course. I just wanted to clarify what I meant. Hence using gen_highpart, gen_lowpart, or simplify_gen_subreg is the appropriate solution. Agreed, If you are doing splits after reload, and are dealing with whole registers, the preferred solution is to create a new REG with the appropriate register number. In particular, gen_highpart and gen_lowpart must not be used after reload. However, up until the patch to add more checking, simplify_gen_subreg could be used after reload. FWIW, I think gen_lowpart, gen_highpart and simplify_gen_subreg are always OK if what you are doing is changing the mode of a value. They are supposed to handle both hard and pseudo registers. So I think the other use of simplify_gen_subreg in this pattern is OK (and gen_lowpart would be have been OK too). Using gen_rtx_REG wouldn't be wrong as such, but it would lose things like ORIGINAL_REGNO. The difference here is that we have a DImode temporary value and an SFmode result that both need the same hard register. The DImode value is written and read only in DImode and the result is written only in SFmode, so there's no real mode change. That's the kind of case where gen_rtx_REG is needed. Out of force of habit, I've tended to use simplify_gen_subreg when doing splitting, no matter whether it is before or after reload. I thought with 'simplify' in the name, it would do the right thing after reload, but evidently it does not. Well, I suppose it depends on what the expectations are. If the target forbids a particular mode change for a particular hard register, simplify_gen_subreg will return a subreg rather than a reg. IMO that's the right thing to do, since it keeps the information that you have a mode change that can't be reduced to a plain reg. Returning null would be another option (maybe better) but would probably have a big impact. So I think the problem in this case was that we were modelling the reuse of the destination register as a mode change when it wasn't really, and the mode change in question was one that the target normally tries to prevent.
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #18 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Apr 8 17:50:45 2014 New Revision: 209223 URL: http://gcc.gnu.org/viewcvs?rev=209223root=gccview=rev Log: gcc/ PR target/60763 * config/rs6000/vsx.md (vsx_xscvdpspn_scalar): Change input to DImode. * config/rs6000/rs6000.md (reload_vsx_from_gprsf): Update accordingly. Use gen_rtx_REG rather than simplify_gen_subreg for op0_di. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/config/rs6000/vsx.md
[Bug target/60788] Miscompilation of __builtin_clz with -mlzcnt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60788 --- Comment #3 from Allan Jensen linux at carewolf dot com --- Sorry for the confusion. I thought Intel had added it from Ivy Bridge, but it was Haswell.
[Bug libstdc++/60789] New: [4.9 Regression] Missing -lm while checking for math functions (e.g., atan2f)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60789 Bug ID: 60789 Summary: [4.9 Regression] Missing -lm while checking for math functions (e.g., atan2f) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: david.abdurachmanov at gmail dot com Math functions tests are failing with GCC 4.9.0 (trunk, r209221), while working fine at least up to 4.8.1. Tested on x86_64 (Scientific Linux 6.5) and aarch64 (Fedora 19). Looking at compile time, seems that `-lm` was lost. This caused a number of _GLIBCXX_HAVE_* not being defined for math functions in `c++config.h`, thus causes functions like `atan2f` to call `(float)atan2(x, y)`. # Fragment from ./x86_64-unknown-linux-gnu/libstdc++-v3/config.log, GCC 4.8.1, checking for `atan2f`. configure:22347: checking for atan2f declaration configure:22372: /build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/./gcc/xgcc -shared-libgcc -B/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/./gcc -nostdinc++ -L/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/x86_64-redhat-linux-gnu/libstdc++-v3/src -L/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/x86_64-redhat-linux-gnu/libstdc++-v3/src/.libs -B/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/bin/ -B/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/lib/ -isystem /build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/include -isystem /build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/sys-include -c -fno-builtin -D_GNU_SOURCE conftest.cpp 5 configure:22372: $? = 0 configure:22388: result: yes configure:22394: checking for atan2f configure:22394: /build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/./gcc/xgcc -B/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/./gcc/ -B/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/bin/ -B/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/lib/ -isystem /build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/include -isystem /build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/sys-include -o conftest -g -O2 conftest.c -lm 5 conftest.c:161:6: warning: conflicting types for built-in function 'atan2f' [enabled by default] char atan2f (); ^ configure:22394: $? = 0 configure:22394: result: yes # Same from GCC 4.9.0 configure:22559: checking for atan2f declaration configure:22584: /build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/./gcc/xgcc -shared-libgcc -B/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/./gcc -nostdinc++ -L/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/x86_64-redhat-linux-gnu/libstdc++-v3/src -L/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/x86_64-redhat-linux-gnu/libstdc++-v3/src/.libs -L/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/x86_64-redhat-linux-gnu/libstdc++-v3/libsupc++/.libs -B/build1/davidlt/gcc421diff/490/a/tmp/BUILDROOT/b60735266dcb81302bac5b296e8c0965/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/x86_64-redhat-linux-gnu/bin/ -B/build1/davidlt/gcc421diff/490/a/tmp/BUILDROOT/b60735266dcb81302bac5b296e8c0965/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/x86_64-redhat-linux-gnu/lib/ -isystem /build1/davidlt/gcc421diff/490/a/tmp/BUILDROOT/b60735266dcb81302bac5b296e8c0965/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/x86_64-redhat-linux-gnu/include -isystem /build1/davidlt/gcc421diff/490/a/tmp/BUILDROOT/b60735266dcb81302bac5b296e8c0965/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/x86_64-redhat-linux-gnu/sys-include -c -fno-builtin
[Bug fortran/60774] f951: internal compiler error: Segmentation fault: 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60774 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-08 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.5 to 4.9 (trunk). Compiling the following reduced tests program energy implicit none ! all dble integer(kind=4)::ns ! size of spatial lattice integer(kind=4)::i,j,k,l integer(kind=4),allocatable::back(:,:) ! works up to 20,10 integer(kind=4)::di,index doubleprecision,allocatable::sumffi(:) doubleprecision,allocatable::f(:,:,:,:) ! the dimensionless field go to 123 do di = 0, ns/2 sumffi(di) = sumffi(di) + f(i,j,k,l)*f(back(i,di),j,k,l) end do 123 contains function T(i,j,k,l,iu,ju,ku,lu,id,jd,kd,ld) ! only what depends on ijkl doubleprecision::T integer(kind=4)::i,j,k,l,iu,id,ju,jd,ku,kd,lu,ld T = f(i,j,k,l)*( f(i,j,k,l) - f(iu,j,k,l) - f(id,j,k,l) ) end function T end program energy gives and ICE with 4.5, the error pr60774_red.f90:13.3: 123 1 Warning: Ignoring statement label in empty statement at (1) pr60774_red.f90:9.11: go to 123 1 Error: Label 123 referenced at (1) is never defined with 4.6 and 4.7, and pr60774_red.f90:13.3: 123 1 Warning: Ignoring statement label in empty statement at (1) During initialization Error: Label 1119913824 referenced at (1) is never defined with 4.8 and 4.9 (and an ICE with my working tree!-).
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Tue Apr 8 20:35:14 2014 New Revision: 209227 URL: http://gcc.gnu.org/viewcvs?rev=209227root=gccview=rev Log: PR ada/60411 * sigtramp.h: Add Android support. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sigtramp.h
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
John Marino gnugcc at marino dot st changed:
What|Removed |Added
CC||gnugcc at marino dot st
--- Comment #11 from John Marino gnugcc at marino dot st ---
Eric,
Thanks for these commits. However, I'm still unable to build
arm-aux-linux-androideabi cross-compiler target after 209227.
This is the current error:
s-osinte.ads:593:07: component sa_flags overlaps sa_mask at line 592
This happens when a-dynpri.adb is being compiled. s-osinte.ads is
s-osinte-android.ads of course.
I think this is a direct consequence of #include asm/signal.h at sigtramp.h
s-ointe-android.ads, lines 590-594:
for struct_sigaction use record
sa_handler at Linux.sa_handler_pos range 0 .. Standard'Address_Size - 1;
sa_maskat Linux.sa_mask_posrange 0 .. 1023;
sa_flags at Linux.sa_flags_pos range 0 .. Standard'Address_Size - 1;
end record;
asm/signal.h (NDK, API 15):
typedef unsigned long sigset_t;
struct sigaction {
union {
__sighandler_t _sa_handler;
void (*_sa_sigaction)(int, struct siginfo *, void *);
} _u;
sigset_t sa_mask;
unsigned long sa_flags;
void (*sa_restorer)(void);
};
So it does seem that struct_sigaction record isn't correct after all.
John
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #12 from John Marino gnugcc at marino dot st --- I am also seeing these errors: s-intman.adb:263:32: SA_NODEFER is not visible s-intman.adb:263:32: non-visible declaration at s-linux.ads:110 s-intman.adb:263:45: SA_RESTART is not visible s-intman.adb:263:45: non-visible declaration at s-linux.ads:109
[Bug fortran/60781] cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781 --- Comment #7 from Laura C lauraelcomeau at yahoo dot co.uk --- I've tried changing the Input.f90 code to character(len=70) :: dem_file='', ! Elevation file name met_file='', ! Driving data file name vegf_file='', ! Vegetation fraction file name vegh_file='', ! Vegetation height file name wind_file='', ! Wind distribution file name RunID='' ! Run identifier i.e adding the ='' into the code, but I still get the same namelist error. Is this what you meant by the 'curly quotes'? Laura
[Bug fortran/60781] cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781 --- Comment #8 from Laura C lauraelcomeau at yahoo dot co.uk --- I've tried changing the Input.f90 code to character(len=70) :: dem_file='', ! Elevation file name met_file='', ! Driving data file name vegf_file='', ! Vegetation fraction file name vegh_file='', ! Vegetation height file name wind_file='', ! Wind distribution file name RunID='' ! Run identifier i.e adding the ='' into the code, but I still get the same namelist error. Is this what you meant by the 'curly quotes'? Laura
[Bug fortran/60781] cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781 --- Comment #9 from Steve Kargl sgk at troutmask dot apl.washington.edu --- Is this what you meant by the 'curly quotes'? No. Your input file contains curly quotes. I've changed the curly quotes to # show you where the problem lies. met_file = #met_04270_62_65.txt# Compare the quoting for vegh_file and met_file. You need to use ASCII character 39. Looks like your input file is using extended ASCII characters 145 and 146. gfortran is expected ASCII not extended ASCII.
[Bug c++/59115] [4.7/4.8/4.9 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59115 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Apr 9 00:09:28 2014 New Revision: 209230 URL: http://gcc.gnu.org/viewcvs?rev=209230root=gccview=rev Log: /cp 2014-04-08 Paolo Carlini paolo.carl...@oracle.com PR c++/59115 * pt.c (process_template_parm): For an invalid non-type parameter only set TREE_TYPE to error_mark_node. (push_inline_template_parms_recursive, comp_template_parms, redeclare_class_template, coerce_template_template_parm, coerce_template_template_parms, unify): Use error_operand_p. /testsuite 2014-04-08 Paolo Carlini paolo.carl...@oracle.com PR c++/59115 * g++.dg/template/crash119.C: New. Added: trunk/gcc/testsuite/g++.dg/template/crash119.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/59115] [4.7/4.8/4.9 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59115 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|4.7.4 |4.9.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug go/60790] New: libatomic convenience library selects IFUNC implementation before obtaining cpu info.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790 Bug ID: 60790 Summary: libatomic convenience library selects IFUNC implementation before obtaining cpu info. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: gary at intrepid dot com CC: nenad at intrepid dot com, PHHargrove at lbl dot gov, rth at gcc dot gnu.org Created attachment 32569 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32569action=edit libatomic cpuinfo patch We ran into this issue recently while implementing atomic memory support for GNU UPC. We followed an approach similar to libgo -- we included libatomic_convenience.a into libgupc.a. This lets libgupc access GCC's __atomic support without requiring the user to link explicitly with libatomic. While debugging the UPC AMO library on a modern X86-64 platform, we noticed that the locked implementation of compare-exchange-16 was being used in spite of the fact of that the CPU supports the CMPX16 operation directly. We determined that the IFUNC selector function was being called before the constructor function in init.c had run. Thus the libat_feat1_ecx variable was zero. Because the feature bit wasn't set, the selector function chose the CAS function which requires explicit locks. Interestingly, __atomic_is_lock_free(16, NULL) returns true, as expected on this platform because it is called after the init_cpuid() constructor is called. One way to fix this issue is to re-work the logic that queries the CPU feature register value, so that it explicitly initializes the value if it is zero. The assumption here is that __get_cpuid() will always return a non-zero value in the ECX feature register. A patch that implements this approach is attached.
[Bug go/60790] libatomic convenience library selects IFUNC implementation before obtaining cpu info.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790 Gary Funck gary at intrepid dot com changed: What|Removed |Added Attachment #32569|0 |1 is obsolete|| --- Comment #1 from Gary Funck gary at intrepid dot com --- Created attachment 32570 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32570action=edit libatomic cpuinfo patch Test for edx when checking bit_CMPXCHG8B.
[Bug c/59073] [4.9 Regression] ICE with missing increment in OpenMP for-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59073 Arseny Solokha asolokha at gmx dot com changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #4 from Arseny Solokha asolokha at gmx dot com --- Cannot reproduce it w/ 4.9.0 20140406.
[Bug libgcc/60790] libatomic convenience library selects IFUNC implementation before obtaining cpu info.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|go |libgcc Resolution|--- |INVALID Assignee|ian at airs dot com|unassigned at gcc dot gnu.org --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- It is better if you just link directly against libatomic. We already require that for C11 _Atomic support in some/most cases. We followed an approach similar to libgo libgo needs to be fixed the same way really.
[Bug libstdc++/50160] vectorbool comparison very slow (no overload)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160 Elizbath Martin elizbathjames at gmail dot com changed: What|Removed |Added CC||elizbathjames at gmail dot com --- Comment #40 from Elizbath Martin elizbathjames at gmail dot com --- Key factors might be the reason due to which its showing slow behavior. Make a class of it and use it for the simple. https://sourceforge.net/projects/working-of-smoothie-machines/ sometimes they shows the abnormal behavior their might be list of reason you have to Go for.
[Bug c/11751] wrong evaluation order of an expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751 Elizbath Martin elizbathjames at gmail dot com changed: What|Removed |Added CC||elizbathjames at gmail dot com --- Comment #87 from Elizbath Martin elizbathjames at gmail dot com --- For the good expansion order make a step by step working Like when go for the buying of the juicer/blender http://zinch.zendesk.com/entries/31114770-Locating-Smoothie-Makers-In-Low-price customer feedback is the key of the success. So For the right order of the expansion an expert advice can work better for you.
