[Bug c/61444] Missing undeclared identifier message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61444 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I fail to see why this would be useful. Anyway, it shouldn't be hard to implement, but probably would need new -Wwhatever option.
[Bug rtl-optimization/61446] New: [4.10 Regression]: ICE in copyprop_hardreg_forward_1, at regcprop.c with -O2 -m32 -march=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61446
Bug ID: 61446
Summary: [4.10 Regression]: ICE in copyprop_hardreg_forward_1,
at regcprop.c with -O2 -m32 -march=corei7
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Following testcase:
--cut here--
unsigned long long
__fixunssfdi (float a)
{
const double dfa = a;
const unsigned int hi = dfa / 0x1p32f;
const unsigned int lo = dfa - (double) hi * 0x1p32f;
return ((unsigned long long) hi (4 * (8))) | lo;
}
--cut here--
ICEs on x86_64-pc-linux-gnu with -O2 -m32 -march=corei7:
./cc1 -O2 -m32 -march=corei7 ree.c
__fixunssfdi
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups *free_inline_summary
whole-program profile_estimate devirt cp inline pure-const
static-var comdatsAssembling functions:
__fixunssfdi
ree.c: In function ‘__fixunssfdi’:
ree.c:11:1: error: insn does not satisfy its constraints:
}
^
(insn 54 11 47 2 (set (reg:DI 0 ax)
(reg:DI 21 xmm0)) ree.c:7 89 {*movdi_internal}
(expr_list:REG_UNUSED (reg:DI 0 ax)
(nil)))
ree.c:11:1: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:776
0x96bec8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/uros/gcc-svn/trunk/gcc/rtl-error.c:109
0x96beef _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/uros/gcc-svn/trunk/gcc/rtl-error.c:120
0x9462a4 copyprop_hardreg_forward_1
/home/uros/gcc-svn/trunk/gcc/regcprop.c:776
0x94645a execute
/home/uros/gcc-svn/trunk/gcc/regcprop.c:1264
Please submit a full bug report,
...
_.split2 pass generates:
...
(insn 11 45 46 2 (set (reg/v:SI 0 ax [orig:85 hi ] [85])
(reg:SI 2 cx [99])) ree.c:7 90 {*movsi_internal}
(nil))
(insn 46 11 47 2 (set (reg:DI 21 xmm0 [118])
(zero_extend:DI (reg/v:SI 0 ax [orig:85 hi ] [85]))) ree.c:10 133
{*zero_extendsidi2}
(nil))
(insn 47 46 48 2 (set (mem/c:DI (reg/f:SI 7 sp) [0 S8 A64])
(reg:DI 21 xmm0 [118])) ree.c:10 89 {*movdi_internal}
(nil))
(insn 48 47 13 2 (set (reg:DF 9 st(1) [orig:101 D.1856 ] [101])
(float:DF (mem/c:DI (reg/f:SI 7 sp) [0 S8 A64]))) ree.c:10 206
{*floatdidf2_i387}
(nil))
...
and this sequence is transformed in _.ree pass to:
...
(insn 11 45 54 2 (set (reg:DI 21 xmm0)
(zero_extend:DI (reg:SI 2 cx [99]))) ree.c:7 133 {*zero_extendsidi2}
(nil))
(insn 54 11 47 2 (set (reg:DI 0 ax)
(reg:DI 21 xmm0)) ree.c:7 -1
(nil))
(insn 47 54 48 2 (set (mem/c:DI (reg/f:SI 7 sp) [0 S8 A64])
(reg:DI 21 xmm0 [118])) ree.c:10 89 {*movdi_internal}
(nil))
(insn 48 47 13 2 (set (reg:DF 9 st(1) [orig:101 D.1856 ] [101])
(float:DF (mem/c:DI (reg/f:SI 7 sp) [0 S8 A64]))) ree.c:10 206
{*floatdidf2_i387}
(nil))
...
(insn 54) is the problematic instruction.
[Bug rtl-optimization/61446] [4.10 Regression]: ICE in copyprop_hardreg_forward_1, at regcprop.c with -O2 -m32 -march=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61446 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||i686 Blocks||61423 Target Milestone|--- |4.10.0
[Bug target/61423] Incorrect conversion from unsigned int to floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61423 --- Comment #8 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #5) Created attachment 32903 [details] Testcase that fails in REE pass This testcase fails with patched gcc in REE pass: This is now PR61446.
[Bug c/61444] Missing undeclared identifier message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61444 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-08 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- I can see one case where this would be useful: if you have a variable and you have the same typo in two different places.
[Bug c/61444] Missing undeclared identifier message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61444 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Created attachment 32908 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32908action=edit show_all_undeclared Patch that adds the -fno-show-all-undeclared option to show all instances of an undeclared variable in a function.
[Bug rtl-optimization/61446] [4.10 Regression]: ICE in copyprop_hardreg_forward_1, at regcprop.c with -O2 -m32 -march=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61446
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-06-08
Ever confirmed|0 |1
--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr ---
This breaks bootstrap on x86_64-apple-darwin13 and other targets (see
https://gcc.gnu.org/ml/gcc-regression/2014-06/). On darwin the failure is
/opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/
-B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.2.0/bin/
-B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.2.0/lib/ -isystem
/opt/gcc/gcc4.10w/x86_64-apple-darwin13.2.0/include -isystem
/opt/gcc/gcc4.10w/x86_64-apple-darwin13.2.0/sys-include-g -O2 -O2 -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -pipe -fno-common -I. -I. -I../.././gcc
-I../../../work/libgcc -I../../../work/libgcc/. -I../../../work/libgcc/../gcc
-I../../../work/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o
_fixunssfti_s.o -MT _fixunssfti_s.o -MD -MP -MF _fixunssfti_s.dep -DSHARED
-DL_fixunsdfdi -c ../../../work/libgcc/libgcc2.c \
-DLIBGCC2_UNITS_PER_WORD=8
../../../../work/libgcc/libgcc2.c: In function '__fixunssfdi':
../../../../work/libgcc/libgcc2.c:1492:1: error: insn does not satisfy its
constraints:
}
^
(insn 60 13 14 2 (set (reg:DI 0 ax)
(reg:DI 21 xmm0)) ../../../../work/libgcc/libgcc2.c:1444 89
{*movdi_internal}
(expr_list:REG_UNUSED (reg:DI 0 ax)
(nil)))
../../../../work/libgcc/libgcc2.c:1492:1: internal compiler error: in
copyprop_hardreg_forward_1, at regcprop.c:776
Reverting r211321 allowed me to bootstrap r211353 on x86_64-apple-darwin13.
[Bug rtl-optimization/61446] [4.10 Regression]: ICE in copyprop_hardreg_forward_1, at regcprop.c with -O2 -m32 -march=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61446
--- Comment #2 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Dominique d'Humieres from comment #1)
This breaks bootstrap on x86_64-apple-darwin13 and other targets (see
https://gcc.gnu.org/ml/gcc-regression/2014-06/). On darwin the failure is
Yes, known problem. Please use following patch to disable REE pass for now:
Index: common/config/i386/i386-common.c
===
--- common/config/i386/i386-common.c(revision 211321)
+++ common/config/i386/i386-common.c(working copy)
@@ -866,7 +866,7 @@
static const struct default_options ix86_option_optimization_table[] =
{
/* Enable redundant extension instructions removal at -O2 and higher. */
-{ OPT_LEVELS_2_PLUS, OPT_free, NULL, 1 },
+{ OPT_LEVELS_2_PLUS, OPT_free, NULL, 0 },
/* Enable function splitting at -O2 and higher. */
{ OPT_LEVELS_2_PLUS, OPT_freorder_blocks_and_partition, NULL, 1 },
/* Turn off -fschedule-insns by default. It tends to make the
[Bug tree-optimization/61434] [4.10 Regression] wrong code at -O3 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61434 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-08 CC||jakub at gcc dot gnu.org, ||kyukhin at gcc dot gnu.org Target Milestone|--- |4.10.0 Summary|wrong code at -O3 on|[4.10 Regression] wrong |x86_64-linux|code at -O3 on x86_64-linux Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r209972.
[Bug c/61447] New: _Alignof returns incorrect results for some types/archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447
Bug ID: 61447
Summary: _Alignof returns incorrect results for some
types/archs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
_Alignof is defined per C11 as the alignment requirement of its operand type.
This is different from GCC's result for __alignof__ (and sometimes for
_Alignof) where it returns the preferred alignment for optimization or the
actual alignment applied.
On i386, _Alignof(long long) returns 8, despite the correct value being 4. With
recent enough gcc (tested on 4.9.0), -std=c11 fixes _Alignof when applied to
the type name, but not when applied to an object: long long x; _Alignof(x)
still gives 8. In order to be correct:
1. _Alignof(object) should always be the same as _Alignof(__typeof__(object))
2. _Alignof(x) should always be the same as (sizeof(struct{char __a;
__typeof__(x) __b;}) - sizeof(x))
Failure of condition 2 results in observably incorrect behavior: a program can
observe the existence of a structure containing members a and b of the same
type where (char*)foo.a-(char*)foo.b is not a multiple of _Alignof(foo.a).
[Bug bootstrap/61448] New: ice on profiledbootstrap with -o2 -flto -fuse-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61448 Bug ID: 61448 Summary: ice on profiledbootstrap with -o2 -flto -fuse-linker-plugin Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hete2 at gmx dot de On my System: uname -m = x86_64 uname -r = 3.5.0-23-generic uname -s = Linux uname -v = #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 on a Intel i3-2120 CPU @ 3.30GHz configuring gcc-4.8.3 with --enable-checking=release --with-arch=native an building with make -j 2 BOOT_CFLAGS='-O2 -flto -fuse-linker-plugin' profiledbootstrap i got the following error: ../../gcc/optabs.c: In Funktion »emit_indirect_jump«: ../../gcc/optabs.c:4478:0: interner Compiler-Fehler: Speicherzugriffsfehler emit_indirect_jump (rtx loc) ^ 0x94b33d crash_signal ../../gcc/toplev.c:332 0x74c2f6 can_refer_decl_in_current_unit_p ../../gcc/gimple-fold.c:70 0x74c6a7 canonicalize_constructor_val(tree_node*, tree_node*) ../../gcc/gimple-fold.c:172 0x7535e0 fold_ctor_reference ../../gcc/gimple-fold.c:2952 0x7534dc fold_nonarray_ctor_reference ../../gcc/gimple-fold.c:2933 0x75375e fold_ctor_reference ../../gcc/gimple-fold.c:2978 0x7530c6 fold_array_ctor_reference ../../gcc/gimple-fold.c:2867 0x75373d fold_ctor_reference ../../gcc/gimple-fold.c:2975 0x753b23 fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*)) ../../gcc/gimple-fold.c:3077 0x753c08 fold_const_aggregate_ref(tree_node*) ../../gcc/gimple-fold.c:3099 0x74cb1a maybe_fold_reference ../../gcc/gimple-fold.c:277 0x74cae6 maybe_fold_reference ../../gcc/gimple-fold.c:269 0x74cda9 fold_gimple_assign ../../gcc/gimple-fold.c:343 0x74efaf fold_stmt_1 ../../gcc/gimple-fold.c:1190 0x74f4c7 fold_stmt(gimple_stmt_iterator*) ../../gcc/gimple-fold.c:1318 0xa767a8 substitute_and_fold(tree_node* (*)(tree_node*), bool (*)(gimple_stmt_iterator*), bool) ../../gcc/tree-ssa-propagate.c:1186 0xb24315 vrp_finalize ../../gcc/tree-vrp.c:9212 0xb24461 execute_vrp ../../gcc/tree-vrp.c:9308 Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein; bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es dienlich ist. Please include the complete backtrace with any bug report. Siehe http://gcc.gnu.org/bugs.html für nähere Anweisungen. lto-wrapper: /home/hete/gcc/gcc-4.8.3/Build3/./prev-gcc/xg++ gab Ende-Status 1 zurück /usr/bin/ld: lto-wrapper failed Normal bootstrapping works. Gcc 4.9.0 hasn't this error, but i have to add -ffat-lto-objects to the boot-cflags.
[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #4 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 32909 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32909action=edit possible fix I am experimenting with this patch, which extends Eric's patch for references of frame_pointer_rtx also to references of stack_pointer_rtx, hard_frame_pointer_rtx and arg_pointer_rtx.
[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047 --- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de --- I tried a boot-strap with this patch, and there are almost no false positives, except a few varargs functions. Most interesting are these cases: /home/ed/gnu/gcc-build/./prev-gcc/xg++ -B/home/ed/gnu/gcc-build/./prev-gcc/ -B/home/ed/gnu/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/ed/gnu/gcc-trunk/libstdc++-v3/libsupc++ -L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. -I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include -I/home/ed/gnu/gcc-build/./gmp -I/home/ed/gnu/gcc-trunk/gmp -I/home/ed/gnu/gcc-build/./mpfr -I/home/ed/gnu/gcc-trunk/mpfr -I/home/ed/gnu/gcc-trunk/mpc/src -I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc-trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/ed/gnu/gcc-build/./cloog/include -I/home/ed/gnu/gcc-trunk/cloog/include -I../gcc-trunk/cloog/include -I/home/ed/gnu/gcc-build/./isl/include -I/home/ed/gnu/gcc-trunk/isl/include -o expmed.o -MT expmed.o -MMD -MP -MF ./.deps/expmed.TPo ../../gcc-trunk/gcc/expmed.c *** sp can trap: offset=34359738424, size=8, low_bound=-144, high_bound=272 *** sp can trap: offset=34359738456, size=8, low_bound=-144, high_bound=272 -- /home/ed/gnu/gcc-build/./prev-gcc/xg++ -B/home/ed/gnu/gcc-build/./prev-gcc/ -B/home/ed/gnu/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/ed/gnu/gcc-trunk/libstdc++-v3/libsupc++ -L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. -I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include -I/home/ed/gnu/gcc-build/./gmp -I/home/ed/gnu/gcc-trunk/gmp -I/home/ed/gnu/gcc-build/./mpfr -I/home/ed/gnu/gcc-trunk/mpfr -I/home/ed/gnu/gcc-trunk/mpc/src -I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc-trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/ed/gnu/gcc-build/./cloog/include -I/home/ed/gnu/gcc-trunk/cloog/include -I../gcc-trunk/cloog/include -I/home/ed/gnu/gcc-build/./isl/include -I/home/ed/gnu/gcc-trunk/isl/include -o fixed-value.o -MT fixed-value.o -MMD -MP -MF ./.deps/fixed-value.TPo ../../gcc-trunk/gcc/fixed-value.c *** sp can trap: offset=34359738472, size=8, low_bound=-144, high_bound=208 *** sp can trap: offset=34359738488, size=8, low_bound=-144, high_bound=240 /home/ed/gnu/gcc-build/./prev-gcc/xg++ -B/home/ed/gnu/gcc-build/./prev-gcc/ -B/home/ed/gnu/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/ed/gnu/gcc-trunk/libstdc++-v3/libsupc++ -L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc
[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047 --- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de --- they only happen in stage3, not in stage2. expmed.c.214r.reload: ;; Function long unsigned int choose_multiplier(long unsigned int, int, int, long unsigned int*, int*, int*) (_Z17choose_multipliermiiPmPiS0_, funcdef_no=1085, decl_uid=47659, symbol_order=801) ... 557: r13:DI=0x7ff78 REG_EQUIV 0x7ff78 ... 547: debug this = debug_implicit_ptr 548: debug D#64 = debug_implicit_ptr 549: debug D#37 = D#64 550: debug this = D#37 551: debug len = optimized away 552: debug D#65 = debug_implicit_ptr 553: debug D#39 = D#65 554: debug this = D#39 555: debug high = [sp:DI+0x80038] 556: debug res = 0 560: NOTE_INSN_DELETED 1334: NOTE_INSN_DELETED 1367: ax:DI=[sp:DI+r13:DI+0xc0] fixed-value.c.214r.reload: ;; Function void fixed_from_string(fixed_value*, const char*, machine_mode) (_Z17fixed_from_stringP11fixed_valuePKc12machine_mode, funcdef_no=827, decl_uid=38219, symbol_order=541) ... 89: NOTE_INSN_BASIC_BLOCK 8 90: debug this = sp:DI+0x70 91: debug D#17 = sp:DI+0x70 92: debug D#2 = D#17 93: debug this = D#2 94: debug len = optimized away 95: debug D#18 = sp:DI+0x70 96: debug this = D#18 97: debug high = [sp:DI+0x80068] 98: dx:DI=0x7ffd8 REG_EQUIV 0x7ffd8 100: dx:DI=[sp:DI+dx:DI+0x90] REG_EQUAL [frame:DI+0x7ffd8] unfortunately, gcc crashes when compiling fold-const.c when I add -fdump-rtl-all-slim to the command line.
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||dominiq at lps dot ens.fr --- Comment #25 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- *** Bug 45128 has been marked as a duplicate of this bug. ***
[Bug fortran/45128] Segmentation fault with -fwhole-file for subref_array_pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45128 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #6 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- I confirm that it's a duplicate of PR 34640 (exact same backtrace). *** This bug has been marked as a duplicate of bug 34640 ***
[Bug fortran/56818] [meta-bug] fortran-dev bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56818 Bug 56818 depends on bug 45128, which changed state. Bug 45128 Summary: Segmentation fault with -fwhole-file for subref_array_pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45128 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047 --- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de --- xg++ [...] ../../gcc-trunk/gcc/fold-const.c -fdump-rtl-all-slim *** fp can trap: offset=34359738280, size=8, low_bound=-368, high_bound=32 ../../gcc-trunk/gcc/fold-const.c: In function 'tree_node* fold_unary_loc(location_t, tree_code, tree, tree)': ../../gcc-trunk/gcc/fold-const.c:8475:1: internal compiler error: Segmentation fault } ^ 0xbeaf1f crash_signal ../../gcc-trunk/gcc/toplev.c:337 0x11a43c0 pp_string(pretty_printer*, char const*) ../../gcc-trunk/gcc/pretty-print.c:906 0xba02c2 print_exp ../../gcc-trunk/gcc/sched-vis.c:391 0xba0dfd print_value(pretty_printer*, rtx_def const*, int) ../../gcc-trunk/gcc/sched-vis.c:510 0xb9fe08 print_pattern(pretty_printer*, rtx_def const*, int) ../../gcc-trunk/gcc/sched-vis.c:620 0xb9fb3b print_insn(pretty_printer*, rtx_def const*, int) ../../gcc-trunk/gcc/sched-vis.c:743 0xb9fd17 print_insn_with_notes ../../gcc-trunk/gcc/sched-vis.c:764 0xba104e dump_insn_slim(_IO_FILE*, rtx_def const*) ../../gcc-trunk/gcc/sched-vis.c:801 0x8a09c7 print_rtl_with_bb(_IO_FILE*, rtx_def const*, int) ../../gcc-trunk/gcc/cfgrtl.c:2196 0xb32db3 execute_function_dump ../../gcc-trunk/gcc/passes.c:1569 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.
[Bug c/61447] _Alignof returns incorrect results for some types/archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- ISO C does not define _Alignof (object), only _Alignof (type).
[Bug fortran/32630] [meta-bug] ISO C binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630 Bug 32630 depends on bug 38829, which changed state. Bug 38829 Summary: Bogus BIND(C) error message https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38829 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/38829] Bogus BIND(C) error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38829 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- This was fixed in gfortran 4.6 and later.
[Bug c/61447] _Alignof returns incorrect results for some types/archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447 --- Comment #2 from Rich Felker bugdal at aerifal dot cx --- Indeed, you seem to be correct in that claim. However it seems desirable that if this usage is not supported, it should be treated as a constraint violation rather than silently producing a wrong/meaningless result that appears right in most cases. In any case, I still think it's a bug that the wrong value is being produced for _Alignof(long long) except with -std=c11. Even if earlier versions of the standard have nothing to say about what it should produce, the principle of least surprise says that it should produce the same result as it does under C11 since only C11 defines _Alignof.
[Bug fortran/38829] Bogus BIND(C) error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38829 --- Comment #2 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Sun Jun 8 15:28:59 2014 New Revision: 211354 URL: http://gcc.gnu.org/viewcvs?rev=211354root=gccview=rev Log: PR fortran/38829 * gfortran.dg/bind_c_usage_29.f90: New file. Added: trunk/gcc/testsuite/gfortran.dg/bind_c_usage_29.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/61447] _Alignof returns incorrect results for some types/archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- What makes you think _Alignof depends on -std=c11 (other than for -pedantic diagnostics)? I don't see any point in requesting alignment of an object, as opposed to a type, unless you want a result that can sometimes be bigger than what you get from _Alignof applied to the type.
[Bug fortran/41627] mixing common and modules elicits ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41627 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |DUPLICATE Known to fail|| --- Comment #10 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- I get, again, the same backtrace on this one as I do for PR34640, so I'm closing it as duplicate. *** This bug has been marked as a duplicate of bug 34640 ***
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||dh458 at oakapple dot net --- Comment #26 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- *** Bug 41627 has been marked as a duplicate of this bug. ***
[Bug c/61447] _Alignof returns incorrect results for some types/archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447 --- Comment #4 from Rich Felker bugdal at aerifal dot cx --- Indeed, I can't reproduce that aspect of the problem now. My best guess is that I accidentally used gcc rather than gcc-4.9 for the test without -std=c11. I'll post a follow-up comment if I do find such a problem again. Back to the issue of _Alignof(object) however, I'm not so sure that your interpretation of the standard is correct anymore. At the very least the standard is ambiguous. 6.3.2.1 Lvalues, arrays, and function designators, paragraph 2, reads: Except when it is the operand of the sizeof operator, the _Alignof operator, the unary operator, the ++ operator, the -- operator, or the left operand of the . operator or an assignment operator, an lvalue that does not have array type is converted to the value stored in the designated object (and is no longer an lvalue); this is called lvalue conversion. This text does not make sense if an expression cannot be the operand of _Alignof. It's very possible that this is just residual cruft that should have been removed, but it would be nice to get some clarification on whether, from the committee's standpoint, the error is the presence of the above text or the omission of text about how _Alignof handles an argument that's not a type.
[Bug fortran/45187] ICE with CRAY pointer in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45187 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org Summary|ICE with CRAY pointer in|ICE with CRAY pointer in |module depending on |module |variable name | --- Comment #2 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Confirm on current trunk. Also, I have an idea why it depends on the variable name :) The ICE is observed with any variable name that is lexicographically smaller than c_ (i.e., that sorts before c_ in alphabetical order). I suppose we're trying to create backend decls for the POINTER in this order, and it fails when the variable has already been created before it. Since the error is a checking in gfc_create_module_variable(), and we probably simply need to bail out if the symbol is a Cray-pointee, here's a suggested patch: Index: trans-decl.c === --- trans-decl.c(revision 211315) +++ trans-decl.c(working copy) @@ -4282,6 +4282,10 @@ gfc_create_module_variable (gfc_symbol * if (sym-attr.use_assoc || sym-attr.in_common) return; + /* Cray pointees will be created elsewhere. */ + if (sym-attr.cray_pointee) +return; + /* Equivalenced variables arrive here after creation. */ if (sym-backend_decl (sym-equiv_built || sym-attr.in_equivalence))
[Bug c/61447] _Alignof returns incorrect results for some types/archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447 --- Comment #5 from Andreas Schwab sch...@linux-m68k.org --- The reference to _Alignof in 6.3.2.1 does not exist in the final version of the standard, according to Larry Jones in comp.std.c (Message-Id: ucvm2a-hig@jones.homeip.net or https://groups.google.com/d/topic/comp.std.c/v5hsWOu5vSw/discussion).
[Bug fortran/45187] ICE with CRAY pointer in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45187 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Patch works, submitted for review: https://gcc.gnu.org/ml/fortran/2014-06/msg00089.html
[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- I take it this one can be closed :)
[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
--- Comment #10 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
(In reply to Richard Biener from comment #9)
Can somebody produce a reduced testcase pair that
just has a bind-C named common with a single int so I can experiment a bit?
$ cat s.f90
module foo
use iso_c_binding
integer(c_int) :: i
common /com/ i
bind(c,name=toto) :: /com/
end module foo
$ cat s.c
int main(void)
{
extern int toto;
toto = 42;
}
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832 --- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still reproduces on current trunk @r211286
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 --- Comment #11 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Janne, can you post some new benchmarks for comparison?
[Bug c/61449] New: Statement expressions disallow storage specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61449
Bug ID: 61449
Summary: Statement expressions disallow storage specifiers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cube2killfield at gmail dot com
Essentially we have a tool which preprocesses C code and produces these inline
statement expressions with prototypes like ({ void foo(void); foo; }) and then
later implements the function. This is fine for global scope functions, but
ideally we want static storage on these functions as they're not suppose to
leak the file scope or be subject to automatic library import. The problem is
one cannot do the following with statement expressions.
({ static void foo(void); foo; })
static void foo() { }
This is fairly inconsistent behavior in respect to what constitutes a valid
declaration. I'm surprised this issue hasn't been run into before. Storage
specifiers should be valid in statement expressions.
[Bug tree-optimization/61437] [4.10 Regression] wrong code on x86_64-linux-gnu when compile separately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61437 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-08 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.10.0 Summary|wrong code on |[4.10 Regression] wrong |x86_64-linux-gnu when |code on x86_64-linux-gnu |compile separately |when compile separately Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r211233.
[Bug fortran/61450] New: ICE in gfc_global_used()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61450
Bug ID: 61450
Summary: ICE in gfc_global_used()
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
$ cat w.f90
module p
integer i1
bind(c,name=foo) :: i1
end module
subroutine truc() bind(c,name=foo)
end
$ gfortran w.f90
w.f90:6.36:
subroutine truc() bind(c,name=foo)
1
Internal Error at (1):
gfc_global_used(): Bad type
I don't know exactly how this specific case arises, but as it's only a
diagnostics trying to be extra smart, I suggest to give it a more decent
fallback, e.g.:
Index: parse.c
===
--- parse.c(revision 211315)
+++ parse.c(working copy)
@@ -4313,33 +4313,32 @@ gfc_global_used (gfc_gsymbol *sym, locus
switch(sym-type)
{
case GSYM_PROGRAM:
- name = PROGRAM;
+ name = as a PROGRAM ;
break;
case GSYM_FUNCTION:
- name = FUNCTION;
+ name = as a FUNCTION ;
break;
case GSYM_SUBROUTINE:
- name = SUBROUTINE;
+ name = as a SUBROUTINE ;
break;
case GSYM_COMMON:
- name = COMMON;
+ name = as a COMMON ;
break;
case GSYM_BLOCK_DATA:
- name = BLOCK DATA;
+ name = as a BLOCK DATA ;
break;
case GSYM_MODULE:
- name = MODULE;
+ name = as a MODULE ;
break;
default:
- gfc_internal_error (gfc_global_used(): Bad type);
- name = NULL;
+ name = ;
}
if (sym-binding_label)
-gfc_error (Global binding name '%s' at %L is already being used as a %s
+gfc_error (Global binding name '%s' at %L is already being used %s
at %L, sym-binding_label, where, name, sym-where);
else
-gfc_error (Global name '%s' at %L is already being used as a %s at %L,
+gfc_error (Global name '%s' at %L is already being used %sat %L,
sym-name, where, name, sym-where);
}
[Bug fortran/61450] ICE in gfc_global_used()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61450 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-08 CC||bur...@net-b.de Ever confirmed|0 |1
[Bug c++/61451] New: Parsing aborted at cp/parser.c:23778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61451
Bug ID: 61451
Summary: Parsing aborted at cp/parser.c:23778
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: svalorzen at gmail dot com
Created attachment 32910
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32910action=edit
Preprocessed source produced by compilation.
The following code:
#include tuple
template typename M
struct is_generative_model {
private:
template typename Z static auto test(int) - decltype(
static_caststd::tuplesize_t, double
(Z::*)(size_t,size_t) const (Z::sampleOR),
static_caststd::tuplesize_t,size_t, double
(Z::*)(size_t,size_t) const (Z::sampleSOR),
std::true_type()
);
template typename Z static auto test(...) - std::false_type;
public:
enum { value = std::is_samedecltype(testM(0)),std::true_type::value
};
};
int main() {
return 0;
}
When compiled with:
g++ -std=c++11 main.cpp
Triggers the following error:
main.cpp:8:110: internal compiler error: in cp_parser_abort_tentative_parse, at
cp/parser.c:23778
static_caststd::tuplesize_t, double
(Z::*)(size_t,size_t) const (Z::sampleOR),
^
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccYAAuUj.out file, please attach this to
your bugreport.
With compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
[Bug c++/61451] Parsing aborted at cp/parser.c:23778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61451
--- Comment #1 from Eugenio Bargiacchi svalorzen at gmail dot com ---
For some reason, if an additional line is added, the error goes away. This
compiles fine:
#include tuple
template typename M
struct is_generative_model {
private:
template typename Z static auto test(int) - decltype(
static_castsize_t (Z::*)() const
(Z::getS),
static_castdouble (Z::*)(size_t,size_t) const
(Z::sample),
static_castsize_t (Z::*)(size_t,size_t) const
(Z::sample),
std::true_type()
);
template typename Z static auto test(...) - std::false_type;
public:
enum { value = std::is_samedecltype(testM(0)),std::true_type::value
};
};
int main() {
return 0;
}
[Bug fortran/36275] [F03] Binding label can be any scalar char initialisation expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36275 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org --- Comment #11 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Patch proposed here, somewhat based on Mikael's patch in comment #6: https://gcc.gnu.org/ml/fortran/2014-06/msg00090.html
[Bug fortran/38839] BIND(C): Allow non-digit/underscore/alphabetic binding names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38839 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||fxcoudert at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org --- Comment #5 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Should be fixed at the same time as this patch here: https://gcc.gnu.org/ml/fortran/2014-06/msg00090.html , which reworks the parsing of binding labels. I intend to find what the consensus is on this issue, incorporate it into the patch, and close this.
[Bug c/61449] Statement expressions disallow storage specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61449 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- I don't see what this has to do with statement expressions. Standard ISO C rules for storage class specifiers are that block-scope declarations for functions need to use extern or no storage class specifier, and if the function has internal linkage, a file-scope static declaration must come before any block-scope declaration (and be visible when the block-scope declaration occurs).
[Bug c/61449] Statement expressions disallow storage specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61449 Dale Weiler cube2killfield at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Dale Weiler cube2killfield at gmail dot com --- Just consulted the standard. You're right. I'll need to make the tool do something else instead.
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 --- Comment #12 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- $ strace -c ./a.out % time seconds usecs/call callserrors syscall -- --- --- - - 99.970.078667 0 100 write 0.030.22 211 fstat 0.000.00 0 5 read 0.000.00 01710 open 0.000.00 0 7 close 0.000.00 0 8 6 stat 0.000.00 017 mmap 0.000.00 012 mprotect 0.000.00 0 1 munmap 0.000.00 0 3 brk 0.000.00 010 rt_sigaction 0.000.00 010 9 access 0.000.00 0 1 execve 0.000.00 0 1 readlink 0.000.00 0 1 arch_prctl -- --- --- - - 100.000.078689 100010425 total This is looking pretty good now!
[Bug tree-optimization/61452] New: hang at -O1 and -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61452
Bug ID: 61452
Summary: hang at -O1 and -Os on x86_64-linux-gnu
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following (valid) code causes gcc trunk (as well gcc 4.8 and 4.9) to hang
at -O1 and -Os (but not at -O0, -O2, and -O3).
This is a regression from 4.7.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140608 (experimental) [trunk revision 211353] (GCC)
$
$ gcc-trunk -O0 small.c; a.out
$ gcc-trunk -O2 small.c; a.out
$ gcc-4.7.3 -O1 small.c; a.out
$ gcc-4.7.3 -Os small.c; a.out
$
$ timeout -s 9 30 gcc-trunk -O1 small.c
Killed
$
int a, b;
short c, d;
char e, f;
int
fn1 (int p1, char p2)
{
return p1 || p2 ? 0 : p2;
}
void
fn2 ()
{
for (; a;)
{
int g;
g = c = e;
for (; a;)
b = fn1 (g = d = e, g);
f = g;
}
}
int
main ()
{
fn2 ();
return 0;
}
[Bug testsuite/61453] New: [4.10 Regression]: gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61453 Bug ID: 61453 Summary: [4.10 Regression]: gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't call Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: dominiq at gcc dot gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf This test passed before r210892, now it fails as follows: Running /tmp/hpautotest-gcc0/gcc/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/bind_c_array_params_2.f90 -O scan-assembler-times call[^\n\r]*myBindC 1 The regexp in question is for the actual subroutine call instruction, which is *not* called call for all targets. Author of commit CC:ed.
[Bug tree-optimization/61301] missed optimization of move if vector passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61301
--- Comment #4 from Thomas Preud'homme thomas.preudhomme at arm dot com ---
(In reply to Richard Biener from comment #3)
_3 = MEM[(const float *)this_1(D) + 4B];
_4 = MEM[(const float *)this_1(D)];
_5 = MEM[(const float *)this_1(D) + 12B];
_6 = MEM[(const float *)this_1(D) + 8B];
_7 = {_3, _4, _5, _6};
return _7;
does look like an opportunity for a bswap pass improvement. Basically
handle CONSTRUCTOR as supported composition operation (and then support
vector loads and shuffle, of course).
I had started working on shuffle support in bswap but I realized this would
probably not help ARM as move between floating point register and general
purpose register are quite slow. I then moved on to higher priority tasks This
doesn't mean I'm finished with the bswap task, as several improvement were
suggested to me during the review of the first patch to improve bswap.
So I wouldn't hold my breath for me doing work for now, feel free to beat me to
it.
[Bug tree-optimization/61301] missed optimization of move if vector passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61301 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Thomas Preud'homme from comment #4) I had started working on shuffle support in bswap but I realized this would probably not help ARM as move between floating point register and general purpose register are quite slow. I then moved on to higher priority tasks This doesn't mean I'm finished with the bswap task, as several improvement were suggested to me during the review of the first patch to improve bswap. But it might help AARCH64 (maybe not ARM's cores though) where the moving between the registers might be faster.
