[Bug tree-optimization/41089] [4.8/4.9/5/6 Regression] stdarg pass produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|SUSPENDED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #60 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #59) (In reply to vries from comment #58) Given the fix of PR64950, we should be able to remove the workaround committed for this PR. I have started bootstrap/regtest with the following revert: Testresults at [1] show that it is now safe to revert the workaround. [1] https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02422.html
[Bug tree-optimization/64950] postpone expanding va_arg till pass_stdarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950 --- Comment #10 from uros at gcc dot gnu.org --- Author: uros Date: Tue Apr 21 06:29:37 2015 New Revision: 57 URL: https://gcc.gnu.org/viewcvs?rev=57root=gccview=rev Log: PR tree-optimization/64950 Revert: 2010-08-02 Uros Bizjak ubiz...@gmail.com PR target/41089 * config/alpha/alpha.c (alpha_build_builtin_va_list): Mark __offset as volatile. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/alpha.c
[Bug tree-optimization/41089] [4.8/4.9/5/6 Regression] stdarg pass produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089 --- Comment #61 from uros at gcc dot gnu.org --- Author: uros Date: Tue Apr 21 06:29:37 2015 New Revision: 57 URL: https://gcc.gnu.org/viewcvs?rev=57root=gccview=rev Log: PR tree-optimization/64950 Revert: 2010-08-02 Uros Bizjak ubiz...@gmail.com PR target/41089 * config/alpha/alpha.c (alpha_build_builtin_va_list): Mark __offset as volatile. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/alpha.c
[Bug target/41089] [4.8/4.9/5/6 Regression] stdarg pass produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|tree-optimization |target Depends on||64950 Resolution|--- |FIXED Target Milestone|4.8.5 |6.0 --- Comment #62 from Uroš Bizjak ubizjak at gmail dot com --- Fixed for gcc 6, no plan to backport.
[Bug c/63357] Warn for P P and P || P (same expression used multiple times in a condition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- I have an untested patch.
[Bug libfortran/65234] Output descriptor (*(1E15.7)) not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65234 --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Tue Apr 21 18:28:39 2015 New Revision: 76 URL: https://gcc.gnu.org/viewcvs?rev=76root=gccview=rev Log: 2015-04-21 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/65234 * gfortran.dg/fmt_unlimited.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_unlimited.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug libfortran/65234] Output descriptor (*(1E15.7)) not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65234 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Fixed on trunk, Closing
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #42 from Richard Henderson rth at gcc dot gnu.org --- (In reply to Andrew Macleod from comment #39) no, __sync was simply an implementation of psABI back when it was new... I'm not aware of any additions, enhancements or guarantees that were added when it was ported to other arch's. Terminology was much looser 14 years ago :-) That's one of the reasons we want to migrate to __atomic... it is supposedly more precisely defined, whereas __sync had some hand-waving. We're now experiencing some different interpretations of that.Regardless of the documentation, we didn't think we'd be supporting something stronger than SEQ_CST since they were suppose to be equivalent... Exactly right. I don't believe there's anywhere we can look for more definitive semantics than the psABI. And as already explored here, that's not entirely helpful.
[Bug libfortran/65234] Output descriptor (*(1E15.7)) not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65234 --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Tue Apr 21 18:23:20 2015 New Revision: 74 URL: https://gcc.gnu.org/viewcvs?rev=74root=gccview=rev Log: 2015-04-21 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/65234 * io/format.c (parse_format_list): Set the seen_dd flag in all cases where a data descriptor has been seen. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c
[Bug other/65820] escape backslashes in .d file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65820 Paul Robinson paul_robinson at playstation dot sony.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Paul Robinson paul_robinson at playstation dot sony.com --- tl;dr: Never Mind. Somebody experimented with this on FreeBSD, apparently the BSD Make doesn't do backslash-quoting at all, so this request would break dependency files there. And, it seems that while GNU Make will prefer to treat multiple backslashes as escapes, if that doesn't find a matching file, it will fall back to the original filespec-as-written. So as long as you don't mix files with different numbers of backslashes in the same directory, it should actually work out. Sigh.
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #13 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- After giving this some consideration and with respect, I have decided to close this as WONtFIX. We have standardized the error messages in runtime/error.c for probably over 10 years now and I think its best to leave it alone.
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-21 CC||vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from vries at gcc dot gnu.org --- Reproduced.
[Bug debug/65821] [4.8/4.9/5/6 regression] incorrect debug line # info for main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-04-21 Target Milestone|--- |4.8.5 Summary|[4.8.2 regression] |[4.8/4.9/5/6 regression] |incorrect debug line # info |incorrect debug line # info |for main|for main Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- What version works correctly? (please provide the testcase as attachment as well)
[Bug tree-optimization/65824] New: [6 Regression] execution failures for stdarg/va-arg testcases for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65824 Bug ID: 65824 Summary: [6 Regression] execution failures for stdarg/va-arg testcases for aarch64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org As mentioned here ( https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01114.html ), there are new failures for aarch64 caused by the introduction of ifn_va_arg: ... FAIL: gcc.c-torture/execute/stdarg-1.c -O0 execution test FAIL: gcc.c-torture/execute/stdarg-1.c -O1 execution test FAIL: gcc.c-torture/execute/stdarg-1.c -O2 execution test FAIL: gcc.c-torture/execute/stdarg-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.c-torture/execute/stdarg-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.c-torture/execute/stdarg-1.c -O3 -fomit-frame-pointer execution test FAIL: gcc.c-torture/execute/stdarg-1.c -O3 -g execution test FAIL: gcc.c-torture/execute/stdarg-1.c -Os execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O0 execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O1 execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O2 execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O3 -fomit-frame-pointer execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O3 -g execution test FAIL: gcc.c-torture/execute/va-arg-11.c -Os execution test ...
[Bug tree-optimization/65823] [6 Regression] ICE in gcc.c-torture/execute/stdarg-2.c -O0/-O1 for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65823 --- Comment #1 from vries at gcc dot gnu.org --- Compiler version: 6.0.0 20150417 (experimental) 222178 (GCC) Platform: armv7l-unknown-linux-gnueabihf configure flags: --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --enable-languages=c,c++,fortran
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org --- What is printed with -Wno-error=narrowing ?
[Bug tree-optimization/65824] [6 Regression] execution failures for stdarg/va-arg testcases for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65824 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Version|5.0 |6.0 Target Milestone|--- |6.0
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 35374 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35374action=edit patch Patch I am testing.
[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649 Nick Clifton nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton nickc at redhat dot com --- Created attachment 35373 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35373action=edit Use %lx/%ld to print long types Hi Guys, Here is a patch to fix this problem. The bug is that in a couple of places the microblaze backend is using %llx to print out the value of a long type. On a 64-bit host this does not matter, but compiling on a 32-bit host the result is extra garbage digits in the output. Cheers Nick
[Bug tree-optimization/65826] mark ifn_va_arg as ECF_LEAF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65826 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-21 Ever confirmed|0 |1
[Bug tree-optimization/65826] New: mark ifn_va_arg as ECF_LEAF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65826 Bug ID: 65826 Summary: mark ifn_va_arg as ECF_LEAF Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org As discussed here ( https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01123.html ): ... You can definitely make it ECF_LEAF too. SNIP Yes to ECF_LEAF ... Patch to be tested: ... diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def index 7e19313..f84e871 100644 --- a/gcc/internal-fn.def +++ b/gcc/internal-fn.def @@ -62,4 +62,4 @@ DEF_INTERNAL_FN (ADD_OVERFLOW, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL) DEF_INTERNAL_FN (SUB_OVERFLOW, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL) DEF_INTERNAL_FN (MUL_OVERFLOW, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL) DEF_INTERNAL_FN (TSAN_FUNC_EXIT, ECF_NOVOPS | ECF_LEAF | ECF_NOTHROW, NULL) -DEF_INTERNAL_FN (VA_ARG, ECF_NOTHROW, NULL) +DEF_INTERNAL_FN (VA_ARG, ECF_LEAF | ECF_NOTHROW, NULL) ...
[Bug sanitizer/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- I remember PR65583, but not anything else in that area.
[Bug tree-optimization/65650] CCP does not propgate copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65650 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Apr 21 12:52:43 2015 New Revision: 67 URL: https://gcc.gnu.org/viewcvs?rev=67root=gccview=rev Log: 2015-04-21 Richard Biener rguent...@suse.de PR tree-optimization/65650 * tree-ssa-ccp.c (valid_lattice_transition): Allow lattice transitions involving copies. (set_lattice_value): Adjust for copy lattice state. (ccp_lattice_meet): Do not merge UNDEFINED and a copy to the copy if that doesn't dominate the merge point. (bit_value_unop): Adjust what we treat as varying mask. (bit_value_binop): Likewise. (bit_value_assume_aligned): Likewise. (evaluate_stmt): When we simplified to a SSA name record a copy instead of dropping to varying. (visit_assignment): Simplify. * gimple-match.h (gimple_simplify): Add another callback. * gimple-fold.c (fold_stmt_1): Adjust caller. (gimple_fold_stmt_to_constant_1): Likewise - pass valueize for the 2nd callback. * gimple-match-head.c (gimple_simplify): Add a callback that is used to valueize the stmt operands and use it that way. * gcc.dg/tree-ssa/ssa-ccp-37.c: New testcase. * gcc.dg/tree-ssa/forwprop-11.c: Adjust. * gcc.dg/tree-ssa/ssa-fre-3.c: Likewise. * gcc.dg/tree-ssa/ssa-fre-4.c: Likewise. * gcc.dg/tree-ssa/ssa-fre-5.c: Likewise. * gcc.dg/tree-ssa/ssa-fre-32.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-37.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/gimple-match-head.c trunk/gcc/gimple-match.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-11.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-32.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-5.c trunk/gcc/tree-ssa-ccp.c
[Bug sanitizer/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- ICE in streamer_get_builtin_tree doesn't ring a bell for me, sorry.
[Bug tree-optimization/65650] CCP does not propgate copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65650 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.0 Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug c/65830] -Wno-shift-count-negative -Wno-shift-count-overflow don't work with const ints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65830 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-21 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Taking.
[Bug c/65830] New: -Wno-shift-count-negative -Wno-shift-count-overflow don't work with const ints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65830
Bug ID: 65830
Summary: -Wno-shift-count-negative -Wno-shift-count-overflow
don't work with const ints
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
When dealing with const ints, the warning can't be suppressed with
-Wno-shift-count-negative -Wno-shift-count-overflow.
A c-c++-common/ test case:
/* PR c/... */
/* { dg-do compile } */
/* { dg-options -O -Wno-shift-count-negative -Wno-shift-count-overflow } */
int
foo (int x)
{
const int a = sizeof (int) * __CHAR_BIT__;
const int b = -7;
int c = 0;
c += x a;/* { dg-bogus left shift count = width of type } */
c += x b;/* { dg-bogus left shift count is negative } */
c += x a;/* { dg-bogus right shift count = width of type } */
c += x b; /* { dg-bogus right shift count is negative } */
return c;
}
[Bug debug/65822] [4.8/4.9/5/6 Regression] Used variant fun names in dwarf info for CTORs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65822 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.5 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I suppose it does do the job.
[Bug tree-optimization/65823] New: [6 Regression] ICE in gcc.c-torture/execute/stdarg-2.c -O0/-O1 for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65823 Bug ID: 65823 Summary: [6 Regression] ICE in gcc.c-torture/execute/stdarg-2.c -O0/-O1 for arm Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Comparing: - https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02096.html (r222178) and - https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02042.html (r222164) shows two new stdarg-2.c failures for arm: ... FAIL: gcc.c-torture/execute/stdarg-2.c -O0 (internal compiler error) FAIL: gcc.c-torture/execute/stdarg-2.c -O0 (test for excess errors) ... According to https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01114.html : ... /projects/.../src/gcc/gcc/testsuite/gcc.c-torture/execute/stdarg-2.c: In function 'f3': /projects/.../src/gcc/gcc/testsuite/gcc.c-torture/execute/stdarg-2.c:61:1: error: incorrect sharing of tree nodes aps[4] # .MEM_5 = VDEF .MEM_11 aps[4] = aps[4]; /projects/.../src/gcc/gcc/testsuite/gcc.c-torture/execute/stdarg-2.c:61:1: internal compiler error: verify_gimple failed 0xae4893 verify_gimple_in_cfg(function*, bool) /projects/.../src/gcc/gcc/tree-cfg.c:5136 0x9e3f2f execute_function_todo /projects/.../src/gcc/gcc/passes.c:1946 0x9e48d3 execute_todo /projects/.../src/gcc/gcc/passes.c:2003 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. ...
[Bug fortran/65825] Cannot change attributes intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65825 --- Comment #2 from Roger Ferrer Ibanez roger.ferrer at bsc dot es --- Well, if so, why are you do you want to declare ubound as intrinsic besides pushing gfortran to its limit? I did not intend to push gfortran anywhere. It actually happened by chance. Kind regards,
[Bug rtl-optimization/65827] New: LRA use smaller reg class than original reg for reload and it spill fail if reg class no hard reg available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65827
Bug ID: 65827
Summary: LRA use smaller reg class than original reg for reload
and it spill fail if reg class no hard reg available
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: npickito at gmail dot com
Created attachment 35375
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35375action=edit
LRA dump
Target: nds32le-elf
Configure option: --target=nds32le-elf --enable-languages=c
--enable-checking=yes
Testcase: gcc.c-torture/execute/pr65427.c
What's happen:
../../src-5.0.0/gcc/testsuite/gcc.c-torture/execute/pr65427.c: In function
‘foo’:
../../src-5.0.0/gcc/testsuite/gcc.c-torture/execute/pr65427.c:17:1: error:
unable to find a register to spill
}
^
../../src-5.0.0/gcc/testsuite/gcc.c-torture/execute/pr65427.c:17:1: error: this
is the insn:
(insn 91 73 221 2 (set (reg/f:SI 227 [143])
(symbol_ref:SI (b) var_decl 0x7f9543aa3360 b))
../../src-5.0.0/gcc/testsuite/gcc.c-torture/execute/pr65427.c:14 28
{*move_addr}
(expr_list:REG_EQUIV (symbol_ref:SI (b) var_decl 0x7f9543aa3360 b)
(nil)))
../../src-5.0.0/gcc/testsuite/gcc.c-torture/execute/pr65427.c:17:1: internal
compiler error: in assign_by_spills, at lra-assigns.c:1428
0xa09f78 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../../src-5.0.0/gcc/rtl-error.c:110
0x92beca assign_by_spills
../../../../src-5.0.0/gcc/lra-assigns.c:1428
0x92c593 lra_assign()
../../../../src-5.0.0/gcc/lra-assigns.c:1603
0x928149 lra(_IO_FILE*)
../../../../src-5.0.0/gcc/lra.c:2365
0x8e8ea9 do_reload
../../../../src-5.0.0/gcc/ira.c:5418
0x8e8ea9 execute
../../../../src-5.0.0/gcc/ira.c:5589
How to reproduce:
nds32le-elf-gcc testsuite/gcc.c-torture/execute/pr65427.c -O2
What's happen in detail:
(full lra dump in attachment)
...
0 Non input pseudo reload: reject++
alt=0,overall=7,losers=1,rld_nregs=1
0 Non input pseudo reload: reject++
alt=1,overall=7,losers=1,rld_nregs=1
Choosing alt 0 in insn 91: (0) =l (1) i {*move_addr} (sp_off=-224)
Creating newreg=227 from oldreg=143, assigning class LOW_REGS to r227
91: r227:SI=`b'
REG_EQUIV `b'
Inserting insn reload after:
221: r143:SI=r227:SI
...
LOW_REGS = r0-r7
GENERAL_REGS = r0-r31
r227 is create from r143 and it's pick LOW_REGS,
and then LRA can't find any register to spill in LOW_REGS class since all
register in LOW_REGS are used by our movmemqi expander.
However reg_pref[r143].allocnoclass is GENERAL_REGS
and its have available hard. register,
but LRA don't get try for that and give up,
r227 setup it's reg class in:
lra-constraints.c
3844 if (get_reload_reg (type, mode, old, goal_alt[i],
3845 loc != curr_id-operand_loc[i], ,
new_reg)
So I think does LRA should consider the allocno class for original reg,
not just the goal_alt[i] of this point?
Possible solution:
Setup prefclass from goal_alt but set allocnoclass from orig_reg's allocnoclass
if possible
diff --git a/gcc/lra.c b/gcc/lra.c
index f4d7a3c..601aec4 100644
--- a/gcc/lra.c
+++ b/gcc/lra.c
@@ -212,6 +212,7 @@ lra_create_new_reg_with_unique_value (machine_mode md_mode,
rtx original,
enum reg_class rclass, const char *title)
{
machine_mode mode;
+ enum reg_class orig_rclass;
rtx new_reg;
if (original == NULL_RTX || (mode = GET_MODE (original)) == VOIDmode)
@@ -243,7 +244,16 @@ lra_create_new_reg_with_unique_value (machine_mode
md_mode, rtx original,
fprintf (lra_dump_file, \n);
}
expand_reg_data (max_reg_num ());
- setup_reg_classes (REGNO (new_reg), rclass, NO_REGS, rclass);
+
+ if (REG_P (original))
+orig_rclass = reg_allocno_class (REGNO (original));
+ else
+orig_rclass = NO_REGS;
+
+ setup_reg_classes (REGNO (new_reg),
+ rclass,
+ NO_REGS,
+ orig_rclass == NO_REGS ? rclass: orig_rclass);
return new_reg;
}
[Bug tree-optimization/65823] [6 Regression] ICE in gcc.c-torture/execute/stdarg-2.c -O0/-O1 for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65823 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- some unshare_expr missing. But the no-oppiness might point at the wrong-code issue as well.
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #60 from Dominik Vogt vogt at linux dot vnet.ibm.com --- Works on s390x.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 --- Comment #9 from vries at gcc dot gnu.org --- Author: vries Date: Tue Apr 21 08:43:07 2015 New Revision: 59 URL: https://gcc.gnu.org/viewcvs?rev=59root=gccview=rev Log: Mark ifn_va_arg with ECF_NOTHROW 2015-04-21 Tom de Vries t...@codesourcery.com PR tree-optimization/65802 * internal-fn.def (VA_ARG): Add ECF_NOTROW to flags. * g++.dg/pr65802.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr65802.C Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.def trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build CC||tom at codesourcery dot com Target Milestone|--- |6.0 Summary|libiberty/vprintf-support.c |[6 Regression] |:41:1: ICE: in expand_i |libiberty/vprintf-support.c |fn_va_arg_1, at |:41:1: ICE: in expand_i |tree-stdarg.c:1095 |fn_va_arg_1, at ||tree-stdarg.c:1095
[Bug tree-optimization/65823] [6 Regression] ICE in gcc.c-torture/execute/stdarg-2.c -O0/-O1 for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65823 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-21 Ever confirmed|0 |1 --- Comment #3 from vries at gcc dot gnu.org --- I have reproduced this failure.
[Bug tree-optimization/65823] [6 Regression] ICE in gcc.c-torture/execute/stdarg-2.c -O0/-O1 for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65823
--- Comment #5 from vries at gcc dot gnu.org ---
original dump:
{
struct va_list aps[10];
struct va_list aps[10];
__builtin_va_start ((struct ) (struct *) aps[4], i);
x = VA_ARG_EXPR aps[4];
__builtin_va_end ((struct ) (struct *) aps[4]);
}
gimplify dump:
f3 (int i)
{
long intD.5 x.0D.4231;
struct va_listD.4222 apsD.4227[10];
try
{
# USE = anything
# CLB = anything
__builtin_va_startD.1052 (apsD.4227[4], 0);
# USE = anything
# CLB = anything
x.0D.4231 = VA_ARG (apsD.4227[4], 0B);
apsD.4227[4] = apsD.4227[4];
xD.4223 = x.0D.4231;
# USE = anything
# CLB = anything
__builtin_va_endD.1051 (apsD.4227[4]);
}
finally
{
apsD.4227 = {CLOBBER};
}
}
The nop introduced during gimplification is not meant to be there. This patch
gets rid of it:
...
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 0a8ef84..c68bd47 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -4792,7 +4792,7 @@ gimplify_modify_expr (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p,
if (ap != NULL_TREE
TREE_CODE (ap) == ADDR_EXPR
TREE_CODE (ap_copy) == ADDR_EXPR
- TREE_OPERAND (ap, 0) != TREE_OPERAND (ap_copy, 0))
+ !operand_equal_p (TREE_OPERAND (ap, 0), TREE_OPERAND (ap_copy, 0),
0))
gimplify_assign (TREE_OPERAND (ap, 0), TREE_OPERAND (ap_copy, 0), pre_p);
if (want_value)
...
[Bug fortran/65825] New: Cannot change attributes intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65825 Bug ID: 65825 Summary: Cannot change attributes intrinsic Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roger.ferrer at bsc dot es Hi, a problem similar to PR57141 happens with the code below. Fails both with gfortran 4.9.2 and 5.0.1 20150412 (prerelease). Both Intel Fortran 14.0.2 and XL Fortran 15.01 accept this code (both print 3 of course). -- t.f90 MODULE moo IMPLICIT NONE INTEGER(4), PUBLIC :: c(3, 3) !! uncomment the following statement !! as a workaround ! PRIVATE :: ubound DATA c(3, 1:ubound(c, 2)) / 1, 2, 3 / END MODULE moo PROGRAM main USE moo IMPLICIT NONE INTEGER(4) :: x INTRINSIC :: ubound ! gfortran rejects this x = ubound(c, 2) ! should print 3 PRINT *, x END PROGRAM main -- end of t.f90 Leaving the upper bound of the subscript-triplet can be used as a workaround. Another workaround involves explicitly stating that ubound name is private. I assume that the code is OK since in both cases ubound does not change its intrinsic meaning. Kind regards,
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Ok, with this I can reproduce it. Not really suitable to create a testcase though.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from vries at gcc dot gnu.org --- patch with test-case committed, marking resolved fixed.
[Bug fortran/65825] Cannot change attributes intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65825 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-21 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.4 up to trunk (6.0). Moving the line INTRINSIC :: ubound ! gfortran rejects this in MODULE moo works around the problem also. I assume that the code is OK since in both cases ubound does not change its intrinsic meaning. Well, if so, why are you do you want to declare ubound as intrinsic besides pushing gfortran to its limit?
[Bug tree-optimization/65823] [6 Regression] ICE in gcc.c-torture/execute/stdarg-2.c -O0/-O1 for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65823
--- Comment #4 from vries at gcc dot gnu.org ---
Minimal test-case test.c:
...
#include stdarg.h
long x;
void
f3 (int i, ...)
{
va_list aps[10];
va_start (aps[4], i);
x = va_arg (aps[4], long);
va_end (aps[4]);
}
...
or preprocessed:
...
typedef __builtin_va_list __gnuc_va_list;
typedef __gnuc_va_list va_list;
long x;
void
f3 (int i, ...)
{
va_list aps[10];
__builtin_va_start (aps[4], i);
x = __builtin_va_arg(aps[4], long);
__builtin_va_end(aps[4]));
}
...
[Bug preprocessor/65834] New: give error for #if with no expression at the previous location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65834
Bug ID: 65834
Summary: give error for #if with no expression at the previous
location
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Distilled from:
http://www.linuxquestions.org/questions/linux-from-scratch-13/replace-gcc-with-clang-4175491981/#post5108443
extern void foo(void);
#define TEST
int bar(void)
{
#if TEST
foo();
#endif
return 0;
}
Currently:
test.c:6:9: error: #if with no expression
#if TEST
^
Expected something like:
test.c:6:9: error: #if with no expression
#if TEST
^
test.c:2:14: note: in expansion of macro ‘TEST’
I think this could be possible by giving the error at the location of TEST
(which should be the previously encoded source_location) rather that at the
current one.
#define TEST
^
[Bug tree-optimization/65823] [6 Regression] ICE in gcc.c-torture/execute/stdarg-2.c -O0/-O1 for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65823 --- Comment #6 from vries at gcc dot gnu.org --- (In reply to vries from comment #5) The nop introduced during gimplification is not meant to be there. This patch gets rid of it: I've build an arm compiler with the patch, and tested execute.exp=stdarg-2.c. Indeed the failure is gone, and the execution succeeds.
[Bug target/65832] Inefficient vector construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65832
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
typedef int v4si __attribute__((vector_size(16)));
v4si bar (int *i, int *j, int *k, int *l)
{
return (v4si) { *i, *j, *k, *l };
}
looks reasonable (no spills at least, stray move for the return value).
movd(%rsi), %xmm0
movd(%rdi), %xmm3
movd(%rcx), %xmm1
movd(%rdx), %xmm2
punpckldq %xmm0, %xmm3
punpckldq %xmm1, %xmm2
movdqa %xmm3, %xmm0
punpcklqdq %xmm2, %xmm0
With -mavx2 we get
vmovd (%rdx), %xmm2
vmovd (%rdi), %xmm3
vpinsrd $1, (%rcx), %xmm2, %xmm1
vpinsrd $1, (%rsi), %xmm3, %xmm0
vpunpcklqdq %xmm1, %xmm0, %xmm0
[Bug target/65780] [5 Regression] Uninitialized common handling in executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780 --- Comment #48 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Stupachenko Evgeny from comment #47) The patch caused significant regressions (see below) on spec2000 INT benchmarks compiled with options “-fPIE -pie -O2 -ffast-math -mfpmath=sse -m32 -march=corei7-avx” or “-fPIE -pie -O2 -ffast-math -mfpmath=sse -m32 -march=slm”. Sandybridge: 164.gzip1635. 1602. -2.01% 197.parser 2159. 2117. -1.94% 254.gap 2909. 2886. -0.79% 256.bzip2 2232. 2154. -3.49% Silvermont: 164.gzip 964. 945. -1.97% 197.parser 951. 940. -1.15% 254.gap 1328. 1296. -2.40% 256.bzip2952. 898. -5.67% That is the price to pay for correctness. If you want to avoid that penalty, I'd say change ld.bfd as well as ld.gold on i?86 to use COPY relocations for PIEs like x86_64 has been changed some time ago, then when configured against improved linker and with small patch to gcc you can recover not just that cost, but some more on top of that.
[Bug target/65780] [5 Regression] Uninitialized common handling in executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780 --- Comment #49 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Stupachenko Evgeny from comment #47) The patch caused significant regressions (see below) on spec2000 INT benchmarks compiled with options “-fPIE -pie -O2 -ffast-math -mfpmath=sse -m32 -march=corei7-avx” or “-fPIE -pie -O2 -ffast-math -mfpmath=sse -m32 -march=slm”. Sandybridge: 164.gzip1635. 1602. -2.01% 197.parser 2159. 2117. -1.94% 254.gap 2909. 2886. -0.79% 256.bzip2 2232. 2154. -3.49% Silvermont: 164.gzip 964. 945. -1.97% 197.parser 951. 940. -1.15% 254.gap 1328. 1296. -2.40% 256.bzip2952. 898. -5.67% As Jakub pointed out, this commit is for correctness. Please open a new bug report to optimize undefined/common symbol access in PIE if linker supports copy reloc in PIE: https://sourceware.org/bugzilla/show_bug.cgi?id=18289
[Bug c/65833] New: Attempting to convert 128 bit integers to 128 bit decimal floating-point results in an unresolved symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65833
Bug ID: 65833
Summary: Attempting to convert 128 bit integers to 128 bit
decimal floating-point results in an unresolved symbol
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mm at mezzarobba dot net
CC: christoph.lauter at lip6 dot fr
The following code
$ cat stitd.c
int main(void) {
__uint128_t foo = 42;
_Decimal128 bar = foo;
(void) bar;
return 0;
}
fails to link with
$ gcc -Wall -Wextra -std=gnu11 stitd.c
/tmp/ccY4noUz.o: In function `main':
stitd.c:(.text+0x27): undefined reference to `__bid_floatunstitd'
collect2: error: ld returned 1 exit status
(exit 1)
Changing __uint128_t to __int128_t results in a similar error. Replacing
_Decimal128 by __float128 works.
~/docs/vrac/c$ gcc -v --version
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)
COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.9/cc1 -quiet -v -imultiarch x86_64-linux-gnu
help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase
help-dummy -version --version -o /tmp/cc2dxKl2.s
GNU C (Debian 4.9.2-10) version 4.9.2 (x86_64-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version
3.1.2-p3, MPC version 1.0.2
warning: MPFR header version 3.1.2-p3 differs from library version 3.1.2-p11.
warning: MPC header version 1.0.2 differs from library version 1.0.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64'
as -v --64 --version -o /tmp/ccNgVCKN.o /tmp/cc2dxKl2.s
GNU assembler version 2.25 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.25
GNU assembler (GNU Binutils for Debian) 2.25
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-linux-gnu'.
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.9/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/4.9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc8TwP9y.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/
--build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker
/lib64/ld-linux-x86-64.so.2 --version
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o
[Bug gcov-profile/65831] New: gcov does not output 0% coverage files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65831
Bug ID: 65831
Summary: gcov does not output 0% coverage files
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: afineman at afineman dot com
Created attachment 35378
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35378action=edit
Always create .gcov file if there is no .gcda file.
When running gcov against a file that was not covered at all (i.e., has no
corresponding .gcda file), gcov 4.6 would correctly output a .gcov file that
indicates 0% coverage. gcov 4.8 does not output any .gcov file in this case,
which I believe is a regression.
=
afineman@hotdog:/tmp$ diff test6.c test8.c
afineman@hotdog:/tmp$ cat test6.c
int
main()
{
return 0;
}
afineman@hotdog:/tmp$ gcc-4.6 --version
gcc-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
afineman@hotdog:/tmp$ gcov-4.6 --version
gcov (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.
afineman@hotdog:/tmp$ gcov-4.8 --version
gcov (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.
afineman@hotdog:/tmp$ gcc-4.8 --version
gcc-4.8 (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
afineman@hotdog:/tmp$ gcc-4.6 --coverage test6.c -o test6
afineman@hotdog:/tmp$ gcc-4.8 --coverage test8.c -o test8
afineman@hotdog:/tmp$ gcov-4.6 test6.c
test6.gcda:cannot open data file, assuming not executed
File 'test6.c'
Lines executed:0.00% of 2
test6.c:creating 'test6.c.gcov'
afineman@hotdog:/tmp$ cat test6.c.gcov
-:0:Source:test6.c
-:0:Graph:test6.gcno
-:0:Data:-
-:0:Runs:0
-:0:Programs:0
-:1:int
#:2:main()
-:3:{
#:4:return 0;
-:5:}
afineman@hotdog:/tmp$ gcov-4.8 test8.c
test8.gcda:cannot open data file, assuming not executed
File 'test8.c'
No executable lines
Removing 'test8.c.gcov'
afineman@hotdog:/tmp$
=
I believe that this is not a duplicate of Bug 35568. Or, at least, in 35568
there seem to be tests involving missing graph files along with missing data
files. This bug is only about (correctly) missing data files due to 0%
coverage, but failing to produce a .gcov file that indicates 0% coverage.
=
I've attached a patch that fixes the problem in my case, but I don't know if my
solution is the correct approach.
Also, I would like to have included something in the testsuite to avoid this in
the future, but I don't have the time right now. If the maintainers want such
a test, I volunteer to write one. (I've never contributed to this project
before, and can't promise when I'll get to it.)
==
Results from running gcov after applying the attached patch:
afineman@hotdog:/tmp$ ./build-gcc/gcc/gcov test8.c
test8.gcda:cannot open data file, assuming not executed
File 'test8.c'
Lines executed:0.00% of 2
Creating 'test8.c.gcov'
afineman@hotdog:/tmp$ cat test8.c.gcov
-:0:Source:test8.c
-:0:Graph:test8.gcno
-:0:Data:-
-:0:Runs:0
-:0:Programs:0
-:1:int
#:2:main()
-:3:{
#:4:return 0;
-:5:}
afineman@hotdog:/tmp$
[Bug target/65832] New: Inefficient vector construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65832
Bug ID: 65832
Summary: Inefficient vector construction
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target: x86_64-*-*, i?86-*-*
typedef int v4si __attribute__((vector_size(16)));
v4si foo (int i, int j, int k, int l)
{
return (v4si) { i, j, k, l };
}
produces
movl%edx, -12(%rsp)
movd-12(%rsp), %xmm1
movl%ecx, -12(%rsp)
movd-12(%rsp), %xmm2
movl%edi, -12(%rsp)
movd-12(%rsp), %xmm0
movl%esi, -12(%rsp)
movd-12(%rsp), %xmm3
punpckldq %xmm2, %xmm1
punpckldq %xmm3, %xmm0
punpcklqdq %xmm1, %xmm0
ret
as we spill everything to the stack we could as well use a vector load, thus
something like
movl%edx, -12(%rsp)
movl%ecx, -16(%rsp)
movl%edi, -20(%rsp)
movl%esi, -24(%rsp)
movdqu -12(%rsp), %xmm0
ret
[Bug target/65832] Inefficient vector construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65832
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
typedef unsigned char v16qi __attribute__((vector_size(16)));
v16qi baz (int i0, int i1, int i2, int i3,
int i10, int i11, int i12, int i13,
int i20, int i21, int i22, int i23,
int i30, int i31, int i32, int i33)
{
return (v16qi) { i0, i1, i2, i3,
i10, i11, i12, i13,
i20, i21, i22, i23,
i30, i31, i32, i33 };
}
is even more funny.
I'm looking whether the vectorizer cost model for these vector constructors
make sense. Currently the cost is
case vec_construct:
elements = TYPE_VECTOR_SUBPARTS (vectype);
return ix86_cost-vec_stmt_cost * (elements / 2 + 1);
which for v16qi and generic would be 9 vector stmts. The assembly for the
above contains 47 instructions. Not sure where elements / 2 + 1 comes from.
[Bug target/65780] [5 Regression] Uninitialized common handling in executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780 Stupachenko Evgeny evstupac at gmail dot com changed: What|Removed |Added CC||evstupac at gmail dot com --- Comment #47 from Stupachenko Evgeny evstupac at gmail dot com --- The patch caused significant regressions (see below) on spec2000 INT benchmarks compiled with options “-fPIE -pie -O2 -ffast-math -mfpmath=sse -m32 -march=corei7-avx” or “-fPIE -pie -O2 -ffast-math -mfpmath=sse -m32 -march=slm”. Sandybridge: 164.gzip1635. 1602. -2.01% 197.parser 2159. 2117. -1.94% 254.gap 2909. 2886. -0.79% 256.bzip2 2232. 2154. -3.49% Silvermont: 164.gzip 964. 945. -1.97% 197.parser 951. 940. -1.15% 254.gap 1328. 1296. -2.40% 256.bzip2952. 898. -5.67%
[Bug lto/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828 --- Comment #2 from Steven Noonan steven at uplinklabs dot net --- I just noticed that libtool appears to be stripping some of the arguments in LDFLAGS when invoking GCC: /bin/sh ../libtool --tag=CC --mode=link gcc -flto -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Werror=missing-prototypes -Werror=implicit-function-declaration -Werror=pointer-arith -Werror=init-self -Werror=format=2 -Werror=missing-include-dirs -fvisibility=hidden -O2 -fsanitize=undefined -Wl,-Bsymbolic-functions -version-info 4400:0:4400 -export-dynamic -O2 -fsanitize=undefined -o libglib-2.0.la -rpath /usr/local/lib [[.lo files]] libcharset/libcharset.la pcre/libpcre.la -lpthread libtool: link: gcc -flto -shared -fPIC -DPIC [[.o files]] -Wl,--whole-archive libcharset/.libs/libcharset.a pcre/.libs/libpcre.a -Wl,--no-whole-archive -lpthread -flto -O2 -Wl,-Bsymbolic-functions -O2 -Wl,-soname -Wl,libglib-2.0.so.0 -o .libs/libglib-2.0.so.0.4400.0 In particular it dropped the -fsanitize=undefined flag. If I invoke the libtool-generated GCC command line with '-fsanitize=undefined' added then there's no ICE. $ gcc -flto -shared -fPIC -DPIC [[.o files]] -Wl,--whole-archive libcharset/.libs/libcharset.a pcre/.libs/libpcre.a -Wl,--no-whole-archive -lpthread -flto -O2 -Wl,-Bsymbolic-functions -O2 -Wl,-soname -Wl,libglib-2.0.so.0 -o .libs/libglib-2.0.so.0.4400.0 -fsanitize=undefined $ ls -cahl .libs/libglib-2.0.so.0.4400.0 -rwxr-xr-x 1 snoonan snoonan 4.3M Apr 21 03:31 .libs/libglib-2.0.so.0.4400.0 Hmm.
[Bug c++/65815] std::array initialization with initializer list: a = {x,y,z} incorrectly flagged as syntax error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815
--- Comment #5 from andras.aszodi at csf dot ac.at ---
If the array is a class member and it is initialized in-class then the
single-brace syntax gets flagged. Please try the following example:
// - file clarrinit.cc --
#include array
#include iostream
class Fred {
public:
const std::arraydouble, 2 arr() const { return _a; }
private:
std::arraydouble, 2 _a = {1.0, 2.0}, // error
_b{3.0, 4.0}, // error
_c{{5.0, 6.0}}; // OK
};
int main(int argc, char *argv[]) {
Fred f;
std::cout f.arr()[0] std::endl;
}
//
Platform: Raspberry Pi 2, OS is Raspbian (not that it should matter IMO)
Command: `g++-4.9 -g -std=c++11 clarrinit.cc -o clarrinit`
Output:
error: array must be initialized with a brace-enclosed initializer
std::arraydouble, 2 _a = {1.0, 2.0},
^
clarrinit.cc:9:39: error: too many initializers for ‘std::arraydouble, 2u’
clarrinit.cc:10:16: error: array must be initialized with a brace-enclosed
initializer
_b{3.0, 4.0},
^
clarrinit.cc:10:16: error: too many initializers for ‘std::arraydouble, 2u’
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Apr 21 12:38:32 2015 New Revision: 66 URL: https://gcc.gnu.org/viewcvs?rev=66root=gccview=rev Log: 2015-04-21 Richard Biener rguent...@suse.de PR tree-optimization/65788 * tree-ssa-ccp.c (evaluate_stmt): Evaluate to UNDEFINED early. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug sanitizer/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||kcc at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Component|lto |sanitizer --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I remember seeing patches for this kind of issue (for GCC 5 at least). Maybe somebody remembers.
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Richard Biener rguenth at gcc dot gnu.org --- Should be fixed.
[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649 --- Comment #5 from Nick Clifton nickc at redhat dot com --- Created attachment 35379 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35379action=edit this time with a %0xlx Hi Guys, *sigh* this has not been my day. The previous two patches both had a small thinko in them - I was printing a hex value into the assembler file without a preceeding 0x prefix... Doh. So, a third attempt at the patch is attached. Cheers Nick
[Bug debug/65821] [4.8/4.9/5/6 regression] incorrect debug line # info for main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821 --- Comment #5 from chihin ko chihin.ko at oracle dot com --- Created attachment 35381 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35381action=edit test case 1/1
[Bug libstdc++/61580] stoi function unknown on W7/Cygwin/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61580 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-21 Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Splitting up the C99 tests to be more fine-grained is on my TODO list for 6.0
[Bug libstdc++/65839] New: xmethods need updating once gdb decides how to fix 18285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65839 Bug ID: 65839 Summary: xmethods need updating once gdb decides how to fix 18285 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dje at google dot com https://sourceware.org/bugzilla/show_bug.cgi?id=18285 documents a mea culpa: ptype on an xmethod expression segvs gdb. Bleah. Once we decide how to handle this in gdb, libstdc++'s xmethods will need updating. I can think of a way to fix the gdb side that doesn't involve changing libstdc++'s xmethods. Maybe it's a reasonable way to go. The issue is that currently, in order to know what the type of the result of the xmethod is, we have to invoke the xmethod. But for ptype we don't want any side-effects. GDB evaluates such expressions with EVAL_AVOID_SIDE_EFFECTS, and while many xmethods typically don't have side-effects some can. And, for completeness sake, even reading target memory can have a side-effect. A better solution would be a way to get the type of the result of the xmethod without having to invoke it, and that will require changes to the source.
[Bug debug/65821] [4.8/4.9/5/6 regression] incorrect debug line # info for main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821 --- Comment #4 from chihin ko chihin.ko at oracle dot com --- (In reply to Richard Biener from comment #3) What version works correctly? (please provide the testcase as attachment as well) 00x000b DW_TAG_compile_unit DW_AT_producer GNU C++ 4.7.2 DW_AT_language DW_LANG_C_plus_plus ... ... 10x0547DW_TAG_subprogram DW_AT_external yes(1) DW_AT_name main DW_AT_decl_file 0x0001 /workspace/chko/ws/dinstall/dbx_test/intel_S11_gcc482/c++defargs3.dbx,gcc/g47/c++defargs3.cc DW_AT_decl_line 0x001d DW_AT_type 0x0371 DW_AT_low_pc0x00400b02 DW_AT_high_pc 0x00400b62 ... ... 0x00400b02 [ 30, 0] NS 0x00400b0a [ 31, 0] NS 0x00400b22 [ 32, 0] NS DI=0x1 0x00400b35 [ 33, 0] NS 0x00400b3f [ 34, 0] NS 0x00400b49 [ 35, 0] NS
[Bug target/65837] New: [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 Bug ID: 65837 Summary: [arm-linux-gnueabihf] lto1 target specific builtin not available Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: prathamesh3492 at gcc dot gnu.org Hi, I got the following error while building chromium on arm-linux-gnueabihf with LTO enabled when linking libshared_memory_support.so: lto1: fatal error: target specific builtin not available Full command line used for linking: http://pastebin.com/2ANsEyMn This appears to be same as PR45790 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45790), which was opened for rs6000 for gcc-4.6. Since it is fixed for rs6000, I am not sure if I should have re-opened it. gcc -v: Using built-in specs. COLLECT_GCC=/home/prathamesh.kulkarni/gcc-linaro-6.0/bin/arm-linux-gnueabihf-gcc COLLECT_LTO_WRAPPER=/home/prathamesh.kulkarni/gcc-linaro-6.0/bin/../libexec/gcc/arm-linux-gnueabihf/6.0.0/lto-wrapper Target: arm-linux-gnueabihf Configured with: '/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git~gcc-chromium/configure' SHELL=/bin/bash --with-bugurl=https://bugs.linaro.org --with-mpc=/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu --with-mpfr=/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu --with-gmp=/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu --with-gnu-as --with-gnu-ld --disable-libstdcxx-pch --disable-libmudflap --with-cloog=no --with-ppl=no --with-isl=no --disable-nls --enable-multiarch --disable-multilib --enable-c99 --with-tune=cortex-a9 --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-shared --enable-static --with-build-sysroot=/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/sysroots/arm-linux-gnueabihf --enable-lto --enable-linker-build-id --enable-long-long --enable-shared --with-sysroot=/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu/libc --enable-languages=c,c++,lto --enable-fix-cortex-a53-835769 --enable-checking=yes --disable-bootstrap --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=arm-linux-gnueabihf --prefix=/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu Thread model: posix gcc version 6.0.0 20150418 (experimental) (GCC) Thank you, Prathamesh
[Bug debug/65838] New: DWARF type units should have DW_AT_comp_dir when needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65838 Bug ID: 65838 Summary: DWARF type units should have DW_AT_comp_dir when needed Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: dje at google dot com DWARF type units don't get DW_AT_comp_dir, and normally (for some definition of normally) they're not needed. But, for completeness sake, there are cases where they are. gdb bug https://sourceware.org/bugzilla/show_bug.cgi?id=18290 has a testcase.
[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Putting this on my active list.
[Bug libstdc++/65840] New: type of result of at least some libstdc++ xmethods is different than real operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65840
Bug ID: 65840
Summary: type of result of at least some libstdc++ xmethods is
different than real operator
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at google dot com
Using libstdc++-v3/testsuite/libstdc++-xmethods/unique_ptr.cc
as a testcase, and modifying it to ensure the * operator is compiled in:
--- gcc-unique_ptr.cc.~1~ 2015-04-21 15:17:37.863001716 -0700
+++ gcc-unique_ptr.cc 2015-04-21 15:18:14.666458223 -0700
@@ -30,7 +30,7 @@ main ()
// { dg-final { note-test *p 10 } }
// { dg-final { regexp-test p.get() 0x.* } }
- return 0; // Mark SPOT
+ return *p; // Mark SPOT
}
// { dg-final { gdb-test SPOT {} 1 } }
bash$ gdb a.out
(gdb) start
(gdb) n # keep next'ing until we get here:
33return *p; // Mark SPOT
(gdb) p *p
$1 = 10
(gdb) disable xm
(gdb) p *p
$2 = (int ) @0x403010: 10
(gdb) pt $1
type = int
(gdb) pt $2
type = int
Note the difference in type of the result of the xmethod vs the real *
operator. IWBN if they had the same type. If this requires additions to gdb we
can do that.
[Bug ipa/65076] [5/6 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #57 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Wed Apr 22 01:32:14 2015 New Revision: 222305 URL: https://gcc.gnu.org/viewcvs?rev=222305root=gccview=rev Log: PR ipa/65076 * passes.def (early_optimizations): Add pass_dse. * g++.dg/tree-ssa/pr61034.C: Update template. * g++.dg/warn/Warray-bounds.C: Harden for DSE. * gcc.dg/Warray-bounds-11.c: Likewise. * gcc.dg/Warray-bounds.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/passes.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tree-ssa/pr61034.C trunk/gcc/testsuite/g++.dg/warn/Warray-bounds.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-11.c trunk/gcc/testsuite/gcc.dg/Warray-bounds.c
[Bug c/65842] New: combine is overly cautious when operating on side effect operands references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65842
Bug ID: 65842
Summary: combine is overly cautious when operating on side
effect operands references
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Created attachment 35382
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35382action=edit
float32 is a custom define type, so default gcc can't compile is directly
this bug is discovered on gcc 4.7.0, but gcc 4.8/4.9 still have such bug.
during the combine:
first try_combine the insn 15 and insn 17, we can get the value of reg 143 is
zero.
then try_combine the insn 17, insn 43 and insn 44, we can get the value of reg
191 is zero. But the insn 43 has side effect, so it bring runtime fail after is
is deleted here.
=
(insn 15 14 17 2 (set (reg:SI 142)
(and:SI (reg:SI 123 [ D.3491 ])
(const_int 1 [0x1]))) 30 {andsi3}
(expr_list:REG_DEAD (reg:SI 123 [ D.3491 ])
(nil)))
(insn 17 15 21 2 (set (reg:SI 143)
(ashiftrt:SI (reg:SI 142)
(const_int 31 [0x1f]))) 42 {ashrsi3_internal}
(nil))
=
(insn 43 88 44 2 (set (reg:SI 165 [ g_123+4 ])
(mem/c:SI (pre_modify:SI (reg/f:SI 164)
(plus:SI (reg/f:SI 164)
(const_int -12 [0xfff4]))) [4 g_123+4 S4 A32]))
test.c:61 48 {movsi_internal}
(expr_list:REG_INC (reg/f:SI 164)
(nil)))
(insn 44 43 51 2 (set (reg:SI 191 [ g_123$6+4 ])
(and:SI (reg:SI 165 [ g_123+4 ])
(reg:SI 143))) test.c:61 30 {andsi3}
(expr_list:REG_DEAD (reg:SI 165 [ g_123+4 ])
(nil)))
related code in gcc is the function simplify_and_const_int_1:
/* If we don't have any bits left, return zero. */
if (constop == 0)
return const0_rtx;
[Bug libstdc++/65840] type of result of at least some libstdc++ xmethods is different than real operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65840 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Well does this matter in practice? In does set *p = 1 work when xm is disable and when it is enable? If the behavior is the same then it does not matter in practice. Or does p *p work both with and without xmethod?
[Bug libstdc++/65839] xmethods need updating once gdb decides how to fix 18285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65839 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-21 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I don't think there are many users of xmethods yet, so changing them in libstdc++ to add a return_type method should be fine.
[Bug libstdc++/65840] type of result of at least some libstdc++ xmethods is different than real operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65840 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-21 Ever confirmed|0 |1
[Bug libstdc++/65839] xmethods need updating once gdb decides how to fix 18285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65839 --- Comment #2 from Doug Evans dje at google dot com --- Re: changing xmethods. The thought was that they'd be changed in an upward compatible manner, but it's good to know we have a bit of freedom. Thanks!
[Bug libstdc++/65840] type of result of at least some libstdc++ xmethods is different than real operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65840 --- Comment #2 from Doug Evans dje at google dot com --- I think it should be more than just a matter of working in practice. A user may get confused by the difference in the type and wonder if time needs to be spent investigating the difference. Tools shouldn't do this to users.
[Bug libstdc++/61580] stoi function unknown on W7/Cygwin/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61580 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- The problem in this case is that newlib only defines C99 functions for C99 or C++11, but the _GLIBCXX_USE_C99 tests in acinclude.m4 are compiled with -std=gnu++98. As discussed previously (on the mailing list IIRC) we need to test whether C99 functions are available in C++98 mode and test again whether they are available in C++11 mode. For std::stoi() we don't care if they are missing in C++98 mode, as long as they are present in C++11 mode (which is true for newlib).
[Bug fortran/65841] New: Seg fault on intrinsic assignment to allocatable derived type with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65841 Bug ID: 65841 Summary: Seg fault on intrinsic assignment to allocatable derived type with allocatable component Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at sourceryinstitute dot org The code below produces a segmentation fault upon the second intrinsic assignment to an allocatable component of derived type containing an allocatable component of intrinsic type. Damian $ cat realloc_alloc_comp_with_alloc_comp.f90 type a real, allocatable :: f end type type b type(a), allocatable :: g end type type(b) c,d c%g=a(1.) d=c d=c ! seg fault with gfortran 5.0 Build 20150216 end $ gfortran realloc_alloc_comp_with_alloc_comp.f90 $ ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7F3705ACEBB7 #1 0x7F3705ACDDB0 #2 0x7F3704FD949F #3 0x7F370502654C #4 0x400901 in MAIN__ at realloc_alloc_comp_with_alloc_comp.f90:0 Segmentation fault (core dumped) $ gfortran --version GNU Fortran (GCC) 5.0.0 20150216 (experimental)
[Bug c++/65815] std::array initialization with initializer list: a = {x,y,z} incorrectly flagged as syntax error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815
--- Comment #6 from andras.aszodi at csf dot ac.at ---
You were too quick, I was too slow... please re-check :-)
(In reply to Daniel Krügler from comment #4)
(In reply to andras.aszodi from comment #3)
The problem manifests itself if the array is a member variable in a class
and initialised inline. Details in my new comment below.
There are no details anywhere. Please keep in mind that a complete code
example is generally required for an issue. So, if I understand you
correctly, you have the following code in mind:
//--
#include array
struct X
{
std::arraydouble, 3 q1 = {1.0, -1.0, 1.0};
};
//--
?
[Bug c++/65815] brace elision doesn't work in NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Status|WAITING |NEW
Summary|std::array initialization |brace elision doesn't work
|with initializer list: a = |in NSDMI
|{x,y,z} incorrectly flagged |
|as syntax error |
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org ---
Reduced:
struct array {
int data [2];
};
struct X {
array a = { 1, 2 };
};
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #18 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #16) What is printed with -Wno-error=narrowing ? I'm also a bit afraid of how setting pedantic-errors in this way interacts with the #pragma GCC diagnostics. Wouldn't it be better to reclassify -Wnarrowing as an error (see diagnostic_classify_diagnostic) then simulate a #pragma GCC diagnostics pop to restore the previous state? The problem is the order in which the re-classification happens, which should appear as if it happened in the command-line and not at the point of warning, but diagnostic_classify_diagnostic assumes #pragmas are handled in the order given in the source code. Another alternative, perhaps simpler, would be to have a different option -Wnarrowing-strict, which by default is -Werror=narrowing-strict (see Werror-implicit-function-declaration) and it is enabled by -Wnarrowing. This way, everything should work as expected (unless latent bugs in the options handling machinery for not passing the error/warning state correctly when enabling dependant options). An even simpler options is to put this under -fpermissive so people realize that what they are doing is very wrong according to the standard (if it is not very wrong, then why error and not just pedwarn?).
[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649 --- Comment #4 from Nick Clifton nickc at redhat dot com --- Created attachment 35376 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35376action=edit Patch resend Darn - apparently the previous version of this patch suffered from TAB/space corruption. So here is a resend of the patch
[Bug lto/65828] New: [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828 Bug ID: 65828 Summary: [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: steven at uplinklabs dot net Host architecture is x86_64, GCC version is the 4.9-20150415 snapshot. I've also seen this ICE on the 5-20150414 snapshot under the same conditions. The only thing I'm doing that's really unusual is combining -flto and -fsanitize=undefined. Normally I'd provide a reduced test case, but delta decided after some churning that the args file provided to lto1 was already reduced -- and the tarball of those objects was larger than the max attachment size. So in lieu of a nice attached repro, here are some steps: $ wget http://ftp.gnome.org/pub/GNOME/sources/glib/2.44/glib-2.44.0.tar.xz $ tar xf glib-2.44.0.tar.xz $ cd glib-2.44.0 $ ./configure --disable-debug CC=gcc -flto AR=gcc-ar RANLIB=gcc-ranlib CFLAGS=-O2 -fsanitize=undefined $ make It will break on the libglib-2.0.la link step: $ gcc -v -save-temps -flto -shared -fPIC -DPIC .libs/libglib_2_0_la-gallocator.o .libs/libglib_2_0_la-gcache.o .libs/libglib_2_0_la-gcompletion.o .libs/libglib_2_0_la-grel.o .libs/libglib_2_0_la-gthread-deprecated.o .libs/libglib_2_0_la-garray.o .libs/libglib_2_0_la-gasyncqueue.o .libs/libglib_2_0_la-gatomic.o .libs/libglib_2_0_la-gbacktrace.o .libs/libglib_2_0_la-gbase64.o .libs/libglib_2_0_la-gbitlock.o .libs/libglib_2_0_la-gbookmarkfile.o .libs/libglib_2_0_la-gbytes.o .libs/libglib_2_0_la-gcharset.o .libs/libglib_2_0_la-gchecksum.o .libs/libglib_2_0_la-gconvert.o .libs/libglib_2_0_la-gdataset.o .libs/libglib_2_0_la-gdate.o .libs/libglib_2_0_la-gdatetime.o .libs/libglib_2_0_la-gdir.o .libs/libglib_2_0_la-genviron.o .libs/libglib_2_0_la-gerror.o .libs/libglib_2_0_la-gfileutils.o .libs/libglib_2_0_la-ggettext.o .libs/libglib_2_0_la-ghash.o .libs/libglib_2_0_la-ghmac.o .libs/libglib_2_0_la-ghook.o .libs/libglib_2_0_la-ghostutils.o .libs/libglib_2_0_la-giochannel.o .libs/libglib_2_0_la-gkeyfile.o .libs/libglib_2_0_la-glib-init.o .libs/libglib_2_0_la-glib-private.o .libs/libglib_2_0_la-glist.o .libs/libglib_2_0_la-gmain.o .libs/libglib_2_0_la-gmappedfile.o .libs/libglib_2_0_la-gmarkup.o .libs/libglib_2_0_la-gmem.o .libs/libglib_2_0_la-gmessages.o .libs/libglib_2_0_la-gnode.o .libs/libglib_2_0_la-goption.o .libs/libglib_2_0_la-gpattern.o .libs/libglib_2_0_la-gpoll.o .libs/libglib_2_0_la-gprimes.o .libs/libglib_2_0_la-gqsort.o .libs/libglib_2_0_la-gquark.o .libs/libglib_2_0_la-gqueue.o .libs/libglib_2_0_la-grand.o .libs/libglib_2_0_la-gregex.o .libs/libglib_2_0_la-gscanner.o .libs/libglib_2_0_la-gsequence.o .libs/libglib_2_0_la-gshell.o .libs/libglib_2_0_la-gslice.o .libs/libglib_2_0_la-gslist.o .libs/libglib_2_0_la-gstdio.o .libs/libglib_2_0_la-gstrfuncs.o .libs/libglib_2_0_la-gstring.o .libs/libglib_2_0_la-gstringchunk.o .libs/libglib_2_0_la-gtestutils.o .libs/libglib_2_0_la-gthread.o .libs/libglib_2_0_la-gthreadpool.o .libs/libglib_2_0_la-gtimer.o .libs/libglib_2_0_la-gtimezone.o .libs/libglib_2_0_la-gtranslit.o .libs/libglib_2_0_la-gtrashstack.o .libs/libglib_2_0_la-gtree.o .libs/libglib_2_0_la-guniprop.o .libs/libglib_2_0_la-gutf8.o .libs/libglib_2_0_la-gunibreak.o .libs/libglib_2_0_la-gunicollate.o .libs/libglib_2_0_la-gunidecomp.o .libs/libglib_2_0_la-gurifuncs.o .libs/libglib_2_0_la-gutils.o .libs/libglib_2_0_la-gvariant.o .libs/libglib_2_0_la-gvariant-core.o .libs/libglib_2_0_la-gvariant-parser.o .libs/libglib_2_0_la-gvariant-serialiser.o .libs/libglib_2_0_la-gvarianttypeinfo.o .libs/libglib_2_0_la-gvarianttype.o .libs/libglib_2_0_la-gversion.o .libs/libglib_2_0_la-gwakeup.o .libs/libglib_2_0_la-gprintf.o .libs/libglib_2_0_la-glib-unix.o .libs/libglib_2_0_la-gthread-posix.o .libs/giounix.o .libs/gspawn.o -Wl,--whole-archive libcharset/.libs/libcharset.a pcre/.libs/libpcre.a -Wl,--no-whole-archive -lpthread -flto -O2 -Wl,-Bsymbolic-functions -Wl,-soname -Wl,libglib-2.0.so.0 -o .libs/libglib-2.0.so.0.4400.0 Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-4.9-20150415/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-multilib --disable-werror --with-multilib-list=m32,m64,mx32
[Bug c++/65815] std::array initialization with initializer list: a = {x,y,z} incorrectly flagged as syntax error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815
--- Comment #3 from andras.aszodi at csf dot ac.at ---
(In reply to Marek Polacek from comment #1)
Hm? This compiles just fine for me:
#include array
const std::arraydouble, 3 q1 = {1.0, -1.0, 1.0};
const std::arraydouble, 3 q2{{1.0, -1.0, 1.0}};
So can you provide a complete test case?
Thanks a lot. Yes, this works for me, too:
#include array
#include iostream
int main(int argc, char *argv[]) {
std::arraydouble, 2 a = {1.0, 2.0};
std::cout a[0] , a[1] std::endl;
}
The problem manifests itself if the array is a member variable in a class and
initialised inline. Details in my new comment below.
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #17 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #16) What is printed with -Wno-error=narrowing ? Try it yourself? Just a warning.
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #19 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #17) (In reply to Manuel López-Ibáñez from comment #16) What is printed with -Wno-error=narrowing ? Try it yourself? Just a warning. Thanks, well at least that works. I guess if someone notices a problem with the #pragmas, a better solution can be found later.
[Bug lto/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828 --- Comment #1 from Steven Noonan steven at uplinklabs dot net --- If you want a nice tarball with a ready-to-go repro case, I've put it here: https://www.uplinklabs.net/files/lto-65828.tar.xz Should just be able to run something like: $ /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto1 -quiet -dumpdir .libs/ -dumpbase libglib-2.0.so.0.4400.0.wpa -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase libglib_2_0_la-gallocator -O2 -O2 -version -fno-trapv -fPIC -fltrans-output-list=libglib-2.0.so.0.4400.0.ltrans.out -fwpa -fresolution=libglib-2.0.so.res @ccWGeoup.args from inside the extracted directory and see the issue.
[Bug c++/65815] std::array initialization with initializer list: a = {x,y,z} incorrectly flagged as syntax error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815
--- Comment #4 from Daniel Krügler daniel.kruegler at googlemail dot com ---
(In reply to andras.aszodi from comment #3)
The problem manifests itself if the array is a member variable in a class
and initialised inline. Details in my new comment below.
There are no details anywhere. Please keep in mind that a complete code example
is generally required for an issue. So, if I understand you correctly, you have
the following code in mind:
//--
#include array
struct X
{
std::arraydouble, 3 q1 = {1.0, -1.0, 1.0};
};
//--
?
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #20 from Jonathan Wakely redi at gcc dot gnu.org --- The problem with -fpermissive is that it doesn't just allow things like narrowing that are valid in C++03 but also allows all kind of ancient constructs that no sane person wants.
[Bug target/65836] [6 Regression] gnat fails to build on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65836 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- but other languages build fine?
[Bug target/65836] [6 Regression] gnat fails to build on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65836 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- This might be the same bug as 65824.
[Bug c++/65681] [c++-concepts] spurious ambiguous template instantiation error; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65681 Tom Honermann tom at honermann dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tom Honermann tom at honermann dot net --- Thanks! This issue appears to be resolved for me. Tested with r38.
[Bug fortran/56743] Namelist bug with comment and no blank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Tue Apr 21 16:13:54 2015 New Revision: 71 URL: https://gcc.gnu.org/viewcvs?rev=71root=gccview=rev Log: 2015-04-21 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/56743 * io/list_read.c (CASE_SEPARATORS): Add case for '!'. (is_separator): Add condition for '!'. (eat_separator): Use notify_std to warn or errord if '!' is encountered before a proper separator. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug c++/65835] New: bootstrap failure: multiple invalid conversions from ‘const char*’ to ‘char*’ [-fpermissive] in winnt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65835
Bug ID: 65835
Summary: bootstrap failure: multiple invalid conversions from
‘const char*’ to ‘char*’ [-fpermissive] in winnt.c
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tprince at computer dot org
Created attachment 35380
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35380action=edit
winnt.c from trunk
g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-
W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-
attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wn
o-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc
-I../../gc
c/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include
-I../../gc
c/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/
../libbacktrace -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I./.
./intl -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber
-I../../gcc/..
/libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace \
../../gcc/config/i386/winnt-stubs.c
../../gcc/config/i386/winnt.c: In function ‘const char*
i386_find_on_wrapper_lis
t(const char*)’:
../../gcc/config/i386/winnt.c:804:32: error: invalid conversion from ‘const
char
*’ to ‘hash_tablewrapped_symbol_hasher::value_type {aka char*}’
[-fpermissive]
return wrappers-find (target);
^
In file included from ../../gcc/hard-reg-set.h:23:0,
from ../../gcc/regs.h:24,
from ../../gcc/config/i386/winnt.c:26:
../../gcc/hash-table.h:623:15: note: initializing argument 1 of
‘hash_tableDe
scriptor, Allocator::value_type hash_tableDescriptor, Allocator::find(const
value_type) [with Descriptor = wrapped_symbol_hasher; Allocator = xcallocator;
hash_tableDescriptor, Allocator::value_type = char*]’
value_type find (const value_type value)
...
g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-
W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-
attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wn
o-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc
-I../../gc
c/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include
-I../../gc
c/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/
../libbacktrace -o hooks.o -MT hooks.o -MMD -MP -MF ./.deps/hooks.TPo
../../gc
c/hooks.c
../../gcc/config/i386/winnt.c: In function ‘void i386_pe_file_end()’:
../../gcc/config/i386/winnt.c:832:50: error: invalid conversion from ‘const
char
*’ to ‘char*’ [-fpermissive]
char *realsym = i386_find_on_wrapper_list (p-name);
^
../../gcc/config/i386/winnt.c:770:1: note: initializing argument 1 of ‘char*
i
386_find_on_wrapper_list(char*)’
i386_find_on_wrapper_list (char *target)
^
[Bug fortran/56743] Namelist bug with comment and no blank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Tue Apr 21 16:33:27 2015 New Revision: 72 URL: https://gcc.gnu.org/viewcvs?rev=72root=gccview=rev Log: 2015-04-21 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/56743 * gfortran.dg/namelist_87.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_87.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/56743] Namelist bug with comment and no blank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Fixed on trunk. Closing.
[Bug target/65836] New: [6 Regression] gnat fails to build on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65836 Bug ID: 65836 Summary: [6 Regression] gnat fails to build on aarch64-linux-gnu Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org seen with r68, aarch64-linux-gnu, ada fails to build in stage2: build/gengtype \ -S ../../src/gcc -I gtyp-input.list -w tmp-gtype.state Makefile:2402: recipe for target 's-gtype' failed make[5]: *** [s-gtype] Segmentation fault
[Bug c++/65835] bootstrap failure: multiple invalid conversions from ‘const char*’ to ‘char*’ [-fpermissive] in winnt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65835 --- Comment #1 from tprince at computer dot org --- Building by casting const char* to char *
[Bug fortran/56744] [meta-bug] Namelist bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744 Bug 56744 depends on bug 56743, which changed state. Bug 56743 Summary: Namelist bug with comment and no blank https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
