[Bug c++/54413] Option for turning off compiler extensions for -std=c++11 with respect to complex/fixed-point numbers missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54413 --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-12 09:12:35 UTC --- Ed, N.B. if you use the ChangeLog entry as the svn commit log then the PR number in the log means Bugzilla gets automatically updated with a link to the commit, and you don't need to attach it
[Bug c++/55280] Compiler error: Class definition is recognized as function declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55280 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-12 09:16:39 UTC --- As Andrew said, this is not a bug, see http://en.wikipedia.org/wiki/Most_vexing_parse You can force it to be parsed as a variable declaration with A a((B()))
[Bug fortran/55272] [4.8 Regression] ICE on passing coarray argument between files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55272
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--- |4.8.0
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-12
09:21:16 UTC ---
The culprit seems to be Rev. 189881.
Untested patch:
--- module.c(Revision 193396)
+++ module.c(Arbeitskopie)
@@ -2395,7 +2395,7 @@ mio_array_spec (gfc_array_spec **asp)
if (iomode == IO_INPUT as-corank)
as-cotype = (as-type == AS_DEFERRED) ? AS_DEFERRED : AS_EXPLICIT;
- if (as-rank 0)
+ if (as-rank + as-corank 0)
for (i = 0; i as-rank + as-corank; i++)
{
mio_expr (as-lower[i]);
[Bug c++/55280] Compiler error: Class definition is recognized as function declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55280 --- Comment #3 from Guangmu Zhu guangmuzhu at gmail dot com 2012-11-12 09:22:01 UTC --- (In reply to comment #2) As Andrew said, this is not a bug, see http://en.wikipedia.org/wiki/Most_vexing_parse You can force it to be parsed as a variable declaration with A a((B())) I got it. Thanks a lot!
[Bug tree-optimization/55281] New: [4.8 Regression] ICE in build_int_cst_wide, at tree.c:1217 (with Ofast, ok with O3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55281
Bug #: 55281
Summary: [4.8 Regression] ICE in build_int_cst_wide, at
tree.c:1217 (with Ofast, ok with O3)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
Created attachment 28666
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28666
preprocesse real-file code
c++ -std=gnu++11 -Ofast -c PhiPattern.ii
plugins/PhiPattern.cc: In member function 'virtual int
PhiPattern::produce(WhiteBoard)':
plugins/PhiPattern.cc:26:5: internal compiler error: in build_int_cst_wide, at
tree.c:1217
int PhiPattern::produce(WhiteBoard event) {
^
0xd393ab build_int_cst_wide(tree_node*, unsigned long, long)
../../gcc-trunk/gcc/tree.c:1217
0xd3990e double_int_to_tree(tree_node*, double_int)
../../gcc-trunk/gcc/tree.c:1067
0xd39dea build_int_cst(tree_node*, long)
../../gcc-trunk/gcc/tree.c:1044
0xbefd2b fold_relational_const(tree_code, tree_node*, tree_node*, tree_node*)
[clone .437619]
../../gcc-trunk/gcc/fold-const.c:16163
0xb870b9 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc-trunk/gcc/fold-const.c:9801
0xba8eef fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc-trunk/gcc/fold-const.c:14676
0xc9f217 fold_binary_op_with_conditional_arg(unsigned int, tree_code,
tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, int) [clone
.437722]
../../gcc-trunk/gcc/fold-const.c:6011
0xb89fb4 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc-trunk/gcc/fold-const.c:9887
0xa3d04a combine_cond_expr_cond
../../gcc-trunk/gcc/tree-ssa-forwprop.c:367
0xa3d2c4 forward_propagate_into_comparison_1(gimple_statement_d*, tree_code,
tree_node*, tree_node*, tree_node*) [clone .1031067]
../../gcc-trunk/gcc/tree-ssa-forwprop.c:414
0x5fccc5 forward_propagate_into_cond
../../gcc-trunk/gcc/tree-ssa-forwprop.c:562
0x5fccc5 ssa_forward_propagate_and_combine
../../gcc-trunk/gcc/tree-ssa-forwprop.c:3012
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[innocent@vinavx0 Octave]$ c++ -std=gnu++11 -O3 -c PhiPattern.ii
[innocent@vinavx0 Octave]$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--prefix=/afs/cern.ch/user/i/innocent/w2 --enable-languages=c,c++,lto,fortran
-enable-gold=yes --enable-lto --with-build-config=bootstrap-lto
--with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64
-with-mpc-lib=/usr/local/lib64 --enable-cloog-backend=isl
--with-cloog=/usr/local --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2
-ftree-vectorize -fPIC' CXXFLAGS='-O2 -fPIC -ftree-vectorize
-fvisibility-inlines-hidden -march=native' -enable-libitm -disable-multilib
Thread model: posix
gcc version 4.8.0 20121112 (experimental) [trunk revision 193427] (GCC)
same with
bzip2 -d PhiPattern.ii.bz2
pb-d-128-141-131-26:bugs48 innocent$ c++ -std=gnu++11 -O3 -c PhiPattern.ii
pb-d-128-141-131-26:bugs48 innocent$ c++ -std=gnu++11 -Ofast -c PhiPattern.ii
plugins/PhiPattern.cc: In member function ‘virtual int
PhiPattern::produce(WhiteBoard)’:
plugins/PhiPattern.cc:26:5: internal compiler error: in build_int_cst_wide, at
tree.c:1217
plugins/PhiPattern.cc:26:5: internal compiler error: Abort trap: 6
c++: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6
pb-d-128-141-131-26:bugs48 innocent$
pb-d-128-141-131-26:bugs48 innocent$
pb-d-128-141-131-26:bugs48 innocent$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin12.2.0/4.8.0/lto-wrapper
Target: x86_64-apple-darwin12.2.0
Configured with: ./configure --enable-languages=c,c++,fortran
--disable-multilib --disable-bootstrap --enable-lto -disable-libitm
Thread model: posix
gcc version 4.8.0 20121109 (experimental) [trunk revision 193360] (GCC)
[Bug rtl-optimization/54127] [4.7/4.8 Regression] ICE in maybe_record_trace_start with asm goto, --target=powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54127 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-12 10:18:24 UTC --- Created attachment 28667 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28667 gcc48-pr54127.patch Untested fix.
[Bug fortran/55282] New: openmp directive and classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55282 Bug #: 55282 Summary: openmp directive and classes Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: valerywe...@hotmail.com Dear All The following code doesnt compile at all with the lattest gfortran. The problem seems to be in the class definition of the variable this (works fine while declared as type). gcc version 4.8.0 20121112 (experimental) (GCC) module mod use omp_lib type :: my_t integer :: i end type my_t contains subroutine init( this ) class( my_t ) :: this !type( my_t ) :: this write(*,*) 'init thread=',omp_get_thread_num() this%i=2 end subroutine init end module mod program prog use mod type( my_t ) :: a !$omp parallel default( none ) !$omp private( a ) !$omp num_threads( 4 ) call init(a) !$omp end parallel end program prog -- gfortran-trunk prog.f90 -fopenmp bug.f90: In function ‘prog’: bug.f90:21:0: error: ‘__vtab_mod_My_t’ not specified in enclosing parallel call init(a) ^ bug.f90:20:0: error: enclosing parallel !$omp num_threads( 4 ) Thanks Valery
[Bug tree-optimization/55281] [4.8 Regression] ICE in build_int_cst_wide, at tree.c:1217 (with Ofast, ok with O3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55281
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-11-12
CC||jakub at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.8.0
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-12
10:33:27 UTC ---
Short testcase:
typedef float VF __attribute__((vector_size (16)));
VF x;
void
foo (void)
{
VF a, b, c;
a = (VF) { 1.0, 2.0, 3.0, 4.0 };
b = (VF) { 5.0, 6.0, 7.0, 8.0 };
c = (VF) { 0.0, 0.0, 0.0, 0.0 };
x = c != ((VF) { 0.0, 0.0, 0.0, 0.0 }) ? a : b;
}
with -Ofast. I was surprised only C++ handles this and not C BTW.
[Bug target/41993] [sh] ICE in create_pre_exit, at mode-switching.c:399
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993 --- Comment #12 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-11-12 10:35:12 UTC --- (In reply to comment #11) Kaz, can you please test following patch, if it works ok SH4? Works fine. I've confirmed that there are no new failures on sh4-unknown-linux-gnu.
[Bug fortran/55272] [4.8 Regression] ICE on passing coarray argument between files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55272 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-12 10:40:30 UTC --- The culprit seems to be Rev. 189881. Untested patch: ... AFAICT the patch does not fix this PR.
[Bug middle-end/55283] New: EON performance regression at -O2 due to loop unrolling changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55283 Bug #: 55283 Summary: EON performance regression at -O2 due to loop unrolling changes Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org EON regressed by about 20% at -O2 due to 2012-11-06 Jan Hubicka j...@suse.cz * cfgloopanal.c (get_loop_hot_path): New function. * tree-ssa-lop-ivcanon.c (struct loop_size): Add CONSTANT_IV, NUM_NON_PURE_CALLS_ON_HOT_PATH, NUM_PURE_CALLS_ON_HOT_PATH, NUM_BRANCHES_ON_HOT_PATH. (tree_estimate_loop_size): Compute the new values. (try_unroll_loop_completely): Disable unrolling of loops with only calls or too many branches. (tree_unroll_loops_completely): Deal also with outer loops of hot loops. * cfgloop.h (get_loop_hot_path): Declare. * params.def (PARAM_MAX_PEEL_BRANCHES): New parameters. * invoke.texi (max-peel-branches): Document. This seems to be bad cost model on array accesses because we unroll only for size at -O2
[Bug middle-end/55283] EON performance regression at -O2 due to loop unrolling changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55283 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-12 10:44:14 UTC --- http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64/252_eon_big.png
[Bug lto/55284] New: [4.8 Regression] ICE in read_cgraph_and_symbols, at lto/lto.c:2944 (when -MMD is passed)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55284 Bug #: 55284 Summary: [4.8 Regression] ICE in read_cgraph_and_symbols, at lto/lto.c:2944 (when -MMD is passed) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincenzo.innoce...@cern.ch touch foo.cc [innocent@vinavx0 Octave]$ c++ -flto -MMD foo.cc -o bha lto1: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2944 0xca054e read_cgraph_and_symbols ../../gcc-trunk/gcc/lto/lto.c:2944 0xca054e lto_main() ../../gcc-trunk/gcc/lto/lto.c:3380 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: c++ returned 1 exit status /afs/cern.ch/user/i/innocent/w2/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status d -v GNU ld (GNU Binutils) 2.22
[Bug fortran/55272] [4.8 Regression] ICE on passing coarray argument between files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55272 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-12 10:52:30 UTC --- Actually, the patch fixed the PR (I did not use the patched version in the previous test). Sorry for the noise.
[Bug fortran/55272] [4.8 Regression] ICE on passing coarray argument between files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55272 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-12 11:03:46 UTC --- Author: burnus Date: Mon Nov 12 11:03:42 2012 New Revision: 193429 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193429 Log: 2012-11-12 Tobias Burnus bur...@net-b.de PR fortran/55272 * module.c (mio_array_spec): Correctly handle coarray scalars. 2012-11-12 Tobias Burnus bur...@net-b.de PR fortran/55272 * gfortran.dg/coarray_29_1.f90: New. * gfortran.dg/coarray_29_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/coarray_29_1.f90 trunk/gcc/testsuite/gfortran.dg/coarray_29_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55272] [4.8 Regression] ICE on passing coarray argument between files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55272 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-12 11:09:50 UTC --- FIXED on the 4.8 trunk (which was only affected).
[Bug fortran/55272] [4.8 Regression] ICE on passing coarray argument between files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55272 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-12 11:10:16 UTC --- really mark as fixed
[Bug tree-optimization/55281] [4.8 Regression] ICE in build_int_cst_wide, at tree.c:1217 (with Ofast, ok with O3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55281
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-12
11:46:30 UTC ---
Actually, that shorter testcase ICEs for a different reason.
static inline float
bar (float k, float j)
{
float l = 0.0f;
if (k j)
l = k;
float t = k / j;
float v = t * t;
if (k == 0)
v = 0.0f;
if (t 0.4f)
v += 0.7;
if (l != 0)
v = 1.5 - v;
return v;
}
void
foo (int *a, int b, float *d, float *e, int *f)
{
for (int l = 0; l != b; ++l)
for (int i = 0; i != 8; ++i)
f[i] = e[i] + bar (a[i], d[i]);
}
is where the original testcase ICEs (-Ofast, both C and C++).
[Bug tree-optimization/55253] [4.8 Regression] Revision 193298 miscompiles sqlite with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55253 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-12 AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-12 12:03:12 UTC --- Confirmed and mine, thanks a lot for the reduced testcase.
[Bug target/55285] New: Botan regression on ia-64 at Mar-2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55285 Bug #: 55285 Summary: Botan regression on ia-64 at Mar-2012 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org http://gcc.opensuse.org/c++bench-terbium/botan/botan-summary.txt-1-0.html shows big regression starting at 2012-03-27 120327.00779 305.24 122247 3599672 73.92 66.60 59.75 48.67 34.98 37.77 27.62 18.96 11.60 29.81 12.71 30.92 45.21 5.05 17.62 39.46 13.04 39.48 31.94 26.33 26.60 44.17 21.35 25.46 84.52 29.83 61.67 29.81 40.88 41.00 35.67 21.19 11.50 5.79 2.94 62.12 40.88 19.23 68.35 122.40 143.46 1097.96 245.17 242.69 90.38 119.04 4.34 165.42 121.75 114.69 68.42 65.40 51.00 109.29 109.04 72.23 56.15 45.92 65.38 23.77 0.75 0.37 120327.66131 397.96 130439 4987752 42.15 39.60 37.21 33.81 27.98 32.10 17.83 13.42 7.35 24.96 11.75 25.85 25.29 3.06 16.35 31.48 10.52 31.56 26.54 24.27 20.62 38.62 18.81 19.79 45.44 25.04 48.00 24.98 28.71 28.77 25.58 13.17 6.73 3.29 1.65 36.67 27.90 13.71 24.90 55.40 67.98 1097.29 245.29 242.83 64.12 85.94 1.55 129.31 101.46 95.79 63.88 37.83 33.19 111.29 110.35 68.75 55.50 33.62 37.85 17.12 0.53 0.26 Patches approximately in this range include: 2012-03-27 Aurelien Buhrig aurelien.buhrig@gmail.com PR middle-end/51893 * expmed.c (store_bit_field_1): Fix wordnum value for big-endian targets. 2012-03-27 Martin Jambor mjam...@suse.cz PR middle-end/52693 * tree-sra.c (sra_modify_assign): Do not call load_assign_lhs_subreplacements when working with an unscalarizable region. 2012-03-27 H.J. Lu hongjiu...@intel.com * opth-gen.awk: Allocated a bit for Mask and InverseMask if it hasn't been allocated. Define a target macro for Mask and InverseMask if it hasn't been defined. Remove MaskExists handling. * doc/options.texi: Remove MaskExists. 2012-03-27 Richard Guenther rguent...@suse.de PR middle-end/52720 * fold-const.c (try_move_mult_to_index): Handle x.array more explicitely. 2012-03-27 Eric Botcazou ebotca...@adacore.com * expmed.c (store_bit_field): Assert that BITREGION_START is a multiple of a unit before computing the offset in units. * expr.c (get_bit_range): Return the null range if the enclosing record is part of a larger bit field. 2012-03-27 Tristan Gingold ging...@adacore.com * config/ia64/vms.h (CASE_VECTOR_MODE): Define. * config/ia64/ia64.md: Remove mode in template. Sign extend operand in expand_simple_binop. * config/ia64/ia64.h (ASM_OUTPUT_ADDR_DIFF_ELT): Use CASE_VECTOR_MODE instead of TARGET_ILP32. (ADDR_VEC_ALIGN): Make it depends on CASE_VECTOR_MODE. 2012-03-26 Steven Bosscher ste...@gcc.gnu.org * varasm.c (assemble_external): #if 0 out the new assert from the previous commit, it breaks the Java and Go front ends. 2012-03-26 Steven Bosscher ste...@gcc.gnu.org * toplev.c (check_global_declaration_1): Do not call assemble_external. * expr.c (emit_block_move_libcall_fn): Likewise. (clear_storage_libcall_fn): Likewise. (expand_expr_addr_expr_1): Likewise. (expand_expr_real_1): Likewise. * calls.c (rtx_for_function_call): Likewise. * varasm.c (assemble_external): Assert this function is only called during or after expanding to RTL. 2012-03-26 Martin Jambor mjam...@suse.cz PR tree-optimization/50052 * tree-sra.c (tree_non_aligned_mem_p): Removed. (tree_non_aligned_mem_for_access_p): Likewise. (build_accesses_from_assign): Removed strict alignment requirements checks. (access_precludes_ipa_sra_p): Likewise. 2012-03-26 Richard Guenther rguent...@suse.de PR tree-optimization/52701 * tree-vect-loop.c (vect_analyze_scalar_cycles_1): Always compute and set the evolution part of PHI nodes. 2012-03-26 Richard Guenther rguent...@suse.de PR tree-optimization/52721 * tree-vect-stmts.c (vect_init_vector): Handle scalars. 2012-03-26 Ulrich Weigand ulrich.weig...@linaro.org PR tree-optimization/52686 * tree-vect-data-refs.c (vect_get_smallest_scalar_type): Handle WIDEN_LSHIFT_EXPR. 2012-03-26 Tristan Gingold ging...@adacore.com * config/alpha/vms.h (LINK_SPEC): Simplify. (STARTFILE_SPEC): Remove -mvms-return-codes handling. (STARTFILE_SPEC): Remove -mvms-return-codes handling. (NAME__MAIN, SYMBOL__MAIN): Remove. (VMS_DEBUG_MAIN_POINTER): Remove. * config/ia64/vms.h: Likewise.
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #37 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-12 12:16:18 UTC --- Fatigue now gets all inlining with -O3 -fwhole-program, with -O3 it gets only half of inlining because jump functions are not able to track array descriptors in both calls to generalized_hookes_law. What are the other testcases to look at?
[Bug target/55285] Botan regression on ia-64 at Mar-2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55285 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-12 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-12 12:18:24 UTC --- There are known performance regressions on strict-alignment platforms because of the SRA changes, see PR tree-opt/54386.
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #38 from Igor Zamyatin izamyatin at gmail dot com 2012-11-12 12:44:43 UTC --- Looks like for x86 r193331 led to significant regression on 172.mgrid for -m32 -O3 -funroll-loops
[Bug lto/55284] [4.8 Regression] ICE in read_cgraph_and_symbols, at lto/lto.c:2944 (when -MMD is passed)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55284 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-11-12 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-12 12:49:32 UTC --- Attachment missing
[Bug lto/55284] [4.8 Regression] ICE in read_cgraph_and_symbols, at lto/lto.c:2944 (when -MMD is passed)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55284 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-11-12 12:55:50 UTC --- just touch foo.cc enough…
[Bug lto/55284] [4.8 Regression] ICE in read_cgraph_and_symbols, at lto/lto.c:2944 (when -MMD is passed)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55284 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-12 12:59:26 UTC --- Ah, sorry, I missed the touch foo.cc, seems a rather simple issue then.
[Bug lto/55284] [4.8 Regression] ICE in read_cgraph_and_symbols, at lto/lto.c:2944 (when -MMD is passed)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55284 --- Comment #4 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-11-12 13:07:35 UTC --- and most probably is already fixed at linker level as does not happen with GNU ld (GNU Binutils) 2.23.51.20121020
[Bug tree-optimization/55286] New: [4.7/4.8 Regression] Bytemark ASSIGNMENT 4% - 10% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55286 Bug #: 55286 Summary: [4.7/4.8 Regression] Bytemark ASSIGNMENT 4% - 10% slower Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com gcc 4.6 branch ASSIGNMENT : 64.389 : 245.01 : 63.55 gcc 4.7 branch ASSIGNMENT : 57.737 : 219.70 : 56.98 gcc 4.7 branch without 175752 ASSIGNMENT : 64.163 : 244.15 : 63.33 gcc 4.8 branch ASSIGNMENT : 61.751 : 234.97 : 60.95 175752: Date: Fri Jul 1 10:00:25 2011 + 2011-07-01 Kai Tietz kti...@redhat.com * tree-ssa-forwprop.c (simplify_bitwise_binary): Fix typo. 2011-07-01 Kai Tietz kti...@redhat.com * gcc.dg/tree-ssa/bitwise-sink.c: New test.
[Bug tree-optimization/54077] Bytemark FP EMULATION 9%-15% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #17 from wbrana wbrana at gmail dot com 2012-11-12 13:17:08 UTC --- there is another bug caused by revision 175752 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55286
[Bug lto/54966] Does LTO requires a larger inline-unit-growth?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54966 --- Comment #11 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-11-12 13:19:42 UTC --- much better with gcc version 4.8.0 20121112 (experimental) [trunk revision 193427] (GCC) but for size 6. v1 with lto [innocent@vinavx0 bugs48]$ c++ -Ofast smatrix.ii -march=native ; taskset -c 2 ./a.out size 5. v1: time in cycles 6925.32 size 5. v2: time in cycles 2123.49 size 5. v3: time in cycles 1067.43 size 6. v1: time in cycles 31216.7 size 6. v2: time in cycles 3521.98 size 6. v3: time in cycles 2523.74 [innocent@vinavx0 bugs48]$ c++ -Ofast smatrix.ii -march=native -flto; taskset -c 2 ./a.out size 5. v1: time in cycles 6367.09 size 5. v2: time in cycles 1181.97 size 5. v3: time in cycles 1194.82 size 6. v1: time in cycles 34811.5 size 6. v2: time in cycles 1909.71 size 6. v3: time in cycles 1803.48 of course inlining also the case v1 would be even better !(the code is equivalent to v2 and v3) I've some other more complex functions where inline is different than 4.7.2 but not necessarily better will try to cut a test case
[Bug tree-optimization/55286] [4.7/4.8 Regression] Bytemark ASSIGNMENT 4% - 10% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55286 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-11-12 13:44:32 UTC --- r175752 is a follow-up fix to r175589, so my guess is that it's the combination of the two that's causing the regression. Can you construct a small test case that demonstrates the code quality regression from these two revisions?
[Bug testsuite/55230] UNSUPPORTED: g++.dg/mv1.C -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55230 Kyrill Tkachov kyrylo.tkachov at arm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #2 from Kyrill Tkachov kyrylo.tkachov at arm dot com 2012-11-12 14:06:50 UTC --- Ah ok, Since we don't have a g++.target directory, g++.dg does seem the most appropriate. I think though that if we end up adding a lot of tests like that in the future, it would be a good idea to create a g++.target directory to reduce the number of UNSUPPORTED complaints on other targets. Thanks, Kyrill
[Bug fortran/55282] [OOP] openmp directive and classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55282 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|openmp directive and|[OOP] openmp directive and |classes |classes --- Comment #1 from janus at gcc dot gnu.org 2012-11-12 14:35:42 UTC --- (In reply to comment #0) The following code doesnt compile at all with the lattest gfortran. The problem seems to be in the class definition of the variable this (works fine while declared as type). [...] bug.f90: In function ‘prog’: bug.f90:21:0: error: ‘__vtab_mod_My_t’ not specified in enclosing parallel This is a known problem, see PR 52531. Note that Fortran 2003 is not supported in OpenMP 3.1. This may change with OpenMP 4, but I'm not sure of that.
[Bug fortran/55282] [OOP] openmp directive and classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55282 --- Comment #2 from janus at gcc dot gnu.org 2012-11-12 14:47:11 UTC --- (In reply to comment #1) Note that Fortran 2003 is not supported in OpenMP 3.1. This may change with OpenMP 4, but I'm not sure of that. Just checked: The public RC at http://openmp.org/wp/openmp-specifications/ says the following: This OpenMP API specification refers to ISO/IEC 1539-1:2004 as Fortran 2003. The following features are not supported: * ... * Polymorphic entities * ... So, it looks like CLASS declarations are still not allowed in OpenMP 4. Too bad!
[Bug c++/55267] double operation giving different results depending on context and optimization level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55267 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-12 14:53:28 UTC --- Dup *** This bug has been marked as a duplicate of bug 323 ***
[Bug middle-end/323] optimized code gives strange floating point results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jkuittinen293482 at gmail ||dot com --- Comment #185 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-12 14:53:28 UTC --- *** Bug 55267 has been marked as a duplicate of this bug. ***
[Bug c++/52538] Extend C++11 UDLs to be compatible with inttypes.h macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-12 14:57:22 UTC --- Fixed for 4.8.0.
[Bug c++/52485] [c++11] add an option to disable c++11 user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52485 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-12 14:59:40 UTC --- Closing.
[Bug tree-optimization/55281] [4.8 Regression] ICE in build_int_cst_wide, at tree.c:1217 (with Ofast, ok with O3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55281 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-12 15:12:20 UTC --- Created attachment 28668 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28668 gcc48-pr55281.patch Untested fix.
[Bug c++/55287] New: GCC crashes and asks to file bug report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55287 Bug #: 55287 Summary: GCC crashes and asks to file bug report Classification: Unclassified Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: gordoncic...@gmail.com This is a compiler bug that occurs on Debian squeeze.. uname -a Linux caraway 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686 GNU/Linux gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.5 (Debian 4.4.5-8) g++ -save-temps -c -o gcc-bug.o gcc-bug.cc g++: Internal error: Killed (program cc1plus) Please submit a full bug report. See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions.
[Bug c++/55287] GCC crashes and asks to file bug report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55287 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-12 15:22:25 UTC --- gcc4.4.x is not maintained anymore. Please try again with a GCC from a currently maintained branch and in case file a proper report: http://gcc.gnu.org/bugs/#report
[Bug tree-optimization/55281] [4.8 Regression] ICE in build_int_cst_wide, at tree.c:1217 (with Ofast, ok with O3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55281 --- Comment #4 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-11-12 15:37:23 UTC --- regression removed by the patch at first sight performances are similar to 4.7.2, so also vectorization is ok
[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-12 15:38:12 UTC --- Honza, I'm a bit confused here: if I understand correctly your r187631 was only about a C++ optimization, but now I see C testcases too here?!? Do we have two separate issues?
[Bug tree-optimization/55281] [4.8 Regression] ICE in build_int_cst_wide, at tree.c:1217 (with Ofast, ok with O3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55281 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org 2012-11-12 16:18:52 UTC --- (In reply to comment #1) [ Using ?: with a vector condition ] I was surprised only C++ handles this and not C BTW. Sorry, I didn't have time to do a C version (harder than C++ because of things like c_wrap_maybe_const that I don't understand yet). Even the C++ version isn't documented yet (I should do it), because it has a number of bugs like this one. By the way, I assume you are not calling pedantic_omit_one_operand_loc because the vector operand is unlikely to have a side effect?
[Bug tree-optimization/55281] [4.8 Regression] ICE in build_int_cst_wide, at tree.c:1217 (with Ofast, ok with O3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55281 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-12 16:23:29 UTC --- I'm just testing that, so I know it doesn't have side-effects. COND_EXPR handling which I've copied was doing the same thing. The reason for the fold-const.c change was that while you handle that case in forwprop, it only triggers if forwprop actually simplifies the condition, but if e.g. copyprop does that, then nothing will fix it up afterwards till expansion.
[Bug tree-optimization/55281] [4.8 Regression] ICE in build_int_cst_wide, at tree.c:1217 (with Ofast, ok with O3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55281 --- Comment #7 from Marc Glisse glisse at gcc dot gnu.org 2012-11-12 16:39:27 UTC --- (In reply to comment #6) I'm just testing that, so I know it doesn't have side-effects. I meant: instead of testing, so the optimization still occurs when there is a side effect. COND_EXPR handling which I've copied was doing the same thing. Ah, indeed. The reason for the fold-const.c change was that while you handle that case in forwprop, it only triggers if forwprop actually simplifies the condition, but if e.g. copyprop does that, then nothing will fix it up afterwards till expansion. Understood.
[Bug c++/55287] GCC crashes and asks to file bug report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55287 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-12 17:01:57 UTC --- Also this ICE is really the kernel killing the program as it ran out of memory or it was over one of the ulimits. Most likely ran of memory.
[Bug debug/55257] [4.8 Regression]: g++.dg/debug/dwarf2/non-virtual-thunk.C scan-assembler thunk.C:30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55257 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-12 AssignedTo|unassigned at gcc dot |hp at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-12 17:08:12 UTC --- (In reply to comment #1) If the target doesn't call final_start_function and final_end_function in output_mi_thunk targhook (or equivalent), it is a target bug. I see. I either missed this requirement when I implemented those bits for CRIS or it wasn't a requirement at the time. BTW, I see several ports are missing those calls. I guess in the general case it can't be left to middle-end to call those functions at the right time, so I'll just update the port and hopefully the documentation, but no promises. Assigning the PR to myself while verifying that this is the cause.
[Bug debug/55257] [4.8 Regression]: g++.dg/debug/dwarf2/non-virtual-thunk.C scan-assembler thunk.C:30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55257 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-12 17:14:41 UTC --- It is a requirement if you want proper debug info or unwind info for the thunk, without that (or without calling the corresponding functions yourself, which is harder to maintain) you don't get proper debug info. It can't be called from the middle end, because some targets need to perform various things before final_start_function (or perhaps after final_end_function).
[Bug debug/55257] [4.8 Regression]: g++.dg/debug/dwarf2/non-virtual-thunk.C scan-assembler thunk.C:30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55257 --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-12 17:21:57 UTC --- (In reply to comment #3) It can't be called from the middle end, because some targets need to perform various things before final_start_function (or perhaps after final_end_function). Yes, that's what I meant, so let's just document the requirement.
[Bug c++/55275] abi_tag attribute doesn't work on explicit specializations of class templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55275 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-12 Ever Confirmed|0 |1 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2012-11-12 17:28:59 UTC --- I agree this is a bug, but I still don't think you need to tag future, since it's new in C++11.
[Bug c++/54413] Option for turning off compiler extensions for -std=c++11 with respect to complex/fixed-point numbers missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54413 --- Comment #16 from Ed Smith-Rowland 3dw4rd at verizon dot net 2012-11-12 17:48:29 UTC --- Thanks, So If there are several ChangeLogs in the tree to get updated which one do I put in the svn commit? Or does it matter? Also, I just realized that maybe I should whip up a sentence or two for http://gcc.gnu.org/gcc-4.8/changes.html?
[Bug c++/55287] GCC crashes and asks to file bug report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55287 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-12 17:50:20 UTC --- Indeed.
[Bug c++/55275] abi_tag attribute doesn't work on explicit specializations of class templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55275 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-12 18:04:53 UTC --- Yep, I filed this before your reply on the list. I'm happy to change future without using the tag, I was just being (maybe too) cautious about ABI changes. Thanks.
[Bug c++/55288] New: Improve handling/suppression of maybe-uninitialized warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288 Bug #: 55288 Summary: Improve handling/suppression of maybe-uninitialized warnings Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: scov...@gmail.com Created attachment 28669 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28669 maybe-uninitialized false positive Enabling -Wmaybe-unused (part of -Wall) can result in false positives, which is fine (the warning is still quite useful). However, there is currently no way to disable such warnings on a per-variable basis. It is possible, but ineffective, to push a diagnostic pragma to ignore such warnings: Warnings are generated where the uninitialized value (!= variable) is eventually consumed, and that can easily happen outside the range covered by the pragma. Inlining makes the problem much worse [1]. The attached test case (reduced from actual code) illustrates the problem clearly, failing to compile with `-O2 -Wall -Werror' even though (a) the value *is* always written before being read and (b) even though the containing function has maybe-uninitialized warnings disabled. Adding -DWORKS allows it to compile by disabling the warning for the call site, even though the offending variable is not in scope at any part of the source code where the pragma is in effect. Since the compiler can clearly track which variable was the problem, I would instead propose a new variable attribute, ((maybe_uninitialized)), to suppress all maybe-uninitialized warnings the marked variable might trigger for its consumers. That way, known false positives can be whitelisted without disabling a useful warning for large swaths of unrelated code [2]. [1] First, it can vastly expand the number of problematice end points that lie outside the pragma (they may even reside in different files). Second, the resulting error message is extremely unhelpful, because it names the variable that was originally uninitialized, rather than the variable that ended up holding the poisoned value at the point of use (the former might not even be in the same file, let alone be in scope, and there's no easy way to figure out which of its uses causes the problem). It would be much better in this case if the diagnostic listed the call site(s) and/or assignments that led to the identified line of code depending on the potentially-uninitialized value, similar to how template substitution failures or errors in included headers are handled today. [2] Another potential solution would be to propagate the pragma to inlined call sites, but that seems like a horrifically hacky and error prone solution.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Carlos O'Donell carlos at systemhalted dot org changed: What|Removed |Added CC||carlos at systemhalted dot ||org --- Comment #8 from Carlos O'Donell carlos at systemhalted dot org 2012-11-12 18:29:12 UTC --- The glibc community is aware of this issue. I've added it to our generic todo list from which developers can help coordinate an implementation. http://sourceware.org/glibc/wiki/Development_Todo/Generic
[Bug c++/54413] Option for turning off compiler extensions for -std=c++11 with respect to complex/fixed-point numbers missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54413 --- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-12 18:30:27 UTC --- (In reply to comment #16) Thanks, So If there are several ChangeLogs in the tree to get updated which one do I put in the svn commit? Or does it matter? I put all of them, prefixed by the dir e.g. http://gcc.gnu.org/viewcvs?view=revisionrevision=192968 Also, I just realized that maybe I should whip up a sentence or two for http://gcc.gnu.org/gcc-4.8/changes.html? That would be great, thanks.
[Bug fortran/55282] [OOP] openmp directive and classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55282 --- Comment #3 from Valery Weber valeryweber at hotmail dot com 2012-11-12 19:18:34 UTC --- Thanks pointing that. Is there any reason for not allowing the classes in openmp? I noticed that other compilers (eg ifort, xlf) can accommodate with this deviation from the standard, is gfortran going in the same direction?
[Bug bootstrap/55289] New: darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 Bug #: 55289 Summary: darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu The merge of the asan branch breaks the bootstrap on darwin due to the missing libsanitizer/interception/mach_override directory and associated files. These were never ported from llvm compiler-rt into the asan gcc branch. Manually adding the libsanitizer/interception/mach_override directory from the llvm compiler-rt 3.2 branch restores the bootstrap on x86_64-apple-darwin12.
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Target||*-*-darwin* Host||*-*-darwin* Build||*-*-darwin* Severity|normal |critical
[Bug fortran/55282] [OOP] openmp directive and classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55282 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org 2012-11-12 20:02:02 UTC --- (In reply to comment #3) Thanks pointing that. Is there any reason for not allowing the classes in openmp? I noticed that other compilers (eg ifort, xlf) can accommodate with this deviation from the standard, is gfortran going in the same direction? Of course there is a good reason. What if a future OpenMP standard introduces classes in manner that conflicts with the way gfortran implements the extension? gfortran would then need an option to toggle between the standard conforming code and the GNU Fortran extension. Which, then, is the default?
[Bug c++/55288] Improve handling/suppression of maybe-uninitialized warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-12 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-12 20:07:31 UTC --- Why don't just initialize the variable? It seems simpler than implementing yet another special attribute in GCC. That said, I find strange that the warning points to somewhere within a function without telling the user where from that function was called. For more complex testcases, this could turn out to be very confusing. Also, the location is not actually pointing to the variable but to ';'. Clang says: pr55288.cc:40:9: warning: variable 'q' may be uninitialized when used here [-Wconditional-uninitialized] foo(q); ^ pr55288.cc:22:8: note: initialize the variable 'q' to silence this warning int q; ^ = 0
[Bug c/47599] -fno-short-wchar does not force long wchar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47599 Earnie earnie at users dot sourceforge.net changed: What|Removed |Added CC||earnie at users dot ||sourceforge.net --- Comment #9 from Earnie earnie at users dot sourceforge.net 2012-11-12 20:15:07 UTC --- Looking at http://msdn.microsoft.com/en-us/library/dh8che7s(v=vs.71).aspx I see that wchar_t is typically defined as unsigned short. MSVC provides a /Zc:wchar_t that causes wchar_t to become a native type that maps to _wchar_t. Currently the mingw.org wchar.h file includes the stddef.h file after defining __need_wchar_t. I need to walk through stddef.h to determine if we (mingw.org) needs to define some other macro based on the provided options. However, I'm feeling like this will be a coordinated effort between both parties. I don't know about Cygwin's versions of the headers, they should match more to what Linux defines.
[Bug target/41993] [sh] ICE in create_pre_exit, at mode-switching.c:399
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-12
20:20:26 UTC ---
I've also tested this on rev 193423 with
make -k check
RUNTESTFLAGS=--target_board=sh-sim\{-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4-single/-ml,-m4/-mb,-m4-single/-mb}
and no new failures.
[Bug rtl-optimization/51447] [4.6/4.7/4.8 Regression] global register variable definition incorrectly removed as dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447 --- Comment #14 from Steven Bosscher steven at gcc dot gnu.org 2012-11-12 20:22:05 UTC --- Author: steven Date: Mon Nov 12 20:21:59 2012 New Revision: 193453 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193453 Log: gcc/ PR rtl-optimization/51447 * df-scan.c (df_get_entry_block_def_set): Add global regs to the set. * df-problems.c (df_lr_local_compute): Make global regs always live. * dce.c (deletable_insn_p): Make insns setting a global reg inherently necessary. testsuite/ PR rtl-optimization/51447 * gcc.c-torture/execute/pr51447.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr51447.c Modified: trunk/gcc/ChangeLog trunk/gcc/dce.c trunk/gcc/df-problems.c trunk/gcc/df-scan.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55290] New: LRA depends on uninitialised values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55290
Bug #: 55290
Summary: LRA depends on uninitialised values
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: vmaka...@redhat.com
[hjl@gnu-tools-1 gcc]$ cat /tmp/z.i
int a[10];
void g(int *p);
void h(int p);
int* f(void) {
int b[10] = { };
struct {
int c[10];
} c = { { } };
g(a[8]);
g(a[9]);
g(a[0]);
g(b[0]);
g(c.c[0]);
return a;
}
[hjl@gnu-tools-1 gcc]$ valgrind ./cc1 -fpreprocessed /tmp/z.i -quiet -dumpbase
z.i -m64 -mtune=generic -march=x86-64 -auxbase z -O2 -version -o z.s
==5815== Memcheck, a memory error detector
==5815== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==5815== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==5815== Command: ./cc1 -fpreprocessed /tmp/z.i -quiet -dumpbase z.i -m64
-mtune=generic -march=x86-64 -auxbase z -O2 -version -o z.s
==5815==
GNU C (GCC) version 4.8.0 20121112 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version
5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.8.0 20121112 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version
5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 28512814d6c61d240aec0db5bb852766
==5815== Conditional jump or move depends on uninitialised value(s)
==5815==at 0x8A4EA5: sparseset_bit_p(sparseset_def*, unsigned long)
(sparseset.h:147)
==5815==by 0x8A5A18: mark_pseudo_regno_live(int) (ira-lives.c:291)
==5815==by 0x8A5CC7: mark_pseudo_reg_live(rtx_def*, unsigned int)
(ira-lives.c:375)
==5815==by 0x8A5D34: mark_ref_live(df_ref_d*) (ira-lives.c:389)
==5815==by 0x8A849F: process_bb_node_lives(ira_loop_tree_node*)
(ira-lives.c:1322)
==5815==by 0x884217: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void
(*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1609)
==5815==by 0x8A90BE: ira_create_allocno_live_ranges() (ira-lives.c:1596)
==5815==by 0x8885FD: ira_build() (ira-build.c:3210)
==5815==by 0x87F5EE: ira(_IO_FILE*) (ira.c:4476)
==5815==by 0x87FB86: rest_of_handle_ira() (ira.c:4710)
==5815==by 0x937D39: execute_one_pass(opt_pass*) (passes.c:2339)
==5815==by 0x937FB0: execute_pass_list(opt_pass*) (passes.c:2400)
==5815==
==5815== Conditional jump or move depends on uninitialised value(s)
==5815==at 0x8A4EA5: sparseset_bit_p(sparseset_def*, unsigned long)
(sparseset.h:147)
==5815==by 0x8A4F37: sparseset_set_bit(sparseset_def*, unsigned long)
(sparseset.h:166)
==5815==by 0x8A5355: make_object_born(ira_object*) (ira-lives.c:122)
==5815==by 0x8A5A37: mark_pseudo_regno_live(int) (ira-lives.c:295)
==5815==by 0x8A5CC7: mark_pseudo_reg_live(rtx_def*, unsigned int)
(ira-lives.c:375)
==5815==by 0x8A5D34: mark_ref_live(df_ref_d*) (ira-lives.c:389)
==5815==by 0x8A849F: process_bb_node_lives(ira_loop_tree_node*)
(ira-lives.c:1322)
==5815==by 0x884217: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void
(*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1609)
==5815==by 0x8A90BE: ira_create_allocno_live_ranges() (ira-lives.c:1596)
==5815==by 0x8885FD: ira_build() (ira-build.c:3210)
==5815==by 0x87F5EE: ira(_IO_FILE*) (ira.c:4476)
==5815==by 0x87FB86: rest_of_handle_ira() (ira.c:4710)
==5815==
==5815== Conditional jump or move depends on uninitialised value(s)
==5815==at 0x88FD3C: sparseset_bit_p(sparseset_def*, unsigned long)
(sparseset.h:147)
==5815==by 0x88FDCE: sparseset_set_bit(sparseset_def*, unsigned long)
(sparseset.h:166)
==5815==by 0x890B9A: build_conflict_bit_table() (ira-conflicts.c:174)
==5815==by 0x892B9F: ira_build_conflicts() (ira-conflicts.c:856)
==5815==by 0x888647: ira_build() (ira-build.c:3227)
==5815==by 0x87F5EE: ira(_IO_FILE*) (ira.c:4476)
==5815==by 0x87FB86: rest_of_handle_ira() (ira.c:4710)
==5815==by 0x937D39: execute_one_pass(opt_pass*) (passes.c:2339)
==5815==by 0x937FB0: execute_pass_list(opt_pass*) (passes.c:2400)
==5815==by 0x937FE1: execute_pass_list(opt_pass*) (passes.c:2401)
==5815==by 0x667BCD: expand_function(cgraph_node*) (cgraphunit.c:1643)
==5815==by 0x668088: expand_all_functions() (cgraphunit.c:1747)
==5815==
==5815== Conditional jump or move depends on uninitialised value(s)
==5815==at 0x8E2237
[Bug rtl-optimization/51447] [4.6/4.7 Regression] global register variable definition incorrectly removed as dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|steven at gcc dot gnu.org |unassigned at gcc dot ||gnu.org Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] global |global register variable|register variable |definition incorrectly |definition incorrectly |removed as dead code|removed as dead code --- Comment #15 from Steven Bosscher steven at gcc dot gnu.org 2012-11-12 20:23:37 UTC --- Fixed on trunk. Could be back-ported, but IMHO this issue is not important enough for that so I'm not going to work on back-ports.
[Bug objc/55291] New: libsanitizer doesn't build multilib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55291 Bug #: 55291 Summary: libsanitizer doesn't build multilib Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, libsanitizer doesn't build multilib, like -m32 and -mx32.
[Bug rtl-optimization/55290] sparseset by design depends on uninitialised values but valgrind doesn't get it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55290 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org Summary|LRA depends on |sparseset by design depends |uninitialised values|on uninitialised values but ||valgrind doesn't get it --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2012-11-12 20:41:19 UTC --- Looks like a valgrind bug to me. There is a VALGRIND_DISCARD for this in sparseset.c:39.
[Bug other/55292] New: libsanitizer doesn't support x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55292
Bug #: 55292
Summary: libsanitizer doesn't support x32
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
sanitizer_common/sanitizer_linux.cc has
void *internal_mmap(void *addr, uptr length, int prot, int flags,
int fd, u64 offset) {
#if __WORDSIZE == 64
return (void *)syscall(__NR_mmap, addr, length, prot, flags, fd, offset);
#else
return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);
#endif
}
uptr internal_filesize(fd_t fd) {
#if __WORDSIZE == 64
struct stat st;
if (syscall(__NR_fstat, fd, st))
return -1;
#else
struct stat64 st;
if (syscall(__NR_fstat64, fd, st))
return -1;
#endif
return (uptr)st.st_size;
}
They are incorrect for x32.
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-12 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-12 20:53:31 UTC --- Manually adding the libsanitizer/interception/mach_override directory from the llvm compiler-rt 3.2 branch restores the bootstrap on x86_64-apple-darwin12. How do I get the libsanitizer/interception/mach_override directory on Xcode 3.2.6?
[Bug target/50457] SH2A atomic functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457 --- Comment #16 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-12 20:57:12 UTC --- Another thing that might be useful for dealing with atomics on SH1* and SH2* targets is to make the compiler generate the rewind sequences in interrupt handler functions. On SH3* and SH4* targets, the interrupt handling jump table is usually designed in such a way, that it can contain (small) setup code before a user specified interrupt handling function is invoked. However, on SH1* and SH2* targets, the processor directly jumps to the user specified interrupt handling function via the interrupt jump table. It would be possible to have two such jump tables, where code in the first table handles atomic sequence rewinding and then jumps to the second (actual) interrupt handling function specified by the user. This is not necessary, if the compiler can insert the atomic sequence rewind code snippet (according to the currently selected atomic model) at the beginning of an interrupt handler function. Moreover, the compiler can omit the atomic rewind sequence if... * an ISR doesn't call any other (non-inlined) functions * an ISR doesn't contain any atomic sequences itself For example, a very simple timer ISR that just increments the high word of the system's free running timer doesn't need to handle any atomics. Another example would be an SCI/SCIF ISR that receives/sends data to/from a buffer. In this case, the ISR probably has two code execution paths. While the receive/send operation is still in progress the code path is probably very short and updates only a few internal variables, which doesn't need any atomic handling. When the receive/send operation has completed, the completion condition has to be propagated to user code and most likely requires calling other functions and thus handling atomic sequences. Ideally, the compiler would insert atomic handling code in the ISR only to those paths, which actually need it. This would reduce interrupt handling time. I'd propose to add a new function attribute 'handle_atomics' that can be used in combination with the 'interrupt_handler' function attribute for this. SH3* and SH4* targets could also benefit from this.
[Bug c++/55288] Improve handling/suppression of maybe-uninitialized warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288 --- Comment #2 from Ryan Johnson scovich at gmail dot com 2012-11-12 21:11:43 UTC --- (In reply to comment #1) Why don't just initialize the variable? It seems simpler than implementing yet another special attribute in GCC. In the original program, the variable is a largish struct, the function is hot, and the 'valid' execution path is not the most common one. Avoiding unnecessary initialization there has a measurable impact on performance. Note that, in other parts of the code that gcc understands better, the initialization is unnecessary (no warning) and gets optimized away even if I do have it in place... much to my chagrin once, after I did a lot of work to refactor a complex function, only to realize that gcc emitted *exactly* the same machine code afterward, because it had already noticed and eliminated the dead stores. There's also a philosophical argument to be made... if we agree that all warnings subject to false positives should be supressible, the current mechanism for maybe-uninitialized is inadequate, and a variable attribute would resolve the issue very nicely. There's precedent for this: you *could* use #ifndef NDEBUG (or even pragma diagnostic) to avoid unused-variable warnings for helper variables used by multiple assertions scattered over a region of code, but setting ((unused)) on the offending variable is much easier to read and maintain, while still allowing other unused variables to be flagged properly.
[Bug tree-optimization/55238] [4.8 Regression] ICE in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55238 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|ICE in |[4.8 Regression] ICE in |find_aggregate_values_for_c |find_aggregate_values_for_c |allers_subset, at |allers_subset, at |ipa-cp.c:2908 building zlib |ipa-cp.c:2908 building zlib
[Bug c/55293] New: Attempt to bootstrap 7.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 Bug #: 55293 Summary: Attempt to bootstrap 7.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive] Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcla...@blastwave.org On a Solaris 10 server : $ uname -a SunOS node002 5.10 Generic_147440-23 sun4v sparc SUNW,T5240 With gcc 4.5.1 from Blastwave : $ which gcc /opt/csw/gcc4/bin/gcc $ gcc --version gcc (Blastwave.org Inc. Mon Aug 9 07:10:45 GMT 2010) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See test report filed : http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01023.html With gmp-5.0.5, mpfr-3.1.1, and mpc-1.0.1 all previously built, tested clean and installed into /usr/local. Configure of GCC 4.7.2 looks fine thus : $ pwd /usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou $ CC='gcc -m64' CXX='g++ -m64' ../gcc-4.7.2/configure --prefix=/usr/local/gcc4 \ --build=sparc64-sun-solaris2.10 --without-gnu-as --without-gnu-ld \ --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local \ --with-ld=/usr/ccs/bin/ld --enable-nls --enable-threads=posix --enable-shared \ --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \ --with-cpu=v9 --enable-stage1-languages=c --disable-multilib \ --libexecdir=/usr/local/gcc4/lib \ --with-pkgversion=Blastwave.org\ Inc.\ Mon\ Nov\ 12\ 04\:18\:15\ GMT\ 2012 \ --with-bugurl=http\:\/\/www.blastwave.org\/support \ --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap checking build system type... sparc64-sun-solaris2.10 checking host system type... sparc64-sun-solaris2.10 checking target system type... sparc64-sun-solaris2.10 checking for a BSD-compatible install... ../gcc-4.7.2/install-sh -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/local/bin/gsed checking for gawk... gawk checking for libitm support... yes checking for gcc... gcc -m64 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -m64 accepts -g... yes checking for gcc -m64 option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether g++ -m64 accepts -g... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16 checking for objdir... .libs checking for the correct version of gmp.h... yes checking for the correct version of mpfr.h... yes checking for the correct version of mpc.h... yes checking for the correct version of the gmp/mpfr/mpc libraries... yes checking for PWL_handle_timeout in -lpwl... no checking for version 0.11 (revision 0 or later) of PPL... no The following languages will be built: c,ada,c++,fortran,lto,objc *** This configuration is not supported in the following subdirectories: target-libmudflap target-libgo target-libffi target-zlib target-libjava target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... checking for bison... bison -y checking for bison... bison checking for gm4... /usr/local/bin/gm4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... (cached) /usr/ccs/bin/ar checking for as... (cached) /usr/ccs/bin/as checking for dlltool... no checking for ld... (cached) /usr/ccs/bin/ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... no checking for objdump... no checking for readelf... no checking for cc... cc checking for c++... c++ checking for gcc... gcc checking for gcj... no checking for gfortran... gfortran checking for gccgo... no checking for ar... no checking for ar... ar checking for as... no checking for as... as checking for dlltool... no checking for dlltool... no checking for ld... no checking for ld... ld checking for lipo... no checking for lipo... no
[Bug c/55293] Attempt to bootstrap GCC 4.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-12 21:48:46 UTC --- Solaris defines a non-standard iconv() signature unless you request POSIX 2001 Try adding -D_XOPEN_SOURCE=600 to the compilation flags
[Bug c/55293] Attempt to bootstrap GCC 4.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-12 21:50:08 UTC --- Or -D_POSIX_C_SOURCE=200112L
[Bug rtl-optimization/55294] New: Invalid RTL sharing in lower-subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55294
Bug #: 55294
Summary: Invalid RTL sharing in lower-subreg
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
I ran into this one while trying out a couple of things on rev 193423 in the SH
backend.
What I did was to disallow SF subregs of integer regs/pseudos in the
'fp_arith_reg_operand' predicate, like that:
Index: gcc/config/sh/predicates.md
===
--- gcc/config/sh/predicates.md(revision 193423)
+++ gcc/config/sh/predicates.md(working copy)
@@ -319,16 +319,24 @@
if (register_operand (op, mode))
{
int regno;
+ machine_mode m;
if (REG_P (op))
-regno = REGNO (op);
+{
+ regno = REGNO (op);
+ m = GET_MODE (op);
+}
else if (GET_CODE (op) == SUBREG REG_P (SUBREG_REG (op)))
-regno = REGNO (SUBREG_REG (op));
+{
+ regno = REGNO (SUBREG_REG (op));
+ m = GET_MODE (SUBREG_REG (op));
+}
else
return 1;
- return (regno = FIRST_PSEUDO_REGISTER
- || FP_REGISTER_P (regno));
+ return (regno = FIRST_PSEUDO_REGISTER || FP_REGISTER_P (regno))
+ (GET_MODE_CLASS (m) == MODE_FLOAT
+ || GET_MODE_CLASS (m) == MODE_VECTOR_FLOAT);
}
return 0;
})
... to avoid operands such as 'subreg:SF (reg:SI)'. On SH FP values might end
up in GP regs (in particular FP vectors .. see e.g. PR 13423) and have to be
loaded into FP regs first. This is currently done during/by reload, but there
are some cases where this causes trouble. Doing the GP - FP reg copies before
reload seems to be a bit better.
After applying the patch above, the following code:
typedef float V2SF __attribute__ ((vector_size (8)));
V2SF
foo (V2SF a, float x, float y)
{
return a * (V2SF) { x, y };
}
compiled with -m4 -O2, makes the lower-subreg 2 pass transform the two insns:
(insn 23 7 24 2 (parallel [
(set (reg:SF 174 [ D.1360 ])
(mult:SF (reg:SF 69 fr5 [ x ])
(subreg:SF (reg/v:V2SF 167 [ a ]) 0)))
(use (reg/v:PSI 151 ))
]) sh_tmp.cpp:7 426 {mulsf3_i}
(expr_list:REG_DEAD (reg:SF 69 fr5 [ x ])
(nil)))
...
(insn 27 24 28 2 (parallel [
(set (reg:SF 177 [ D.1360 ])
(mult:SF (reg:SF 68 fr4 [ y ])
(subreg:SF (reg/v:V2SF 167 [ a ]) 4)))
(use (reg/v:PSI 151 ))
]) sh_tmp.cpp:7 426 {mulsf3_i}
(expr_list:REG_DEAD (reg/v:V2SF 167 [ a ])
(expr_list:REG_DEAD (reg:SF 68 fr4 [ y ])
(nil
into:
(insn 23 7 24 2 (parallel [
(set (reg:SF 174 [ D.1360 ])
(mult:SF (reg:SF 69 fr5 [ x ])
(subreg:SF (concatn/v:V2SF [
(reg:SI 191 [ a ])
(reg:SI 192 [ a+4 ])
]) 0)))
(use (reg/v:PSI 151 ))
]) sh_tmp.cpp:7 426 {mulsf3_i}
(expr_list:REG_DEAD (reg:SF 69 fr5 [ x ])
(nil)))
...
(insn 27 24 28 2 (parallel [
(set (reg:SF 177 [ D.1360 ])
(mult:SF (reg:SF 68 fr4 [ y ])
(subreg:SF (concatn/v:V2SF [
(reg:SI 191 [ a ])
(reg:SI 192 [ a+4 ])
]) 4)))
(use (reg/v:PSI 151 ))
]) sh_tmp.cpp:7 426 {mulsf3_i}
(expr_list:REG_DEAD (reg:SF 68 fr4 [ y ])
(nil)))
.. which results in an invalid rtl sharing:
sh_tmp.cpp:8:1: error: shared rtx
(concatn/v:V2SF [
(reg:SI 191 [ a ])
(reg:SI 192 [ a+4 ])
])
sh_tmp.cpp:8:1: internal compiler error: internal consistency failure
Note: I had to disable the assert in lower-subreg.c:1582 to get this info,
because the assert would actually trigger before it gets to the rtl sharing
checks. The original call stack is:
sh_tmp.cpp: In function 'foo':
sh_tmp.cpp:8:1: internal compiler error: in decompose_multiword_subregs, at
lower-subreg.c:1582
}
^
0x89184f5 decompose_multiword_subregs
../../gcc-trunk2/gcc/lower-subreg.c:1582
0x89185ac rest_of_handle_lower_subreg2
../../gcc-trunk2/gcc/lower-subreg.c:1659
Please submit a full bug report,
I've attached the logs of the split1 pass before subreg2 and the log of the
subreg2 pass which I got after applying this:
Index: gcc/lower-subreg.c
===
--- gcc/lower-subreg.c(revision 193423)
+++ gcc/lower-subreg.c(working copy)
@@
[Bug rtl-optimization/55294] Invalid RTL sharing in lower-subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55294 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-12 21:53:58 UTC --- Created attachment 28670 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28670 split1 and subreg2 logs
[Bug rtl-optimization/55294] Invalid RTL sharing in lower-subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55294 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-12 21:55:11 UTC --- I think this is because: (subreg:SF (reg/v:V2SF 167 [ a ]) 0))) is invalid to begin with. Yes we don't reject it but I think we should.
[Bug c/55293] Attempt to bootstrap GCC 4.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 --- Comment #3 from Dennis Clarke dclarke at blastwave dot org 2012-11-12 22:07:29 UTC --- OKay, I am extracting a fresh gcc 4.7.2 tarball and then running a new bootstrap with the defines suggested. Results should appear in seven hours or so, however I am hoping for results in 24 hours as that would be a full three stage bootstrap.
[Bug c/55293] Attempt to bootstrap GCC 4.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 --- Comment #4 from Dennis Clarke dclarke at blastwave dot org 2012-11-12 22:10:01 UTC --- bootstrap fails in 71 seconds : $ mkdir gcc-4.7.2_sparc64-sun-solaris2.10 $ cd gcc-4.7.2_sparc64-sun-solaris2.10 $ env | sort ../gcc-4.7.2_sparc64-sun-solaris2.10.env $ ls -la total 20 drwxr-xr-x 2 dclarke other 2 Nov 12 21:58 . drwxrwxr-x 138 root adbs 247 Nov 12 21:58 .. $ $ pwd /usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10 $ uname -a SunOS node002 5.10 Generic_147440-23 sun4v sparc SUNW,T5240 $ $ env | sort AR=/usr/ccs/bin/ar AS=/usr/ccs/bin/as BUILD=/usr/local/build CC=/opt/csw/gcc4/bin/gcc COLUMNS=124 CONFIG_SHELL=/bin/bash CPPFLAGS=-I/usr/local/include:/opt/csw/gcc4/include CXX=/opt/csw/gcc4/bin/g++ EDITOR=/usr/xpg4/bin/vi HOME=/export/home/dclarke LANG=C LC_ALL=C LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LD=/usr/ccs/bin/ld LD_LIBRARY_PATH=/usr/local/lib:/opt/csw/gcc4/lib/sparcv9:/opt/csw/gcc4/lib LD_OPTIONS=-R/usr/local/lib:/opt/csw/gcc4/lib/$ISALIST:/opt/csw/gcc4/lib -L/usr/local/lib:/opt/csw/gcc4/lib/$ISALIST:/opt/csw/gcc4/lib LD_RUN_PATH=/usr/local/lib:/opt/csw/gcc4/lib/$ISALIST LINES=43 LOGNAME=dclarke M4=/usr/local/bin/gm4 MACHTYPE=sparc-sun-solaris MAIL=/usr/mail/dclarke MAKE=/usr/local/bin/gmake MANPATH=/usr/local/man:/usr/local/share/man:/usr/share/man:/usr/X11/share/man OSTYPE=solaris PAGER=/usr/xpg4/bin/more PATH=/opt/csw/gcc4/bin:/usr/local/bin:/usr/local/sbin:/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/opt/schily/bin:/usr/local/texlive/2012/bin/sparc-solaris PERL=/usr/local/bin/perl PKG_CONFIG_PATH=/usr/local/lib/pkgconfig PWD=/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10 SED=/usr/local/bin/gsed SHELL=/bin/ksh SRC=/usr/local/src SSH_CLIENT=66.103.52.207 33595 22 SSH_CONNECTION=66.103.52.207 33595 66.225.151.250 22 SSH_TTY=/dev/pts/1 STY=4301.pts-1.node002 TERM=vt100 TZ=GMT0 USER=dclarke VISUAL=/usr/xpg4/bin/vi WINDOW=3 _=/usr/xpg4/bin/env $ $ which gcc /opt/csw/gcc4/bin/gcc $ $ gcc --version gcc (Blastwave.org Inc. Mon Aug 9 07:10:45 GMT 2010) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ $ ls -lad ../gcc-4.7.2 drwxr-xr-x 33 dclarke other 75 Oct 29 04:04 ../gcc-4.7.2 $ $ which as /usr/ccs/bin/as $ which ld /usr/ccs/bin/ld $ $ echo $CFLAGS $ echo $CXXFLAGS $ $ CC='gcc -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO' \ CXX='g++ -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO' \ ../gcc-4.7.2/configure --prefix=/usr/local/gcc4 \ --build=sparc64-sun-solaris2.10 --without-gnu-as --without-gnu-ld \ --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local \ --with-ld=/usr/ccs/bin/ld --enable-nls --enable-threads=posix --enable-shared \ --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \ --with-cpu=v9 --enable-stage1-languages=c --disable-multilib \ --libexecdir=/usr/local/gcc4/lib \ --with-pkgversion=Blastwave.org\ Inc.\ Mon\ Nov\ 12\ 22\:02\:41\ GMT\ 2012 \ --with-bugurl=http\:\/\/www.blastwave.org\/support \ --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap checking build system type... sparc64-sun-solaris2.10 checking host system type... sparc64-sun-solaris2.10 checking target system type... sparc64-sun-solaris2.10 checking for a BSD-compatible install... ../gcc-4.7.2/install-sh -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/local/bin/gsed checking for gawk... gawk checking for libitm support... yes checking for gcc... gcc -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO accepts -g... yes checking for gcc -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO option to accept ISO C89... unsupported checking whether we are using the GNU C++ compiler... yes checking whether g++ -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO accepts -g... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare
[Bug target/55295] New: [SH] Add support for fipr instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295
Bug #: 55295
Summary: [SH] Add support for fipr instruction
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh4*-*-*
Created attachment 28671
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28671
Example combine patterns
On SH4* targets there is a currently unused instruction 'fipr' which can be
used to calculate the dot product of two V4SF vectors:
fipr FVm, FVn
FR(n+3) = FR(m+0)*FR(n+0) + FR(m+1)*FR(n+1) + FR(m+2)*FR(n+2) + FR(m+3)*FR(n+3)
Some (C++) code that could utilize this:
typedef float v4sf __attribute__ ((vector_size (16)));
float test00 (const v4sf a, const v4sf b)
{
return a[0] * b[0] + a[1] * b[1] + a[2] * b[2] + a[3] * b[3];
}
float test01 (const v4sf a, const v4sf b, const v4sf c)
{
float x = a[0] * b[0] + a[1] * b[1] + a[2] * b[2] + a[3] * b[3];
float y = c[0] * b[0] + c[1] * b[1] + c[2] * b[2] + c[3] * b[3];
return x + y;
}
float test02 (float a0, float a1, float a2, float a3,
float b0, float b1, float b2, float b3)
{
return a0 * b0 + a1 * b1 + a2 * b2 + a3 * b3;
}
float test03 (const float* a, const float* b)
{
return a[0] * b[0] + a[1] * b[1] + a[2] * b[2] + a[3] * b[3];
}
Dot products of vectors with 3 elements could also be handled by the fipr insn
by setting the irrelevant element to 0.0 in one of the vector operands. For 2
element vectors an fmul,fmac sequence seems to be adequate (which already
works).
I've tried adding some combine patterns to handle the V2SF case (see
attachment), but the results are not so convincing. For example, the case
float test02 (float a0, float a1, float a2, float a3,
float b0, float b1, float b2, float b3)
{
return a0 * b0 + a1 * b1 + a2 * b2 + a3 * b3;
}
compiled with -O2 -m4-single -mb results in:
fmov.s fr12,@-r15 ! 42movsf_ie/7[length = 2]
fmov.s fr13,@-r15 ! 43movsf_ie/7[length = 2]
fmov.s fr14,@-r15 ! 44movsf_ie/7[length = 2]
fmov.s fr15,@-r15 ! 45movsf_ie/7[length = 2]
fmovfr9,fr12! 31movsf_ie/1[length = 2]
fmovfr8,fr13! 32movsf_ie/1[length = 2]
fmovfr11,fr14 ! 33movsf_ie/1[length = 2]
fmovfr10,fr15 ! 34movsf_ie/1[length = 2]
fmovfr5,fr0 ! 27movsf_ie/1[length = 2]
fmovfr4,fr1 ! 28movsf_ie/1[length = 2]
fmovfr7,fr2 ! 29movsf_ie/1[length = 2]
fmovfr6,fr3 ! 30movsf_ie/1[length = 2]
fiprfv12,fv0! 35fipr_compact[length = 2]
fmov.s @r15+,fr15 ! 50movsf_ie/6[length = 2]
fmov.s @r15+,fr14 ! 51movsf_ie/6[length = 2]
fmovfr3,fr0 ! 36movsf_ie/1[length = 2]
fmov.s @r15+,fr13 ! 52movsf_ie/6[length = 2]
rts ! 54*return_i[length = 2]
fmov.s @r15+,fr12 ! 53movsf_ie/6[length = 2]
which actually is supposed to be:
fiprfv4,fv8
rts
fmovfr11,fr0
Also, in the case of
float test01 (const v4sf a, const v4sf b, const v4sf c)
{
float x = a[0] * b[0] + a[1] * b[1] + a[2] * b[2] + a[3] * b[3];
float y = c[0] * b[0] + c[1] * b[1] + c[2] * b[2] + c[3] * b[3];
return x + y;
}
only one fipr insn is generated, due to various other optimization effects.
It seems there is no standard name pattern for doing FP vector dot products
yet.
I guess it would be better to also have some tree-optimization support for
this.
[Bug target/55295] [SH] Add support for fipr instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-12 22:39:27 UTC --- I forgot to mention that at least there should be a target specific built-in function to generate the fipr insn. There is already a SHmedia built-in for that, so adding one for SH4* shouldn't be a big deal. However, ideally the compiler would discover fipr opportunities by itself (when compiling with -ffast-math).
[Bug c/55293] Attempt to bootstrap GCC 4.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 --- Comment #5 from Dennis Clarke dclarke at blastwave dot org 2012-11-12 22:44:19 UTC --- okay, exact same failure happens with -D_POSIX_C_SOURCE=200112L by itself. Am trying with _XOPEN_SOURCE=600 defined. Thus far ( well past 70 secs ) the stage 1 phase seems to be running. So I will report what I see in seven hours or more .. hopefully a lot lot more. dc
[Bug target/55296] New: [SH] Add support for disinterrupt function attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55296 Bug #: 55296 Summary: [SH] Add support for disinterrupt function attribute Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org Target: sh*-*-* For some low-level code it is sometimes useful to temporarily disable interrupts. Enabling/disabling interrupts manually can be error prone. I think it would be useful to have support for a function attribute that allows the user to disable interrupts for individual functions. There is already a function attribute 'disinterrupt' that is used by the Epiphany and MeP target, which could be re-used for this purpose.
[Bug c/55293] Attempt to bootstrap GCC 4.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 --- Comment #6 from Dennis Clarke dclarke at blastwave dot org 2012-11-12 23:06:56 UTC --- the following fails also .. and it fails early : $ $ CC='gcc -m64 -g -D_XOPEN_SOURCE=600' CXX='g++ -m64 -g -D_XOPEN_SOURCE=600' \ ../gcc-4.7.2/configure --prefix=/usr/local/gcc4 --build=sparc64-sun-solaris2.10 --without-gnu-as \ --without-gnu-ld --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --with-ld=/usr/ccs/bin/ld \ --enable-nls --enable-threads=posix --enable-shared --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \ --with-cpu=v9 --enable-stage1-languages=c --disable-multilib --libexecdir=/usr/local/gcc4/lib \ --with-pkgversion=Blastwave.org\ Inc.\ Mon\ Nov\ 12\ 22\:56\:32\ GMT\ 2012 \ --with-bugurl=http\:\/\/www.blastwave.org\/support --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap checking build system type... sparc64-sun-solaris2.10 checking host system type... sparc64-sun-solaris2.10 checking target system type... sparc64-sun-solaris2.10 checking for a BSD-compatible install... ../gcc-4.7.2/install-sh -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/local/bin/gsed checking for gawk... gawk checking for libitm support... yes checking for gcc... gcc -m64 -g -D_XOPEN_SOURCE=600 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -m64 -g -D_XOPEN_SOURCE=600 accepts -g... yes checking for gcc -m64 -g -D_XOPEN_SOURCE=600 option to accept ISO C89... unsupported checking whether we are using the GNU C++ compiler... yes checking whether g++ -m64 -g -D_XOPEN_SOURCE=600 accepts -g... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16 checking for objdir... .libs checking for the correct version of gmp.h... yes checking for the correct version of mpfr.h... yes checking for the correct version of mpc.h... yes checking for the correct version of the gmp/mpfr/mpc libraries... yes checking for PWL_handle_timeout in -lpwl... no checking for version 0.11 (revision 0 or later) of PPL... no The following languages will be built: c,ada,c++,fortran,lto,objc *** This configuration is not supported in the following subdirectories: target-libmudflap target-libgo target-libffi target-zlib target-libjava target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for bison... bison -y checking for bison... bison checking for gm4... /usr/local/bin/gm4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... (cached) /usr/ccs/bin/ar checking for as... (cached) /usr/ccs/bin/as checking for dlltool... no checking for ld... (cached) /usr/ccs/bin/ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... no checking for objdump... no checking for readelf... no checking for cc... cc checking for c++... c++ checking for gcc... gcc checking for gcj... no checking for gfortran... gfortran checking for gccgo... no checking for ar... no checking for ar... ar checking for as... no checking for as... as checking for dlltool... no checking for dlltool... no checking for ld... no checking for ld... ld checking for lipo... no checking for lipo... no checking for nm... no checking for nm... nm checking for objdump... no checking for objdump... no checking for ranlib... no checking for ranlib... ranlib checking for readelf... no checking for readelf... no checking for strip... no checking for strip... strip checking for windres... no checking for windres... no checking for windmc... no checking for windmc... no checking where to find the target ar... host tool checking where to find the target as... host tool checking where to find the target cc... just compiled checking where to find the target c++... just compiled checking where to find the target c++ for libstdc++... just compiled checking where to find the target dlltool... host tool checking where to find the target gcc... just compiled checking where to find the target gcj... host tool checking where to find the target gfortran... just compiled checking where to find the target gccgo... host tool checking where to find the target ld... host tool checking where to find the target lipo... host
[Bug fortran/55297] New: 4.8 Regression: type-bound operator clashes with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55297 Bug #: 55297 Summary: 4.8 Regression: type-bound operator clashes with abstract interface Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dam...@rouson.net $ cat athlete.f90 module athlete_module type athlete contains procedure :: negative generic :: operator(-) = negative end type abstract interface integer function sum_interface(this) import athlete class(athlete) this end function end interface contains integer function negative(this) class(athlete) ,intent(in) :: this end function end module $ gfortran-mp-4.7 -c athlete.f90 $ gfortran-mp-4.8 -c athlete.f90 athlete.f90:5.29: generic :: operator(-) = negative 1 Error: Entity 'negative' at (1) is already present in the interface wlan-clients-2916:gnu rouson$ gfortran-mp-4.8 --version GNU Fortran (MacPorts gcc48 4.8-20121021_0) 4.8.0 20121021 (experimental)
[Bug target/55298] New: [SH] Add support to disable FPU usage for individual functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55298
Bug #: 55298
Summary: [SH] Add support to disable FPU usage for individual
functions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
On SH3* and SH4* targets, 'fast interrupt handlers' (non-reentrant ISRs) can be
implemented by specifying the 'interrupt_handler' and 'nosave_low_regs'
function attributes. If such an ISR invokes another function the compiler
currently generates push/pop insns for all call clobbered FP registers. This
could be avoided by specifying another function attribute ('nofpu') to turn off
hardware FPU usage for a particular function. A 'nofpu' ISR that invokes only
'nofpu' functions then does not need to push/pop any FP registers.
Some ABI compatibility issues I can think of at the moment are:
When a 'nofpu' function invokes a normal function (that could use the FPU or
takes any args in FP regs) the best thing is probably to issue a compile time
error.
When a normal function invokes a 'nofpu' function that does not take any FP
args (in registers) there is no problem.
When a normal function invokes a 'nofpu' function that takes FP args in GP regs
the call must use the 'nofpu' ABI.
Alternatively, the compiler could generate two versions of 'nofpu' functions.
One version that follows the 'nofpu' ABI and a normal version. Normal
functions that invoke 'nofpu' functions could then switch to a call to the
normal variant of the 'nofpu' function. The duplicated code would then be
eliminated by the linker.
Note: Currently the only way to disable HW FPU usage is to specify e.g.
'-m4-nofpu', which only works for whole translation units. Also, due to the
ABI differences invoking functions in translation units that were compiled with
'-m4-nofpu' from translation units compiled with '-m4' is not going to work.
[Bug c/55299] New: missed optimization: ASR idiom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55299
Bug #: 55299
Summary: missed optimization: ASR idiom
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: o...@survex.com
This is similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54579 but for a
different (and perhaps clearer) idiom for arithmetic shift right. I've filed
this as a separate PR rather than adding it as a comment, but if it's actually
the same issue underneath, please merge or mark as a duplicate.
int asr(int a, int b)
{
return a 0 ? ~((~a) b) : a b;
}
olly@gcc12:~$ /opt/cfarm/gcc-latest/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/cfarm/gcc-latest/bin/gcc
COLLECT_LTO_WRAPPER=/home/iulius/autobuild/bin/gcc-4.7.1/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.1-src/configure
--prefix=/home/iulius/autobuild/bin/gcc-4.7.1
--with-gmp=/home/iulius/autobuild/bin/gmp-5.0.5
--with-mpfr=/home/iulius/autobuild/bin/mpfr-3.1.0
--with-mpc=/home/iulius/autobuild/bin/mpc-0.9 --disable-nls
--enable-threads=posix --disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 4.7.1 (GCC)
Compiling with:
LD_LIBRARY_PATH=/opt/cfarm/mpc-latest/lib:/opt/cfarm/mpfr-latest/lib:/opt/cfarm/gmp-latest/lib
/opt/cfarm/gcc-latest/bin/gcc -O2 -S asr.c -o asr.S
Gives this for the function asr:
asr:
.LFB0:
movl%edi, %eax
movl%esi, %ecx
sarl%cl, %eax
testl%edi, %edi
js.L5
rep
ret
.p2align 4,,10
.p2align 3
.L5:
movl%edi, %eax
notl%eax
sarl%cl, %eax
notl%eax
ret
Ideally the conditional would be optimised down to just the sarl instruction.
I've checked the older compiler versions on gcc12 (back to 4.1.1) and they all
leave the branch in. So if this is a regression, it isn't at all recent.
[Bug fortran/55297] [4.8 Regression] type-bound operator clashes with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55297 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-12 CC||janus at gcc dot gnu.org Summary|4.8 Regression: type-bound |[4.8 Regression] type-bound |operator clashes with |operator clashes with |abstract interface |abstract interface Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-12 23:46:10 UTC --- Revision 188914 (2012-06-24) does not give error; revision 189336 (2012-07-06) does.
[Bug target/55300] New: [SH] Add support for store queue address space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55300
Bug #: 55300
Summary: [SH] Add support for store queue address space
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh4*-*-*
On SH4* targets there is a store queue (SQ) resource. While the management of
the SQ resource (i.e. how user code obtains a pointer to the SQ) is beyond the
scope of the compiler, there is one thing that it could help with. The usage
of the SQ has some restrictions on the memory accesses that are valid in the SQ
area:
* Reads from SQ area are not valid (return garbage or zero, don't remember)
* Writes must be 32 bit or 64 bit wide
User code that utilizes the SQ to write data could, for example, do so by
obtaining a pointer to the SQ area from the system, then cast the pointer to
some user defined data struct to be filled in and write data to the SQ area by
setting members in the struct. However, the members of such a struct must all
be accessed with 32 or 64 bit mem refs. For example this would be invalid:
struct
{
int a, b, c;
char d0,d1,d2,d3;
int x[4];
};
If I'm not mistaken, such invalid mem refs can be avoided by adding a target
specific address space.
[Bug bootstrap/55293] bootstrap failure: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-12 Component|c |bootstrap CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 Summary|Attempt to bootstrap GCC|bootstrap failure: invalid |4.7.2 on Solaris 10 Sparc |conversion from 'char**' to |fails with |'const char**' |gcc/pretty-print.c:954:28: |[-fpermissive] |error: invalid conversion | |from 'char**' to 'const | |char**' [-fpermissive] | Target Milestone|--- |4.7.3 Build||*-*-solaris2.* --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-12 23:57:53 UTC --- The workaround is to add --disable-nls to the configure line. That being said, we should probably do something.
[Bug target/55301] New: [SH] broken sp_switch function attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55301
Bug #: 55301
Summary: [SH] broken sp_switch function attribute
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
The example from the sp_switch function attribute documentation:
void* alt_stack;
void f (void) __attribute__ ((interrupt_handler, sp_switch (alt_stack)));
void f (void)
{
}
results in
sh_tmp.cpp: In function 'void f()':
sh_tmp.cpp:9:1: error: unrecognizable insn:
(insn 8 3 9 2 (parallel [
(const_int 1 [0x1])
(mem/u/c:SI (label_ref 0) [0 S4 A32])
]) sh_tmp.cpp:8 -1
(nil))
sh_tmp.cpp:9:1: internal compiler error: in extract_insn, at recog.c:2109
This happens on 4.8, 4.7 branch and 4.6 branch.
[Bug bootstrap/55293] bootstrap failure: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-13 00:15:19 UTC --- pretty-print.c already does: ICONV_CONST char *inbuf = CONST_CAST (char *, ident); and ICONV_CONST should be set to 'const' by gcc/configure (using the macros from config/iconv.m4) Could configure be finding GNU libiconv, with a correct signature, so ICONV_CONST is empty, but during compilation of pretty-print.c the system iconv.h is found instead, which needs ICONV_CONST?
[Bug target/55302] New: [SH] Add support for logical ops with GBR mems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55302 Bug #: 55302 Summary: [SH] Add support for logical ops with GBR mems Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org Target: sh*-*-* Since now GCC supports GBR based mem refs through the __builtin_thread_pointer function (PR 54760), support for logical operations on QImode GBR mem refs could be added. The insns in question are: and.b #imm,@(r0,gbr) or.b #imm,@(r0,gbr) tst.b #imm,@(r0,gbr) xor.b #imm,@(r0,gbr) Although the insns are slower than using separate loads/stores and operation insn sequences, the resulting code can be potentially more compact. It might be beneficial to enable these insns when optimizing for size.
[Bug bootstrap/55293] bootstrap failure: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-13 00:21:03 UTC --- pretty-print.c already does: ICONV_CONST char *inbuf = CONST_CAST (char *, ident); and ICONV_CONST should be set to 'const' by gcc/configure (using the macros from config/iconv.m4) Could configure be finding GNU libiconv, with a correct signature, so ICONV_CONST is empty, but during compilation of pretty-print.c the system iconv.h is found instead, which needs ICONV_CONST? Yup, that's a well-known scenario on Solaris, there is a dozen of PRs about this in the database I think.
[Bug target/55303] New: [SH] Add support for clips / clipu instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55303 Bug #: 55303 Summary: [SH] Add support for clips / clipu instructions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org Target: sh2a*-*-* Support for the following SH2A specific instructions should be added: clips.b Rn clips.w Rn clipu.b Rn clipu.w Rn These can be used to implement saturating arithmetic, for example.
[Bug objc/55291] libsanitizer doesn't build multilib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55291 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-13 00:33:06 UTC --- configure.ac has #AM_ENABLE_MULTILIB(, ..)
[Bug other/55304] New: libsanitizer can't be used with GCC autoconf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55304 Bug #: 55304 Summary: libsanitizer can't be used with GCC autoconf Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com GCC only requires autoconf 2.64 while configure.ac has AC_PREREQ([2.68])
