Re: Truncate optimisation question
But that's the problem with trying to do the optimisation in this way. We first simplify a truncation of an SImode addition X. Then we simplify a zero extension of that truncation. Then we have the opportunity to realise that the zero extension wasn't necessary after all, so we actually want to undo both simplifications and go back to the original addition pattern. So undoing the simplifications is precisely what we're aiming for here, again regardless of RISCness. In other words, you want to add the reverse transformation in combine.c to undo the effects of the simplication in simplify-rtx.c? And move the latter simplification back to combine.c in the process? -- Eric Botcazou
Re: Truncate optimisation question
Eric Botcazou ebotca...@adacore.com writes: But that's the problem with trying to do the optimisation in this way. We first simplify a truncation of an SImode addition X. Then we simplify a zero extension of that truncation. Then we have the opportunity to realise that the zero extension wasn't necessary after all, so we actually want to undo both simplifications and go back to the original addition pattern. So undoing the simplifications is precisely what we're aiming for here, again regardless of RISCness. In other words, you want to add the reverse transformation in combine.c to undo the effects of the simplication in simplify-rtx.c? And move the latter simplification back to combine.c in the process? No, the second follow-up was about moving the simplification to combine.c and guarding it with !WORD_REGISTER_OPERATIONS, or whatever other check you prefer, so that no undoing is necessary. To be clear, that isn't what I want. :-) It just seems less bad than guarding a simplify-rtx.c operation based on the target. What I really want is to do redundancy elimination as a separate pass, without tying it combine and without doing it the way that combine does. But it's not like I've got time to do that. The quote above was just me griping about the way that, although combine is asking simplify-rtx.c to simplify i1-combined-with-i2, it's actually relying on the simplifications being no-ops, so that the original i1 is still available when i1-with-i2 is further combined into i3 and the redundancy of i2 becomes known, giving i1-with-i3. It just seems like a fragile way to do redundancy elimination. Thanks, Richard
3 libstdc++ tests fail at random
Hi, I have been seeing 3 libstdc++ tests: FAIL: 17_intro/headers/c++200x/stdc+ +.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess errors) FAIL: 30_threads/async/async.cc execution test fail/pass at random on a fast machine. Is this expected? -- H.J.
Re: 3 libstdc++ tests fail at random
On 12/07/2013 04:48 PM, H.J. Lu wrote: Hi, I have been seeing 3 libstdc++ tests: FAIL: 17_intro/headers/c++200x/stdc+ +.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess errors) FAIL: 30_threads/async/async.cc execution test fail/pass at random on a fast machine. Is this expected? Yes, do you like it? ;) Seriously, it's the first time I see this, maybe because my machines aren't so fast, but I don't see what the performance of the machine may have to do with the first two. Or are you only seeing it with highly parallel make checks? Thus does it have something to do with Jakub's recent tweaks? In any case, please provide more information and send all the messages having to do with the library to the library mailing list too. Jon may want to investigate the 30_threads/async/async.cc fail: I understand it happens only with -m32, right? Thanks, Paolo.
Re: 3 libstdc++ tests fail at random
On Sat, Dec 07, 2013 at 05:43:12PM +0100, Paolo Carlini wrote:
On 12/07/2013 04:48 PM, H.J. Lu wrote:
I have been seeing 3 libstdc++ tests:
FAIL: 17_intro/headers/c++200x/stdc+
+.cc (test for excess errors)
FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for
excess errors)
These two failed for me just once so far, in i686-linux build,
the errors were the same for both, perhaps related to PR58627?
Just a random guess, but until that PR is fixed, if the compiler is using
ggc_freed memory, really anything can happen.
tree check: expected tree_list, have error_mark in dump_template_bindings, at
cp/error.c:274
_M_head(const _Head_base __b) noexcept { return __b._M_head_impl; }
^
0x8bcc083 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9190
0x831d349 tree_check
../../gcc/tree.h:2702
0x831d349 dump_template_bindings
../../gcc/cp/error.c:274
0x831d349 dump_substitution
../../gcc/cp/error.c:1386
0x831e3fd dump_function_decl
../../gcc/cp/error.c:1515
0x8320c19 decl_to_string
../../gcc/cp/error.c:2829
0x8320c19 cp_printer
../../gcc/cp/error.c:3430
0x92c7c89 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:616
0x92c840d pp_format_verbatim(pretty_printer*, text_info*)
../../gcc/pretty-print.c:675
0x92c8471 pp_verbatim(pretty_printer*, char const*, ...)
../../gcc/pretty-print.c:871
0x8311530 print_instantiation_full_context
../../gcc/cp/error.c:3199
0x8311530 maybe_print_instantiation_context
../../gcc/cp/error.c:3343
0x831f4eb cp_diagnostic_starter
../../gcc/cp/error.c:3027
0x92c5c0a diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
Re: 3 libstdc++ tests fail at random
On Sat, Dec 7, 2013 at 9:09 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Dec 07, 2013 at 05:43:12PM +0100, Paolo Carlini wrote:
On 12/07/2013 04:48 PM, H.J. Lu wrote:
I have been seeing 3 libstdc++ tests:
FAIL: 17_intro/headers/c++200x/stdc+
+.cc (test for excess errors)
FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for
excess errors)
These two failed for me just once so far, in i686-linux build,
I saw them quite often on both x86-64 and i686.
the errors were the same for both, perhaps related to PR58627?
Just a random guess, but until that PR is fixed, if the compiler is using
ggc_freed memory, really anything can happen.
tree check: expected tree_list, have error_mark in dump_template_bindings, at
cp/error.c:274
_M_head(const _Head_base __b) noexcept { return __b._M_head_impl; }
^
0x8bcc083 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9190
0x831d349 tree_check
../../gcc/tree.h:2702
0x831d349 dump_template_bindings
../../gcc/cp/error.c:274
0x831d349 dump_substitution
../../gcc/cp/error.c:1386
0x831e3fd dump_function_decl
../../gcc/cp/error.c:1515
0x8320c19 decl_to_string
../../gcc/cp/error.c:2829
0x8320c19 cp_printer
../../gcc/cp/error.c:3430
0x92c7c89 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:616
0x92c840d pp_format_verbatim(pretty_printer*, text_info*)
../../gcc/pretty-print.c:675
0x92c8471 pp_verbatim(pretty_printer*, char const*, ...)
../../gcc/pretty-print.c:871
0x8311530 print_instantiation_full_context
../../gcc/cp/error.c:3199
0x8311530 maybe_print_instantiation_context
../../gcc/cp/error.c:3343
0x831f4eb cp_diagnostic_starter
../../gcc/cp/error.c:3027
0x92c5c0a diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:791
0x92c63c9 internal_error(char const*, ...)
../../gcc/diagnostic.c:1129
0x8bcc083 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9190
0x840928a tree_check
../../gcc/tree.h:2702
0x840928a decl_is_template_id
../../gcc/cp/mangle.c:291
0x840dba6 write_nested_name
../../gcc/cp/mangle.c:949
0x840e320 write_name
../../gcc/cp/mangle.c:866
I saw
spawn -ignore SIGHUP
/export/gnu/import/git/gcc-test-intel64/bld/./gcc/xg++ -shared-libgcc
-B/export/gnu/import/git/gcc-test-intel64/bld/./gcc -nostdinc++
-L/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/4.9.0/x86_64-unknown-linux-gnu/bin/
-B/usr/4.9.0/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/4.9.0/x86_64-unknown-linux-gnu/include -isystem
/usr/4.9.0/x86_64-unknown-linux-gnu/sys-include
-B/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fdiagnostics-color=never -D_GLIBCXX_ASSERT -fmessage-length=0
-ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2
-D_GNU_SOURCE -DLOCALEDIR=. -nostdinc++
-I/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/export/gnu/import/git/gcc-test-intel64/src-trunk/libstdc++-v3/libsupc++
-I/export/gnu/import/git/gcc-test-intel64/src-trunk/libstdc++-v3/include/backward
-I/export/gnu/import/git/gcc-test-intel64/src-trunk/libstdc++-v3/testsuite/util
/export/gnu/import/git/gcc-test-intel64/src-trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++.cc
-std=gnu++0x -S -o stdc++.s^M
In file included from /usr/include/features.h:375:0,^M
from /usr/include/assert.h:36,^M
from
/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/libstdc++-v3/include/cassert:43,^M
from
/export/gnu/import/git/gcc-test-intel64/src-trunk/libstdc++-v3/include/precompiled/stdc++.h:33:^M
/usr/include/complex.h:112:1: internal compiler error: Segmentation fault^M
__END_DECLS^M
^^M
0xb47fcf crash_signal^M
../../src-trunk/gcc/toplev.c:336^M
0xd5bb3b decl_assembler_name(tree_node*)^M
../../src-trunk/gcc/tree.c:599^M
0x8ae23f dwarf2out_finish^M
../../src-trunk/gcc/dwarf2out.c:24005^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See http://gcc.gnu.org/bugs.html for instructions.^M
and
spawn -ignore SIGHUP
/export/gnu/import/git/gcc-test-intel64/bld/./gcc/xg++ -shared-libgcc
-B/export/gnu/import/git/gcc-test-intel64/bld/./gcc -nostdinc++
Re: 3 libstdc++ tests fail at random
On Sat, Dec 7, 2013 at 9:26 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, Dec 7, 2013 at 9:09 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Dec 07, 2013 at 05:43:12PM +0100, Paolo Carlini wrote:
On 12/07/2013 04:48 PM, H.J. Lu wrote:
I have been seeing 3 libstdc++ tests:
FAIL: 17_intro/headers/c++200x/stdc+
+.cc (test for excess errors)
FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for
excess errors)
These two failed for me just once so far, in i686-linux build,
I saw them quite often on both x86-64 and i686.
the errors were the same for both, perhaps related to PR58627?
Just a random guess, but until that PR is fixed, if the compiler is using
ggc_freed memory, really anything can happen.
tree check: expected tree_list, have error_mark in dump_template_bindings,
at cp/error.c:274
_M_head(const _Head_base __b) noexcept { return __b._M_head_impl; }
^
0x8bcc083 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9190
0x831d349 tree_check
../../gcc/tree.h:2702
0x831d349 dump_template_bindings
../../gcc/cp/error.c:274
0x831d349 dump_substitution
../../gcc/cp/error.c:1386
0x831e3fd dump_function_decl
../../gcc/cp/error.c:1515
0x8320c19 decl_to_string
../../gcc/cp/error.c:2829
0x8320c19 cp_printer
../../gcc/cp/error.c:3430
0x92c7c89 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:616
0x92c840d pp_format_verbatim(pretty_printer*, text_info*)
../../gcc/pretty-print.c:675
0x92c8471 pp_verbatim(pretty_printer*, char const*, ...)
../../gcc/pretty-print.c:871
0x8311530 print_instantiation_full_context
../../gcc/cp/error.c:3199
0x8311530 maybe_print_instantiation_context
../../gcc/cp/error.c:3343
0x831f4eb cp_diagnostic_starter
../../gcc/cp/error.c:3027
0x92c5c0a diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:791
0x92c63c9 internal_error(char const*, ...)
../../gcc/diagnostic.c:1129
0x8bcc083 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9190
0x840928a tree_check
../../gcc/tree.h:2702
0x840928a decl_is_template_id
../../gcc/cp/mangle.c:291
0x840dba6 write_nested_name
../../gcc/cp/mangle.c:949
0x840e320 write_name
../../gcc/cp/mangle.c:866
I saw
spawn -ignore SIGHUP
/export/gnu/import/git/gcc-test-intel64/bld/./gcc/xg++ -shared-libgcc
-B/export/gnu/import/git/gcc-test-intel64/bld/./gcc -nostdinc++
-L/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/4.9.0/x86_64-unknown-linux-gnu/bin/
-B/usr/4.9.0/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/4.9.0/x86_64-unknown-linux-gnu/include -isystem
/usr/4.9.0/x86_64-unknown-linux-gnu/sys-include
-B/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fdiagnostics-color=never -D_GLIBCXX_ASSERT -fmessage-length=0
-ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2
-D_GNU_SOURCE -DLOCALEDIR=. -nostdinc++
-I/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/export/gnu/import/git/gcc-test-intel64/src-trunk/libstdc++-v3/libsupc++
-I/export/gnu/import/git/gcc-test-intel64/src-trunk/libstdc++-v3/include/backward
-I/export/gnu/import/git/gcc-test-intel64/src-trunk/libstdc++-v3/testsuite/util
/export/gnu/import/git/gcc-test-intel64/src-trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++.cc
-std=gnu++0x -S -o stdc++.s^M
In file included from /usr/include/features.h:375:0,^M
from /usr/include/assert.h:36,^M
from
/export/gnu/import/git/gcc-test-intel64/bld/x86_64-unknown-linux-gnu/libstdc++-v3/include/cassert:43,^M
from
/export/gnu/import/git/gcc-test-intel64/src-trunk/libstdc++-v3/include/precompiled/stdc++.h:33:^M
/usr/include/complex.h:112:1: internal compiler error: Segmentation fault^M
__END_DECLS^M
^^M
0xb47fcf crash_signal^M
../../src-trunk/gcc/toplev.c:336^M
0xd5bb3b decl_assembler_name(tree_node*)^M
../../src-trunk/gcc/tree.c:599^M
0x8ae23f dwarf2out_finish^M
../../src-trunk/gcc/dwarf2out.c:24005^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See http://gcc.gnu.org/bugs.html for instructions.^M
and
spawn -ignore SIGHUP
/export/gnu/import/git/gcc-test-intel64/bld/./gcc/xg++ -shared-libgcc
bisonc++ ??
Googling: gcc undefined reference to `lexer_line' yields: http://stackoverflow.com/questions/4262531/trouble-building-gcc-4-6 Please check for it in configure and mention it in the dependency message. :) Thank you!
Re: bisonc++ ??
On 12/07/13 12:59, Bruce Korb wrote: Googling: gcc undefined reference to `lexer_line' yields: http://stackoverflow.com/questions/4262531/trouble-building-gcc-4-6 Please check for it in configure and mention it in the dependency message. :) Thank you! Oops -- I was too optimistic: build/gengtype.o build/errors.o build/gengtype-lex.o build/gengtype-parse.o build/gengtype-state.o build/version.o ../../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a build/gengtype.o: In function `create_optional_field_': /u/gnu/proj/gcc-svn-bld/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1002: undefined reference to `lexer_line' What is this message really telling me?
gcc-4.7-20131207 is now available
Snapshot gcc-4.7-20131207 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20131207/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 205785 You'll find: gcc-4.7-20131207.tar.bz2 Complete GCC MD5=99482872d7d7f76b387543b5746d0ee7 SHA1=c260cb808712255952357767671907cf3ea3a246 Diffs from 4.7-20131130 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Remove spam in GCC mailing list
The Got It button has been removed on Warning: Enabling the Script panel causes a Firefox slow-down due to a platform bug. This will be fixed with the next major Firefox and Firebug versions. It appears when Firebug has a warning. The Launchpad account seotaewong40 has been suspended with request from W. Grant for renaming a page. Firebug has a partial Turkish translation; for example: Warning: Enabling the Script panel causes a Firefox slow-down due to a platform bug. This will be fixed with the next major Firefox and Firebug versions. in Console, Errors, Warnings and Debug Info are not translated. Spammers post heaps of links to commercial websites that have nothing at all to do with GCC.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #25 from Kostya Serebryany kcc at gcc dot gnu.org --- https://bugzilla.kernel.org/show_bug.cgi?id=66721 Good! Looking forward for a fix and hoping to have it in the next Ubuntu LTS. Any chance? Is there anything else we could do with this tsan issue? (given that this is our FAQ entry #1)
[Bug target/52898] SH Target: Inefficient DImode comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52898
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
Kaz, I'd like to deprecate the mcbranchdi and mcmpeqdi options in 4.9 and make
the current default values fixed as follows:
mcbranchdi is usually enabled (it gets disabled in some SH5 case in
sh_option_override).
mcmpeqdi is always disabled.
As a side effect, it would also fix PR 51697 (mcbranchdi will not be disabled
for -Os).
Are you OK with the following patch for 4.9?
Index: gcc/common/config/sh/sh-common.c
===
--- gcc/common/config/sh/sh-common.c(revision 205756)
+++ gcc/common/config/sh/sh-common.c(working copy)
@@ -34,7 +34,6 @@
{ OPT_LEVELS_1_PLUS_SPEED_ONLY, OPT_mdiv_, inv:minlat, 1 },
{ OPT_LEVELS_SIZE, OPT_mdiv_, SH_DIV_STR_FOR_SIZE, 1 },
{ OPT_LEVELS_0_ONLY, OPT_mdiv_, , 1 },
-{ OPT_LEVELS_SIZE, OPT_mcbranchdi, NULL, 0 },
/* We can't meaningfully test TARGET_SHMEDIA here, because -m
options haven't been parsed yet, hence we'd read only the
default. sh_target_reg_class will return NO_REGS if this is
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi(revision 205756)
+++ gcc/doc/invoke.texi(working copy)
@@ -959,7 +959,7 @@
-mindexed-addressing -mgettrcost=@var{number} -mpt-fixed @gol
-maccumulate-outgoing-args -minvalid-symbols @gol
-matomic-model=@var{atomic-model} @gol
--mbranch-cost=@var{num} -mzdcbranch -mno-zdcbranch -mcbranchdi -mcmpeqdi @gol
+-mbranch-cost=@var{num} -mzdcbranch -mno-zdcbranch @gol
-mfused-madd -mno-fused-madd -mfsca -mno-fsca -mfsrra -mno-fsrra @gol
-mpretend-cmove -mtas}
@@ -20252,15 +20252,6 @@
enabled by default when generating code for SH4 and SH4A. It can be
explicitly
disabled by specifying @option{-mno-zdcbranch}.
-@item -mcbranchdi
-@opindex mcbranchdi
-Enable the @code{cbranchdi4} instruction pattern.
-
-@item -mcmpeqdi
-@opindex mcmpeqdi
-Emit the @code{cmpeqdi_t} instruction pattern even when @option{-mcbranchdi}
-is in effect.
-
@item -mfused-madd
@itemx -mno-fused-madd
@opindex mfused-madd
Index: gcc/config/sh/sh.opt
===
--- gcc/config/sh/sh.opt(revision 205756)
+++ gcc/config/sh/sh.opt(working copy)
@@ -233,11 +233,11 @@
Assume that zero displacement conditional branches are fast
mcbranchdi
-Target Var(TARGET_CBRANCHDI4)
+Target Undocumented Var(TARGET_CBRANCHDI4) Warn(%qs is deprecated and has no
effect)
Enable cbranchdi4 pattern
mcmpeqdi
-Target Var(TARGET_CMPEQDI_T)
+Target Undocumented Var(TARGET_CMPEQDI_T) Warn(%qs is deprecated and has no
effect)
Emit cmpeqdi_t pattern even when -mcbranchdi is in effect.
mcut2-workaround
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 205756)
+++ gcc/config/sh/sh.c(working copy)
@@ -771,6 +771,11 @@
SUBTARGET_OVERRIDE_OPTIONS;
if (optimize 1 !optimize_size)
target_flags |= MASK_SAVE_ALL_TARGET_REGS;
+
+ /* Set default values of TARGET_CBRANCHDI4 and TARGET_CMPEQDI_T. */
+ TARGET_CBRANCHDI4 = 1;
+ TARGET_CMPEQDI_T = 0;
+
sh_cpu = PROCESSOR_SH1;
assembler_dialect = 0;
if (TARGET_SH2)
[Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de --- hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- slpeel_tree_peel_loop_to_edge has comments: The first guard is: if (FIRST_NITERS == 0) then skip the first loop, and go directly to the second loop. This is removed by r205730. It's implemented in terms of scalar loop iterations (latch execution count).
[Bug target/52898] SH Target: Inefficient DImode comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52898 --- Comment #8 from Kazumoto Kojima kkojima at gcc dot gnu.org --- I'm OK with it.
[Bug target/18649] terminate called after throwing - IOT/Abort trap (core dumped)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18649 --- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org --- For mingw-code this bug is fixed. It was caused by a bug in SjLj catch-reason. Issue is fixed for 32-bit and 64-bit mingw targets for all open branches. As report was for different targets, it would be good if PPC maintainer could verify that this issue is fixed for this target, too.
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-07 CC||janus at gcc dot gnu.org Summary|Class array pointers: |[OOP] Class array pointers: |compile error on valid code |compile error on valid code |(Different ranks in pointer |(Different ranks in pointer |assignment) |assignment) Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. Thanks for reporting! Here is a reduced test case, which is sufficient to trigger the error: implicit none Type TObjectList end Type Class(TObjectList), pointer :: Arr(:) Arr = ArrayItem() contains function ArrayItem() result(P) Class(TObjectList), pointer :: P(:) end function end
[Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- (In reply to rguent...@suse.de from comment #7) hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- slpeel_tree_peel_loop_to_edge has comments: The first guard is: if (FIRST_NITERS == 0) then skip the first loop, and go directly to the second loop. This is removed by r205730. It's implemented in terms of scalar loop iterations (latch execution count). Is that ever possible to have latch execution count 0 and FIRST_NITERS == 0? It happens in x32 253.perlbmk.
[Bug target/19970] Java Disabled for MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19970 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||ktietz at gcc dot gnu.org --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- As libgcj (and java in total) gets less to no maintenance in general and the build-time of libjava is for general purpose very high on Windows, I would like to drop this enhancement PR. In general it is possible to build java + libgcj for mingw targets by manually enable it.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #26 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Kostya Serebryany from comment #25) https://bugzilla.kernel.org/show_bug.cgi?id=66721 Good! Looking forward for a fix and hoping to have it in the next Ubuntu LTS. Any chance? Is there anything else we could do with this tsan issue? (given that this is our FAQ entry #1) TSAN tests shouldn't depend on kernel to load PIE at a suitable address at random since kernel may load PIE at the wrong address. TSAN tests should specify a load address which works with TSAN.
[Bug preprocessor/56686] gcc cannot find include header file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56686
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org ---
That is a MinGW.org issue. For mingw-w64 this issue is fixed. Well, actually
it is under the hood a msvcrt issue about stat-routines. Sadly it can't handle
proper trailing slashes on paths.
To verify the issue simply check following test program:
#include io.h
#include sys/stat.h
#include stdio.h
int main()
{
struct stat fb;
if (stat (./, fb))
printf ('./' stat failed.\n);
return 0;
}
I close this bug as invalid, due it isn't caused, nor to be fixed by gcc.
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 --- Comment #2 from janus at gcc dot gnu.org --- This draft patch fixes the error (but has not been regtested yet): Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 205782) +++ gcc/fortran/resolve.c(working copy) @@ -2616,6 +2616,8 @@ found: expr-ts = sym-ts; expr-value.function.name = sym-name; expr-value.function.esym = sym; + if (sym-ts.type == BT_CLASS CLASS_DATA (sym)-as) +expr-rank = CLASS_DATA (sym)-as-rank; if (sym-as != NULL) expr-rank = sym-as-rank; With the patch the reduced test case in comment 1 compiles cleanly, but the full code in comment 0 then gives an ICE on a different location: ObjectLists.f90: In function ‘addarray’: ObjectLists.f90:240:0: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6473 allocate(Pt%P(1:SIZE(P)), source= P) ^ 0x636b4b gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) /home/jweil/gcc49/trunk/gcc/fortran/trans-array.c:6473 0x65597e gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*) /home/jweil/gcc49/trunk/gcc/fortran/trans-expr.c:6609 0x676cd1 gfc_trans_allocate(gfc_code*) /home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:5124 0x6269c7 trans_code /home/jweil/gcc49/trunk/gcc/fortran/trans.c:1778 0x66df53 gfc_trans_if_1 /home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:986 0x673d2a gfc_trans_if(gfc_code*) /home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:1017 0x626aa7 trans_code /home/jweil/gcc49/trunk/gcc/fortran/trans.c:1720 0x674088 gfc_trans_block_construct(gfc_code*) /home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:1344 0x626a37 trans_code /home/jweil/gcc49/trunk/gcc/fortran/trans.c:1728 0x66df53 gfc_trans_if_1 /home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:986 0x673d2a gfc_trans_if(gfc_code*) /home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:1017 0x626aa7 trans_code /home/jweil/gcc49/trunk/gcc/fortran/trans.c:1720 0x67585d gfc_trans_integer_select /home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:1992 0x67585d gfc_trans_select(gfc_code*) /home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:2486 0x626a47 trans_code /home/jweil/gcc49/trunk/gcc/fortran/trans.c:1744 0x674088 gfc_trans_block_construct(gfc_code*) /home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:1344 0x626a37 trans_code /home/jweil/gcc49/trunk/gcc/fortran/trans.c:1728 0x646382 gfc_generate_function_code(gfc_namespace*) /home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:5604 0x627ed1 gfc_generate_module_code(gfc_namespace*) /home/jweil/gcc49/trunk/gcc/fortran/trans.c:1956 0x5da09b translate_all_program_units /home/jweil/gcc49/trunk/gcc/fortran/parse.c:4523
[Bug c++/59416] New: A nested template reusing the template arguments of the enclosing type in a template template argument not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59416
Bug ID: 59416
Summary: A nested template reusing the template arguments of
the enclosing type in a template template argument not
working
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test:
templateint,int struct Obj;
templatetypename... Ts struct A {
templatetemplateTs... class struct B { };
};
int main()
{
Aint,int::BObj x{ };
}
edoceo3.cpp:8:20: error: type/value mismatch at argument 1 in template
parameter list for ‘templateclass ... Ts templatetemplatetemplateTs
...anonymous classtemplate-parameter-2-1 templateclass ... Ts
templateTs ...anonymous classtemplate-parameter-2-1 struct ATs::B’
Aint,int::BObj x{ };
^
edoceo3.cpp:8:20: error: expected a template of type ‘templateclass ... Ts
templateTs ...anonymous classtemplate-parameter-2-1’, got ‘templateint
anonymous, int anonymous struct Obj’
edoceo3.cpp:8:23: error: invalid type in declaration before ‘{’ token
Aint,int::BObj x{ };
clang compiles this code. It certainly looks valid to me, since in the
attempted instantiation, A's template arguments are 'int,int', and then
the template argument for A::B should be 'template int, int class',
and Obj is such a template.
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) With the patch the reduced test case in comment 1 compiles cleanly, but the full code in comment 0 then gives an ICE on a different location: ObjectLists.f90: In function ‘addarray’: ObjectLists.f90:240:0: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6473 allocate(Pt%P(1:SIZE(P)), source= P) Here is a reduced test case for the ICE (which seems unrelated to the original error): module ObjectLists implicit none type :: t end type type Object_array_pointer class(t), pointer :: p(:) end type contains subroutine AddArray (P, Pt) class(t) :: P(:) class(Object_array_pointer) :: Pt select type (Pt) class is (Object_array_pointer) allocate(Pt%P(1:SIZE(P)), source=P) end select end subroutine end module
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 --- Comment #4 from janus at gcc dot gnu.org --- Btw, when using the second (commented-out) version of 'AddArray' (which apparently crashes with ifort), the full code in comment 0 compiles cleanly with gfortran trunk plus the patch in comment 2.
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 --- Comment #5 from Antony Lewis antony at cosmologist dot info --- Thanks for the quick fix! The sourced allocate errors crop up in various places in the full code, and already seem to be known in several bug reports, e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 For example in this case you just get a compiler error: module test Type InterpGrid2D REAL, pointer :: z(:,:) = NULL() contains procedure :: Init = InterpGrid2D_Init end Type InterpGrid2D contains subroutine InterpGrid2D_Init(W, z) class(InterpGrid2D):: W REAL, INTENT(IN), pointer :: z(:,:) allocate(W%z, source = z) end subroutine InterpGrid2D_Init end module
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to Antony Lewis from comment #5) The sourced allocate errors crop up in various places in the full code, and already seem to be known in several bug reports, e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 For example in this case you just get a compiler error: Yes, this error is the one described in PR44672, but the issue of comment 3 is somewhat different. Not sure if there is already a PR for it. In fact comment 3 compiles cleanly with 4.7, so the ICE seems to be a regression in 4.8.
[Bug tree-optimization/59417] New: ICE in determine_value_range, at tree-ssa-loop-niter.c:176
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417
Bug ID: 59417
Summary: ICE in determine_value_range, at
tree-ssa-loop-niter.c:176
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Hi !
I'm using GCC 4.9 20131207.
$ cat deter.c
int a, b, d;
short c;
void f(void)
{
if(b)
{
int *e;
if(d)
{
for(; b; a++)
lbl1:
d = 0;
for(; d = 1; d++)
{
int **q = e;
for(**q = 0; **q = 0; **q++)
d = 0;
}
}
}
else
{
int t;
for(c = 0; c 77; c++)
for(c = 0; c 46; c++);
for (; t = 0; t++)
lbl2:
;
goto lbl1;
}
goto lbl2;
}
$ xgcc -w -O2 deter.c
deter.c: In function ‘f’:
deter.c:4:6: internal compiler error: in determine_value_range, at
tree-ssa-loop-niter.c:176
void f(void)
^
0xac1d8e determine_value_range
../../srcdir/gcc/tree-ssa-loop-niter.c:176
0xac27f7 bound_difference
../../srcdir/gcc/tree-ssa-loop-niter.c:486
0xac27f7 number_of_iterations_cond
../../srcdir/gcc/tree-ssa-loop-niter.c:1416
0xac27f7 number_of_iterations_exit(loop*, edge_def*, tree_niter_desc*, bool,
bool)
../../srcdir/gcc/tree-ssa-loop-niter.c:1972
0xa3e30d number_of_latch_executions
../../srcdir/gcc/tree-scalar-evolution.c:2888
0xac3973 estimate_numbers_of_iterations_loop
../../srcdir/gcc/tree-ssa-loop-niter.c:3411
0xac5997 estimate_numbers_of_iterations_loop
../../srcdir/gcc/tree-ssa-loop-niter.c:3509
0xac5997 max_loop_iterations(loop*, double_int*)
../../srcdir/gcc/tree-ssa-loop-niter.c:3507
0xac5a2a finite_loop_p(loop*)
../../srcdir/gcc/tree-ssa-loop-niter.c:2125
0xa7801f find_obviously_necessary_stmts
../../srcdir/gcc/tree-ssa-dce.c:422
0xa7a5a5 perform_tree_ssa_dce
../../srcdir/gcc/tree-ssa-dce.c:1441
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 tree-optimization/59417] ICE in determine_value_range, at tree-ssa-loop-niter.c:176
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417 Markus Trippelsdorf octoploid at yandex dot com changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||octoploid at yandex dot com --- Comment #1 from Markus Trippelsdorf octoploid at yandex dot com --- Git blame points to r204516.
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- The issue of comment 3 appeared between revisions 187190 (2012-05-05) and 187198 (actually 187193 and I'ld bet for 187192).
[Bug fortran/44672] [F08] ALLOCATE with SOURCE and no array-spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Summary|[F2008] ALLOCATE with |[F08] ALLOCATE with SOURCE |SOURCE and no array-spec|and no array-spec --- Comment #5 from janus at gcc dot gnu.org --- There is a partial patch in PR 44529 comment 1.
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 --- Comment #8 from janus at gcc dot gnu.org --- The patch in comment 2 regtests cleanly.
[Bug middle-end/59011] [4.7 Regression] ICE in make_decl_rtl, at varasm.c:1147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011 --- Comment #7 from Mikael Pettersson mikpelinux at gmail dot com --- It appears the test case wasn't added to 4.8 branch.
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 janus at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #9 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #7) The issue of comment 3 appeared between revisions 187190 (2012-05-05) and 187198 (actually 187193 and I'ld bet for 187192). r187192 was Paul's fix for PR 41600.
[Bug middle-end/59011] [4.7 Regression] ICE in make_decl_rtl, at varasm.c:1147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Sat Dec 7 15:43:05 2013 New Revision: 205783 URL: http://gcc.gnu.org/viewcvs?rev=205783root=gccview=rev Log: PR middle-end/59011 * gimplify.c (nonlocal_vla_vars): New variable. (gimplify_var_or_parm_decl): Put VAR_DECLs for VLAs into nonlocal_vla_vars chain. (gimplify_body): Call declare_vars on nonlocal_vla_vars chain if outer_bind has DECL_INITIAL (current_function_decl) block. * gcc.dg/pr59011.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr59011.c
[Bug target/58864] [4.8/4.9 regression] ICE in connect_traces, at dwarf2cfi.c:NNNN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Sat Dec 7 15:43:48 2013 New Revision: 205784 URL: http://gcc.gnu.org/viewcvs?rev=205784root=gccview=rev Log: PR target/58864 * optabs.c (emit_conditional_move): Save and restore pending_stack_adjust and stack_pointer_delta if cmove can't be used. * g++.dg/opt/pr58864.C: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/opt/pr58864.C
[Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409 --- Comment #9 from rguenther at suse dot de rguenther at suse dot de --- hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- (In reply to rguent...@suse.de from comment #7) hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- slpeel_tree_peel_loop_to_edge has comments: The first guard is: if (FIRST_NITERS == 0) then skip the first loop, and go directly to the second loop. This is removed by r205730. It's implemented in terms of scalar loop iterations (latch execution count). Is that ever possible to have latch execution count 0 and FIRST_NITERS == 0? It happens in x32 253.perlbmk. That should be impossible. Richard.
[Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to rguent...@suse.de from comment #9)
Is that ever possible to have latch execution count 0
and FIRST_NITERS == 0? It happens in x32 253.perlbmk.
That should be impossible.
That is what I thought too. But this patch
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index 380fd22..68c24a0 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -1273,6 +1273,17 @@ slpeel_tree_peel_loop_to_edge (struct loop *loop,
pre_condition =
fold_build2 (LT_EXPR, boolean_type_node, scalar_loop_iters,
build_int_cst (TREE_TYPE (scalar_loop_iters), limit));
+ tree first_condition =
+fold_build2 (LE_EXPR, boolean_type_node, *first_niters,
+ build_int_cst (TREE_TYPE (*first_niters), 0));
+ first_condition =
+fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
+ first_condition,
+ fold_build2 (LT_EXPR, boolean_type_node, scalar_loop_iters,
+ *first_niters));
+ pre_condition =
+fold_build2 (TRUTH_OR_EXPR, boolean_type_node,
+ pre_condition, first_condition);
if (cond_expr)
{
pre_condition =
fixes the problem. But I can't explain why/how it can make
a difference at all.
[Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com --- latch execution count can be an expression like if (b) in gcc.dg/torture/pr59058.c. Will such an expression be possible negative at run-time?
[Bug debug/59418] New: ICE in maybe_record_trace_start, at dwarf2cfi.c:2221
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59418
Bug ID: 59418
Summary: ICE in maybe_record_trace_start, at dwarf2cfi.c:2221
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: rmansfield at qnx dot com
Target: arm-unknown-linux-gnueabi
$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnueabi
Configured with: ../configure --target=arm-unknown-linux-gnueabi
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi
--with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root
--disable-multilib
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared
--disable-libmudflap --disable-libssp --enable-checking
Thread model: posix
gcc version 4.9.0 20131207 (experimental) [trunk revision 205782] (GCC)
$ cat ~/ice1.i
extern int printf (const char *__format, ...);
void
foo (const char *pptr, int caplen)
{
int type;
const char *tptr;
if (caplen 4)
{
(void) printf (foo);
return;
}
while (tptr pptr)
{
switch (type)
{
case 0x01:
printf ();
case 0x0b:
printf ();
case 0x0e:
printf ();
case 0x10:
printf (%1.2fW, bar (tptr, caplen) / 1000.0);
}
}
printf (foo);
}
$ ./xgcc -B. ~/ice1.i -Os -g -march=armv7-a -mfloat-abi=softfp
/home/ryan/ice1.i: In function 'foo':
/home/ryan/ice1.i:28:1: internal compiler error: in maybe_record_trace_start,
at dwarf2cfi.c:2221
}
^
0x68035f maybe_record_trace_start
../../gcc/dwarf2cfi.c:2221
0x680619 create_trace_edges
../../gcc/dwarf2cfi.c:2313
0x6806fc scan_trace
../../gcc/dwarf2cfi.c:2526
0x68129e create_cfi_notes
../../gcc/dwarf2cfi.c:2552
0x68129e execute_dwarf2_frame
../../gcc/dwarf2cfi.c:2907
0x68129e execute
../../gcc/dwarf2cfi.c:3403
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 middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #12 from H.J. Lu hjl.tools at gmail dot com ---
This function:
SV *
sv_mortalcopy(SV *oldstr)
{
dTHR;
register SV *sv;
new_SV(sv);
SvANY(sv) = 0;
SvREFCNT(sv) = 1;
SvFLAGS(sv) = 0;
sv_setsv(sv,oldstr);
if (++PL_tmps_ix = PL_tmps_max)
sv_mortalgrow();
PL_tmps_stack[PL_tmps_ix] = sv;
SvTEMP_on(sv);
return sv;
}
is compiled into
00494220 Perl_sv_mortalcopy:
494220:41 54push %r12
494222:55 push %rbp
494223:48 89 fe mov%rdi,%rsi
494226:53 push %rbx
494227:83 ec 10 sub$0x10,%esp
49422a:8b 1d c0 c3 27 00mov0x27c3c0(%rip),%ebx#
7105f0 PL_sv_root
494230:85 dbtest %ebx,%ebx
494232:0f 84 e0 00 00 00je 494318 Perl_sv_mortalcopy+0xf8
494238:67 8b 03 mov(%ebx),%eax
49423b:83 05 aa c3 27 00 01 addl $0x1,0x27c3aa(%rip)#
7105ec PL_sv_count
494242:89 05 a8 c3 27 00mov%eax,0x27c3a8(%rip)#
7105f0 PL_sv_root
494248:89 ddmov%ebx,%ebp
49424a:67 c7 03 00 00 00 00 movl $0x0,(%ebx)
494251:67 c7 43 04 01 00 00 00 movl $0x1,0x4(%ebx)
494259:48 89 ef mov%rbp,%rdi
49425c:67 c7 43 08 00 00 00 00 movl $0x0,0x8(%ebx)
494264:e8 f7 bf ff ff callq 490260 Perl_sv_setsv
494269:8b 15 41 b5 27 00mov0x27b541(%rip),%edx#
70f7b0 PL_tmps_ix
49426f:8b 3d 03 bd 27 00mov0x27bd03(%rip),%edi#
70ff78 PL_tmps_max
494275:44 8b 15 3c c0 27 00 mov0x27c03c(%rip),%r10d#
7102b8 PL_tmps_stack
49427c:44 8d 4a 01 lea0x1(%rdx),%r9d
494280:41 39 f9 cmp%edi,%r9d
494283:44 89 0d 26 b5 27 00 mov%r9d,0x27b526(%rip)#
70f7b0 PL_tmps_ix
49428a:7d 1cjge4942a8 Perl_sv_mortalcopy+0x88
49428c:67 43 89 1c 8a mov%ebx,(%r10d,%r9d,4)
494291:67 81 4b 08 00 08 00 00 orl$0x800,0x8(%ebx)
494299:83 c4 10 add$0x10,%esp
49429c:48 89 e8 mov%rbp,%rax
49429f:5b pop%rbx
4942a0:5d pop%rbp
4942a1:41 5cpop%r12
4942a3:c3 retq
4942a4:0f 1f 40 00 nopl 0x0(%rax)
4942a8:be 00 02 00 00 mov$0x200,%esi
4942ad:81 ff 00 02 00 00cmp$0x200,%edi
4942b3:41 b8 80 00 00 00mov$0x80,%r8d
4942b9:89 f1mov%esi,%ecx
4942bb:41 0f 4c c8 cmovl %r8d,%ecx
4942bf:8d 34 0f lea(%rdi,%rcx,1),%esi
4942c2:8b 3d f0 bf 27 00mov0x27bff0(%rip),%edi#
7102b8 PL_tmps_stack
4942c8:89 35 aa bc 27 00mov%esi,0x27bcaa(%rip)#
70ff78 PL_tmps_max
4942ce:c1 e6 02 shl$0x2,%esi
4942d1:85 f6test %esi,%esi
4942d3:74 2bje 494300 Perl_sv_mortalcopy+0xe0
4942d5:85 fftest %edi,%edi
4942d7:74 6fje 494348 Perl_sv_mortalcopy+0x128
4942d9:e8 52 d6 f6 ff callq 401930 realloc@plt
4942de:85 c0test %eax,%eax
4942e0:74 4eje 494330 Perl_sv_mortalcopy+0x110
4942e2:44 8b 0d c7 b4 27 00 mov0x27b4c7(%rip),%r9d#
70f7b0 PL_tmps_ix
4942e9:41 89 c4 mov%eax,%r12d
4942ec:44 89 25 c5 bf 27 00 mov%r12d,0x27bfc5(%rip)#
7102b8 PL_tmps_stack
4942f3:45 89 e2 mov%r12d,%r10d
4942f6:eb 94jmp49428c Perl_sv_mortalcopy+0x6c
4942f8:0f 1f 84 00 00 00 00 00 nopl 0x0(%rax,%rax,1)
494300:45 31 e4 xor%r12d,%r12d
494303:85 fftest %edi,%edi
494305:74 e5je 4942ec Perl_sv_mortalcopy+0xcc
494307:e8 b4 d1 f6 ff callq 4014c0 free@plt
49430c:44 8b 0d 9d b4 27 00 mov0x27b49d(%rip),%r9d#
70f7b0 PL_tmps_ix
494313:eb d7jmp4942ec Perl_sv_mortalcopy+0xcc
494315:0f 1f 00 nopl (%rax)
494318:67 48 89 7c 24 08mov%rdi,0x8(%esp)
49431e:e8 2d de fe ff callq 482150 more_sv.lto_priv.92
494323:67 48 8b 74 24 08mov0x8(%esp),%rsi
494329:89 c3mov%eax,%ebx
49432b:e9 18 ff ff ff jmpq 494248 Perl_sv_mortalcopy+0x28
494330:80 3d cd c2 27 00 00 cmpb $0x0,0x27c2cd(%rip)#
710604 PL_nomemok
[Bug fortran/59411] Problem with TYPE(C_PTR) constant initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org --- (In reply to mrestelli from comment #0) type(c_ptr), parameter :: p2 = pp 1 Error: non-constant initialization expression at (1) However, as far as I can tell, the code is correct (ifort accepts it). well, just because ifort accepts it doesn't mean that it's valid. In fact the corresponing case with actual Fortran pointers (i.e. pointer initialization) is only allowed since F08, cf. PR45290. One should check the Fortran standard for restrictions in the case of C_PTRs (which, strictly speaking, are no actual pointers in the Fortran sense).
[Bug fortran/59411] Problem with TYPE(C_PTR) constant initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to janus from comment #1) One should check the Fortran standard for restrictions in the case of C_PTRs (which, strictly speaking, are no actual pointers in the Fortran sense). Since C_PTR is a derived type in the Fortran sense, I don't see why any restrictions on pointer init should apply. Unless there are any special restrictions for C_PTR, the code should be valid, just as the corresponding code with any other derived type: module m implicit none type :: t end type type(t), parameter :: pp = t() type(t), parameter :: p2 = pp end module m
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Severity|blocker |normal
[Bug fortran/59411] Problem with TYPE(C_PTR) constant initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411 --- Comment #3 from janus at gcc dot gnu.org --- In F03, I think the relevant quotes are: R506 initialization is = initialization-expr or = null-init 7.1.7 Initialization expression An initialization expression is an expression with limitations that make it suitable for use as a kind type parameter, initializer, or named constant. It is an expression in which each operation is intrinsic, and each primary is (1) A constant or subobject of a constant, ... Since pp is clearly a constant, the code should be valid (probably also in F08).
[Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com --- loop in Perl_pp_aassign is miscompiled: 44098a: e8 91 38 05 00 callq 494220 Perl_sv_mortalcopy 44098f: 67 89 03mov%eax,(%ebx) 440992: 83 c3 04add$0x4,%ebx 440995: 67 44 8b 1b mov(%ebx),%r11d 440999: 45 85 dbtest %r11d,%r11d 44099c: 74 12 je 4409b0 Perl_pp_aassign+0x1c0 44099e: 44 89 dfmov%r11d,%edi $r11d has invalid memory address. 4409a1: c6 05 65 fc 2c 00 00movb $0x0,0x2cfc65(%rip)# 71060d PL_tainted 4409a8: e8 73 38 05 00 callq 494220 Perl_sv_mortalcopy
[Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #14 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to H.J. Lu from comment #13)
loop in Perl_pp_aassign is miscompiled:
44098a: e8 91 38 05 00 callq 494220 Perl_sv_mortalcopy
44098f: 67 89 03mov%eax,(%ebx)
440992: 83 c3 04add$0x4,%ebx
440995: 67 44 8b 1b mov(%ebx),%r11d
440999: 45 85 dbtest %r11d,%r11d
44099c: 74 12 je 4409b0 Perl_pp_aassign+0x1c0
44099e: 44 89 dfmov%r11d,%edi
$r11d has invalid memory address.
4409a1: c6 05 65 fc 2c 00 00movb $0x0,0x2cfc65(%rip)#
71060d PL_tainted
4409a8: e8 73 38 05 00 callq 494220 Perl_sv_mortalcopy
Loop is
for (relem = firstrelem; relem = p; relem++) {
/*SUPPRESS 560*/
if (sv = *relem) {
TAINT_NOT; /* Each item is independent */
*relem = sv_mortalcopy(sv);
}
It was unrolled into
sv = *relem
TAINT_NOT
eax = Perl_sv_mortalcopy (sv)
*relem = eax
eax += 4;
sv = *(SV **) eax
TAINT_NOT
eax = Perl_sv_mortalcopy (sv)
I don't see how eax += 4 can be correct. Return from
Perl_sv_mortalcopy is unrelated to relem.
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 --- Comment #10 from janus at gcc dot gnu.org --- Author: janus Date: Sat Dec 7 19:27:19 2013 New Revision: 205785 URL: http://gcc.gnu.org/viewcvs?rev=205785root=gccview=rev Log: 2013-12-07 Janus Weil ja...@gcc.gnu.org PR fortran/59414 * resolve.c (resolve_specific_f0): Handle CLASS-valued functions. 2013-12-07 Janus Weil ja...@gcc.gnu.org PR fortran/59414 * gfortran.dg/class_result_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_result_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 --- Comment #11 from janus at gcc dot gnu.org --- r205785 fixes the original error (i.e. comment 1). ToDo: The ICE regression of comment 3.
[Bug libfortran/59419] New: [4.9 Regression] Failing OPEN with FILE='xxx' and IOSTAT creates the file 'xxx' after revision 196783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419 Bug ID: 59419 Summary: [4.9 Regression] Failing OPEN with FILE='xxx' and IOSTAT creates the file 'xxx' after revision 196783 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: jb at gcc dot gnu.org, t...@tilo-schwarz.de While the test open(unit=-10, file='xxx') end gives an error at run time without creating the file 'xxx'. The test integer :: i open(unit=-10, file='xxx', iostat=i) print *, i end prints 5002 at run time and create an empty file 'xxx'. This does not happens with r196783, but does with r196819.
[Bug libfortran/59419] [4.9 Regression] Failing OPEN with FILE='xxx' and IOSTAT creates the file 'xxx' after revision 196783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Technically, one has: u = find_unit (opp-common.unit); if (u == NULL) /* Negative unit and no NEWUNIT-created unit found. */ generate_error (opp-common, LIBERROR_BAD_OPTION, Bad unit number in OPEN statement); without err=/stat= it prints an error and doesn't return. But with, it continues after that line. Hence, a return is needed. It probably also affects other code in the I/O library.
[Bug libfortran/59419] [4.9 Regression] Failing OPEN with FILE='xxx' and IOSTAT creates the file 'xxx' after revision 196783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-07 CC||jvdelisle at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Dominique, probably rightly, suspects r196805. (In reply to Tobias Burnus from comment #1) generate_error (opp-common, LIBERROR_BAD_OPTION, Bad unit number in OPEN statement); without err=/stat= it prints an error and doesn't return. But with, it continues after that line. Hence, a return is needed. ... but not a simple return but one which ends with a library_end(). Other code in that file uses: (opp-common.flags IOPARM_LIBRETURN_MASK) == IOPARM_LIBRETURN_OK) as condition. Hence, that would be another possibility.
[Bug c/59420] New: arm: broken code generated (memset from newlib 2.0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420 Bug ID: 59420 Summary: arm: broken code generated (memset from newlib 2.0) Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: holler at ahsoftware dot de Created attachment 31396 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31396action=edit memset.i Using gcc (4.8.2) to compile newlib 2.0 broken code will be generated for memset. Target was an ARM cortex-m3. I believe that happens for 4.7.3 too, but I'm totally sure if I'm not just had another bug with 4.7.3 (would have to verify it). Compiler was cross-gcc build on Gentoo with crossdev. gcc -v: Target: arm-cortexm3-eabi Configured with: /var/tmp/portage/cross-arm-cortexm3-eabi/gcc-4.8.2/work/gcc-4.8.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-cortexm3-eabi/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/arm-cortexm3-eabi/4.8.2/include --datadir=/usr/share/gcc-data/arm-cortexm3-eabi/4.8.2 --mandir=/usr/share/gcc-data/arm-cortexm3-eabi/4.8.2/man --infodir=/usr/share/gcc-data/arm-cortexm3-eabi/4.8.2/info --with-gxx-include-dir=/usr/lib/gcc/arm-cortexm3-eabi/4.8.2/include/g++-v4 --host=x86_64-pc-linux-gnu --target=arm-cortexm3-eabi --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-cloog --disable-lto --disable-nls --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --disable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --with-python-dir=/share/gcc-data/arm-cortexm3-eabi/4.8.2/python --enable-poison-system-directories --enable-checking=release --disable-libgcj --enable-libstdcxx-time --disable-libquadmath --enable-languages=c,c++ --with-sysroot=/usr/arm-cortexm3-eabi --disable-bootstrap --with-newlib --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.2 p1.0, pie-0.5.8' --with-mode=thumb --with-cpu=cortex-m3 --with-float=soft Thread model: single gcc version 4.8.2 (Gentoo 4.8.2 p1.0, pie-0.5.8) The broken code was compiled with: make[5]: Entering directory `/var/tmp/portage/cross-arm-cortexm3-eabi/newlib-2.0.0/work/build/arm-cortexm3-eabi/newlib/libc/string' arm-cortexm3-eabi-gcc -B/var/tmp/portage/cross-arm-cortexm3-eabi/newlib-2.0.0/work/build/arm-cortexm3-eabi/newlib/ -isystem /var/tmp/portage/cross-arm-cortexm3-eabi/newlib-2.0.0/work/build/arm-cortexm3-eabi/newlib/targ-include -isystem /var/tmp/portage/cross-arm-cortexm3-eabi/newlib-2.0.0/work/newlib-2.0.0/newlib/libc/include -B/var/tmp/portage/cross-arm-cortexm3-eabi/newlib-2.0.0/work/build/arm-cortexm3-eabi/libgloss/arm -L/var/tmp/portage/cross-arm-cortexm3-eabi/newlib-2.0.0/work/build/arm-cortexm3-eabi/libgloss/libnosys -L/var/tmp/portage/cross-arm-cortexm3-eabi/newlib-2.0.0/work/newlib-2.0.0/libgloss/arm -DPACKAGE_NAME=\newlib\ -DPACKAGE_TARNAME=\newlib\ -DPACKAGE_VERSION=\2.0.0\ -DPACKAGE_STRING=\newlib\ 2.0.0\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -I. -I/var/tmp/portage/cross-arm-cortexm3-eabi/newlib-2.0.0/work/newlib-2.0.0/newlib/libc/string -D__SINGLE_THREAD__ -DARM_RDI_MONITOR -fno-builtin -g -O2 -O3 -pipe -fomit-frame-pointer -std=gnu99 -save-temps -c -o lib_a-memset.o `test -f 'memset.c' || echo '/var/tmp/portage/cross-arm-cortexm3-eabi/newlib-2.0.0/work/newlib-2.0.0/newlib/libc/string/'`memset.c If more information is necessary or helpful, please just notify me.
[Bug c/59420] arm: broken code generated (memset from newlib 2.0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420 --- Comment #1 from Alexander Holler holler at ahsoftware dot de --- Created attachment 31397 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31397action=edit memset.s
[Bug libstdc++/59421] New: stof(), stod() wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421 Bug ID: 59421 Summary: stof(), stod() wrong result Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: stefan.helm...@t-online.de sometimes: y = stod(str); // with str = 0 cout y endl; prints out: 0.4167 It depends on where the executable is copied to. It does not depend on optimisation level. I use c++11. workaround: y = stod(+str+); Windows 7 64 bit, mingw-builds/x64-4.8.1-posix-seh-rev5
[Bug c/59420] arm: broken code generated (memset from newlib 2.0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420 --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org --- You'll get more attention paid to this if you can describe why you think the code generated is incorrect.
[Bug middle-end/59420] arm: broken code generated (memset from newlib 2.0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Richard Earnshaw from comment #2) You'll get more attention paid to this if you can describe why you think the code generated is incorrect. The issue is there is a loop inside of memset that gets converted to a call to memset; that is if I read the assembly code correctly. if that is the case then this is a bug in the newlib makefiles as they should be using -fno-tree-loop-distribute-patterns or like what glibc does: /* Add the compiler optimization to inhibit loop transformation to library calls. This is used to avoid recursive calls in memset and memmove default implementations. */ #ifdef HAVE_CC_INHIBIT_LOOP_TO_LIBCALL # define inhibit_loop_to_libcall \ __attribute__ ((__optimize__ (-fno-tree-loop-distribute-patterns))) #else # define inhibit_loop_to_libcall #endif So closing as invalid, please report this to newlib. Note the work around is not to use -O3 or use -O3 -fno-tree-loop-distribute-patterns .
[Bug libstdc++/59421] stof(), stod() wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-08 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Do you have a full testcase that is able to compile and work?
[Bug libstdc++/59421] stof(), stod() wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) Do you have a full testcase that is able to compile and work? s/work/run/
[Bug c++/59300] visibility computation misses some attributes in namespaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59300 --- Comment #1 from Rafael Avila de Espindola rafael.espindola at gmail dot com --- clang had an even stranger behavior (http://llvm.org/bugs/show_bug.cgi?id=18174). I fixed that in a way that it now agrees with gcc on the testcase in this bug. It would still be nice to know if the current behavior is intentional or not.
[Bug libfortran/59419] [4.9 Regression] Failing OPEN with FILE='xxx' and IOSTAT creates the file 'xxx' after revision 196783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419 --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- I will take this one if you like.
[Bug middle-end/59420] arm: broken code generated (memset from newlib 2.0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420 --- Comment #4 from Alexander Holler holler at ahsoftware dot de --- Thanks a lot for the very fast solution. I wasn't aware that gcc does such optimizations and maybe posted the bug too fast without really having examined the assembler. Using -fno-tree-loop-distribute-patterns indeed fixes the problem. Again, thanks a lot.
[committed] Avoid -Wformat-security warning in libssp
Hi! libssp apparently doesn't build with -Werror=format-security which is planned to be default for Fedora. While this is a false positive, msg3 is always one of two string literals, I think it doesn't hurt to use %s there. Committed to trunk as obvious. --- libssp/ChangeLog(revision 205753) +++ libssp/ChangeLog(working copy) @@ -1,3 +1,7 @@ +2013-12-07 Jakub Jelinek ja...@redhat.com + + * ssp.c (fail): Avoid -Wformat-security warning. + 2013-09-20 Alan Modra amo...@gmail.com * configure: Regenerate. --- libssp/ssp.c(revision 205753) +++ libssp/ssp.c(working copy) @@ -1,5 +1,5 @@ /* Stack protector support. - Copyright (C) 2005, 2009 Free Software Foundation, Inc. + Copyright (C) 2005-2013 Free Software Foundation, Inc. This file is part of GCC. @@ -136,7 +136,7 @@ fail (const char *msg1, size_t msg1len, #ifdef HAVE_SYSLOG_H /* Only send the error to syslog if there was no tty available. */ else -syslog (LOG_CRIT, msg3); +syslog (LOG_CRIT, %s, msg3); #endif /* HAVE_SYSLOG_H */ /* Try very hard to exit. Note that signals may be blocked preventing Jakub
Re: Cleanup Linux libc selection and Android support
On 6/11/2013, at 1:44 pm, Maxim Kuvyrkov ma...@kugelworks.com wrote: On 19/09/2013, at 8:26 am, Maxim Kuvyrkov ma...@kugelworks.com wrote: Following recent breakage caused by adding nominal Android support to all *linux* targets [*] this patch series cleans up libc selection for Linux targets (-mglibc/-muclibc/-mbionic), splits libc selection logic from Android support, and removes Android handling from targets that don't support it. Ping. Anyone wants to review these cleanup patches to config.gcc, config/t-* and config/*.h files, or should I just start committing them quietly :-P ? This patch series was approved by Jeff Law, and I've committed them after retesting on current mainline. Thank you, -- Maxim Kuvyrkov www.kugelworks.com
Re: wide-int, rtl
Kenneth Zadeck zad...@naturalbridge.com writes: +/* One could argue that GET_MODE_PRECISION (TYPE_MODE (type)) + should always be the same as TYPE_PRECISION (type). + However, it is not. Since we are converting from tree to + rtl, we have to expose this ugly truth here. */ +temp = immed_wide_int_const (wide_int::from + (exp, +GET_MODE_PRECISION (TYPE_MODE (type)), +TYPE_SIGN (type)), + TYPE_MODE (type)); +return temp; + } I don't really see how one could argue that, given that there are much fewer modes than possible type precisions, so please rewrite the comment, e.g.: Given that TYPE_PRECISION (type) is not always equal to GET_MODE_PRECISION (TYPE_MODE (type)), we need to extend from the former to the latter according to the signedness of the type. What about a fast track where the precisions are indeed equal? There is not really a faster track here.you still are starting with a tree and converting to an rtx. All that the default one would do would be to access the types precision and sign and use that. FWIW it would be: temp = immed_wide_int_const (exp, TYPE_MODE (type)); But it's hard to tell whether it would buy much. It didn't show up as a hot spot when I was doing performance measurements before. --- a/gcc/machmode.def +++ b/gcc/machmode.def @@ -229,6 +229,9 @@ UACCUM_MODE (USA, 4, 16, 16); /* 16.16 */ UACCUM_MODE (UDA, 8, 32, 32); /* 32.32 */ UACCUM_MODE (UTA, 16, 64, 64); /* 64.64 */ +/* Should be overridden by EXTRA_MODES_FILE if wrong. */ +#define MAX_BITS_PER_UNIT 8 + What is it for? It's not documented at all. This requires some discussion as to the direction we want to go. This is put in so that in gen_modes we can compute MAX_BITSIZE_MODE_ANY_INT and MAX_BITSIZE_MODE_ANY_MODE.The problem is that during genmodes we do have access to BITS_PER_UNIT.These two computed symbols are then used as compile time constants in other parts of the compiler to allocate data structures that are guaranteed to be large enough. Richard Sandiford put this in so we would preserve the ability to build a multi-targetted compiler where the targets had different values for BITS_PER_UNIT. So one possibility is that we add some documentation to this effect. Sorry, I forgot yesterday an important detail behind why this seemed like a good thing. I think there was a strong feeling (from me and others) that wide-int.h shouldn't depend on tm.h. If we make wide-int.h depend on tm.h then basically all the compiler does. So as it stands we can't use BITS_PER_UNIT directly. Having a MAX_BITS_PER_UNIT for all compiled-in targets (which obviously as things stand is exactly one) seemed like a reasonable abstraction. Alternatively we could say that BITS_PER_UNIT is really part of the definition of QImode and move it to the modes.def file. Thanks, Richard
Re: [PATCH] Add -mtune=ia support
On Fri, 6 Dec 2013, H.J. Lu wrote: http://en.wikipedia.org/wiki/IA IA-32, Intel Architecture, 32-bit IA-64, Intel Architecture, 64-bit And Intel 64 is an implementation of and extension to the 64-bit extension of IA-32 created by AMD, totally unrelated to IA-64. Marketing. :-) Gerald
Re: [REPOST] Invalid Code when reading from unaligned zero-sized array
It's not fully fixing the issue as _all_ aggregates that may be
accessed beyond their declarations size are broken.
Sure, but we don't need to support such nonsense in the general case. And not
every language allows it, for example in Ada you cannot do that of course.
I'd say we should simply stop giving aggregates a mode besides BLKmode.
What can possibly break with that ...
Nothing, but this will unnecessarily pessimize well-behaved languages, e.g. in
Ada we overalign structures in some cases to give them integral modes.
struct { char c[4]; }
has SImode, we accept all trailing arrays as possibly extending beyond the
struct declaration.
Alternatively all structs with aggregate members should not have a
mode != BLKmode.
This could work as well, although I'd restrict this to arrays, recursively.
--
Eric Botcazou
Re: [wide-int] small cleanup in wide-int.*
Kenneth Zadeck zad...@naturalbridge.com writes: #define WIDE_INT_MAX_ELTS \ - ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \ - / HOST_BITS_PER_WIDE_INT) + (((MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \ +/ HOST_BITS_PER_WIDE_INT) + 1) I think this should be: (MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_WIDE_INT + 1) We only need an extra HWI if MAX_BITSIZE_MODE_ANY_INT is an exact multiple of HOST_BITS_PER_WIDE_INT. we will do this later when some other issues that Eric B raised are settled. I think you're talking about defining MAX_BITSIZE_MODE_ANY_INT as MAX_SIZE_MODE_ANY_INT * BITS_PER_UNIT, but that's orthogonal to the change above. IMO it doesn't make sense to both round up the division and also add 1 to the result. So I think we should make this change regardless of whatever follows. Looks good to me otherwise, thanks. Richard so this one works the way you want.While it is true the the problems are disjoint, the solution will likely evolving change the same lines of source in two different ways. Well, if we're changing the definition of WIDE_INT_MAX_ELTS now (and we are) I think we should change it to something that makes sense. All we want is 1 extra bit. We don't need to round up the size and then add a whole HWI on top. Doing that will potentially pessimise targets that don't need anything beyond SImode. It's not like I can approve the patch anyway though, so I'll leave it there. Thanks, Richard
Re: [REPOST] Invalid Code when reading from unaligned zero-sized array
I'd certainly be concerned. Ports have (for better or worse) keyed on BLKmode rather than looking at the underlying types. So if something which was previously SImode or DImode is now BLKmode, there's a nonzero chance we're going to change how it gets passed. Well, we have been saying that calling conventions need to be keyed on types rather than modes for more than a decade... I recall auditing and fixing the SPARC back-end circa 2003, so how long are we going to use this argument? That being said, the concern is certainly valid so we may want to go for a kludge instead of the fix. The point is that the kludge should do exactly what the fix would have done in the RTL expander and nothing more; it's out of question to pessimize all the other languages and all the other cases in the C family of languages for highly artificial testcases using non-portable code. -- Eric Botcazou
Re: [REPOST] Invalid Code when reading from unaligned zero-sized array
That being said, the concern is certainly valid so we may want to go for a kludge instead of the fix. The point is that the kludge should do exactly what the fix would have done in the RTL expander and nothing more; it's out of question to pessimize all the other languages and all the other cases in the C family of languages for highly artificial testcases using non-portable code. What about: 1. a new boolean language hook support_trailing_arrays, 2. a new flag on RECORD_OR_UNION_TYPE_P types, 3. modifying stor-layout.c so that it sets the new flag on the appropriate types when support_trailing_arrays is true, 4. modifying expr.c along the lines of Bernd's latest idea to avoid returning anything but a MEM for objects with a type on which the flag is set? -- Eric Botcazou
Re: [patch] microblaze-rtems Add TARGET_BIG_ENDIAN_DEFAULT
On 12/06/13 19:13, Ralf Corsepius wrote: Hi, I intend to the patch below to gcc-trunk and 4.8-branch: It's a partial sync of the microblaze-rtems* section in gcc/config.gcc with microblaze*-*-elf's: Add TARGET_BIG_ENDIAN_DEFAULT-switch for microblaze*-*-rtems*. Ralf OK. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
[PATCH] -fuse-caller-save - Implement TARGET_FN_OTHER_HARD_REG_USAGE hook for MIPS
Richard,
This patch implements the target hook TARGET_FN_OTHER_HARD_REG_USAGE (posted
here: http://gcc.gnu.org/ml/gcc-patches/2013-03/msg01318.html) for MIPS, to
address the issue that $6 is sometimes used in split calls.
Build and reg-tested on MIPS.
OK for stage1?
Thanks,
- Tom
2013-11-12 Chung-Lin Tang clt...@codesourcery.com
Tom de Vries t...@codesourcery.com
* config/mips/mips.c (POST_CALL_TMP_REG): Define.
(mips_split_call): Use POST_CALL_TMP_REG.
(mips_fn_other_hard_reg_usage): New function.
(TARGET_FN_OTHER_HARD_REG_USAGE): Define targhook using new function.
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 36ba6df..3f60f5b 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -175,6 +175,11 @@ along with GCC; see the file COPYING3. If not see
/* Return the usual opcode for a nop. */
#define MIPS_NOP 0
+/* Temporary register that is used after a call, and suitable for both
+ MIPS16 and non-MIPS16 code. $4 and $5 are used for returning complex double
+ values in soft-float code, so $6 is the first suitable candidate. */
+#define POST_CALL_TMP_REG (GP_ARG_FIRST + 2)
+
/* Classifies an address.
ADDRESS_REG
@@ -6990,10 +6995,8 @@ mips_split_call (rtx insn, rtx call_pattern)
{
emit_call_insn (call_pattern);
if (!find_reg_note (insn, REG_NORETURN, 0))
-/* Pick a temporary register that is suitable for both MIPS16 and
- non-MIPS16 code. $4 and $5 are used for returning complex double
- values in soft-float code, so $6 is the first suitable candidate. */
-mips_restore_gp_from_cprestore_slot (gen_rtx_REG (Pmode, GP_ARG_FIRST + 2));
+mips_restore_gp_from_cprestore_slot (gen_rtx_REG (Pmode,
+ POST_CALL_TMP_REG));
}
/* Return true if a call to DECL may need to use JALX. */
@@ -18699,6 +18702,32 @@ mips_case_values_threshold (void)
else
return default_case_values_threshold ();
}
+
+/* Implement TARGET_FN_OTHER_HARD_REG_USAGE. */
+
+static void
+mips_fn_other_hard_reg_usage (struct hard_reg_set_container *fn_used_regs)
+{
+ /* POST_CALL_TMP_REG is used in splitting calls after register allocation.
+ With -fno-use-caller-save, the register is available because register
+ allocation ensures that members of call_used_regs are not live across
+ calls.
+ With -fuse-caller-save that's not the case, so we're missing a clobber on
+ the unsplit call insn to tell register allocation that the register is used
+ by the split call insn(s) after register allocation (we don't need the
+ clobber for a non-returning call, but we don't expect there will be a
+ penalty if we add the clobber for both returning and non-returning calls).
+
+ For the sake of simplicity we don't add the individual clobbers, but we use
+ this hook to mark the reg as clobbered. This is a bit ugly, since this
+ hook is called during the final pass on a function, and we're expressing
+ here that the insn after a call to this function will clobber a register.
+
+ The condition is the pass-independent part of TARGET_SPLIT_CALLS. */
+ if (TARGET_EXPLICIT_RELOCS
+ TARGET_CALL_CLOBBERED_GP)
+SET_HARD_REG_BIT (fn_used_regs-set, POST_CALL_TMP_REG);
+}
/* Initialize the GCC target structure. */
#undef TARGET_ASM_ALIGNED_HI_OP
@@ -18933,6 +18962,9 @@ mips_case_values_threshold (void)
#undef TARGET_CASE_VALUES_THRESHOLD
#define TARGET_CASE_VALUES_THRESHOLD mips_case_values_threshold
+#undef TARGET_FN_OTHER_HARD_REG_USAGE
+#define TARGET_FN_OTHER_HARD_REG_USAGE mips_fn_other_hard_reg_usage
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include gt-mips.h
[Patch, Fortran, OOP] PR 59414: Class array pointers: compile error on valid code (Different ranks in pointer assignment)
Hi all,
here is a small patch to fix a problem with class-array-valued
functions, where the rank was not determined properly. Regtestes on
x86_64-unknown-linux-gnu. Ok for trunk?
[Note: This patch only fixes the rejects-valid problem of comment 0/1,
but not the ICE of comment 2/3, which is a completely separate issue.]
Cheers,
Janus
2013-12-07 Janus Weil ja...@gcc.gnu.org
PR fortran/59414
* resolve.c (resolve_specific_f0): Handle CLASS-valued functions.
2013-12-07 Janus Weil ja...@gcc.gnu.org
PR fortran/59414
* gfortran.dg/class_result_2.f90: New.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 205782)
+++ gcc/fortran/resolve.c (working copy)
@@ -2616,7 +2616,9 @@ found:
expr-ts = sym-ts;
expr-value.function.name = sym-name;
expr-value.function.esym = sym;
- if (sym-as != NULL)
+ if (sym-ts.type == BT_CLASS CLASS_DATA (sym)-as)
+expr-rank = CLASS_DATA (sym)-as-rank;
+ else if (sym-as != NULL)
expr-rank = sym-as-rank;
return MATCH_YES;
! { dg-do compile }
!
! PR 59414: [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
!
! Contributed by Antony Lewis ant...@cosmologist.info
implicit none
Type TObjectList
end Type
Class(TObjectList), pointer :: Arr(:)
Arr = ArrayItem()
contains
function ArrayItem() result(P)
Class(TObjectList), pointer :: P(:)
end function
end
Re: [Patch, Fortran, OOP] PR 59414: Class array pointers: compile error on valid code (Different ranks in pointer assignment)
Janus Weil wrote: here is a small patch to fix a problem with class-array-valued functions, where the rank was not determined properly. Regtestes on x86_64-unknown-linux-gnu. Ok for trunk? [Note: This patch only fixes the rejects-valid problem of comment 0/1, but not the ICE of comment 2/3, which is a completely separate issue.] Looks good to me. Thanks for the patch! Tobias 2013-12-07 Janus Weil ja...@gcc.gnu.org PR fortran/59414 * resolve.c (resolve_specific_f0): Handle CLASS-valued functions. 2013-12-07 Janus Weil ja...@gcc.gnu.org PR fortran/59414 * gfortran.dg/class_result_2.f90: New.
Re: [Patch, Fortran, OOP] PR 59414: Class array pointers: compile error on valid code (Different ranks in pointer assignment)
2013/12/7 Tobias Burnus bur...@net-b.de: Janus Weil wrote: here is a small patch to fix a problem with class-array-valued functions, where the rank was not determined properly. Regtestes on x86_64-unknown-linux-gnu. Ok for trunk? [Note: This patch only fixes the rejects-valid problem of comment 0/1, but not the ICE of comment 2/3, which is a completely separate issue.] Looks good to me. Thanks for the patch! Thanks for the review. Committed as r205785. Cheers, Janus
[C++ Patch] Fix __is_base_of vs incomplete types
Hi, noticed this while preparing some testcases for the library (but probably Daniel pointed it out together with related issues some time ago): if we don't handle separately identical types modulo cv-qualifiers, we incorrectly return false for incomplete types. Tested x86_64-linux. Thanks, Paolo. /cp 2013-12-07 Paolo Carlini paolo.carl...@oracle.com * semantics.c (trait_expr_value, [CPTK_IS_BASE_OF]): Implement the letter of 20.11.6 about Base and Derived naming the same class type modulo cv-qualifiers. /testsuite 2013-12-07 Paolo Carlini paolo.carl...@oracle.com * g++.dg/ext/is_base_of_incomplete-2.C: New. Index: cp/semantics.c === --- cp/semantics.c (revision 205782) +++ cp/semantics.c (working copy) @@ -7108,7 +7108,8 @@ trait_expr_value (cp_trait_kind kind, tree type1, case CPTK_IS_BASE_OF: return (NON_UNION_CLASS_TYPE_P (type1) NON_UNION_CLASS_TYPE_P (type2) - DERIVED_FROM_P (type1, type2)); + (same_type_ignoring_top_level_qualifiers_p (type1, type2) + || DERIVED_FROM_P (type1, type2))); case CPTK_IS_CLASS: return (NON_UNION_CLASS_TYPE_P (type1)); Index: testsuite/g++.dg/ext/is_base_of_incomplete-2.C === --- testsuite/g++.dg/ext/is_base_of_incomplete-2.C (revision 0) +++ testsuite/g++.dg/ext/is_base_of_incomplete-2.C (working copy) @@ -0,0 +1,5 @@ +struct T; + +int check1[__is_base_of(T, T) ? 1 : -1]; +int check2[__is_base_of(T, const T) ? 1 : -1]; +int check3[__is_base_of(volatile T, T) ? 1 : -1];
fixinclude patch for fenv.h on Ubuntu
This patch fixes Ian's issue, and several similar patterns:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00681.html
$ make check
autogen -T ../.././fixincludes/check.tpl ../.././fixincludes/inclhack.def
/bin/sh ./check.sh ../.././fixincludes/tests/base
Fixed: testing.h
[[...]]
Fixed: unistd.h
All fixinclude tests pass
/u/gnu/proj/gcc-svn-bld/build-x86_64-unknown-linux-gnu/fixincludes
Full build for x86-64 in progress. Patch submission likely tomorrow.
Index: fixincludes/ChangeLog
===
--- fixincludes/ChangeLog (revision 204533)
+++ fixincludes/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2013-09-20 Bruce Korb bk...@gnu.org
+
+ * inclhack.def: many of the headers found under bits/ are
+ often stashed under architecture directories. Apply fixes
+ to those, too. Also, re-ordered a couple of misordered fixes.
+
2013-09-20 Alan Modra amo...@gmail.com
* configure: Regenerate.
Index: fixincludes/fixincl.x
===
--- fixincludes/fixincl.x (revision 204533)
+++ fixincludes/fixincl.x (working copy)
[[generated]]
Index: fixincludes/inclhack.def
===
--- fixincludes/inclhack.def (revision 204533)
+++ fixincludes/inclhack.def (working copy)
@@ -1140,6 +1140,20 @@
};
/*
+ * Old Linux kernel's compiler.h header breaks Traditional CPP
+ */
+fix = {
+hackname = complier_h_tradcpp;
+files = linux/compiler.h;
+
+select= #define __builtin_warning\\(x, y\\.\\.\\.\\) \\(1\\);
+c_fix = format;
+c_fix_arg = /* __builtin_warning(x, y...) is obsolete */;
+
+test_text = #define __builtin_warning(x, y...) (1);
+};
+
+/*
* Fix various macros used to define ioctl numbers.
* The traditional syntax was:
*
@@ -1509,6 +1523,60 @@
};
/*
+ * Incorrect feraiseexcept extern inline in bits/fenv.h on x86_64
+ * that fails when compiling for SSE-less 32-bit x86.
+ */
+fix = {
+hackname = feraiseexcept_nosse_invalid;
+mach = 'i[34567]86-*-linux*', 'x86*-linux*', 'amd64-*-linux*';
+files = bits/fenv.h, '*/bits/fenv.h';
+select= ^([\t ]*)__asm__ __volatile__ \\(\divss %0, %0 *\ :
+ : \x\ \\(__f\\)\\);$;
+bypass= \fdiv .*; fwait\;
+
+c_fix = format;
+c_fix_arg = - _EOText_
+ # ifdef __SSE_MATH__
+ %0
+ # else
+ %1__asm__ __volatile__ (fdiv st, st(0); fwait
+ %1 : =t (__f) : 0 (__f));
+ # endif
+ _EOText_;
+
+test_text = - _EOText_
+ __asm__ __volatile__ (divss %0, %0 : : x (__f));
+ _EOText_;
+};
+
+/*
+ * Incorrect feraiseexcept extern inline in bits/fenv.h on x86_64
+ * that fails when compiling for SSE-less 32-bit x86.
+ */
+fix = {
+hackname = feraiseexcept_nosse_divbyzero;
+mach = 'i[34567]86-*-linux*', 'x86*-linux*', 'amd64-*-linux*';
+files = bits/fenv.h, '*/bits/fenv.h';
+select= ^([\t ]*)__asm__ __volatile__ \\(\divss %1, %0 *\ :
+ : \x\ \\(__f\\), \x\ \\(__g\\)\\);$;
+bypass= \fdivp .*; fwait\;
+
+c_fix = format;
+c_fix_arg = - _EOText_
+ # ifdef __SSE_MATH__
+ %0
+ # else
+ %1__asm__ __volatile__ (fdivp st, st(1); fwait
+ %1 : =t (__f) : 0 (__f), u (__g) : st(1));
+ # endif
+ _EOText_;
+
+test_text = - _EOText_
+ __asm__ __volatile__ (divss %1, %0 : : x (__f), x (__g));
+ _EOText_;
+};
+
+/*
* Between 8/24/1998 and 2/17/2001, FreeBSD system headers presume
* neither the existence of GCC 3 nor its exact feature set yet break
* (by design?) when __GNUC__ is set beyond 2.
@@ -1738,7 +1806,7 @@
versions. */
fix = {
hackname = glibc_strncpy;
-files = bits/string2.h;
+files = bits/string2.h, '*/bits/string2.h';
bypass= __builtin_strncpy;
c_fix = format;
c_fix_arg = # define strncpy(dest, src, n) __builtin_strncpy (dest, src, n);
@@ -2411,7 +2479,7 @@
*/
fix = {
hackname = huge_val_hex;
-files = bits/huge_val.h;
+files = bits/huge_val.h, '*/bits/huge_val.h';
select= ^#[ \t]*define[ \t]*HUGE_VAL[ \t].*0x1\\.0p.*;
bypass= __builtin_huge_val;
@@ -2426,7 +2494,7 @@
*/
fix = {
hackname = huge_valf_hex;
-files = bits/huge_val.h;
+files = bits/huge_val.h, '*/bits/huge_val.h';
select= ^#[ \t]*define[ \t]*HUGE_VALF[ \t].*0x1\\.0p.*;
bypass= __builtin_huge_valf;
@@ -2441,7 +2509,7 @@
*/
fix = {
hackname = huge_vall_hex;
-files = bits/huge_val.h;
+files = bits/huge_val.h, '*/bits/huge_val.h';
select= ^#[ \t]*define[ \t]*HUGE_VALL[ \t].*0x1\\.0p.*;
bypass= __builtin_huge_vall;
@@ -4226,7 +4294,7 @@
fix = {
hackname = thread_keyword;
files = pthread.h;
-files = bits/sigthread.h;
+files = bits/sigthread.h, '*/bits/sigthread.h';
select= ([* ])__thread([,)]);
c_fix = format;
c_fix_arg = %1__thr%2;
@@ -4760,72 +4828,4
