[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #52 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Harald van Dijk from comment #51)
Note that a consequence of this is that a function declaration that uses a
typedef may not be compatible with the typedef (I think):
extern C { void f(); }
typedef void t();
t f, *g = f; // valid redeclaration of f, invalid initialisation of g
Fun!
extern C t f; // invalid redeclaration of f
I am not 100% sure about that one.
Linkage conflicts with built-in declarations of functions are also a bit of
a problem:
Yes, as I said in comment #38 and comment #39, giving builtin functions the
right linkage is a big missing part of the patch.
implementing this as described makes GCC fail to compile,
At least in the version of the patch that is attached to the PR, gcc tries to
accept almost anything except in some pedantic mode. The goal is to avoid
breaking every code on earth, or the patch has no chance of ever being
accepted.
(I may well continue working on this, but if I do, I will only do so
occasionally and will likely not be able to send anything meaningful or
useful for a long time.)
Good luck!
[Bug libgcc/60464] [arm] ARM -mthumb version of libgcc contains ARM (non-thumb) code; not safe for thumb-only architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60464 --- Comment #7 from Jeremy Cooper jeremygccb at baymoo dot org --- I have managed to resolve the problem by doing two things. However, one of them is still distasteful (editing the GCC 4.8.2 source). 1. Edited gcc/config/arm/t-arm-elf, uncommenting the following lines: MULTILIB_OPTIONS += march=armv7 MULTILIB_DIRNAMES += thumb2 MULTILIB_EXCEPTIONS += march=armv7* marm/*march=armv7* MULTILIB_MATCHES += march?armv7=march?armv7-a MULTILIB_MATCHES += march?armv7=march?armv7-r MULTILIB_MATCHES += march?armv7=march?armv7-m MULTILIB_MATCHES += march?armv7=mcpu?cortex-a8 MULTILIB_MATCHES += march?armv7=mcpu?cortex-r4 MULTILIB_MATCHES += march?armv7=mcpu?cortex-m3 2. configure --target=arm-none-eabi --enable-languages=c --disable-libssp --disable-libstdcxx Is there a reason these were commented out? Is the armv7 multilib unstable?
[Bug target/58271] ICE in gcc for a MIPS target during compilation with -mpaired-single -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58271 --- Comment #2 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Sat Mar 8 09:27:23 2014 New Revision: 208425 URL: http://gcc.gnu.org/viewcvs?rev=208425root=gccview=rev Log: gcc/ PR target/58271 * config/mips/mips.c (mips_option_override): Promote -mpaired-single warning to an error. Disable TARGET_PAIRED_SINGLE and TARGET_MIPS3D if they can't be used. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c
[Bug c++/60393] [c++1y] ICE with with invalid functions with auto parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60393 --- Comment #1 from Adam Butcher abutcher at gcc dot gnu.org --- Author: abutcher Date: Sat Mar 8 09:33:03 2014 New Revision: 208426 URL: http://gcc.gnu.org/viewcvs?rev=208426root=gccview=rev Log: Fix PR c++/60393 PR c++/60393 * parser.c (cp_parser_parameter_declaration_clause): Move generic function template unwinding on error into a more general location, ... (cp_parser_skip_to_end_of_statement): ... here. PR c++/60393 * g++.dg/cpp1y/pr60393.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr60393.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60033] [c++1y] ICE in retrieve_specialization while compiling recursive generic lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60033 --- Comment #8 from Adam Butcher abutcher at gcc dot gnu.org --- Author: abutcher Date: Sat Mar 8 09:33:12 2014 New Revision: 208427 URL: http://gcc.gnu.org/viewcvs?rev=208427root=gccview=rev Log: Fix PR c++/60033 PR c++/60033 * pt.c (tsubst_copy): When retrieving a capture pack from a generic lambda, remove the lambda's own template argument list prior to fetching the specialization. PR c++/60033 * g++.dg/cpp1y/pr60033.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr60033.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60033] [c++1y] ICE in retrieve_specialization while compiling recursive generic lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60033 Adam Butcher abutcher at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |abutcher at gcc dot gnu.org Target Milestone|--- |4.9.0 --- Comment #9 from Adam Butcher abutcher at gcc dot gnu.org --- Fixed in 4.9.
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #17 from rguenther at suse dot de rguenther at suse dot de --- On 3/7/14 10:57 PM, hjl.tools at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #14 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Richard Biener from comment #13) Huh, adding a pre-header should _never_ do sth like that. Can you produce a small testcase that exhibits these kind of changes with adding/removing a preheader? I don't have a small testcase and it only shows up with -mx32. Here is what I see. The diffs in 064t.copyprop3 are diff -up good/gromacs.x.064t.copyprop3 bad/gromacs.x.064t.copyprop3 --- good/gromacs.x.064t.copyprop32014-03-06 13:14:22.897298915 -0800 +++ bad/gromacs.x.064t.copyprop32014-03-06 13:22:00.221999369 -0800 @@ -22774,6 +22774,7 @@ inl3300 (int restrict nri, int[0:] * r goto bb 8; bb 3: + n_213 = 1; bb 4: # n_8 = PHI 1(3), n_218(7) n_213 is unused. There are many diffs in SSA_NAME_VERSION in 066t.vrp1. Diffs in 082t.reassoc1 are diff -up good/gromacs.x.082t.reassoc1 bad/gromacs.x.082t.reassoc1 --- good/gromacs.x.082t.reassoc12014-03-06 13:14:22.948297990 -0800 +++ bad/gromacs.x.082t.reassoc12014-03-06 13:22:00.273998425 -0800 @@ -24250,11 +24250,11 @@ inl3300 (int restrict nri, int[0:] * r float _201; float _202; int _206; + float _208; float _210; float _211; float _215; float _216; - float _242; bb 2: _19 = *nri_18(D); @@ -24403,8 +24403,8 @@ inl3300 (int restrict nri, int[0:] * r ff_152 = _155 + fp_147; vnb12_153 = vv_149 * c12_116; fijr_154 = ff_152 * c12_116; - _242 = vnb12_153 + vnb6_134; - vnbtot_156 = _242 + vnbtot_11; + _208 = vnb12_153 + vnb6_134; + vnbtot_156 = _208 + vnbtot_11; _157 = fijd_135 + fijc_109; _158 = _157 + fijr_154; _159 = ((_158)); When it gets to 089t.sincos, diffs are diff -up good/gromacs.x.089t.sincos bad/gromacs.x.089t.sincos --- good/gromacs.x.089t.sincos2014-03-06 13:14:22.967297646 -0800 +++ bad/gromacs.x.089t.sincos2014-03-06 13:22:00.291998098 -0800 @@ -24252,14 +24252,14 @@ inl3300 (int restrict nri, int[0:] * r float _201; float _202; int _206; + float _208; float _210; float _211; + float powmult_213; float _215; float _216; - float powmult_238; - float powmult_240; - float powmult_241; - float _242; + float powmult_243; + float powmult_244; powmult_xxx are created by make_temp_ssa_name (type, NULL, powmult) in tree-ssa-math-opts.c for rsq11 = dx11*dx11+dy11*dy11+dz11*dz11; Different powmult_xxx have nothing to do with each others. The orders of powmult SSA_NAME_VERSION are different. As the result, sort_by_operand_rank sorts them differently and diffs in 125t.reassoc2 are powmult_80 = dx11_70 * dx11_70; - powmult_241 = dy11_71 * dy11_71; - powmult_240 = dz11_72 * dz11_72; - _699 = powmult_240 + powmult_80; - rsq11_77 = _699 + powmult_241; + powmult_213 = dy11_71 * dy11_71; + _75 = powmult_213 + powmult_80; + powmult_244 = dz11_72 * dz11_72; + rsq11_77 = _75 + powmult_244; This is rsq11 = dx11*dx11+dz11*dz11+dy11*dy11; vs rsq11 = dx11*dx11+dy11*dy11+dz11*dz11; For FP operations, they may generate slightly different results. It shows the reassoc pass is unstable, depending on FREE_SSANAMES when make_temp_ssa_name is called. The question is why that all is dependent on whether we add/remove preheaders. That shouldn't create any new SSA names or remove existing ones. Yes, maybe sort_by_operand_rank shouldn't sort by SSA_NAME_VERSION but by existing gimple_uid of the definition stmt (so try to preserve stmt order). But that's a completely unrelated thing.
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #15 from linzj manjian2006 at gmail dot com ---
dir = merge_dir (dir, old_insns_match_p (0, i1, i2));
if (dir == dir_none || (!dir_p dir != dir_both))
break;
{
print_rtl_single (stdout, i1);
print_rtl_single (stdout, i2);
printf (dir = %d\n,dir);
}
outputs:
(insn 14 13 53 3 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) 1.cpp:14 241 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil
(insn 38 55 39 4 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) 241 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil
dir = 1
That's exactly what should not be merged.
[Bug fortran/60462] get_command returns more than it should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60462 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-03-08 CC||burnus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- Change status to WAITING. At least the following information is required: - Operating system/Target - GCC version, e.g. gfortran -v - An example program Does it work with the code Steve posted in comment 1?
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #16 from linzj manjian2006 at gmail dot com ---
I have dodged this bug by the following patch:
diff --git a/gcc/cfgcleanup.c b/gcc/cfgcleanup.c
index 77196ee..d7c2b1e 100644
--- a/gcc/cfgcleanup.c
+++ b/gcc/cfgcleanup.c
@@ -1106,20 +1106,7 @@ old_insns_match_p (int mode ATTRIBUTE_UNUSED, rtx i1,
rtx i2)
/* ??? Do not allow cross-jumping between different stack levels. */
p1 = find_reg_note (i1, REG_ARGS_SIZE, NULL);
p2 = find_reg_note (i2, REG_ARGS_SIZE, NULL);
- if (p1 p2)
-{
- p1 = XEXP (p1, 0);
- p2 = XEXP (p2, 0);
- if (!rtx_equal_p (p1, p2))
-return dir_none;
-
- /* ??? Worse, this adjustment had better be constant lest we
- have differing incoming stack levels. */
- if (!frame_pointer_needed
- find_args_size_adjust (i1) == HOST_WIDE_INT_MIN)
-return dir_none;
-}
- else if (p1 || p2)
+ if (p1 || p2)
return dir_none;
p1 = PATTERN (i1);
I don't expect this patch used formally though.It's just a dodge.
[Bug fortran/60447] Empty .s file created when using -E flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-08 CC||burnus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org --- gcc/fortran/options.c's gfc_post_options contains: /* FIXME: return gfc_cpp_preprocess_only (); The return value of this function indicates whether the backend needs to be initialized. On -E, we don't need the backend. However, if we return 'true' here, an ICE occurs. Initializing the backend doesn't hurt much, hence, for now we can live with it as is. */ return false; * * * If one returns true, it indeed fails with a segfault. * * * For C, its LANG_HOOKS_INIT (= c_objc_common_init) has: if (c_common_init () == false) return false; which returns false for flag_preprocess_only. I think, we have to do something similar for gfortran's LANG_HOOKS_INIT (= gfc_init).
[Bug c++/60393] [c++1y] ICE with with invalid functions with auto parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60393 Adam Butcher abutcher at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |abutcher at gcc dot gnu.org Target Milestone|--- |4.9.0 --- Comment #2 from Adam Butcher abutcher at gcc dot gnu.org --- Fixed in 4.9.
[Bug other/60465] New: Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
Bug ID: 60465
Summary: Compiling glibc-2.17,2.18 with gcc-4.8.2 and
binutils-2.23.2,2.24 results in segfaults in _start /
elf_get_dynamic_info
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: devurandom at gmx dot net
Created attachment 32309
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32309action=edit
backtrace (glibc-2.18,binutils-2.24,gcc-4.8.2)
I tried to build glibc-2.17 and 2.18 with binutils-2.23.2 or 2.24 and
gcc-4.8.2, but always run into the same segfault when loading programs with the
new runtime linker.
Please find a backtrace for the glibc-2.18, binutils-2.24, gcc-4.8.2
combination attached.
It crashes in exactly the same way when running without --library-path and when
running with ../usr/bin/locale (from glibc-2.18) or /bin/date as argument.
Since glibc-2.17 compiled fine with gcc-4.7.3, I assume that gcc-4.8.2 is to
blame.
The context of the crash is (according to glibc-2.18/elf/get-dynamic-info.h):
elf_get_dynamic_info (struct link_map *l, ElfW(Dyn) *temp) {
ElfW(Dyn) **info;
info = l-l_info;
info[DT_ADDRTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM + DT_VERSIONTAGNUM
+ DT_EXTRANUM + DT_VALNUM] = dyn;
}
GDB reports this function being called as:
elf_get_dynamic_info (temp=0x0, l=0x200800051458 _rtld_local+2456)
What I find to be suspicious is the changed order of parameters.
I would like to check this with valgrind, too, but it is not available on ia64
(i.e. anything but x86, ppc and arm).
See-Also: https://bugs.gentoo.org/show_bug.cgi?id=503838
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #1 from devurandom at gmx dot net --- Created attachment 32310 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32310action=edit emerge --info
[Bug rtl-optimization/60466] New: Support for HARD_REGNO_NREGS_HAS_PADDING and HARD_REGNO_NREGS_WITH_PADDING broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60466
Bug ID: 60466
Summary: Support for HARD_REGNO_NREGS_HAS_PADDING and
HARD_REGNO_NREGS_WITH_PADDING broken
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
It looks like HARD_REGNO_NREGS_HAS_PADDING and HARD_REGNO_NREGS_WITH_PADDING
no longer work correctly, possibly since subreg_get_info was introduced.
I doubt anyone cares since it's only used for long double on -m32 with
-m128bit-long-double, but just recording it anyway.
Test case:
void foo (void)
{
_Complex long double x;
asm volatile ( : =r (x));
asm volatile ( :: r (__imag__ x), r (__real__ x));
}
When compiled on x86_64-linux-gnu with -m32 -m128bit-long-double -O2
it fails the second of these asserts in subreg_get_info:
/* This should always pass, otherwise we don't know how to verify
the constraint. These conditions may be relaxed but
subreg_regno_offset would need to be redesigned. */
gcc_assert ((GET_MODE_SIZE (xmode) % GET_MODE_SIZE (ymode)) == 0);
gcc_assert ((nregs_xmode % nregs_ymode) == 0);
nregs_xmode is set to the number of registers that there would be if
no padding were present:
nregs_xmode = HARD_REGNO_NREGS_WITH_PADDING (xregno, xmode);
But nregs_ymode is always set to the real number (without padding):
nregs_ymode = hard_regno_nregs[xregno][ymode];
nregs_xmode is used here:
offset_adj -= subreg_lowpart_offset (ymode,
mode_for_size (GET_MODE_BITSIZE (xmode) / nregs_xmode,
MODE_INT, 0));
where using the padded value looks correct. The division will give
a 16-byte mode, matching ymode's size, and the lowpart offset will be 0.
But later we have:
mode_multiple = GET_MODE_SIZE (xmode) / GET_MODE_SIZE (ymode);
...
nregs_multiple = nregs_xmode / nregs_ymode;
...
info-offset = (y_offset / (mode_multiple / nregs_multiple)) * nregs_ymode;
where it doesn't look correct to mix padded and unpadded register counts.
[Bug fortran/60450] [4.7/4.8 Regression] ICE with SHAPE intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60450 --- Comment #7 from janus at gcc dot gnu.org --- Author: janus Date: Sat Mar 8 13:59:00 2014 New Revision: 208430 URL: http://gcc.gnu.org/viewcvs?rev=208430root=gccview=rev Log: 2014-03-08 Janus Weil ja...@gcc.gnu.org PR fortran/60450 * simplify.c (gfc_simplify_shape): Only clear shape if it was really created successfully. 2014-03-08 Janus Weil ja...@gcc.gnu.org PR fortran/60450 * gfortran.dg/shape_8.f90: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/shape_8.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/simplify.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/60450] [4.7/4.8 Regression] ICE with SHAPE intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60450 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to kargl from comment #6) Patch is OK with a testcase. Thanks, committed to the 4.8 branch as r208430. Will backport to 4.7 soon.
[Bug fortran/60462] get_command returns more than it should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60462 Fred Krogh fkrogh#gcc at mathalacarte dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- My apologies for a very bad bug report. I was running in the debugger, and started the run with run ./tapt -u ./mps afiro I should have started it with run -u ./mps afiro Doing things the correct way still puts in the the full path for the command, but I don't think there is anything here that should be called a bug. Sorry.
[Bug plugins/41757] Add PLUGIN_FINISH_DECL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41757 devurandom at gmx dot net changed: What|Removed |Added CC||devurandom at gmx dot net --- Comment #6 from devurandom at gmx dot net --- (In reply to PaX Team from comment #5) this feature seems to have been implemented already in gcc 4.7.x, can it be backported to 4.5.x and 4.6.x perhaps? I would like to see that happen, too. E.g. gcc-lua-cdecl and Gentoo's hardened-sources would benefit from this.
[Bug fortran/60447] Empty .s file created when using -E flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Sat Mar 8 18:53:18 2014 New Revision: 208431 URL: http://gcc.gnu.org/viewcvs?rev=208431root=gccview=rev Log: 2014-03-08 Tobias Burnus bur...@net-b.de PR fortran/60447 * f95-lang.c (gfc_init): Return false when only preprocessing. * options.c (gfc_post_options): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/options.c
[Bug fortran/60447] Empty .s file created when using -E flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org --- FIXED on the 4.9 trunk. Thanks for the report!
[Bug middle-end/60467] New: ICE with -fcilkplus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60467
Bug ID: 60467
Summary: ICE with -fcilkplus
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: bviyer at gcc dot gnu.org
The following code ICEs with -fcilkplus:
void f(void) { }
int main() {
_Cilk_spawn(f);
return 0;
}
foo.c: In function 'main':
foo.c:4:1: internal compiler error: in tree_block, at tree.c:11241
_Cilk_spawn(f);
^
0xbeb577 tree_block(tree_node*)
../../gcc/tree.c:11241
0x61fbde create_cilk_wrapper
../../gcc/c-family/cilk.c:718
0x61fbde gimplify_cilk_spawn(tree_node**)
../../gcc/c-family/cilk.c:756
[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60148 --- Comment #13 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Only documentation remains for this patch. Need to document gfortran extended behavior for default behavior when writing to name lists whne no DELIM= has been specified. gfortran defaults to DELIM=quotes to assure the namelist can be read back in.
[Bug fortran/45143] [F2008,corrig1] Endless loop with unlimited edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45143 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Closing, no time for original plans.
[Bug libfortran/60468] New: ./fpu-target.h:93:3: error: unknown type name 'choke'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60468 Bug ID: 60468 Summary: ./fpu-target.h:93:3: error: unknown type name 'choke' Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa1.1-hp-hpux10.20 Target: hppa1.1-hp-hpux10.20 Build: hppa1.1-hp-hpux10.20 Build of libgfortran fails here: libtool: compile: /xxx/gnu/gcc/objdir/./gcc/xgcc -B/xxx/gnu/gcc/objdir/./gcc/ - B/opt/gnu/gcc/gcc-4.9/hppa1.1-hp-hpux10.20/bin/ -B/opt/gnu/gcc/gcc-4.9/hppa1.1-h p-hpux10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.9/hppa1.1-hp-hpux10.20/include -isystem /opt/gnu/gcc/gcc-4.9/hppa1.1-hp-hpux10.20/sys-include -DHAVE_CONFIG_H -I. - I../../../gcc/libgfortran -iquote../../../gcc/libgfortran/io -I../../../gcc/libg fortran/../gcc -I../../../gcc/libgfortran/../gcc/config -I../../../gcc/libgfortr an/../libquadmath -I../.././gcc -I../../../gcc/libgfortran/../libgcc -I../libgcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definitio n -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -MT fpu.lo -MD -MP -MF .deps /fpu.Tpo -c ../../../gcc/libgfortran/runtime/fpu.c -fPIC -DPIC -o .libs/fpu.o In file included from ../../../gcc/libgfortran/runtime/fpu.c:29:0: ./fpu-target.h: In function 'get_fpu_except_flags': ./fpu-target.h:93:3: error: unknown type name 'choke' choke me ^ Problem is sysv version of fpu-target.h has been selected because configure found fpsetmask but it didn't find fp_except or fp_rnd because they are defined in math.h, not ieeefp.h. The fp routines are also declared in math.h. On hpux11, this doesn't happen because fpsetmask is gone. As a result, generic support is selected. This is probably not optimal but that's another issue.
[Bug middle-end/60469] New: simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469
Bug ID: 60469
Summary: simple cilk plus program ICEs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
gcc version 4.9.0 20140209 (experimental) (GCC)
gcc -fcilkplus test.c
cilk.c: In function 'main':
tcilk.c:14:5: internal compiler error: Segmentation fault
int main()
^
0x8a5df7 crash_signal
../../gcc/gcc/toplev.c:337
0x9048e3 get_frame_type
../../gcc/gcc/tree-nested.c:234
0x9048e3 get_chain_decl
../../gcc/gcc/tree-nested.c:342
0x9056bc get_chain_decl
../../gcc/gcc/tree-nested.c:851
0x9056bc get_nonlocal_debug_decl
../../gcc/gcc/tree-nested.c:856
0x905932 convert_nonlocal_reference_op
../../gcc/gcc/tree-nested.c:934
0xa61f7c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, pointer_set_t*, tree_node* (*)(tree_node**, int*, tree_node*
(*)(tree_node**, int*, void*), void*, pointer_set_t*))
../../gcc/gcc/tree.c:10920
0x725263 walk_gimple_op(gimple_statement_base*, tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:221
0x725476 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:535
0x725629 walk_gimple_seq_mod(gimple_statement_base**, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:577
0x725629 walk_gimple_seq_mod(gimple_statement_base**, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:58
0x725551 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:577
0x725629 walk_gimple_seq_mod(gimple_statement_base**, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:58
0x725521 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:545
0x725629 walk_gimple_seq_mod(gimple_statement_base**, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:58
0x904127 walk_body
../../gcc/gcc/tree-nested.c:603
0x9060ee walk_function
../../gcc/gcc/tree-nested.c:614
0x9060ee walk_all_functions
../../gcc/gcc/tree-nested.c:679
0x90739f lower_nested_functions(tree_node*)
../../gcc/gcc/tree-nested.c:2724
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.
test program:
void foo() { asm( ::: memory); }
#define ALEN 1024
void f(int *a, int *b, int *c)
{
int i;
#pragma simd
for (i = 0; i ALEN; i++)
a[i] = b[i] * c[i];
}
int main()
{
int a[ALEN], b[ALEN], c[ALEN];
b[:] = 100;
c[0:ALEN:2] = 99;
c[1:ALEN:2] = 101;
f(a, b, c);
asm( ::: memory); /* Make sure a,b,c, are not optimized away */
_Cilk_spawn foo();
_Cilk_spawn foo();
_Cilk_sync;
return 0;
}
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #29 from Manfred Schwarb manfred99 at gmx dot ch --- The regression flag was re-added by Tobias in comment 23 due to a regression in the testcase of comment 21: !234567 character buffer*10 integer i,j DO j=1, write(buffer,'(i4)') j write(*,*) buffer(1:4) read(buffer,'(i10)') i write(*,*) i ENDDO end Here are the profiles of gfortran 4.6: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls Ts/call Ts/call name 97.45 3.06 3.06 _gfortrani_read_decimal 1.59 3.11 0.05 memset 0.64 3.13 0.02 __write_nocancel 0.32 3.14 0.01 format_lex 0.00 3.14 0.001 0.00 0.00 main and gfortran trunk: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls Ts/call Ts/call name 59.96 2.71 2.71 read_utf8 38.72 4.46 1.75 _gfortrani_read_decimal 0.66 4.49 0.03 memset 0.22 4.50 0.01 fflush 0.22 4.51 0.01 formatted_transfer 0.22 4.52 0.01 malloc_consolidate 0.00 4.52 0.001 0.00 0.00 main so the difference is obvious, the utf8 treatment makes the difference. Is there a possibility to speed up reading the trivial cases? 99.99% of fortran input will be ASCII, I guess... And again, the magical approach is to add LEN_TRIM to avoid reading 10 space characters and interpreting them as utf8. So if something like Thomas' patch could be applied also for formatted reads, this would speed up things dramatically as well.
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
Richard Henderson rth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #17 from Richard Henderson rth at gcc dot gnu.org ---
The REG_ARGS_SIZE notes are a red-herring.
The bug is that
(insn:TI 66 61 31 4 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg:SI 0 ax [orig:85 D.1918 ] [85])) z.c:21 66 {*pushsi2}
(nil))
as noted above created by split2, is not processed by the dwarf2cfi
code at all, and so its stack adjustment is lost entirely. Thus when
we remove its adjustment later, we wind up with the wrong answer and
that leads directly to the abort.
[Bug bootstrap/55807] Support musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55807 David Heidelberger (okias) david.heidelberger at ixit dot cz changed: What|Removed |Added CC||david.heidelberger at ixit dot cz --- Comment #12 from David Heidelberger (okias) david.heidelberger at ixit dot cz --- Hello, how it look? Also, there are two bugs for musl support #55807 (this) and #58446 . Anyway, musl is ready to use, so if we could avoid patching gcc manually, it would be great. Any information appreciated :)
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 David Heidelberger (okias) david.heidelberger at ixit dot cz changed: What|Removed |Added CC||david.heidelberger at ixit dot cz --- Comment #15 from David Heidelberger (okias) david.heidelberger at ixit dot cz --- in which state is musl patches integration? btw. here is also old bug #55807
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #18 from linzj manjian2006 at gmail dot com ---
(In reply to Richard Henderson from comment #17)
The REG_ARGS_SIZE notes are a red-herring.
The bug is that
(insn:TI 66 61 31 4 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg:SI 0 ax [orig:85 D.1918 ] [85])) z.c:21 66 {*pushsi2}
(nil))
as noted above created by split2, is not processed by the dwarf2cfi
code at all, and so its stack adjustment is lost entirely. Thus when
we remove its adjustment later, we wind up with the wrong answer and
that leads directly to the abort.
Hi rth,
you are right,I have been distracted.And I have tried to fix this in i386.c
ix86_force_to_memory ix86_free_from_memory,but fail.
The split is defined as follow:
(define_split
[(set (match_operand 0 register_operand)
(match_operator 3 binary_fp_operator
[(float (match_operand:SWI24 1 register_operand))
(match_operand 2 register_operand)]))]
reload_completed
X87_FLOAT_MODE_P (GET_MODE (operands[0]))
X87_ENABLE_FLOAT (GET_MODE (operands[0]), GET_MODE (operands[1]))
[(const_int 0)]
{
operands[4] = ix86_force_to_memory (GET_MODE (operands[1]), operands[1]);
operands[4] = gen_rtx_FLOAT (GET_MODE (operands[0]), operands[4]);
emit_insn (gen_rtx_SET (VOIDmode, operands[0],
gen_rtx_fmt_ee (GET_CODE (operands[3]),
GET_MODE (operands[3]),
operands[4],
operands[2])));
ix86_free_from_memory (GET_MODE (operands[1]));
DONE;
})
in i386.md:13640
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #30 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- The read: read(buffer,'(i10)') i is an entirely different code path then the example in Comment #22 because of the format specifier. This is handled very differently from a list directed read. In read_block_form we take the users intent of i10 very literally. I also see how we can do a trim on it. I will work on this as a separate patch, keeping in mind this test case is well contrived. :)
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #31 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Mar 9 03:17:16 2014 New Revision: 208438 URL: http://gcc.gnu.org/viewcvs?rev=208438root=gccview=rev Log: 2014-03-08 Jerry DeLisle jvdeli...@gcc.gnu PR libfortran/38199 * io/list_read.c (next_char): Delete unuseful error checks. (eat_spaces): For character array reading, skip ahead over spaces rather than call next_char multiple times. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438 --- Comment #19 from Richard Henderson rth at gcc dot gnu.org --- Created attachment 32311 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32311action=edit proposed patch Running full tests on this overnight, but it fixes the ICE.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #32 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Created attachment 32312 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32312action=edit New patch for case in comment 21 This is just a preliminary runtime patch. Without: real0m7.519s user0m7.496s sys0m0.000s With patch: real0m1.433s user0m1.424s sys0m0.002s Which is not a bad improvement. I am still looking at what we could do on the front-end.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #33 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Mar 9 05:34:34 2014 New Revision: 208439 URL: http://gcc.gnu.org/viewcvs?rev=208439root=gccview=rev Log: 2014-03-08 Jerry DeLisle jvdeli...@gcc.gnu PR libfortran/38199 * io/list_read.c (next_char): Mark unlikely error checks. (eat_spaces): For character array reading, skip ahead over spaces rather than call next_char multiple times. Modified: trunk/libgfortran/ChangeLog
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438 --- Comment #20 from linzj manjian2006 at gmail dot com --- (In reply to Richard Henderson from comment #19) Created attachment 32311 [details] proposed patch Running full tests on this overnight, but it fixes the ICE. Oh, It never comes to me that both setting the insn frame related adding a argument note.
