[Bug c++/58815] Casting/Conversion operator for std::decimal not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815 --- Comment #9 from Janis Johnson janis at gcc dot gnu.org --- I haven't paid attention to decimal float since leaving IBM, so it was very interesting to see the updated C++11 working paper. It makes sense to me to use C++11 functionality in the GNU C++ decimal float support, especially in the case of explicit conversions.
[Bug c++/58815] Casting/Conversion operator for std::decimal not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815 --- Comment #12 from Janis Johnson janis at gcc dot gnu.org --- I obviously don't know C++ very well and the decimal float support in libstdc++ is very ugly. It would be nice if someone rewrites it in actual C++ someday; the tests should help with that effort.
[Bug c++/58815] Casting/Conversion operator for std::decimal not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815 --- Comment #4 from Janis Johnson janis at gcc dot gnu.org --- I vaguely remember a problem with those conversion and have no idea now what it was, but I'll try to find something in the mailing list archives. decimal/decimal includes a workaround: /// Non-conforming extension: Conversion to integral type. long long decimal32_to_long_long(decimal32 __d); long long decimal64_to_long_long(decimal64 __d); long long decimal128_to_long_long(decimal128 __d); long long decimal_to_long_long(decimal32 __d); long long decimal_to_long_long(decimal64 __d); long long decimal_to_long_long(decimal128 __d);
[Bug c++/58815] Casting/Conversion operator for std::decimal not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815 --- Comment #5 from Janis Johnson janis at gcc dot gnu.org --- From Janis in http://gcc.gnu.org/ml/libstdc++/2009-09/msg00115.html The TR defines, within each of the classes decimal32, decimal64, and decimal128, the following conversion: // 3.2.[234].4 conversion to integral type: operator long long() const; Apparently there's a way to implement this if one knows enough about C++, but providing this implicit conversion from a decimal float type to long long allows further implicit conversions from long long to other types, including float, double, and long double, which are not supposed to be allowed. Furthermore, a conversion from a decimal float type to a generic float type that goes through long long truncates the fractional part of the value which is rather surprising. This version of the patch leaves out that conversion and provides a set of functions to convert to long long, which made testing the rest of the functionality much easier. Any suggestions for how to do with using the current (not C++0x) standard? Or is it OK to require the use of C++0x functionality with this extension? From Benjamin Kosnik in http://gcc.gnu.org/ml/libstdc++/2009-09/msg00127.html I think it is not ok to require the use of C++0x with the decimal floating point extension. It is clearly designed with C++2003 in mind, and makes no use of C++0x features. When you post testsuite files demonstrating this issue in detail I'll take a look at this overload issue. From Janis in http://gcc.gnu.org/ml/libstdc++/2009-10/msg4.html With the submission on Monday I mentioned that this patch does not support an implicit conversion to integral types (long long) from each of the decimal classes. Those are in the patch, commented out and with a comment that now says (DISABLED). If those are not disabled then all of the error checks in the bad-*.cc tests fail. I can't see how to allow implicit conversions to long long while also prohibiting bitwise operations with decimal floating-point operands or conversions and casts to generic floating-point types. I didn't find any further discussion of this issue.
[Bug target/58172] New: ifcvt test failures for armv8-a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58172 Bug ID: 58172 Summary: ifcvt test failures for armv8-a Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: janis at gcc dot gnu.org CC: ramana at gcc dot gnu.org Target: arm-none-eabi The following test failures are regressions from GCC 4.8 for arm-none-eabi with multilib flags that include -march=armv8-a: gcc.target/arm/thumb-ifcvt.c scan-assembler asrne gcc.target/arm/thumb-ifcvt.c scan-assembler lslne gcc.target/arm/thumb2-cond-cmp-1.c scan-assembler cmpne gcc.target/arm/thumb2-cond-cmp-2.c scan-assembler cmpeq gcc.target/arm/thumb2-cond-cmp-3.c scan-assembler cmpgt gcc.target/arm/thumb2-cond-cmp-4.c scan-assembler cmpne The failures begin with this patch: r197346 | ramana | 2013-04-02 04:25:50 -0700 (Tue, 02 Apr 2013) | 17 lines Add support for Cortex-A53. 2013-04-02 Ian Caulfield ian.caulfi...@arm.com Ramana Radhakrishnan ramana.radhakrish...@arm.com * config/arm/arm-arches.def (armv8-a): Default to cortex-a53. * config/arm/t-arm (MD_INCLUDES): Depend on cortex-a53.md. * config/arm/cortex-a53.md: New file. * config/arm/bpabi.h (BE8_LINK_SPEC): Handle cortex-a53. * config/arm/arm.md (generic_sched, generic_vfp): Handle cortex-a53. * config/arm/arm.c (arm_issue_rate): Likewise. * config/arm/arm-tune.md: Regenerate * config/arm/arm-tables.opt: Regenerate. * config/arm/arm-cores.def: Add cortex-a53. If the tests aren't expected to use conditional instructions for armv8-a then they should be skipped for use of that flag.
[Bug debug/57389] ICE in dbx_reg_number, at dwarf2out.c:10507 on powerpc-spe target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57389 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #7 from Janis Johnson janis at gcc dot gnu.org --- I'm getting the ICE described in the submitter's description in 13 C tests for powerpc-none-eabispe, and the patch in comment 5 fixes it.
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448 --- Comment #17 from Janis Johnson janis at gcc dot gnu.org --- Paolo, I don't remember, but assume I didn't uncover anything else that was interesting.
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448 --- Comment #21 from Janis Johnson janis at gcc dot gnu.org --- I'm definitely not working on the bug anymore, and would have to do a lot of work (better left to experts) to figure out if the test is valid. Please assign it to someone else, or at least unassign it from me (or tell me how to do that). If the functionality really mattered to the submitter he would have spoken up again.
[Bug target/57814] New: gcc.target/powerpc/pr46728-* test failures for eabi targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57814 Bug ID: 57814 Summary: gcc.target/powerpc/pr46728-* test failures for eabi targets Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: janis at gcc dot gnu.org CC: wschmidt at gcc dot gnu.org Target: powerpc-none-eabi, powerpc-none-eabispe Several of the tests added for PR46728 fail for powerpc-none-eabi and powerpc-none-eabispe. The tests all use -mpowerpc-gpopt; is that option expected to work for those targets? If not I can add directives to skip tests using that option for powerpc-*-eabi*; if it should work then I'll provide further information about test failures and internal compiler errors (segfaults). My testing has been for GCC mainline and the 4.8 branch. It would be nice if the compiler complained when -mpowerpc-gpopt is used with incompatible targets, but that idea was shot down in PR24913.
[Bug target/57816] New: ICE compiling __builtin_sqrt with powerpc-none-eabispe with -mpowerpc-gpopt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57816
Bug ID: 57816
Summary: ICE compiling __builtin_sqrt with powerpc-none-eabispe
with -mpowerpc-gpopt
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: janis at gcc dot gnu.org
CC: wschmidt at gcc dot gnu.org
Host: i686-pc-linux-gnu
Target: powerpc-none-eabispe
Build: i686-pc-linux-gnu
With current mainline a compiler for powerpc-none-eabispe gets a segfault
compiling gcc.target/powerpc/pr46728-1.c and several other pr46728-*.c tests.
Here's a minimized testcase:
void
foo (double x, double y)
{
if (x != __builtin_sqrt (y))
__builtin_abort ();
}
and crash output:
z.c: In function 'foo':
z.c:4:29: internal compiler error: Segmentation fault
if (x != __builtin_sqrt (y))
^
0x85e8510 crash_signal
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/toplev.c:333
0x8401ebe aggregate_value_p(tree_node const*, tree_node const*)
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/function.c:1980
0x82888ca emit_library_call_value_1
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/calls.c:3661
0x828e2a3 emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, int, ...)
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/calls.c:4349
0x837e2bb convert_move(rtx_def*, rtx_def*, int)
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/expr.c:398
0x837e968 convert_modes(machine_mode, machine_mode, rtx_def*, int)
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/expr.c:781
0x851c6a7 widen_operand
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/optabs.c:350
0x8527e1b expand_unop(machine_mode, optab_tag, rtx_def*, rtx_def*, int)
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/optabs.c:3302
0x8261508 expand_builtin_mathfn
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/builtins.c:2052
0x827cfe1 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/builtins.c:5898
0x8374604 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/expr.c:10226
0x8382b56 store_expr(tree_node*, rtx_def*, int, bool)
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/expr.c:5239
0x8385536 expand_assignment(tree_node*, tree_node*, bool)
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/expr.c:5025
0x829ca61 expand_call_stmt
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/cfgexpand.c:2178
0x829ca61 expand_gimple_stmt_1
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/cfgexpand.c:2218
0x829ca61 expand_gimple_stmt
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/cfgexpand.c:2370
0x829df6e expand_gimple_basic_block
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/cfgexpand.c:4204
0x82a0a39 gimple_expand_cfg
/scratch/janisjo/build4/fsf-powerpc-eabispe/src/gcc-mainline/gcc/cfgexpand.c:4723
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.
I attempted to discover when this failure starts, but it's intermittent with
the GCC build. I have not seen the failure with target powerpc-none-eabi.
[Bug target/57814] gcc.target/powerpc/pr46728-* test failures for eabi targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57814 --- Comment #2 from Janis Johnson janis at gcc dot gnu.org --- I filed http://gcc.gnu.org/PR57816 for the ICE mentioned above.
[Bug testsuite/55780] effective targets arm_arch_v*_multilib are not strict enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55780 --- Comment #5 from Janis Johnson janis at gcc dot gnu.org 2013-02-19 23:53:05 UTC --- The gcc.target/arm/ftest-*.c tests now work without hangs, but the effective target checks are still in the testsuite available to be used by other tests where they will show the same problems. These effective target checks could be useful, but not in their current state.
[Bug testsuite/56206] [4.7.3 regression] dg-require-effective-target arm_hard_vfp_ok triggers many test suite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56206 --- Comment #1 from Janis Johnson janis at gcc dot gnu.org 2013-02-04 18:07:12 UTC --- Author: janis Date: Mon Feb 4 18:07:06 2013 New Revision: 195725 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195725 Log: PR testsuite/56206 * lib/target-supports.exp (check_effective_target_arm_hard_vfp_ok): Fix typo. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/lib/target-supports.exp
[Bug testsuite/55994] multiple definition or memset or strlen for builtins tests with LTO options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994 --- Comment #6 from Janis Johnson janis at gcc dot gnu.org 2013-01-25 00:26:43 UTC --- Author: janis Date: Fri Jan 25 00:26:34 2013 New Revision: 195458 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195458 Log: Backport from mainline 2013-01-16 Janis Johnson jani...@codesourcery.com PR testsuite/55994 * gcc.c-torture/execute/builtins/builtins.exp: Add -Wl,--allow-multiple-definition for eabi and elf targets. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
[Bug target/56091] New: gcc.target/arm/pr43137.c fails for THUMB-1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56091 Bug #: 56091 Summary: gcc.target/arm/pr43137.c fails for THUMB-1 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Target: arm-none-eabi This test failure now appears for mainline arm-none-eabi for all THUMB-1 effective targets: FAIL: gcc.target/arm/pr43137.c scan-assembler-not movtr1, r[1-9] This is a compile-only test so I was able to run it for 34 sets of flags comprising all values of -march supported by GAS, with and without -mthumb as appropriate. The test failure begins with this patch to GCC mainline: r187015 | rsandifo | 2012-05-01 07:45:24 -0700 (Tue, 01 May 2012) | 33 lines This is a regression from GCC 4.7
[Bug target/56092] New: gcc.target/arm/volatile-bitfields-1.c fails for THUMB and armv[78]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56092 Bug #: 56092 Summary: gcc.target/arm/volatile-bitfields-1.c fails for THUMB and armv[78] Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Target: arm-none-eabi This test failure now appears for mainline arm-none-eabi: FAIL: gcc.target/arm/volatile-bitfields-1.c scan-assembler ldrb[\t ]+[^n]*,[\t ]*\[[^n]*\] This is a compile-only test so I was able to run it for 34 sets of flags comprising all values of -march supported by GAS, with and without -mthumb as appropriate. The test fails for THUMB-1 and THUMB-2, and for armv7a, armv7r, and armv8a in ARM mode. The test failure begins with this patch to GCC mainline: r193605 | rsandifo | 2012-11-18 09:33:38 -0800 (Sun, 18 Nov 2012) | 37 lines This is a regression from GCC 4.7.
[Bug target/56093] New: gcc.target/arm/wmul-11.c fails for armv5te and iwmmxt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56093 Bug #: 56093 Summary: gcc.target/arm/wmul-11.c fails for armv5te and iwmmxt Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Target: arm-none-eabi This test failure now appears for mainline arm-none-eabi: FAIL: gcc.target/arm/wmul-11.c scan-assembler smull This is a compile-only test so I was able to run it for 34 sets of flags comprising all values of -march supported by GAS, with and without -mthumb as appropriate. It now fails for armv5te, iwmmxt, and iwmmxt2. The test is skipped if the effective target is not arm_dsp. The test failure begins with this patch to GCC mainline: r190050 | rth | 2012-08-01 13:26:58 -0700 (Wed, 01 Aug 2012) | 1 line Allow MODE_PARTIAL_INT in expmed costs This is a regression from GCC 4.7.
[Bug debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55794 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #1 from Janis Johnson janis at gcc dot gnu.org 2013-01-22 17:36:49 UTC --- For arm-none-eabi the line that is recorded is 33 rather than 30. I see from gcc-testresults that the test also fails for moxie-elf, bfin-rtems, and m32r-rtems.
[Bug debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55794 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #2 from Janis Johnson janis at gcc dot gnu.org 2013-01-22 17:39:09 UTC --- Adding Cary to the mailing list since he added this test.
[Bug target/56043] New: ICE in rs6000_builtin_vectorized_libmass for vsx-mass-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56043 Bug #: 56043 Summary: ICE in rs6000_builtin_vectorized_libmass for vsx-mass-1.c Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: meiss...@gcc.gnu.org Target: powerpc-none-eabi My mainline compiler for powerpc-none-eabi gets a null pointer dereference for a test: /scratch/janisjo/build6/fsf-powerpc-eabi/src/gcc-mainline/gcc/testsuite/gcc.target/powerpc/vsx-mass-1.c: In function 'test_float_atan2':^M /scratch/janisjo/build6/fsf-powerpc-eabi/src/gcc-mainline/gcc/testsuite/gcc.target/powerpc/vsx-mass-1.c:80:1: internal compiler error: Segmentation fault^M 0x85fb2d2 crash_signal^M /scratch/janisjo/build6/fsf-powerpc-eabi/src/gcc-mainline/gcc/toplev.c:332^M 0x813611c contains_struct_check /scratch/janisjo/build6/fsf-powerpc-eabi/src/gcc-mainline/gcc/tree.h:3782 0x88b5172 rs6000_builtin_vectorized_libmass /scratch/janisjo/build6/fsf-powerpc-eabi/src/gcc-mainline/gcc/config/rs6000/rs6000.c:3751 0x88093be vect_analyze_loop_operations /scratch/janisjo/build6/fsf-powerpc-eabi/src/gcc-mainline/gcc/tree-vect-loop.c:1443 0x880ac46 vect_analyze_loop_2 /scratch/janisjo/build6/fsf-powerpc-eabi/src/gcc-mainline/gcc/tree-vect-loop.c:1720 0x880ac46 vect_analyze_loop(loop*) /scratch/janisjo/build6/fsf-powerpc-eabi/src/gcc-mainline/gcc/tree-vect-loop.c:1773 0x8825e13 vectorize_loops() /scratch/janisjo/build6/fsf-powerpc-eabi/src/gcc-mainline/gcc/tree-vectorizer.c:113 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. FAIL: gcc.target/powerpc/vsx-mass-1.c (internal compiler error) FAIL: gcc.target/powerpc/vsx-mass-1.c (test for excess errors) The null pointer dereference comes from a null value assigned to bdecl returned from builtin_decl_implicit in calls in rs6000_builtin_vectorized_libmass. If that function returns NULL_TREE when bdecl is NULL then the test program compiles but nost of the assembly scans fail, so perhaps that isn't a valid fix. Here's the output from my tests when the null pointers are avoided: PASS: gcc.target/powerpc/vsx-mass-1.c (test for excess errors) PASS: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+atan2d2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+atan2f4 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+hypotd2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+hypotf4 PASS: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+powd2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+powf4 PASS: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+acosd2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+acosf4 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+acoshd2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+acoshf4 PASS: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+asind2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+asinf4 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+asinhd2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+asinhf4 PASS: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+atand2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+atanf4 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+atanhd2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+atanhf4 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+cbrtd2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+cbrtf4 PASS: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+cosd2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+cosf4 PASS: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+coshd2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+coshf4 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+erfd2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+erff4 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+erfcd2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+erfcf4 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+exp2d2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+exp2f4 PASS: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+expd2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+expf4 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+expm1d2 FAIL: gcc.target/powerpc/vsx-mass-1.c scan-assembler bl[\\. ]+expm1f4 PASS:
[Bug tree-optimization/55995] vect increase_alignment notes missing from dump file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55995 --- Comment #2 from Janis Johnson janis at gcc dot gnu.org 2013-01-16 16:38:24 UTC --- Interesting, it causes the compiler to segfault on both arm-none-eabi and powerpc-none-eabi: /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/aligned-section-anchors-nest-1.c:31:1: internal compiler error: Segmentation fault^M 0x8605072 crash_signal^M /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/gcc/toplev.c:332^M 0x82f5523 contains_struct_check^M /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/gcc/tree.h:3782^M 0x82f5523 dump_loc^M /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/gcc/dumpfile.c:266^M 0x82f56a2 dump_printf_loc(int, unsigned int, char const*, ...)^M /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/gcc/dumpfile.c:370^M 0x882ffc7 increase_alignment^M /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/gcc/tree-vectorizer.c:238^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 FAIL: gcc.dg/vect/aligned-section-anchors-nest-1.c (internal compiler error) FAIL: gcc.dg/vect/aligned-section-anchors-nest-1.c (test for excess errors)
[Bug testsuite/54622] gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 --- Comment #8 from Janis Johnson janis at gcc dot gnu.org 2013-01-16 18:50:06 UTC --- Author: janis Date: Wed Jan 16 18:49:57 2013 New Revision: 195249 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195249 Log: PR testsuite/54622 * lib/target-supports.exp (check_effective_target_vect_perm_byte, check_effective_target_vect_perm_short, check_effective_target_vect_widen_mult_qi_to_hi_pattern, check_effective_target_vect64): Return 0 for big-endian ARM. (check_effective_target_vect_widen_sum_qi_to_hi): Return 1 for ARM. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug testsuite/55994] multiple definition or memset or strlen for builtins tests with LTO options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994 --- Comment #5 from Janis Johnson janis at gcc dot gnu.org 2013-01-16 18:52:56 UTC --- Author: janis Date: Wed Jan 16 18:52:51 2013 New Revision: 195250 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195250 Log: PR testsuite/55994 * gcc.c-torture/execute/builtins/builtins.exp: Add -Wl,--allow-multiple-definition for eabi and elf targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
[Bug tree-optimization/42172] inefficient bit fields assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42172 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #8 from Janis Johnson janis at gcc dot gnu.org 2013-01-17 00:26:10 UTC --- The test gcc.target/arm/pr42172-1.c currently passes for armv6t2, armv7*, and armv8* with and without -mthumb. At this point can the test be limited to those processors, or XFAILed for others?
[Bug testsuite/54139] [4.8 regression] some ARM Thumb-2 tests appear to be run on ARMv5TE hardware causing unhandled exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54139 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #5 from Janis Johnson janis at gcc dot gnu.org 2013-01-15 16:32:54 UTC --- There are 3 separate problems described in this PR. The first is about the effective target tests used by gcc.target/arm and is a duplicate of PR55780. The second, the ICE for test mmx-2.c, is described in PR54338. The third is for failures like FAIL: gcc.c-torture/execute/builtins/memset.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects that fail to link due to multiple definitions of memset or strlen; I see this for arm-none-eabi (and I think some other EABI targets) but not for GNU/Linux targets. The same tests fail for GCC 4.7 so it's not a regression. I'll file a PR if there isn't one already.
[Bug lto/55994] New: multiple definition or memset or strlen for builtins tests with LTO options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994 Bug #: 55994 Summary: multiple definition or memset or strlen for builtins tests with LTO options Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Target: *-*-eabi or *-elf I get the following test failures for multiple targets for GCC 4.7 and mainline: FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/memmove-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/memops-asm.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/memset-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/memset.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/stpcpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/stpncpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/strcat-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/strcpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/strlen-2.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/strlen-3.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/strlen.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/strncat-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/strncpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects The reported failure is /tmp/cc3DFMVG.ltrans1.ltrans.o: In function `memset': cc3DFMVG.ltrans1.o:(.text+0x558): multiple definition of `memset' /scratch/janisjo/build6/fsf-4.7-arm-eabi/install/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/libc.a(lib_a-memset.o):/scratch/janisjo/build6/fsf-4.7-arm-eabi/src/newlib-mainline/newlib/libc/string/memset.c:57: first defined here collect2: error: ld returned 1 exit status or /tmp/cc2KdAgP.ltrans0.ltrans.o: In function `strlen': cc2KdAgP.ltrans0.o:(.text+0x0): multiple definition of `strlen' /scratch/janisjo/build6/fsf-4.7-arm-eabi/install/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/libc.a(lib_a-strlen.o):/scratch/janisjo/build6/fsf-4.7-arm-eabi/src/newlib-mainline/newlib/libc/machine/arm/strlen.c:68: first defined here collect2: error: ld returned 1 exit status I've seen the failures for arm-none-eabi and powerpc-none-eabi with FSF sources (the only targets I've tried) and also for CodeSourcery sources for those plus mips-sde-elf, m68k-elf, and i686-mingw32. They all use newlib. The same tests pass for GNU/Linux targets. These test options were added for GCC 4.7. This problem was mentioned in PR54139.
[Bug testsuite/54139] [4.8 regression] some ARM Thumb-2 tests appear to be run on ARMv5TE hardware causing unhandled exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54139 --- Comment #8 from Janis Johnson janis at gcc dot gnu.org 2013-01-15 17:11:40 UTC --- The gcc.c-torture/execute/builtins failures with LTO options are now covered by PR55994.
[Bug tree-optimization/55995] New: vect increase_alignment notes missing from dump file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55995 Bug #: 55995 Summary: vect increase_alignment notes missing from dump file Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: sing...@gcc.gnu.org Target: arm*-*-* powerpc*-*-* Test gcc.dg/vect/aligned-section-anchors-nest-1.c started failing with the patch added in revisions 191883 and 191884 that changes the verbosity of compiler dump files. The dump file scan is for a file created with -fdump-ipa-increase-alignment and a message output with MSG_NOTE. Unlike -fdump-tree-switch-options, there is apparently no support for -fdump-ipa-switch-options and I couldn't figure out how to get the notes included in the increase_alignment dump file. The messages are output from function increase_alignment in tree-vectorizer.c. The test is run for effective targets section_anchors and vect_int, which includes powerpc*-*-* and arm*-*-*. The test was added in 2009 so this is a regression.
[Bug testsuite/55994] multiple definition or memset or strlen for builtins tests with LTO options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994 --- Comment #4 from Janis Johnson janis at gcc dot gnu.org 2013-01-15 20:00:17 UTC --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00801.html.
[Bug target/54338] internal compiler error: in find_costs_and_classes, at ira-costs.c:1711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54338 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #4 from Janis Johnson janis at gcc dot gnu.org 2013-01-10 00:13:31 UTC --- Test gcc.target/arm/mmx-2.c still gets this ICE with current mainline.
[Bug testsuite/55780] effective targets arm_arch_v*_multilib are not strict enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55780 --- Comment #2 from Janis Johnson janis at gcc dot gnu.org 2013-01-03 22:52:03 UTC --- Here's the configuration for the FSF mainline compiler I'm using: Target: arm-none-eabi Configured with: /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared --enable-lto --with-newlib --disable-nls --prefix=/opt/codesourcery --with-headers=yes --with-sysroot=/opt/codesourcery/arm-none-eabi --with-build-sysroot=/scratch/janisjo/build6/fsf-arm-eabi/install/arm-none-eabi --disable-libgomp --disable-libitm Thread model: single gcc version 4.8.0 20130103 (experimental) (GCC) For this compiler, none of the links fail for the arm_arch_v*_multilib checks. Some of those checks fail at runtime, causing ftest-*.c tests to be UNSUPPORTED. In more cases, the simulator passes when running the arm_arch_v*_multilib check and then fails when running the test, causing it to FAIL instead of being UNSUPPORTED. It should be easy enough to add a check_link procedure, similar to check_compile or check_runtime, but from I've seen that would pass with all of these checks for my configuration. I suspect that a more robust link check would need target-specific code requiring calls to target-specific runtime libraries. A separate issue is that these checks are being used to determine whether or not to skip dg-do run tests, and that those tests can be rewritten to check the tested functionality at compile-time instead of run time; see http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01339.html.
[Bug testsuite/55780] New: effective targets arm_arch_v*_multilib are not strict enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55780 Bug #: 55780 Summary: effective targets arm_arch_v*_multilib are not strict enough Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: rearn...@arm.com Target: arm The arm_arch_v*_multilib effective targets check that a minimal C program will execute when compiled for a particular ARM processor, but the test used is an empty program and the tests that use those checks have more complicated code. All of the effective target checks pass using the gdb arm simulator or QEMU, but some of the ftest-*.c tests then get illegal instructions or hang. Checks for the ability to run programs on particular hardware should include code that will only run on that hardware, as is done for effective target whose keywords end in _hw_available.
[Bug target/54723] test gcc.target/arm/div64-unwinding.c fails for GNU/Linux target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54723 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Janis Johnson janis at gcc dot gnu.org 2012-10-12 19:27:49 UTC --- I'm declaring this Not a Bug based on this response from Richard Earnshaw in http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00966.html: I don't believe there's a bug here. The ARM EABI defines __aeabi_idiv0 as a hook that will be called if division by zero occurs. While the default implementation simply raises SIGFPE on linux, it is perfectly possible to provide your own definition of this hook and then throw() a C++ exception. In order to do that you'd need unwind information in the divdi implementation ([u]divsi tailcalls the hook). Technically you could argue the same for bare metal, but in that case the arguments against the code bloat outweigh this very small corner case and users wanting this will have to rebuild their support code. On linux, I think the presence of the unwind information is correct, since the code bloat problem is very much a secondary concern.
[Bug testsuite/54622] gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 --- Comment #6 from Janis Johnson janis at gcc dot gnu.org 2012-09-26 16:45:25 UTC --- It's important to continue to run the vectorization tests with ARM big-endian to detect regressions in the execution tests, so I don't want to exclude it from all vect effective targets. I'll propose a set of effective targets used in the scans that should exclude ARM big-endian.
[Bug testsuite/54622] gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 --- Comment #7 from Janis Johnson janis at gcc dot gnu.org 2012-09-26 21:51:53 UTC --- I've tried requiring arm_little_endian for various vect_ effective targets, but the missing support isn't at all clear-cut. Lots of vectorization takes place so it's important to continue to pay attention to the execute tests, but for now I think we'll just handle big-endian expected failures locally.
[Bug target/54338] internal compiler error: in find_costs_and_classes, at ira-costs.c:1711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54338 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #3 from Janis Johnson janis at gcc dot gnu.org 2012-09-26 22:57:13 UTC --- I get the same ICE from current trunk for arm-none-eabi for test gcc.target/arm/mmx-2.c when -mcpu=iwmmxt is added to dg-options.
[Bug target/54723] New: test gcc.target/arm/div64-unwinding.c fails for GNU/Linux target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54723 Bug #: 54723 Summary: test gcc.target/arm/div64-unwinding.c fails for GNU/Linux target Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Target: arm-none-linux-gnueabi Test gcc.target/arm/div64-unwinding.c checks that performing a 64-bit division does not pull in the unwinder. When Julian Brown added the test he mentioned that it was for use with bare-metal targets, but the test is not restricted to them. When asked about it recently he said Actually the mechanism through which the test fails for Linux/glibc is unknown: it might be worth trying to figure out what causes the unwinder to be pulled into the binary for Linux toolchains. Or it might not... I plan to XFAIL the test for GNU/Linux targets, so this PR provides a handy place to record additional thoughts about the failure.
[Bug testsuite/54622] New: gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 Bug #: 54622 Summary: gcc.dg/vect test failures for arm big-endian Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: i...@gcc.gnu.org Target: arm Created attachment 28219 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28219 list of vect test failures for arm big-endian 71 vectorization tests (plus corresponding checks with -flto) pass for ARM little endian but fail for ARM big endian with current mainline. I'll attach the list. Some of them are scans that are gated on effective targets that always fail for ARM big endian; perhaps that's a coincidence, or perhaps some of these effective-target checks should require arm_little_endian: vect64 (2) vect-widen_shift (8) vect_perm_byte (1) vect_perm_short (1) vect_strided3 (1) Testing for ARM big-endian is straightforward for any ARM build. Avoid execution tests with a local patch to gcc/testsuite/gcc.dg/vect/vect.exp to add 'set dg-do-what-default compile' after calling check_vect_support_and_set_flags, and then pass the appropriate flags in RUNTESTFLAGS.
[Bug testsuite/54622] gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 --- Comment #2 from Janis Johnson janis at gcc dot gnu.org 2012-09-19 01:16:58 UTC --- Effective targets vect_unpack and vect_pack_trunc both require little endian for ARM, which is why I thought that perhaps some of the others do as well.
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664
--- Comment #14 from Janis Johnson janis at gcc dot gnu.org 2012-08-01
23:35:12 UTC ---
Ramana, chunks of regular expressions within parentheses are matched and added
to the returned expression that is used in scan-assembler-times. To avoid
returning parenthesized bits you need to replace (regexp) with (?:regexp).
Here's what works in vst4Qu8.c (cut and pasted, so tabs are wrong):
/* { dg-final { scan-assembler-times vst4\.8\[
\]+\\\{(?:(?:\[dD\]\[0-9\]+-\[dD\]\[0-9\]+)|(?:\[dD\]\[0-9\]+, \[dD\]\[0-9\]+,
\[dD\]\[0-9\]+, \[dD\]\[0-9\]+))\\\},
\\\[\[rR\]\[0-9\]+\(?::\[0-9\]+\)?\\\]!?\(?:\[ \]+@\[a-zA-Z0-9 \]+\)?\n 2
} } */
I haven't tried modifying the test generator.
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664
--- Comment #8 from Janis Johnson janis at gcc dot gnu.org 2012-07-31
15:56:12 UTC ---
For some reason I couldn't apply the patch, but manually changed the tests to
use { scan-assembler-times regexp 2 } instead of { scan assembler regexp }.
Ramana, have you tried running the tests? They should pass but don't. I'll
take a closer look at what scan-assembler-times and Tcl's regexp are doing.
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664 --- Comment #10 from Janis Johnson janis at gcc dot gnu.org 2012-07-31 16:49:23 UTC --- The problem is the regular expression, which matches far too much text and ends up with a length of 5 instead of 2.
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664 --- Comment #11 from Janis Johnson janis at gcc dot gnu.org 2012-07-31 17:30:15 UTC --- Sorry, I had been assuming that the tests in our tree match what's upstream but the expressions to match are slightly different. I'll keep investigating.
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664 --- Comment #13 from Janis Johnson janis at gcc dot gnu.org 2012-07-31 18:01:55 UTC --- The scan-assembler finds the expression at least once and passes. The scan-assembler-times directive expects to find the expression twice, but the returned match is 5 lines, not 2. I'm building a version whose tests match those upstream and will report what's happening there. I'm not set up to run neon tests with an upstream tree.
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664 --- Comment #5 from Janis Johnson janis at gcc dot gnu.org 2012-07-30 18:34:50 UTC --- Thanks for looking, Ramana. I noticed in my investigation that the search string needs to be different for scan-assembler-times than for scan-assembler, since the regular expression handling seems to be different.
[Bug testsuite/20771] Duplicate PCH test names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20771 --- Comment #7 from Janis Johnson janis at gcc dot gnu.org 2012-07-09 22:10:46 UTC --- Author: janis Date: Mon Jul 9 22:10:40 2012 New Revision: 189393 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189393 Log: Backport from mainline. 2012-06-28 Janis Johnson jani...@codesourcery.com * g++.dg/cpp0x/nullptr19.c: Remove exta directives on same line. * g++.dg/template/error46.C: Add missing comment to dg-message. * g++.dg/template/crash107.C: Likewise. * g++.dg/template/error47.C: Likewise. * g++.dg/template/crash108.C: Likewise. * g++.dg/overload/operator5.C: Likewise. * gcc.dg/Wstrict-aliasing-converted-assigned.c: Fix syntax errors in dg-message directives, add comments. 2012-06-26 Janis Johnson jani...@codesourcery.com * lib/scandump.exp (scan-dump, scan-dump-not, scan-dump-dem, scan-dump-dem-not): Use printable pattern in test name. 2012-06-25 Janis Johnson jani...@codesourcery.com * lib/target-supports-dg.exp (testname-for-summary): New. * lib/profopt.exp (profopt_execute): Define testname_with_flags. * lib/gcc-dg.exp (cleanup-coverage-files, cleanup-repo-notes, cleanup-stack-usage, cleanup-dump, cleanup-saved-temps, scan-module, scan-module-absence, output-exists, output-exists-not: Use testname-for-summary. (dg-test): Clean up testname_with_flags. * lib/scanasm.exp (scan-assembler, scan-assembler-not, scan-hidden, scan-not-hidden, scan-file, scan-file-not, scan-stack-usage, scan-stack-usage-not, scan-assembler-times, scan-assembler-dem, scan-assembler-dem-not, object-size: Use testname-for-summary. * lib/gcov.exp (run-gcov): Likewise. * lib/scandump.exp (scan-dump, scan-dump-times, scan-dump-not, scan-dump-dem, scan-dump-dem-note): Likewise. * lib/profopt.exp: Make prof_option_list local to profopt-execute. * g++.dg/tree-prof/tree-prof.exp (PROFOPT_OPTIONS): Define after including profopt.opt; save and restore existing value. * g++.dg/bprob/bprob.exp: Likewise. * gcc.dg/matrix/matrix.exp: Likewise. * gcc.dg/tree-prof/tree-prof.exp: Likewise. * gcc.misc-tests/bprob.exp: Likewise; also replace formerly-ignored PROFOPT_OPTIONS. 2012-06-15 Janis Johnson jano...@codesourcery.com * lib/gcov.exp (verify-lines, verify-branches, verify-calls): Use testname that includes flags, passed in as new argument, in pass/fail messages. (run_gcov): Get testname from dg-test, use it in pass/fail messages and pass it to verify-* procedures. * g++.dg/torture/stackalign/stackalign.exp: Combine stack alignment torture options with usual torture options. * g++.dg/cpp0x/auto27.C: Add comments to checks for multiple messages reported for one line of source code. * g++.dg/cpp0x/constexpr-decl.C: Likewise. * g++.dg/cpp0x/decltype2.C: Likewise. * g++.dg/cpp0x/decltype3.C: Likewise. * g++.dg/cpp0x/lambda/lambda-syntax1.C: Likewise. * g++.dg/cpp0x/regress/error-recovery1.C: Likewise. * g++.dg/cpp0x/static_assert3.C: Likewise. * g++.dg/cpp0x/udlit-cpp98-neg.C: Likewise. * g++.dg/cpp0x/udlit-shadow-neg.C: Likewise. * g++.dg/cpp0x/union1.C: Likewise. * g++.dg/cpp0x/variadic-ex10.C: Likewise. * g++.dg/cpp0x/variadic-ex14.C: Likewise. * g++.dg/cpp0x/variadic2.C: Likewise. * g++.dg/cpp0x/variadic20.C: Likewise. * g++.dg/cpp0x/variadic74.C: Likewise. * g++.dg/diagnostic/bitfld2.C: Likewise. * g++.dg/ext/attrib44.C: Likewise. * g++.dg/ext/no-asm-1.C: Likewise. * g++.dg/other/error34.C: Likewise. * g++.dg/parse/crash46.C: Likewise. * g++.dg/parse/error10.C: Likewise. * g++.dg/parse/error2.C: Likewise. * g++.dg/parse/error3.C: Likewise. * g++.dg/parse/error36.C: Likewise. * g++.dg/parse/error8.C: Likewise. * g++.dg/parse/error9.C: Likewise. * g++.dg/parse/parser-pr28152-2.C: Likewise. * g++.dg/parse/parser-pr28152.C: Likewise. * g++.dg/parse/template25.C: Likewise. * g++.dg/parse/typename11.C: Likewise. * g++.dg/tc1/dr147.C: Likewise. * g++.dg/template/deduce3.C: Likewise. * g++.dg/template/koenig9.C: Likewise. * g++.dg/template/pr23510.C: Likewise. * g++.dg/warn/pr12242.C: Likewise. * g++.dg/warn/pr30551-2.C: Likewise. * g++.dg/warn/pr30551.C: Likewise. * g++.old-deja/g++.other/typename1.C: Likewise. * g++.old-deja/g++.pt/niklas01a.C: Likewise. 2012-06-13 Janis Johnson jani...@codesourcery.com PR testsuite/20771 * lib/dg-pch.exp (dg-flags-pch): Add flags to make compile lines in test summary unique. * lib/scanasm.exp (scan-assembler, scan-assembler-not, scan-hidden, scan-not-hiddent, scan-file, scan-file-not, scan-stack-usage, scan-stack-usage-not): Don't strip torture options from test name. * lib/scandump.exp (scan-dump-times): Use printable version of regexp in test summary line
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664 --- Comment #2 from Janis Johnson janis at gcc dot gnu.org 2012-06-20 14:15:52 UTC --- Two scan-assembler directives with the same search string don't look for two instances of the same string, they just look for the same thing twice and pass if that string only occurs once. To look for two of them you'd need scan-assembler-times, with 2 as the expected number.
[Bug testsuite/20771] Duplicate PCH test names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20771 --- Comment #5 from Janis Johnson janis at gcc dot gnu.org 2012-06-13 22:56:00 UTC --- Author: janis Date: Wed Jun 13 22:55:56 2012 New Revision: 188540 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188540 Log: PR testsuite/20771 * lib/dg-pch.exp (dg-flags-pch): Add flags to make compile lines in test summary unique. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/dg-pch.exp
[Bug testsuite/20771] Duplicate PCH test names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20771 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Janis Johnson janis at gcc dot gnu.org 2012-06-13 23:03:08 UTC --- Fixed by the original patch from comment 4 which was later overwritten, and again by the patch in comment 5.
[Bug testsuite/53664] New: neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664 Bug #: 53664 Summary: neon-testgen.ml generates duplicate scan-assembler directives Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Target: arm Tests gcc/testsuite/gcc.target/arm/neon/v*.c are generated by the script gcc/config/arm/neon-testgen.ml. 54 of these tests have duplicate scan-assembler test directives, leading to duplicate lines in the test summary file. The test generator is an O'Caml program. I'm hoping that someone who knows that language will kindly take a look at this bug, fix it, and regenerate the tests.
[Bug testsuite/53665] New: test g++.dg/abi/mangle50.C has duplicate scan-assembler lines
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53665 Bug #: 53665 Summary: test g++.dg/abi/mangle50.C has duplicate scan-assembler lines Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: ja...@gcc.gnu.org Test g++.dg/abi/mangle50.C has three dg-final test directives with scan-assembler checks, two of which are identical. The third one is probably supposed to be for function h, but instead of guessing what it should be I'll let someone who understands the issue figure it out.
[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50722 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #8 from Janis Johnson janis at gcc dot gnu.org 2012-02-10 18:36:37 UTC --- Since the test only needs to compile and there are other targets (at least arm-none-eabi) that warn, a cleaner fix would be to add -w to the options to avoid the warnings.
[Bug c++/51364] C++ interoperability with ISO-C extension DFP types requires explicit typedefs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51364 --- Comment #11 from Janis Johnson janis at gcc dot gnu.org 2011-12-19 20:36:52 UTC --- The large code size isn't from the generated code, it's from the runtime support in static libraries; compile main.c with -c and look at the size of main.o. You might compare it to similar code using double and long double compiled with and without -msoft-float. With limited exceptions (I know of only one) decimal floating-point arithmetic must be supported through software emulation. GCC does this with libraries that were written to be fast and accurate rather than small.
[Bug c++/51364] C++ interoperability with ISO-C extension DFP types requires explicit typedefs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51364 --- Comment #7 from Janis Johnson janis at gcc dot gnu.org 2011-12-18 01:32:43 UTC --- An executable with decimal float support is very big because the runtime support is in static libraries, not in shared libraries (DLLs). That will probably change if it ever gets widespread use.
[Bug c++/51486] g++ doesn't implicitly search for decimal header in system include path include/c++/version/decimal/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51486 --- Comment #5 from Janis Johnson janis at gcc dot gnu.org 2011-12-09 17:04:04 UTC --- Header decimal didn't go with the standard headers because it's not part of the standard. My first couple of patches put it in tr24733/decimal on the recommendation of Benjamin Kosnik. Ed Smith-Rowland in http://gcc.gnu.org/ml/libstdc++/2009-10/msg00012.html suggested putting it in decimal/decimal instead, where it would be just as hidden from standard files but more recognizable. Benjamin agreed and made that change. I don't care where it goes, just wanted to clarify why it is where it is now.
[Bug c++/51364] C++ interoperability with ISO-C extension DFP types requires explicit typedefs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51364 --- Comment #2 from Janis Johnson janis at gcc dot gnu.org 2011-11-30 21:33:46 UTC --- The definitions that n2732 wants to add are typedefs to the C++ classes, but interoperability with C requires the typedefs using modes that Ryan shows. I never got a good answer from the authors of the C++ technical report about how to provide C/C++ interoperability. I'm not sure what dfp/stdlib.h is, but perhaps it should define typedefs if __cplusplus is defined.
[Bug c++/51364] C++ interoperability with ISO-C extension DFP types requires explicit typedefs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51364 --- Comment #4 from Janis Johnson janis at gcc dot gnu.org 2011-11-30 21:44:19 UTC --- If following the spec works, then by all means do that. It's been quite a long time since I've thought about decimal float support and my memory is a bit hazy.
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473 --- Comment #14 from Janis Johnson janis at gcc dot gnu.org 2011-09-30 17:33:48 UTC --- Author: janis Date: Fri Sep 30 17:33:41 2011 New Revision: 179399 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179399 Log: gcc/cp PR c++/44473 * mangle.c (write_type): Handle CV qualifiers for decimal classes. gcc/testsuite PR c++/44473 * g++.dg/dfp/44473-1.C: New test. * g++.dg/dfp/44473-2.C: New test. * g++.dg/dfp/mangle-1.C: New test. * g++.dg/dfp/mangle-2.C: New test. * g++.dg/dfp/mangle-3.C: New test. * g++.dg/dfp/mangle-4.C: New test. * g++.dg/dfp/mangle-5.C: New test. Added: trunk/gcc/testsuite/g++.dg/dfp/44473-1.C trunk/gcc/testsuite/g++.dg/dfp/44473-2.C trunk/gcc/testsuite/g++.dg/dfp/mangle-1.C trunk/gcc/testsuite/g++.dg/dfp/mangle-2.C trunk/gcc/testsuite/g++.dg/dfp/mangle-3.C trunk/gcc/testsuite/g++.dg/dfp/mangle-4.C trunk/gcc/testsuite/g++.dg/dfp/mangle-5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473 --- Comment #11 from Janis Johnson janis at gcc dot gnu.org 2011-09-28 23:04:13 UTC --- There's a patch here: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00625.html approved here: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01208.html Apparently I never checked it in. I'll test it and ask on gcc-patches if I can check it in now.
[Bug tree-optimization/49742] New: ICE for gcc.dg/vect/O3-pr39675-2.c on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742
Summary: ICE for gcc.dg/vect/O3-pr39675-2.c on ARM
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: rgue...@gcc.gnu.org
Test gcc.dg/vect/O3/pr39675-2.c fails with an ICE on arm-none-linux-gnueabi:
Executing on host: arm-none-linux-gnueabi-gcc
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c
-mfpu=neon -mfloat-abi=softfp -ffast-math -ftree-vectorize
-fno-vect-cost-model -O2 -fdump-tree-vect-details -O3 -fno-ipa-cp-clone -S -o
O3-pr39675-2.s(timeout = 300)
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c:
In function 'foo':
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c:27:1:
error: insn does not satisfy its constraints:
(insn 95 37 44 2 (set (reg:V2SI 95 d16 [orig:177 vect_array.21_I_lsm0.31 ]
[177])
(mem/u/c/i:V2SI (symbol_ref/u:SI (*.LC0) [flags 0x2]) [3 S8 A64]))
750 {*neon_movv2si}
(nil))
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c:27:1:
internal compiler error: in reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The same failure results if the test program is compiled with options
-mfpu=neon -mfloat-abi=softfp -O3.
The test starts failing with this patch:
2011-06-30 Richard Guenther rguent...@suse.de
PR tree-optimization/46787
* tree-data-ref.c (dr_address_invariant_p): Remove.
(find_data_references_in_stmt): Invariant accesses are ok now.
* tree-vect-stmts.c (vectorizable_load): Handle invariant
loads.
* tree-vect-data-refs.c (vect_analyze_data_ref_access): Allow
invariant loads.
* gcc.dg/vect/vect-121.c: New testcase.
r175704 | rguenth | 2011-06-30 13:27:43 + (Thu, 30 Jun 2011)
[Bug middle-end/49719] New: test gcc.target/arm/sibcall-1.c fails for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49719 Summary: test gcc.target/arm/sibcall-1.c fails for ARM Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Test gcc.target/arm/sibcall-1.c starts failing with r176042, a fix for PR middle-end/49519, for arm-none-linux-gnueabi configured with defaults for arch and cpu. The failure can be reproduced with a simple cross cc1. See discussion in 49519.
[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519 --- Comment #31 from Janis Johnson janis at gcc dot gnu.org 2011-07-12 15:06:03 UTC --- I filed PR middle-end/49719 for the sibcall-1.c failure.
[Bug target/49678] New: scan for mov fails in gcc.target/arm/pr42575.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49678 Summary: scan for mov fails in gcc.target/arm/pr42575.c Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Test gcc.target/arm/pr42575.c was added on 2010-08-18 in r163334. The scan for no mov started failing a few days later with: r163601 | bernds | 2010-08-27 22:11:50 + (Fri, 27 Aug 2010) The test specifies -march=armv7-a, which is overridden for multilibs that specify -march=, but it fails even for the default multilib. It passes for a few multilibs. Here are results for the scan for current trunk with the multilibs I've been using for compile-only tests, in case that provides useful clues: default: FAIL march_armv4t: FAIL march_armv5: FAIL march_armv5te: FAIL march_armv5te-mfloat-abi_softfp: FAIL march_armv5te-mfloat-abi_softfp-mbig-endian: FAIL march_armv5t: FAIL march_armv6: FAIL march_armv6j: FAIL march_armv6t2: PASS march_armv6z: PASS march_armv6zk: PASS march_armv7-a: FAIL march_armv7-a-mfloat-abi_hard-mfpu_neon: FAIL march_armv7-a-mfloat-abi_softfp-mfpu_neon: FAIL march_armv7-r: FAIL march_iwmmxt2: FAIL march_iwmmxt: FAIL mbig-endian: FAIL mcpu_xscale: PASS mfloat-abi_soft-mfpu_neon-fp16: FAIL mfloat-abi_soft-mfpu_vfpv3xd-fp16: FAIL mfpu_vfpv4: FAIL mthumb: PASS mthumb-march_armv4t: PASS mthumb-march_armv5te: PASS mthumb-march_armv5t: PASS mthumb-march_armv6: PASS mthumb-march_armv6j: PASS mthumb-march_armv6-m: PASS mthumb-march_armv6t2: PASS mthumb-march_armv6z: PASS mthumb-march_armv6zk: PASS mthumb-march_armv7-a: PASS mthumb-march_armv7: PASS mthumb-march_armv7-mfix-cortex-m3-ldrd: PASS mthumb-march_armv7-m: PASS mthumb-march_armv7-r: FAIL mthumb-march_iwmmxt2: PASS mthumb-march_iwmmxt: PASS mthumb-mcpu_cortex-a8: PASS With the 4.6 branch the only difference is that mcpu_xscale fails.
[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #25 from Janis Johnson janis at gcc dot gnu.org 2011-07-08 23:36:25 UTC --- Test gcc.target/arm/sibcall-1.c starts failing with r176042 for arm-none-linux-gnueabi configured with defaults for arch and cpu. The failure can be reproduced with a simple cross cc1.
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #11 from Janis Johnson janis at gcc dot gnu.org 2011-06-27 18:05:41 UTC --- I have confirmed that the -Os failures began with r175063 and that the tests pass for several revision before that and pass for several after, so it's unlikely to be an intermittent failure. If it would help I can send dump files for r175063 and the one just before that.
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #5 from Janis Johnson janis at gcc dot gnu.org 2011-06-24 22:00:07 UTC --- Starting with r175063, arm-none-linux-gnueabi using default configuration for arch/cpu/fpu/float-abi gets these failures: FAIL: gcc.c-torture/execute/920501-7.c execution, -Os FAIL: gcc.c-torture/execute/comp-goto-2.c execution, -Os FAIL: gcc.dg/torture/stackalign/comp-goto-1.c -Os execution test FAIL: gcc.dg/torture/stackalign/non-local-goto-4.c -Os execution test The failures are only for -Os, not for other optimization levels that Ramana sees for his configuration. Let me know if this needs a separate PR.
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #7 from Janis Johnson janis at gcc dot gnu.org 2011-06-24 23:01:40 UTC --- Created attachment 24600 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24600 rtl dump for -Os failure
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #9 from Janis Johnson janis at gcc dot gnu.org 2011-06-24 23:02:58 UTC --- I still get the -Os failures (I never had the others) with r175389 and have attached the requested rtl dumps.
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #8 from Janis Johnson janis at gcc dot gnu.org 2011-06-24 23:02:12 UTC --- Created attachment 24601 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24601 rtl dump for -Os failure
[Bug c++/46003] cond5.C fails for ARM EABI tests.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46003 --- Comment #7 from Janis Johnson janis at gcc dot gnu.org 2011-06-08 15:49:02 UTC --- Test g++.dg/template/cond5.C starts passing for arm-none-linux-gnueabi with r174682, the fix for PR49134 mentioned in comment 6.
[Bug c++/49259] template/incomplete6.C ICE in build_target_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49259 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.08 21:54:15 Ever Confirmed|0 |1 --- Comment #1 from Janis Johnson janis at gcc dot gnu.org 2011-06-08 21:54:15 UTC --- This was fixed by r174682, Jason's fix for c++/49134.
[Bug c++/49259] template/incomplete6.C ICE in build_target_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49259 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Janis Johnson janis at gcc dot gnu.org 2011-06-08 21:54:46 UTC --- Closing as FIXED.
[Bug c++/49259] New: template/incomplete6.C ICE in build_target_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49259 Summary: template/incomplete6.C ICE in build_target_expr Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Test g++.dg/template/incomplete6.C fails for arm-none-linux-gnueabi and arm-none-eabi: /scratch/janisjo/arm-eabi-fsf/src/gcc-mainline/gcc/testsuite/g++.dg/template/incomplete6.C: In member function 'Intsizeof (declvalF()(T())) SF, T::f(A) [with A = int, F = int (*)(...), T = templint]': /scratch/janisjo/arm-eabi-fsf/src/gcc-mainline/gcc/testsuite/g++.dg/template/incomplete6.C:21:29: instantiated from here /scratch/janisjo/arm-eabi-fsf/src/gcc-mainline/gcc/testsuite/g++.dg/template/incomplete6.C:16:9: internal compiler error: in build_target_expr, at cp/tree.c:296 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions The failure starts with this patch: r174101 | jason | 2011-05-24 03:49:03 + (Tue, 24 May 2011) PR c++/49102 * call.c (convert_arg_to_ellipsis): Call force_rvalue.
[Bug c++/49260] New: cpp0x/lambda/lambda-eh2.C fails execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260 Summary: cpp0x/lambda/lambda-eh2.C fails execution Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Test g++.dg/cpp0x/lambda/lambda-eh2.C fails execution on several targets as shown by archived test results: alpha-dec-osf5.1b arm-none-linux-gnueabi hppa2.0w-hp-hpux11.11 i686-apple-darwin9 powerpc-apple-darwin9.8.0 powerpc64-unknown-linux-gnu sh4-unknown-linux-gnu sparc-sun-solaris2.8, 2.9, 2.10 (but not 2.11) It also fails for arm-none-eabi, although the build has failed lately. Testing on arm-none-linux-gnueabi shows that the test has failed on that target since it was added on 2011-05-23 for r174076, to go with this fix: 2011-05-23 Jason Merrill ja...@redhat.com PR c++/47263 * decl.c (use_eh_spec_block): Do use an EH spec block for a lambda op().
[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260 --- Comment #1 from Janis Johnson janis at gcc dot gnu.org 2011-06-01 17:31:24 UTC --- Output when the test runs on QEMU for arm-none-linux-gnueabi: terminate called after throwing an instance of 'int' *** EXIT code 4242 FAIL: g++.dg/cpp0x/lambda/lambda-eh2.C execution test
[Bug bootstrap/49247] New: libiberty configure assumes newlib does not supply psignal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49247 Summary: libiberty configure assumes newlib does not supply psignal Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org A build of GCC mainline for arm-none-eabi using mainline newlib fails with: /scratch/janisjo/arm-eabi-fsf/src/gcc-mainline/libiberty/strsignal.c:554:1: error: conflicting types for 'psignal' /scratch/janisjo/arm-eabi-fsf/install/arm-none-eabi/include/signal.h:27:6: note: previous declaration of 'psignal' was here where the installed version comes from newlib. The libiberty version has an argument with char * and the newlib version uses const char * for that argument. The newlib version of psignal was added on 2011-05-04. The libiberty version of psignal is not compiled if HAVE_PSIGNAL is defined, but when building against newlib it is never defined. libiberty/configure.ac says: # If we are being configured for newlib, we know which functions # newlib provide and which ones we will be expected to provide. and # Of the functions in $checkfuncs, newlib only has strerror. This is no longer true, as the latest newlib now has psignal as well. It could also be the case that later versions of newlib will have other funtions in $checkfuncs.
[Bug testsuite/49175] vect/pr48172.c execution failure for ARM GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49175
--- Comment #3 from Janis Johnson janis at gcc dot gnu.org 2011-05-31
22:43:42 UTC ---
Usually the vect tests only require effective targets like vect_int if they are
checking that particular optimizations took place. There are no such checks in
this test.
The vector tests use neon options if check_effective_target_arm_neon_hw (from
lib/target-supports.exp) returns true. The test the proc executes is:
int
main (void)
{
long long a = 0, b = 1;
asm (vorr %P0, %P1, %P2
: =w (a)
: 0 (a), w (b));
return (a != 1);
}
compiled with neon options. That test apparently passes, but there's a neon
instruction generated for the test that fails. Should the test used for
arm_neon_hw be different?
[Bug tree-optimization/49175] New: vect/pr48172.c execution failure for ARM GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49175 Summary: vect/pr48172.c execution failure for ARM GNU/Linux Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Test gcc.dg/vect/pr48172.c fails at execution for arm-none-linux-gnueabi with Illegal Instruction, with the test run on QEMU for -march=armv4t. The test also fails execution for armv5tel-brewer-linux-gnueabi, a native configuration: http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg02524.html. The test was added on 2011-05-12, but the test program also fails with GCC 4.6 and 4.5.
[Bug target/49180] New: pr45070.c fails for -Os -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49180 Summary: pr45070.c fails for -Os -mthumb Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Test gcc.c-torture/execute/pr45070.c has failed execution for -Os -mthumb since it was added. The accompanying fix was for a problem with -Os, which was fixed for some ARM targets but not for thumb.
[Bug c++/46003] cond5.C fails for ARM EABI tests.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46003 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||aoliva at gcc dot gnu.org, ||janis at gcc dot gnu.org --- Comment #4 from Janis Johnson janis at gcc dot gnu.org 2011-05-26 01:19:47 UTC --- Test g++.dg/template/cond5.C started failing for arm-none-linux-gnueabi with this patch: r132158 | aoliva | 2008-02-06 20:31:43 + (Wed, 06 Feb 2008) | 10 lines gcc/cp/ChangeLog: PR c++/35056 * tree.c: Include tree-flow.h. (build_target_expr): Check type compatibility. * Make-lang.in (cp/tree.o): Depend on $(TREE_FLOW_H). * call.c (convert_like_real): Convert bitfield to expected type. gcc/testsuite/ChangeLog: PR c++/35056 * g++.dg/conversion/bitfield8.C: New.
[Bug tree-optimization/49135] ICE in gcc.c-torture/execute/920302-1.c on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49135 --- Comment #3 from Janis Johnson janis at gcc dot gnu.org 2011-05-24 16:07:25 UTC --- With sources updated yesterday the ICE is at line 11950. Configured with: /scratch/janisjo/arm-linux-fsf/src/gcc-mainline/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --enable-shared --enable-lto --enable-symvers=gnu --enable-__cxa_atexit --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --disable-libgomp --enable-poison-system-directories --with-gmp= --with-mpfr= --with-mpc= --with-ppl= --with-cloog= --with-libelf= --with-build-time-tools= --with-build-sysroot=
[Bug c++/49134] New: ICE in g++.dg/cpp0x/constexpr tests for arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49134 Summary: ICE in g++.dg/cpp0x/constexpr tests for arm Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org On arm-none-linux-gnueabi, tests constexpr-abi1.C, constexpr-ex4.C, and constexpr-static6.C in g++.dg/cpp0x all get an internal compiler error starting with this patch: r172790 | jason | 2011-04-20 19:39:02 + (Wed, 20 Apr 2011) | 2 lines PR c++/48657 * decl.c (cp_finish_decl): Simplify template handling. Here's the output from constexpr-abi1.C; output for the others is similar: /scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/g++.dg/cpp0x/constexpr-abi1.C:14:28: internal compiler error: in build_target_expr, at cp/tree.c:292 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/49135] New: ICE in gcc.c-torture/execute/920302-1.c on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49135 Summary: ICE in gcc.c-torture/execute/920302-1.c on arm Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Test gcc.c-torture/execute/920302-1.c gets an internal compiler error on arm-none-linux-gnueabi, which began with this patch: r172954 | rguenth | 2011-04-26 09:21:44 + (Tue, 26 Apr 2011) | 12 lines 2011-04-26 Richard Guenther rguent...@suse.de PR middle-end/48694 * tree.h (OEP_CONSTANT_ADDRESS_OF): New operand_equal_flag. * fold-const.c (operand_equal_p): For TREE_CONSTANT ADDR_EXPRs compare the operands with OEP_CONSTANT_ADDRESS_OF. Treat trees with TREE_SIDE_EFFECTS equal when OEP_CONSTANT_ADDRESS_OF is set. * gcc.dg/torture/pr48694-1.c: New testcase. * gcc.dg/torture/pr48694-2.c: Likewise Here's the compiler output: /scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/920302-1.c: In function 'execute': /scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/920302-1.c:27:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:12107 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/47404] gcc.dg/pr46909.c FAILs on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47404 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #2 from Janis Johnson janis at gcc dot gnu.org 2011-02-17 23:22:51 UTC --- This test has failed on all mips, m68k, and powerpc* targets since it was added by: r167800 | jakub | 2010-12-14 06:09:59 -0800 (Tue, 14 Dec 2010) | 15 lines PR tree-optimization/46909 * gimple-fold.c (and_var_with_comparison_1): Save partial result even in the is_and case, if both partial results are the same, return it. (or_var_with_comparison_1): Use is_or predicate instead of innercode == TRUTH_OR_EXPR test. Save partial result even in the is_or case, if both partial results are the same, return it. In the !is_or case when both partial results are the same, return the partial result instead of boolean_true_node. * gcc.c-torture/execute/pr46909-1.c: New test. * gcc.c-torture/execute/pr46909-2.c: New test. * gcc.dg/pr46909.c: New test.
[Bug c++/46862] ICE on std::decimal::decimal32 without any fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46862 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.15 04:00:43 Ever Confirmed|0 |1 --- Comment #5 from Janis Johnson janis at gcc dot gnu.org 2010-12-15 04:00:43 UTC --- I'm working on a fix.
[Bug c++/46862] ICE on std::decimal::decimal32 without any fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46862
--- Comment #2 from Janis Johnson janis at gcc dot gnu.org 2010-12-09
18:42:13 UTC ---
TYPE_TRANSPARENT_AGGR is set in begin_class_definition in semantics.c for the
classes std::decimal::decimal{32|64|128}. It assumes that they are defined as
in the GNU Standard C++ Library. That code should probably ICE with a good
message if there is no first field or if the first field doesn't have an
expected type. If that sounds appropriate I can write a patch.
The C++ compiler would have to know details of other implementations of the
decimal classes in order to pass them as the underlying scalar types.
[Bug c++/46862] ICE on std::decimal::decimal32 without any fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46862 --- Comment #4 from Janis Johnson janis at gcc dot gnu.org 2010-12-09 18:50:13 UTC --- This doesn't have anything to do with libdecnumber, it's about how std::decimal::decimalxx are defined in libstdc++. Instead of an ICE with a nice message it would be more appropriate to issue a warning (error?) that GCC can't pass the class the same as the associated scalar type as required by the ABI, and don't set TYPE_TRANSPARENT_AGGR.
[Bug c++/2288] Variable declared in for-loop-header is in wrong scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2288 --- Comment #15 from Janis Johnson janis at gcc dot gnu.org 2010-10-27 17:38:36 UTC --- Peter, I don't know what address you should use for me; ask on #gcc if you should use the IBM one, otherwise it's janis.marie.john...@gmail.com.
