[Bug c/63554] New: ice in execute_todo, at passes.c:1797 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63554 Bug ID: 63554 Summary: ice in execute_todo, at passes.c:1797 with -O3 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 33731 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33731action=edit C source code Attached code, when compiled by 20141015, with flag -O3, does the following $ ../results/bin/gcc -c -O3 bug167.c utilmod.c: In function ‘nssutil_AddSecmodDBEntry.isra.2’: utilmod.c:609:1: internal compiler error: in execute_todo, at passes.c:1797 0xa1351b execute_todo ../../src/trunk/gcc/passes.c:1797 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. $ The code is fine with -O2. $ ../results/bin/gcc -c -O2 bug167.c $
[Bug c/63554] [5 Regression] ice in execute_todo, at passes.c:1797 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63554
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-16
CC||trippels at gcc dot gnu.org
Target Milestone|--- |5.0
Summary|ice in execute_todo, at|[5 Regression] ice in
|passes.c:1797 with -O3 |execute_todo, at
||passes.c:1797 with -O3
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
~ % cat bug167.c
char *a;
void
nssutil_ReadSecmodDB (void)
{
long b = __builtin_object_size (0, 0);
a = __builtin___strncat_chk (a, , 1, b);
}
~ % gcc -c -O2 bug167.c
bug167.c: In function ‘nssutil_ReadSecmodDB’:
bug167.c:3:1: internal compiler error: in execute_todo, at passes.c:1797
nssutil_ReadSecmodDB (void)
^
0x10650633 execute_todo
../../gcc/gcc/passes.c:1797
[Bug c++/49604] forward-declared enum's elements in class scope gets default access (class vs struct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49604
Melissa myriachan at gmail dot com changed:
What|Removed |Added
CC||myriachan at gmail dot com
--- Comment #3 from Melissa myriachan at gmail dot com ---
Happens for me on 5.0.0 build 2014/10/15 (via wandbox) through 4.6.x - whenever
typed enums were added.
Simpler test case than the original:
class MyTable {
public:
enum Constants : unsigned;
};
enum MyTable::Constants : unsigned {
LENGTH = 12,
};
int main()
{
return MyTable::LENGTH;
}
[Bug lto/63555] New: ICE compiling simple test with SDB debugging info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63555
Bug ID: 63555
Summary: ICE compiling simple test with SDB debugging info
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
I see ICE when try to compile a small test with -gcoff. Problem appears when
we have structure field and static variable with the same name. Here is a
reproducer:
typedef struct {
int *next;
} list;
int *next;
int main(int argc, char **argv)
{
return 0;
}
gcc -m64 -c -gcoff short.c
cc1: internal compiler error: in needed_p, at cgraphunit.c:237
0x7c1a8c symtab_node::needed_p()
../../gcc-pl/gcc/cgraphunit.c:236
0x7c3933 analyze_functions
../../gcc-pl/gcc/cgraphunit.c:936
0x7c7579 symbol_table::finalize_compilation_unit()
../../gcc-pl/gcc/cgraphunit.c:2288
0x627b77 c_write_global_declarations()
../../gcc-pl/gcc/c/c-decl.c:10431
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.
Here is failing assert:
/* Double check that no one output the function into assembly file
early. */
gcc_checking_assert (!DECL_ASSEMBLER_NAME_SET_P (decl)
|| !TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME
(decl)));
During file parsing we have a call to sdbout_symbol for structure type. It
causes output of its field and field's name is marked as referenced. Later
variable analysis hits assert because variable's assembler name is shared with
the structure field.
[Bug c/63549] ICE in build_array_ref with invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63549 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-16 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Even 4.4 ICEs, 3.4 works.
[Bug c/63549] [4.8/4.9/5] ICE in build_array_ref with invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63549 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |4.8.4 Summary|ICE in build_array_ref with |[4.8/4.9/5] ICE in |invalid code|build_array_ref with ||invalid code
[Bug c/63549] [4.8/4.9/5] ICE in build_array_ref with invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63549 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 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Mine.
[Bug tree-optimization/62031] [4.8 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 --- Comment #10 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 15 Oct 2014, clyon at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 --- Comment #9 from clyon at gcc dot gnu.org --- Forgot to mention that my observation is true on trunk and 4.9 branch. I didn't notice it earlier because I run validations for every commit on the 4.9 branch, and not as often on trunk. Can you please try to investigate? (does it only fail at -O0?!)
[Bug tree-optimization/33447] Non-empty latch block prevents loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33447 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.3, 4.9.1, 5.0 Resolution|--- |FIXED --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Fixed in 4.8+
[Bug tree-optimization/63168] loop header copying fails - not vectorized: latch block not empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63168 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||dorit at il dot ibm.com --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 28643 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/28643] redundant phi-node in latch-block prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28643 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- No testcase here but problem is exactly the same as described in PR63168. *** This bug has been marked as a duplicate of bug 63168 ***
[Bug tree-optimization/33244] Missed opportunities for vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33244 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-16 Blocks||53947 Summary|Missed opportunities for|Missed opportunities for |vectorization due to PRE|vectorization Ever confirmed|0 |1 Known to fail||4.9.2 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- No loop in the testcase is vectorized for the testcase with 4.9 or trunk but non-empty latches are no longer a problem. Confirmed.
[Bug c/63554] [5 Regression] ice in execute_todo, at passes.c:1797 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63554 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug middle-end/63556] New: gcc should dedup string postfixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63556
Bug ID: 63556
Summary: gcc should dedup string postfixes
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
With this code:
extern void func(char *a, char *b);
void f(void)
{
func(abc, xabc);
func(abc, abc);
}
we get:
.LC0:
.string xabc
.LC1:
.string abc
So the abcs get deduped. But it could also dedup the postfix by pointing
abc to xabc + 1. This would save some space.
[Bug middle-end/63556] gcc should dedup string postfixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63556 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/63556] gcc should dedup string postfixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63556
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-16
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Confirmed. Constant/literal pool also misses merging V2DF { 0., 0. } with
DF 0. for example (and more). There's another PR for that somewhere with
some hackish patch from me.
[Bug rtl-optimization/61605] Potential optimization: Keep unclobbered argument registers live across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #8 from vries at gcc dot gnu.org --- Patches submitted at: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01513.html https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01514.html
[Bug middle-end/63556] gcc should dedup string postfixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63556 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org --- This is done by the linker, as part of the merge section handling. Contents of section .rodata: 4005b0 01000200 78616263 00 xabc.
[Bug tree-optimization/62031] [4.8 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #10) On Wed, 15 Oct 2014, clyon at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 --- Comment #9 from clyon at gcc dot gnu.org --- Forgot to mention that my observation is true on trunk and 4.9 branch. I didn't notice it earlier because I run validations for every commit on the 4.9 branch, and not as often on trunk. Can you please try to investigate? (does it only fail at -O0?!) Especially please state if you are cross-testing and one target triplet that shows the failure.
[Bug middle-end/63544] [5 Regression] hash_map ends in an infinite loop if overwritten mark_empty uses a different value than 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63544 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- How is this a regression?
[Bug bootstrap/63545] ICE building GCC hash_tablecselib_hasher,xcallocator::find_slot_with_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63545 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-10-16 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Please provide preprocessed source of the failing compile.
[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- This may be too late to get at lto_file_decl_datas?
[Bug tree-optimization/63551] [4.9/5 Regression] wrong code (segfaults) at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63551
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-16
CC||hubicka at gcc dot gnu.org
Target Milestone|--- |5.0
Summary|wrong code (segfaults) at |[4.9/5 Regression] wrong
|-Os on x86_64-linux-gnu |code (segfaults) at -Os on
||x86_64-linux-gnu
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Confirmed.
fn2 ()
{
bb 2:
d = 0;
__builtin_unreachable ();
}
?
Somehow IPA inline inserts this call.
Considering fn1/2 with 7 size
to be inlined into fn2/3 in t.c:22
Estimated badness is -1073741826, frequency 1.00.
Badness calculation for fn2/3 - fn1/2
size growth -2, time 0 big_speedup
-1073741826: Growth -2 = 0
Introduced new external node (__builtin_unreachable/7).
Processing frequency fn1
from ipa-inline-analysis.c:edge_set_predicate
757 if (predicate false_predicate_p (predicate) e-callee)
758 {
759 struct cgraph_node *callee = !e-inline_failed ? e-callee :
NULL;
760
761 e-redirect_callee (cgraph_node::get_create
762 (builtin_decl_implicit
(BUILT_IN_UNREACHABLE)));
763 e-inline_failed = CIF_UNREACHABLE;
764 if (callee)
765 callee-remove_symbol_and_inline_clones ();
thus there is some bug in predicate compute.
[Bug tree-optimization/63551] [4.9/5 Regression] wrong code (segfaults) at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63551 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I guess we somehow miss the punning through the union makes '4294967286' signed '-10'. Analyzing function: fn2/3 function fn2/3 parameter descriptors: Jump functions of caller fn2/3: callsite fn2/3 - fn1/2 : param 0: UNKNOWN Aggregate passed by value: offset: 0, cst: 4294967286
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #21 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #20)
Still present at revision 203491 and the patch in comment #14 does not help.
Trivial reproducer:
=
__attribute__((noinline))
void foo (void)
{
__builtin_unreachable();
}
int main (int ac, char *av[])
{
foo ();
return 0;
}
=
As Mike surmises this is another case where we emit code that does not comply
with the atom model that ld64 (and lld) uses.
foo() and main() both end up empty for -O 0.
Mike: any thoughts on this? - seems you were intending to take a look.
(it also breaks bootstrapping llvm with GCC in Release mode)
[Bug tree-optimization/62031] [4.8 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 --- Comment #12 from clyon at gcc dot gnu.org --- Sorry, I thought you had the setup needed to reproduce the tests. I am using qemu. All execution tests fail (not only -O0), for instance with GCC configured as: --target=arm-none-eabi --with-mode=arm --with-cpu=cortex-a9 FAIL: gcc.dg/torture/pr62031.c -O0 execution test FAIL: gcc.dg/torture/pr62031.c -O1 execution test FAIL: gcc.dg/torture/pr62031.c -O2 execution test FAIL: gcc.dg/torture/pr62031.c -O3 -fomit-frame-pointer execution test FAIL: gcc.dg/torture/pr62031.c -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gcc.dg/torture/pr62031.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gcc.dg/torture/pr62031.c -O3 -g execution test FAIL: gcc.dg/torture/pr62031.c -Os execution test FAIL: gcc.dg/torture/pr62031.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.dg/torture/pr62031.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test
[Bug fortran/63553] [OOP] Wrong code when assigning a CLASS to a TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-16 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed on 4.9.1 up to trunk (5.0). 4.8.3 gives the error pr63553.f90:21.3: tm=cm 1 Error: Can't convert CLASS(mother) to TYPE(mother) at (1)
[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-16 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.6 up to trunk (5.0). 4.5 gives pr63552.f90:8.19: pure function f(a,b) 1 Error: Argument 'a' of pure function 'f' at (1) must be INTENT(IN) pr63552.f90:16.5: use m 1 Fatal Error: Can't open module file 'm.mod' for reading at (1): No such file or directory
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 63168, which changed state. Bug 63168 Summary: loop header copying fails - not vectorized: latch block not empty https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63168 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/63168] loop header copying fails - not vectorized: latch block not empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63168 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Oct 16 10:13:52 2014 New Revision: 216304 URL: https://gcc.gnu.org/viewcvs?rev=216304root=gccview=rev Log: 2014-10-16 Richard Biener rguent...@suse.de PR tree-optimization/63168 * tree-cfg.c (gimple_can_merge_blocks_p): Only protect latches if after merging they are no longer simple. * cfghooks.c (merge_blocks): Handle merging a latch block into another block. * gcc.dg/tree-ssa/loop-40.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-40.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfghooks.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug tree-optimization/63168] loop header copying fails - not vectorized: latch block not empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63168 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||5.0 Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug c/63557] New: builtin __udivti3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63557 Bug ID: 63557 Summary: builtin __udivti3 Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: postjb at gmx dot net Created attachment 33732 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33732action=edit test-source __udivti3 doesn't work. Any simple testcase fails. build:### $ gcc tst.c -o tst -lm file:### ./tst: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped version:### $ gcc -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/ usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c ++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-di r=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.o pensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudfla p --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstd cxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cp u=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) run: $ ./tst 1310749 140734356054592 source:## unsigned long long a,b; a = __udivti3(1000ULL,10ULL,b); printf(%llu\n,a); printf(%llu\n,b);
[Bug c/63557] builtin __udivti3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63557 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- You don't supply TImode args and miss a prototype.
[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #31 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Thu Oct 16 10:58:36 2014 New Revision: 216307 URL: https://gcc.gnu.org/viewcvs?rev=216307root=gccview=rev Log: gcc/ PR target/53513 * config/sh/sh-protos.h (emit_sf_insn, emit_df_insn, expand_sf_unop, expand_sf_binop, expand_df_unop, expand_df_binop): Remove. * config/sh/sh.c (sh_emit_set_t_insn): Adjust generated insn pattern to match fp insn patterns. (calc_live_regs): Add FPSCR_MODES_REG and FPSCR_STAT_REG to the ignore list. (emit_sf_insn, emit_df_insn, expand_sf_unop, expand_sf_binop, expand_df_unop, expand_df_binop): Remove. (sh_conditional_register_usage): Mark FPSCR_MODES_REG and FPSCR_STAT_REG as not call clobbered. (sh_emit_mode_set): Emit fpscr store-modify-load sequence instead of invoking fpscr_set_from_mem. * config/sh/sh.h (MAX_REGISTER_NAME_LENGTH): Increase to 6. (SH_REGISTER_NAMES_INITIALIZER): Add names for FPSCR_MODES_REG and FPSCR_STAT_REG. (REGISTER_NAMES): Adjust. (SPECIAL_REGISTER_P): Add FPSCR_MODES_REG and FPSCR_STAT_REG. (FIRST_PSEUDO_REGISTER): Increase to 156. (DWARF_FRAME_REGISTERS): Define as 153 to keep the original value. (FIXED_REGISTERS, CALL_USED_REGISTERS): Add FPSCR_MODES_REG and FPSCR_STAT_REG. (REG_CLASS_CONTENTS): Adjust ALL_REGS bit mask to include FPSCR_MODES_REG and FPSCR_STAT_REG. (REG_ALLOC_ORDER): Add FPSCR_MODES_REG and FPSCR_STAT_REG. * config/sh/sh.md (FPSCR_MODES_REG, FPSCR_STAT_REG, FPSCR_PR, FPSCR_SZ): Add new constants. (UNSPECV_FPSCR_MODES, UNSPECV_FPSCR_STAT): Add new unspecv constants. (movpsi): Use TARGET_FPU_ANY condition, invoke gen_fpu_switch. (fpu_switch): Add use and set of FPSCR_STAT_REG and FPSCR_MODES_REG. Use TARGET_FPU_ANY condition. (fpu_switch peephole2): Remove. (fpu_switch split): Use simple_mem_operand to capture the mem and adjust split implementation. (extend_psi_si, truncate_si_psi): New insns. (toggle_sz, toggle_pr): Use FPSCR_SZ, FPSCR_PR constants. Add set of FPSCR_MODES_REG. (push_e, push_4, pop_e, pop_4, movdf_i4, reload_indf__frn, movsf_ie, reload_insf__frn, force_mode_for_call, calli, calli_tbr_rel, calli_pcrel, call_pcrel, call_compact, call_compact_rettramp, call_valuei, call_valuei_tbr_rel, call_valuei_pcrel, call_value_pcrel, call_value_compact, call_value_compact_rettramp, call, call_pop_compact, call_pop_compact_rettramp, call_value, sibcalli, sibcalli_pcrel, sibcalli_thunk, sibcall_pcrel, sibcall_compact, sibcall, sibcall_valuei, sibcall_valuei_pcrel, sibcall_value_pcrel, sibcall_value_compact, sibcall_value, call_value_pop_compact, call_value_pop_compact_rettramp, various unnamed splits): Replace use of FPSCR_REG with use of FPSCR_MODES_REG. Adjust gen_* function uses. (floatsisf2_i4, *floatsisf2_ie): Merge into floatsisf2_i4. (fix_truncsfsi2_i4, *fixsfsi): Merge into fix_truncsfsi2_i4. (cmpgtsf_t, cmpgtsf_t_i4): Merge into cmpgtsf_t. (cmpeqsf_t, cmpeqsf_t_i4): Merge into cmpeqsf_t. (ieee_ccmpeqsf_t, *ieee_ccmpeqsf_t_4): Merge into ieee_ccmpeqsf_t. (udivsi3_i4, divsi3_i4, addsf3_i, subsf3_i, mulsf3_i, fmasf4_i, *fmasf4, divsf3_i, floatsisf2_i4, fix_truncsfsi2_i4, cmpgtsf_t, cmpeqsf_t, ieee_ccmpeqsf_t, sqrtsf2_i, rsqrtsf2, fsca, adddf3_i, subdf3_i, muldf3_i, divdf3_i, floatsidf2_i, fix_truncdfsi2_i, cmpgtdf_t, cmpeqdf_t, *ieee_ccmpeqdf_t, sqrtdf2_i, extendsfdf2_i4, truncdfsf2_i4): Replace use of FPSCR_REG with clobber of FPSCR_STAT_REG and use of FPSCR_MODES_REG. Adjust gen_* function uses. gcc/testsuite/ PR target/53513 * gcc.target/sh/pr54680.c: Adjust matching of lds insn. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh-protos.h trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.h trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sh/pr54680.c
[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz --- This may be too late to get at lto_file_decl_datas? I think the problem is dwarf2out for whatever reason referring to a symbol that was optimized out... It does not make sense to try to figure out section of b when b is not going to be output. Honza
[Bug c++/63558] New: cannot silence jump to case label with fpermissive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63558
Bug ID: 63558
Summary: cannot silence jump to case label with fpermissive
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
extern int abs(int);
static long int n_ants;
enum enum_var_types
{ VAR_NONE, VAR_DELTA, VAR_SWITCH };
static enum enum_var_types option_var_n_ants;
void
adapt_parameters_next_iteration(void)
{
switch(option_var_n_ants) {
case VAR_NONE: break;
case VAR_DELTA:
int trunc_n_ants = 0;
n_ants += trunc_n_ants;
break;
case VAR_SWITCH:
break;
default: break;
}
}
$ ~/test1/216257/build/gcc/cc1plus -fpermissive adaptation.ii
adaptation.ii:18:10: warning: jump to case label [-fpermissive]
case VAR_SWITCH:
^
adaptation.ii:15:13: error: crosses initialization of ‘int trunc_n_ants’
int trunc_n_ants = 0;
^
adaptation.ii:20:7: warning: jump to case label [-fpermissive]
default: break;
^
adaptation.ii:15:13: error: crosses initialization of ‘int trunc_n_ants’
int trunc_n_ants = 0;
^
The error should be an inform that is conditional on the previous permerror
return value.
(And what's up with the extra spacing before 'crosses'?)
[Bug tree-optimization/63551] [4.9/5 Regression] wrong code (segfaults) at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63551 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org --- indeed, somewhere we need to view convert the aggregate value... Predicates works on conditions on arguments, so I suppose this ought to happen at ipa-prop side. Martin?
[Bug c++/49604] forward-declared enum's elements in class scope gets default access (class vs struct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49604 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid, ||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-16 Ever confirmed|0 |1
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #15 from Stupachenko Evgeny evstupac at gmail dot com --- Created attachment 33733 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33733action=edit patch to fix darwin bootstrap With pseudo GOT register we don't need to set GOT register after any jump, and therefore don't need nonlocal_goto_receiver and builtin_setjmp_receiver for i386. Please try attached patch (just removing nonlocal_goto_receiver and builtin_setjmp_receiver from i386.md).
[Bug sanitizer/63559] New: -fsanitize=thread sets no preprocessor flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63559 Bug ID: 63559 Summary: -fsanitize=thread sets no preprocessor flags Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: rogero at howzatt dot demon.co.uk 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 When -fsanitize=address is supplied the builtin __SANITIZE_ADDRESS__ is defined. There does not appear to be an equivalent for -fsanitize=thread, which could be used for conditionally compiling code to avoid tsan reporting false positives.
[Bug sanitizer/63559] -fsanitize=thread sets no preprocessor flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63559 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #1 from Dmitry Vyukov dvyukov at google dot com --- Hi Roger, Please also report the false positives themselves to thread-saniti...@googlegroups.com or https://groups.google.com/forum/#!forum/thread-sanitizer We would like to fix them as well.
[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #32 from Oleg Endo olegendo at gcc dot gnu.org --- As a next step, I'd like to add built-in functions to get/set the FPSCR on SH. We have the old __get_fpscr and __set_fpscr functions in libgcc which modify the __fpscr_values array and the FPSCR. One idea would be to make __get_fpscr and __set_fpscr built-in functions, so that new code never generates the respective library calls. I don't know how expected/unexpected that would be for users and their existing code. For example, the current glibc does this in sysdeps/sh/sh4/fpu/fpu_control.h: #if defined __GNUC__ __BEGIN_DECLS /* GCC provides this function. */ extern void __set_fpscr (unsigned long); #define _FPU_SETCW(cw) __set_fpscr ((cw)) #else #define _FPU_SETCW(cw) __asm__ (lds %0,fpscr : : r (cw)) #endif By making __set_fpscr a builtin it would automagically work, but would never update the __fpscr_values. I'm not sure what kind of other fpscr related work arounds build on top of that. Alternatively, we could name the built-in functions differently. I've briefly checked the docs of other targets, this is what I've found: aarch64: unsigned int __builtin_aarch64_get_fpcr () void __builtin_aarch64_set_fpcr (unsigned int) unsigned int __builtin_aarch64_get_fpsr () void __builtin_aarch64_set_fpsr (unsigned int) ARM: unsigned int __builtin_arm_get_fpscr () void __builtin_arm_set_fpscr (unsigned int) MIPS: unsigned int __builtin_mips_get_fcsr (void) void __builtin_mips_set_fcsr (unsigned int value) I'd propose the following for SH: unsigned int __builtin_sh_get_fpscr () void __builtin_sh_set_fpscr (unsigned int) Any opinions or feedback regarding the matter?
[Bug tree-optimization/63185] Improve DSE with branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Btw, what was the original testcase? It's all a little bit complicated and not really fit for the current simple handling of PHIs. Because with a conditional store we have to continue looking for uses on the other path (for regular stores we'd have expected code sinking to sink the store). That is, without making the walk very much more expensive there isn't anything we can do about this.
[Bug target/61770] march=native detects corei7-avx on non avx cpu (Celeron 847)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61770 R. Dragone rdragone at asifade dot in changed: What|Removed |Added CC||rdragone at asifade dot in --- Comment #1 from R. Dragone rdragone at asifade dot in --- Just encountered the same problem myself. gcc -march=native -E -v - /dev/null 21 | grep cc1 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.3/cc1 -E -quiet -v - -march=corei7-avx -mcx16 -msahf -mno-movbe -mno-aes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=corei7-avx -fno-strict-overflow -fPIE -fstack-protector-all cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Pentium(R) CPU B960 @ 2.20GHz stepping: 7 microcode : 0x1b cpu MHz : 1679.476 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dtherm bogomips: 4389.89 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Pentium(R) CPU B960 @ 2.20GHz stepping: 7 microcode : 0x1b cpu MHz : 1973.039 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dtherm bogomips: 4389.89 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401 --- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Thu Oct 16 12:21:29 2014 New Revision: 216314 URL: https://gcc.gnu.org/viewcvs?rev=216314root=gccview=rev Log: gcc/ PR target/59401 * config/sh/sh.h (CALL_REALLY_USED_REGISTERS): Expand macro and set GBR to 0. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.h
[Bug c/63554] [5 Regression] ice in execute_todo, at passes.c:1797 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63554 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug c/63554] [5 Regression] ice in execute_todo, at passes.c:1797 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63554 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Oct 16 12:25:52 2014 New Revision: 216315 URL: https://gcc.gnu.org/viewcvs?rev=216315root=gccview=rev Log: 2014-10-16 Richard Biener rguent...@suse.de PR middle-end/63554 * builtins.c (fold_builtin_4): Do not call fold_builtin_strncat_chk. (fold_builtin_strncat_chk): Move ... * gimple-fold.c (gimple_fold_builtin_strncat_chk): ... here. (gimple_fold_builtin): Call gimple_fold_builtin_strncat_chk. * gcc.dg/torture/pr63554.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr63554.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/62031] [4.8 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 --- Comment #13 from clyon at gcc dot gnu.org --- To be more specific, I'm using qemu 2.0.0. But I've switched to a new x86_64 host running Ubuntu-14.04, and the tests pass. I observed the failures when using a x86_64 host running Red-Hat 5. And qemu-2.0.0 in both cases. I am going to take a further look at the RHEL5 (I need to restart the builds manually).
[Bug target/63260] [SH] fabs, fneg do not need fp-mode setting and do not use fpscr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63260 --- Comment #9 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Thu Oct 16 12:32:24 2014 New Revision: 216317 URL: https://gcc.gnu.org/viewcvs?rev=216317root=gccview=rev Log: gcc/testsuite/ PR target/63260 * gcc.target/sh/pr63260.c: Fix typo __builtin_fabs vs. __builtin_abs. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sh/pr63260.c
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 33733 [details] patch to fix darwin bootstrap With pseudo GOT register we don't need to set GOT register after any jump, and therefore don't need nonlocal_goto_receiver and builtin_setjmp_receiver for i386. Please try attached patch (just removing nonlocal_goto_receiver and builtin_setjmp_receiver from i386.md). With the patch bootstrap fails with libtool: link: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs -B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.4.0/bin/ -B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.4.0/lib/ -isystem /opt/gcc/gcc4.10w/x86_64-apple-darwin13.4.0/include -isystem /opt/gcc/gcc4.10w/x86_64-apple-darwin13.4.0/sys-include-dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libstdc++.6.dylib .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,-force_load,../libsupc++/.libs/libsupc++convenience.a -Wl,-force_load,../src/c++98/.libs/libc++98convenience.a -Wl,-force_load,../src/c++11/.libs/libc++11convenience.a -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs -lm -Wl,-single_module -Wl,-exported_symbols_list -Wl,libstdc++-symbols.explist -install_name /opt/gcc/gcc4.10w/lib/libstdc++.6.dylib -compatibility_version 7 -current_version 7.21 -Wl,-single_module ld: warning: cannot export hidden symbol __cxxabiv1::__pbase_type_info::__pointer_catch(__cxxabiv1::__pbase_type_info const*, void**, unsigned int) const from ../libsupc++/.libs/libsupc++convenience.a(pbase_type_info.o) ld: warning: cannot export hidden symbol std::basic_stringbufchar, std::char_traitschar, std::allocatorchar ::~basic_stringbuf() from ../src/c++98/.libs/libc++98convenience.a(complex_io.o) ld: warning: cannot export hidden symbol std::basic_stringbufwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::~basic_stringbuf() from ../src/c++98/.libs/libc++98convenience.a(complex_io.o) ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o) ld: warning: cannot export hidden symbol std::ctypechar::do_narrow(char, char) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o) ld: warning: cannot export hidden symbol std::ctypechar::do_narrow(char const*, char const*, char, char*) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o) ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char const*, char const*, char*) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_istreamchar, std::char_traitschar -in-std::istrstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_ostreamchar, std::char_traitschar -in-std::ostrstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_istreamchar, std::char_traitschar -in-std::strstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_iostreamchar, std::char_traitschar -in-std::strstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o) ld: warning: cannot export hidden symbol std::ctypechar::do_narrow(char, char) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o) ld: warning: cannot export hidden symbol std::ctypechar::do_narrow(char const*, char const*, char, char*) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o) ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char const*, char const*, char*) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o) ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o) ld: warning: cannot export hidden symbol std::ctypechar::do_narrow(char, char) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o) ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char const*, char const*, char*) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o) ld:
[Bug c++/63508] ICE when using bracketed initializer on pointer to member function of a templated class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63508 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-16 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Even 4.7 ICEs.
[Bug tree-optimization/63185] Improve DSE with branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) Btw, what was the original testcase? Sorry, I don't remember. Probably something involving std::vector or std::string. Since llvm optimizes it just fine, I hadn't realized it would be so hard. That is, without making the walk very much more expensive there isn't anything we can do about this. Ok, thanks for looking at it. Down to P5?
[Bug bootstrap/63545] ICE building GCC hash_tablecselib_hasher,xcallocator::find_slot_with_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63545 --- Comment #2 from Bill Klees bill.klees at teamquest dot com --- Created attachment 33734 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33734action=edit Preprocessed Source for Failing Compile
[Bug go/63560] New: __go_set_defer_retaddr shouldn't be split by IPA split
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63560
Bug ID: 63560
Summary: __go_set_defer_retaddr shouldn't be split by IPA split
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: mliska at suse dot cz
CC: cmang at google dot com, hubicka at ucw dot cz, iant at
google dot com,
mliska at suse dot cz
Starting from r216305, IPA ICF can unify functions that will change decision
made by IPA inline. As a result, we end up with split function:
Not working version:
bytes_test.$thunk0 (struct
{
struct __go_descriptor * fn;
} * __go_thunk_parameter)
{
bool _3;
bb 2:
# DEBUG $ret49 = 0
_3 = __go_set_defer_retaddr (retaddr);
if (_3 != 0)
goto bb 4 (retaddr);
else
goto bb 3;
bb 3:
bytes_test.$thunk0.part.15 (__go_thunk_parameter_4(D));
retaddr:
# DEBUG $ret49 = 0
return 0;
}
I discussed this stuff with Ian and Honza and the agreement is that we should
not split functions decorated with noinline attribute. Honza will come up with
a patch.
Thank you,
Martin
[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #33 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #32) I'd propose the following for SH: unsigned int __builtin_sh_get_fpscr () void __builtin_sh_set_fpscr (unsigned int) Any opinions or feedback regarding the matter? Looks fine to me.
[Bug libgomp/63561] New: gfortran runtime hang on function print-stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63561 Bug ID: 63561 Summary: gfortran runtime hang on function print-stmt Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: sidio47 at hotmail dot com CC: jakub at gcc dot gnu.org Created attachment 33735 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33735action=edit Source code demonstrating runtime hang. Attached is a Fortran program that attempts to print the output of a function from a module. From my tests, when certain compile libraries are used, the program will wait indefinitely using all versions of GCC (gfortran) that I have access to (4.9.1, 4.8.3, 4.7.1) on three different systems: 1.) Linux 3.16.3-200.fc20.x86_64 #1 SMP Wed Sep 17 22:34:21 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux 2.) Linux 2.6.32-431.17.1.el6.x86_64 #1 SMP Wed May 7 23:32:49 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux 3.) Linux 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:37:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux The code has no openmp or mpi calls. I believe the module to be irrelevant; i.e. the hang still occurs with an external function. 1.) Plain old vanilla gfortran works as intended. 2.) Adding the -fopenmp flag will cause it to hang. 3.) Adding the mpif90 wrapper from MVAPICH2 will cause it to hang. i.e: 1.) gfortran silly.F90 -o silly ./silly --- Works 2.) gfortran silly.F90 -o silly -fopenmp ./silly --- Hangs 3.) mpif90 silly.F90 -o silly ./silly --- Hangs
[Bug libgomp/63561] gfortran runtime hang on function print-stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63561 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-10-16 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- The code is invalid: recursive I/O (see pr30617 for the discussion).
[Bug sanitizer/61100] asan/tsan should have the sanitizer includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61100 --- Comment #5 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Thu Oct 16 13:42:48 2014 New Revision: 216322 URL: https://gcc.gnu.org/viewcvs?rev=216322root=gccview=rev Log: 2014-10-16 Yury Gribov y.gri...@samsung.com Backport from mainline 2014-05-14 Yury Gribov y.gri...@samsung.com PR sanitizer/61100 * Makefile.am (nodist_saninclude_HEADERS): Install public headers. * Makefile.in: Regenerate. * c-c++-common/asan/asan-interface-1.c: New test. * lib/asan-dg.exp (asan_include_flags): New function. (asan_init): Call asan_include_flags to obtain path to sanitizer headers. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/asan-interface-1.c Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/lib/asan-dg.exp branches/gcc-4_9-branch/libsanitizer/ChangeLog branches/gcc-4_9-branch/libsanitizer/Makefile.am branches/gcc-4_9-branch/libsanitizer/Makefile.in
[Bug ipa/63562] New: [5 Regression] ICE : in ipcp_verify_propagated_values, at ipa-cp.c:907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63562 Bug ID: 63562 Summary: [5 Regression] ICE : in ipcp_verify_propagated_values, at ipa-cp.c:907 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: marxin at gcc dot gnu.org IPA ICF causes Firefox build to fail on ppc64 with -O3 -flto during final libxul link: lto1: internal compiler error: in ipcp_verify_propagated_values, at ipa-cp.c:907 0x10c6beb3 ipcp_verify_propagated_values() ../../gcc/gcc/ipa-cp.c:907 0x10c6eceb ipcp_propagate_stage ../../gcc/gcc/ipa-cp.c:2341 0x10c6eceb ipcp_driver ../../gcc/gcc/ipa-cp.c:3726 0x10c6eceb execute ../../gcc/gcc/ipa-cp.c:3819 Please submit a full bug report, with preprocessed source if appropriate.
[Bug sanitizer/61530] [4.10 Regression] segfault with asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530 --- Comment #10 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Thu Oct 16 13:46:39 2014 New Revision: 216326 URL: https://gcc.gnu.org/viewcvs?rev=216326root=gccview=rev Log: New asan-instrumentation-with-call-threshold parameter. 2014-10-16 Yury Gribov y.gri...@samsung.com Backport from mainline 2014-06-16 Yury Gribov y.gri...@samsung.com * asan.c (check_func): New function. (maybe_create_ssa_name): Likewise. (build_check_stmt_with_calls): Likewise. (use_calls_p): Likewise. (report_error_func): Change interface. (build_check_stmt): Allow non-integer lengths; add support for new parameter. (asan_instrument): Likewise. (instrument_mem_region_access): Moved code to build_check_stmt. (instrument_derefs): Likewise. (instrument_strlen_call): Likewise. * cfgcleanup.c (old_insns_match_p): Add support for new functions. * doc/invoke.texi: Describe new parameter. * params.def: Define new parameter. * params.h: Likewise. * sanitizer.def: Describe new builtins. * c-c++-common/asan/instrument-with-calls-1.c: New test. * c-c++-common/asan/instrument-with-calls-2.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-1.c: Update test patterns. * c-c++-common/asan/no-redundant-instrumentation-2.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-4.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-5.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-6.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-7.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-8.c: Likewise. Backport from mainline 2014-06-16 Yury Gribov y.gri...@samsung.com * asan.c (build_check_stmt): Fix maybe-uninitialized warning. Backport from mainline 2014-06-18 Yury Gribov y.gri...@samsung.com PR sanitizer/61530 * asan.c (build_check_stmt): Add condition. * c-c++-common/asan/pr61530.c: New test. Backport from mainline 2014-06-18 Yury Gribov y.gri...@samsung.com PR sanitizer/61547 * asan.c (instrument_strlen_call): Fixed instrumentation of trailing byte. * c-c++-common/asan/strlen-overflow-1.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/instrument-with-calls-1.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/instrument-with-calls-2.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/pr61530.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/strlen-overflow-1.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/asan.c branches/gcc-4_9-branch/gcc/cfgcleanup.c branches/gcc-4_9-branch/gcc/doc/invoke.texi branches/gcc-4_9-branch/gcc/params.def branches/gcc-4_9-branch/gcc/params.h branches/gcc-4_9-branch/gcc/sanitizer.def branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-1.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-2.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-4.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-5.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-6.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-7.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-8.c
[Bug sanitizer/61547] Invalid sanitization of trailing byte in __builtin_strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61547 --- Comment #6 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Thu Oct 16 13:46:39 2014 New Revision: 216326 URL: https://gcc.gnu.org/viewcvs?rev=216326root=gccview=rev Log: New asan-instrumentation-with-call-threshold parameter. 2014-10-16 Yury Gribov y.gri...@samsung.com Backport from mainline 2014-06-16 Yury Gribov y.gri...@samsung.com * asan.c (check_func): New function. (maybe_create_ssa_name): Likewise. (build_check_stmt_with_calls): Likewise. (use_calls_p): Likewise. (report_error_func): Change interface. (build_check_stmt): Allow non-integer lengths; add support for new parameter. (asan_instrument): Likewise. (instrument_mem_region_access): Moved code to build_check_stmt. (instrument_derefs): Likewise. (instrument_strlen_call): Likewise. * cfgcleanup.c (old_insns_match_p): Add support for new functions. * doc/invoke.texi: Describe new parameter. * params.def: Define new parameter. * params.h: Likewise. * sanitizer.def: Describe new builtins. * c-c++-common/asan/instrument-with-calls-1.c: New test. * c-c++-common/asan/instrument-with-calls-2.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-1.c: Update test patterns. * c-c++-common/asan/no-redundant-instrumentation-2.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-4.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-5.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-6.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-7.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-8.c: Likewise. Backport from mainline 2014-06-16 Yury Gribov y.gri...@samsung.com * asan.c (build_check_stmt): Fix maybe-uninitialized warning. Backport from mainline 2014-06-18 Yury Gribov y.gri...@samsung.com PR sanitizer/61530 * asan.c (build_check_stmt): Add condition. * c-c++-common/asan/pr61530.c: New test. Backport from mainline 2014-06-18 Yury Gribov y.gri...@samsung.com PR sanitizer/61547 * asan.c (instrument_strlen_call): Fixed instrumentation of trailing byte. * c-c++-common/asan/strlen-overflow-1.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/instrument-with-calls-1.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/instrument-with-calls-2.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/pr61530.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/strlen-overflow-1.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/asan.c branches/gcc-4_9-branch/gcc/cfgcleanup.c branches/gcc-4_9-branch/gcc/doc/invoke.texi branches/gcc-4_9-branch/gcc/params.def branches/gcc-4_9-branch/gcc/params.h branches/gcc-4_9-branch/gcc/sanitizer.def branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-1.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-2.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-4.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-5.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-6.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-7.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-8.c
[Bug tree-optimization/63278] Fails to compute loop bound from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63278 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-16 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I have a patch.
[Bug ipa/63562] [5 Regression] ICE : in ipcp_verify_propagated_values, at ipa-cp.c:907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63562 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617 --- Comment #39 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #29) It is hanging on undefined, I think there is a difference here, a big difference. What is the difference for you? Just as a side note, that's not me who classed the PR as invalid and so far I did not see a class ICE on undefined. Just because you've mentioned this PR: There is a significant difference. ICE on invalid is something clearly undesirable, because it is the compiler that is crashing, and compiler should not have undefined behavior on whatever garbage you throw at it. If you compile code with undefined behavior in it, run it and that code crashes, hangs or formats your disk, that is a bug in the code you are running, not in the compiler. Anything can happen when you invoke undefined behavior. And anything includes hanging, segfault, formatting your disk etc. E.g. if you invoke undefined behavior in some loop, gcc will often optimize away loop bound checks in that case (on the assumption that in valid code, the loop e.g. could be invoked only certain number of iterations and not more). So, you may very well get a hang in that case too.
[Bug sanitizer/62089] Sanitizer may fail to instrument struct accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62089 --- Comment #4 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Thu Oct 16 13:52:45 2014 New Revision: 216331 URL: https://gcc.gnu.org/viewcvs?rev=216331root=gccview=rev Log: 2014-10-16 Yury Gribov y.gri...@samsung.com Backport from mainline 2014-08-18 Yury Gribov y.gri...@samsung.com PR sanitizer/62089 * asan.c (instrument_derefs): Fix bitfield check. * c-c++-common/asan/pr62089.c: New test. * c-c++-common/asan/bitfield-1.c: New test. * c-c++-common/asan/bitfield-2.c: New test. * c-c++-common/asan/bitfield-3.c: New test. * c-c++-common/asan/bitfield-4.c: New test. Backport from mainline 2014-08-28 Yury Gribov y.gri...@samsung.com * c-c++-common/asan/pr62089.c: Fix test on 32-bit platforms. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/bitfield-1.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/bitfield-2.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/bitfield-3.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/bitfield-4.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/pr62089.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/asan.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug sanitizer/61897] sanitizer internal compiler error: in build2_stat, at tree.c:4160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61897 --- Comment #5 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Thu Oct 16 13:53:33 2014 New Revision: 216332 URL: https://gcc.gnu.org/viewcvs?rev=216332root=gccview=rev Log: 2014-10-16 Yury Gribov y.gri...@samsung.com Backport from mainline 2014-09-01 Yury Gribov y.gri...@samsung.com PR sanitizer/61897 PR sanitizer/62140 * asan.c (asan_mem_ref_get_end): Handle non-ptroff_t lengths. (build_check_stmt): Likewise. (instrument_strlen_call): Likewise. (asan_expand_check_ifn): Likewise and fix types. (maybe_cast_to_ptrmode): New function. * c-c++-common/asan/pr62140-1.c: New test. * c-c++-common/asan/pr62140-2.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/pr62140-1.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/pr62140-2.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/asan.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/62140] [GCC-4.10.0][ASAN] ICE: : in build2_stat, at tree.c:4265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62140 --- Comment #8 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Thu Oct 16 13:53:33 2014 New Revision: 216332 URL: https://gcc.gnu.org/viewcvs?rev=216332root=gccview=rev Log: 2014-10-16 Yury Gribov y.gri...@samsung.com Backport from mainline 2014-09-01 Yury Gribov y.gri...@samsung.com PR sanitizer/61897 PR sanitizer/62140 * asan.c (asan_mem_ref_get_end): Handle non-ptroff_t lengths. (build_check_stmt): Likewise. (instrument_strlen_call): Likewise. (asan_expand_check_ifn): Likewise and fix types. (maybe_cast_to_ptrmode): New function. * c-c++-common/asan/pr62140-1.c: New test. * c-c++-common/asan/pr62140-2.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/pr62140-1.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/pr62140-2.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/asan.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617 Cyrus sidio47 at hotmail dot com changed: What|Removed |Added CC||sidio47 at hotmail dot com --- Comment #40 from Cyrus sidio47 at hotmail dot com --- *** Bug 63561 has been marked as a duplicate of this bug. ***
[Bug libgomp/63561] gfortran runtime hang on function print-stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63561 Cyrus sidio47 at hotmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Cyrus sidio47 at hotmail dot com --- Got it. *** This bug has been marked as a duplicate of bug 30617 ***
[Bug fortran/63553] [OOP] Wrong code when assigning a CLASS to a TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553 patnel97269-gfortran at yahoo dot fr changed: What|Removed |Added CC||patnel97269-gfortran@yahoo. ||fr --- Comment #2 from patnel97269-gfortran at yahoo dot fr --- As I wrote here https://gcc.gnu.org/ml/fortran/2014-10/msg00079.html, I think this case is also related : program toto implicit none type mother integer :: i end type mother type,extends(mother) :: child end type child type(mother) :: tm type(child) :: tc class(mother),allocatable :: cm,cm2 class(child),allocatable :: cc allocate(cm) allocate(child::cm2) cm%i=10 select type (cm2) type is (child) cm2%mother=cm end select print *,'class cm2 is type tm',extends_type_of(cm2,tm) print *,'class cm2 is class cm',extends_type_of(cm2,cm) print *,'class cm2 is type tc',extends_type_of(cm2,tc) print *,'class cm2 is class cc',extends_type_of(cm2,cc) print *,'cm2=cm', cm%i,cm2%i end program
[Bug target/61770] march=native detects corei7-avx on non avx cpu (Celeron 847)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61770 --- Comment #2 from Mikael Pettersson mikpelinux at gmail dot com --- (In reply to R. Dragone from comment #1) Just encountered the same problem myself. gcc -march=native -E -v - /dev/null 21 | grep cc1 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.3/cc1 -E -quiet -v - -march=corei7-avx -mcx16 -msahf -mno-movbe -mno-aes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -march=corei7-avx -mno-avx -mno-avvx2 looks strange, but should (in principle) work. Is there an actual code generation error (avx code erroneously emitted)? 4.7 is no longer maintained, please check if 4.8.3 and 4.9.1 have the same issue.
[Bug go/63560] __go_set_defer_retaddr shouldn't be split by IPA split
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63560
--- Comment #1 from Jan Hubicka hubicka at ucw dot cz ---
Does something like this work?
Honza
Index: ipa-split.c
===
--- ipa-split.c(revision 216318)
+++ ipa-split.c(working copy)
@@ -1613,6 +1613,19 @@ execute_split_functions (void)
return 0;
}
+ if (lookup_attribute (noinline, DECL_ATTRIBUTES (current_function_decl)))
+{
+ if (dump_file)
+fprintf (dump_file, Not splitting: function is noinline.\n);
+ return 0;
+}
+ if (lookup_attribute (section, DECL_ATTRIBUTES (current_function_decl)))
+{
+ if (dump_file)
+fprintf (dump_file, Not splitting: function is in user defined
section.\n);
+ return 0;
+}
+
/* We enforce splitting after loop headers when profile info is not
available. */
if (profile_status_for_fn (cfun) != PROFILE_READ)
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #17 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #16) Created attachment 33733 [details] patch to fix darwin bootstrap With pseudo GOT register we don't need to set GOT register after any jump, and therefore don't need nonlocal_goto_receiver and builtin_setjmp_receiver for i386. Please try attached patch (just removing nonlocal_goto_receiver and builtin_setjmp_receiver from i386.md). With the patch bootstrap fails with ld: illegal text reloc in 'std::strstream::strstream()' to 'construction vtable for std::basic_ostreamchar, std::char_traitschar -in-std::strstream' for architecture x86_64 collect2: error: ld returned 1 exit status It's possible that this ^ is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 (investigating)… once we get past this .. I suppose someone should try a bootstrap on i686-darwin .. will try to fit that in later.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #18 from Stupachenko Evgeny evstupac at gmail dot com --- Created attachment 33736 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736action=edit patch disabling just nonlocal_goto_receiver split Am I correct that this is 64 bits library link failed? If so it is really strange, because the patch removes patterns under !TARGET_64BIT. Can you please try more conservative patch disabling just nonlocal_goto_receiver split bootstrapping it from scratch?
[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-16
CC||ccoutant at google dot com,
||jakub at redhat dot com,
||jason at redhat dot com
Ever confirmed|0 |1
--- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org ---
OK, the problem seems to be that dwarf2out tries to produce RTL for a variable
that is optimized out. This happens here:
/* Try harder to get a rtl. If this symbol ends up not being emitted
in the current CU, resolve_addr will remove the expression referencing
it. */
if (rtl == NULL_RTX
TREE_CODE (decl) == VAR_DECL
!DECL_EXTERNAL (decl)
TREE_STATIC (decl)
DECL_NAME (decl)
!DECL_HARD_REGISTER (decl)
DECL_MODE (decl) != VOIDmode)
{
rtl = make_decl_rtl_for_debug (decl);
if (!MEM_P (rtl)
|| GET_CODE (XEXP (rtl, 0)) != SYMBOL_REF
|| SYMBOL_REF_DECL (XEXP (rtl, 0)) != decl)
rtl = NULL_RTX;
}
producing RTL brings the function in, because it wants to work out its section
that breaks. I do not think dwarf2out really needs RTL for variable that was
never output.
Shall we kludge around and make make_decl_rtl-for_debug to not ICE but return
sort of random RTL or shall we just prevent this path with reference_to_unused
check?
For Martin and Trevor, I think safe workaround is to just comment out this
path.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #19 from Dominique d'Humieres dominiq at lps dot ens.fr --- Can you please try more conservative patch disabling just nonlocal_goto_receiver split bootstrapping it from scratch? It still get the same error/warnings as in comment 16 with the conservative patch.
[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #3)
OK, the problem seems to be that dwarf2out tries to produce RTL for a
variable that is optimized out. This happens here:
/* Try harder to get a rtl. If this symbol ends up not being emitted
in the current CU, resolve_addr will remove the expression referencing
it. */
if (rtl == NULL_RTX
TREE_CODE (decl) == VAR_DECL
!DECL_EXTERNAL (decl)
TREE_STATIC (decl)
DECL_NAME (decl)
!DECL_HARD_REGISTER (decl)
DECL_MODE (decl) != VOIDmode)
{
rtl = make_decl_rtl_for_debug (decl);
if (!MEM_P (rtl)
|| GET_CODE (XEXP (rtl, 0)) != SYMBOL_REF
|| SYMBOL_REF_DECL (XEXP (rtl, 0)) != decl)
rtl = NULL_RTX;
}
producing RTL brings the function in, because it wants to work out its
section that breaks. I do not think dwarf2out really needs RTL for variable
that was never output.
Shall we kludge around and make make_decl_rtl-for_debug to not ICE but
return sort of random RTL or shall we just prevent this path with
reference_to_unused check?
For Martin and Trevor, I think safe workaround is to just comment out this
path.
Commenting that out will severely decrease debug info quality.
Yes, dwarf2out really needs a RTL for those, and some that will not affect
-fcompare-debug, with the right (mangled?) name of the var and various other
attributes on the MEM.
Re: [Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64
Commenting that out will severely decrease debug info quality. It was meant as a workaround for PPC Firefox builds ;) Yes, dwarf2out really needs a RTL for those, and some that will not affect -fcompare-debug, with the right (mangled?) name of the var and various other attributes on the MEM. Why are those needed for variables that was fully optimized out? Mangled name is acccessible via DECL_ASSEMBLER_NAME, so it may be prettier if dwarf2out took it directly from DECL rather than going to RTL. I suppose one can bypass the whole ancros machinery for those and avoid the ICE. Produced RTL however won't be useful for any real work on it. Honza
[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz --- Commenting that out will severely decrease debug info quality. It was meant as a workaround for PPC Firefox builds ;) Yes, dwarf2out really needs a RTL for those, and some that will not affect -fcompare-debug, with the right (mangled?) name of the var and various other attributes on the MEM. Why are those needed for variables that was fully optimized out? Mangled name is acccessible via DECL_ASSEMBLER_NAME, so it may be prettier if dwarf2out took it directly from DECL rather than going to RTL. I suppose one can bypass the whole ancros machinery for those and avoid the ICE. Produced RTL however won't be useful for any real work on it. Honza
[Bug target/61713] ICE when building c++ code with atomic functions for thumb1 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61713 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 Known to fail|4.10.0 |5.0 --- Comment #8 from ktkachov at gcc dot gnu.org --- This has been fixed on trunk and 4.9
[Bug tree-optimization/63563] New: [4.9/5 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5106 with -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63563
Bug ID: 63563
Summary: [4.9/5 Regression] ICE: in vectorizable_store, at
tree-vect-stmts.c:5106 with -mavx2
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
A gentoo user emailed me the following testcase:
markus@x4 ~ % cat blub.ii
struct A
{
unsigned long m_count;
unsigned long m_sum;
unsigned long m_min;
unsigned long m_max;
void
m_fn1 (A *p1)
{
m_count = m_sum = m_min = p1-m_min;
if (__builtin_expect (m_max, 0))
m_max = p1-m_max;
}
};
struct B
{
A m_stat[];
void
m_fn2 ()
{
A *a = m_stat[0];
A b, c = m_stat[0];
for (; a b; a++)
a-m_fn1 (c);
}
};
struct C
{
B m_lock_stat;
void
m_fn3 ()
{
m_lock_stat.m_fn2 ();
}
};
struct PFS_table_share
{
C m_table_stat;
} d;
void
PFS_tablesafe_aggregate_io ()
{
d.m_table_stat.m_fn3 ();
}
markus@x4 ~ % g++ -O3 -mavx2 -c blub.ii
blub.ii: In function ‘void PFS_tablesafe_aggregate_io()’:
blub.ii:41:1: internal compiler error: in vectorizable_store, at
tree-vect-stmts.c:5106
PFS_tablesafe_aggregate_io ()
^
0xdeba83 vectorizable_store
../../gcc/gcc/tree-vect-stmts.c:5106
0xdf0371 vect_analyze_stmt(gimple_statement_base*, bool*, _slp_tree*)
../../gcc/gcc/tree-vect-stmts.c:7105
0xdfbc91 vect_analyze_loop_operations
../../gcc/gcc/tree-vect-loop.c:1505
0xdfbc91 vect_analyze_loop_2
../../gcc/gcc/tree-vect-loop.c:1766
0xdfbc91 vect_analyze_loop(loop*)
../../gcc/gcc/tree-vect-loop.c:1864
0xe113f7 vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:432
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 lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- When this code is invoked, DECL_RTL for some variable might not be set yet, even when it will or might be set later on (e.g. TLS vars), e.g. when compiling some other function. So, we need some RTL for it but not set the rtl on the actual decl.
Re: [Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64
Here we die because we do not have variable constructor in LTO stream because the variable was optimized out at compile time already. Do we still need to build RTL here? We can easily check for optimized out vars... But if we need a placeholder RTL, I suppose most practical variant would be to avoid get_variable_section from ICEing for those optimized out vars and just assume something (it is all about decision whether the var will be in rodata/rodata.rel or rodata.rel.local - definitely not relevant for dwarf2out)
[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546 --- Comment #7 from Jan Hubicka hubicka at ucw dot cz --- Here we die because we do not have variable constructor in LTO stream because the variable was optimized out at compile time already. Do we still need to build RTL here? We can easily check for optimized out vars... But if we need a placeholder RTL, I suppose most practical variant would be to avoid get_variable_section from ICEing for those optimized out vars and just assume something (it is all about decision whether the var will be in rodata/rodata.rel or rodata.rel.local - definitely not relevant for dwarf2out)
[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546
--- Comment #8 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
this patch should avoid production of RTL only for those vars that we know are
never used by real code.
Index: dwarf2out.c
===
--- dwarf2out.c (revision 216317)
+++ dwarf2out.c (working copy)
@@ -15755,7 +15755,9 @@ rtl_for_decl_location (tree decl)
TREE_STATIC (decl)
DECL_NAME (decl)
!DECL_HARD_REGISTER (decl)
- DECL_MODE (decl) != VOIDmode)
+ DECL_MODE (decl) != VOIDmode
+ (symtab-state = CONSTRUCTION
+ || varpool_node::get (decl)))
{
rtl = make_decl_rtl_for_debug (decl);
if (!MEM_P (rtl)
[Bug sanitizer/63564] New: -fsanitize=address obscures access to free memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564 Bug ID: 63564 Summary: -fsanitize=address obscures access to free memory Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de 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 Created attachment 33737 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33737action=edit test example with sem_post to free memory Hi, apparently the address sanitizer does not check the sem_post, sem_wait and similar if the memory is free or the semaphore already deleted. what makes this worse, is that the attached example crashes in the following malloc but works with -fsanitize=address. gcc -pthread test.c ./a.out Segmentation fault (core dumped) = app crashes in malloc, not in sem_post! gcc -pthread -fsanitize=address test.c ./a.out = works, and sanitizer fixes the malloc!
[Bug sanitizer/63564] -fsanitize=address obscures access to free memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- You would need glibc compiled with -fsanitize=address (unless the write is done in assembly) to detect that. And, the reason that glibc malloc reports the problem is that it performs some cheap checks, in particular if you happen to overwrite glibc malloc's internal data structures, it will sometimes be able to cheaply detect that and report. asan malloc doesn't have anything like that. Expecting that -fsanitize=address will reveal all issues in your code is unrealistic.
[Bug sanitizer/63564] -fsanitize=address obscures access to free memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564 --- Comment #2 from Kostya Serebryany kcc at gcc dot gnu.org --- We don't intercept sem_post/sem_wait and don't instrument glibc where they are implemented. Sadly, the same applies to quite a few other glibc functions. In future we may have fully instrumented glibc, but in the meantime we need to add more interceptors. Patches are welcome, see https://code.google.com/p/address-sanitizer/wiki/HowToContribute Most likely sanitizer_common/sanitizer_common_interceptors.inc will need to be modified.
[Bug go/63560] __go_set_defer_retaddr shouldn't be split by IPA split
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63560 --- Comment #2 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Thu Oct 16 17:17:40 2014 New Revision: 216341 URL: https://gcc.gnu.org/viewcvs?rev=216341root=gccview=rev Log: PR go/63560 compiler: Mark functions that call defer_retaddr as not inlinable. This is to that the GCC middle-end won't split them. See http://gcc.gnu.org/PR63560. Modified: trunk/gcc/go/gofrontend/gogo.cc trunk/gcc/go/gofrontend/gogo.h trunk/gcc/go/gofrontend/statements.cc
[Bug sanitizer/63564] -fsanitize=address obscures access to free memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564 --- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de --- In the original example (it was ported from windows, and the windows semaphores are completely immune against this kind of error) the sem_post were in *another* thread and there were several milliseconds between the free the next malloc. So this is already a really, really hard to find bug. But what I don't understand, why the malloc does *not* crash when address sanitizer is used. The same for thread sanitizer, it does not spot the error, and the error does not happen in debug builds only in release builds.
[Bug sanitizer/63564] -fsanitize=address obscures access to free memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564 --- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #3) In the original example (it was ported from windows, and the windows semaphores are completely immune against this kind of error) the sem_post were in *another* thread and there were several milliseconds between the free the next malloc. So this is already a really, really hard to find bug. But what I don't understand, why the malloc does *not* crash when address sanitizer is used. If the program has undefined behavior then the program's behavior is, well, undefined. You can not expect malloc to crash if there is a bug in the code. asan's malloc does not rely on malloc headers for bookeeping so it did not crash. The same for thread sanitizer, it does not spot the error, and the error does not happen in debug builds only in release builds. Good point. tsan does intercept sem_post/sem_wait but does not detect when there is a use-after-free on it (we do it for pthread_mutex_lock though). Dmitry, You may want to add that to tsan.
[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #34 from Oleg Endo olegendo at gcc dot gnu.org --- Test run for -m2e -ml, -m2a -mb, -m2a-single -mb, -m4-single-ml has finished and shows no new failures (except the ISR stuff).
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #20 from Iain Sandoe iains at gcc dot gnu.org --- so I rewound to r216156 and made the change to i386.md (removed the receiver and nonlocal label stuff). So, that succeeds in getting to stage #3 and then fails building [m32] target libs which is much more likley to be fallout from these changes. (Transcript below) Note that there is some PIC register handling in common code for darwin (config/darwin.c) - is it possible that a required change has been missed? meanwhile, I'll try and track down what appears to be a second bootstrap crasher in the same window = libtool: compile: /GCC/ml/gcc-trunk-appleas/./gcc/xgcc -B/GCC/ml/gcc-trunk-appleas/./gcc/ -B/compilers/gcc-trunk/x86_64-apple-darwin12/bin/ -B/compilers/gcc-trunk/x86_64-apple-darwin12/lib/ -isystem /compilers/gcc-trunk/x86_64-apple-darwin12/include -isystem /compilers/gcc-trunk/x86_64-apple-darwin12/sys-include -DHAVE_CONFIG_H -I. -I/GCC/gcc-trunk/libquadmath -I /GCC/gcc-trunk/libquadmath/../include -g -O2 -m32 -MT math/frexpq.lo -MD -MP -MF math/.deps/frexpq.Tpo -c /GCC/gcc-trunk/libquadmath/math/frexpq.c -fno-common -DPIC -o math/.libs/frexpq.o /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:68:non-relocatable subtraction expression, LC0 minus L1$pb /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:68:symbol: L1$pb can't be undefined in a subtraction expression /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:unknown:Undefined local symbol L1$pb make[6]: *** [math/frexpq.lo] Error 1 make[5]: *** [all] Error 2
[Bug target/59888] Darwin linker error illegal text-relocation with -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 --- Comment #9 from Iain Sandoe iains at gcc dot gnu.org --- do we have a revision # that triggered this behaviour? (or has it always been there?)
[Bug sanitizer/63559] -fsanitize=thread sets no preprocessor flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63559 --- Comment #2 from Roger Orr rogero at howzatt dot demon.co.uk --- Hi Dmitry, the false positives I've investigated seem to be down to spin-locked queues and use of intel tbb concurrency data structures - AFAICT we don't have source for the latter so I wouldn't expect tsan to resolve either of them.
[Bug target/59888] Darwin linker error illegal text-relocation with -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- do we have a revision # that triggered this behaviour? (or has it always been there?) Up to r189986 (2012-07-30) compiling the second code in comment 6 gives the error pr59888_3.f90:5.22: call gee(c_funloc(gee)) 1 Error: Parameter 'gee' to 'c_funloc' at (1) must be BIND(C) After r190090 (2012-08-02) compiling the same code gives ld: illegal text-relocation to '___foo_MOD_gee' in /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccutec2S.o from 'anon' in /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccutec2S.o for architecture x86_64 collect2: error: ld returned 1 exit status Probably 2012-07-31 Tobias Burnus bur...@net-b.de * interface.c (gfc_procedure_use): Return gfc_try instead of void. * gfortran.h (gfc_procedure_use): Update prototype. * resolve.c (gfc_iso_c_func_interface): Allow noninteroperable procedures for c_funloc for TS29113. * (gfc_iso_c_sub_interface): Ditto for c_f_procpointer. Add diagnostic for c_ptr vs. c_funptr for c_f_(proc)pointer.
[Bug target/59888] Darwin linker error illegal text-relocation with -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- The change occurred at r190003 and an error Error: TS 29113: Noninteroperable argument 'gee' to 'c_funloc' at (1) is emitted if one uses -std=f2008.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #21 from Igor Zamyatin izamyatin at gmail dot com --- (In reply to Iain Sandoe from comment #20) libtool: compile: /GCC/ml/gcc-trunk-appleas/./gcc/xgcc -B/GCC/ml/gcc-trunk-appleas/./gcc/ -B/compilers/gcc-trunk/x86_64-apple-darwin12/bin/ -B/compilers/gcc-trunk/x86_64-apple-darwin12/lib/ -isystem /compilers/gcc-trunk/x86_64-apple-darwin12/include -isystem /compilers/gcc-trunk/x86_64-apple-darwin12/sys-include -DHAVE_CONFIG_H -I. -I/GCC/gcc-trunk/libquadmath -I /GCC/gcc-trunk/libquadmath/../include -g -O2 -m32 -MT math/frexpq.lo -MD -MP -MF math/.deps/frexpq.Tpo -c /GCC/gcc-trunk/libquadmath/math/frexpq.c -fno-common -DPIC -o math/.libs/frexpq.o /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:68:non- relocatable subtraction expression, LC0 minus L1$pb /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:68:symbol: L1$pb can't be undefined in a subtraction expression /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:unknown: Undefined local symbol L1$pb make[6]: *** [math/frexpq.lo] Error 1 make[5]: *** [all] Error 2 Can we look at the rtl dumps and probably asm file?
[Bug target/59888] Darwin linker error illegal text-relocation with -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 --- Comment #12 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #11) The change occurred at r190003 and an error Error: TS 29113: Noninteroperable argument 'gee' to 'c_funloc' at (1) is emitted if one uses -std=f2008. I realize that in simplifying the testcase, I made it non-standard conforming. Try the same revisions with the amended program below, I fear the error message might be a red herring: module foo contains subroutine bar use, intrinsic :: iso_c_binding call gee(c_funloc(gee)) end subroutine subroutine gee(f) bind(c) use, intrinsic :: iso_c_binding type(c_funptr) :: f end subroutine end module foo
[Bug go/63565] New: please document that (and why) Go binaries should not be stripped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63565 Bug ID: 63565 Summary: please document that (and why) Go binaries should not be stripped Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at gcc dot gnu.org CC: cmang at google dot com please document that (and why) Go binaries should not be stripped. the standard action for distributions is to strip binaries unconditionally, however there are some issues seen when binaries are stripped. The Debian and Ubuntu builds strip libgo itself, which seems to work fine, but stripping some applications leads to errors. So it would be good to know which information can be safely stripped, and which not.
