[Bug rtl-optimization/63475] Postreload CSE propagates aliased memory operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-14 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #5 from Uroš Bizjak --- Patch at [1] [1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01209.html
[Bug tree-optimization/63464] compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464 --- Comment #11 from rguenther at suse dot de --- On Mon, 13 Oct 2014, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464 > > --- Comment #9 from Jakub Jelinek --- > Created attachment 33697 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33697&action=edit > gcc5-pr63464.patch > > WIP patch. What is missing: > 1) the optimize_range_tests_to_bit_test call should be guarded by > lshift_cheap_p (), Richard, any preference on where to declare that function > (tree-switch-conversion.h and include that in tree-ssa-reassoc.c, somewhere > else?) In optabs.[ch]? > 2) much more importantly, it right now doesn't actually fixup the IL, so > instead of the desirable jump around the shift we have there just > BIT_IOR_EXPR (and the shift actually happens to be done first, before > the range test). Richard, any preference how to represent it in the IL > from in between the optimization and fixup once all bbs are > reassociated? I've been thinking about e.g. some pass-through internal > call on the TRUTH_ORIF_EXPR operand. Another option might be, if we'd > adjust update_range_test, so that it would not only emit a > gimplification of the range test, but also an optional gimple_seq before > that, would be to push all the SSA_NAMEs that would be otherwise passed > to the internal call, into some vector, and just split bb after the def > stmt of those SSA_NAMEs and also before the (single, hopefully) user of > that SSA_NAME, adding an edge around the middle of the bb and PHI. Can't you "queue" the BIT_IOR_EXPR stmt somewhere and after reassoc finished split the BBs as desired? Richard.
[Bug tree-optimization/63512] [5 Regression] ICE: error: virtual use of statement not up-to-date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63512 --- Comment #3 from Richard Biener --- Author: rguenth Date: Tue Oct 14 07:36:02 2014 New Revision: 216174 URL: https://gcc.gnu.org/viewcvs?rev=216174&root=gcc&view=rev Log: 2014-10-14 Richard Biener PR tree-optimization/63512 * tree-ssa-pre.c (create_expression_by_pieces): Mark stmts modified. * g++.dg/torture/pr63512.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr63512.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/63512] [5 Regression] ICE: error: virtual use of statement not up-to-date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63512 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug c++/63531] gcc segfaults on some sourcefiles when using '-Weffc++' and '-fsanitize=undefined' together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63531 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-14 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.2 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- I'll take a look.
[Bug target/63527] [5 Regression] -fPIC uses 2 registers for GOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63527 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |5.0
[Bug target/63442] [AArch64] ICE with ubsan/overflow-int128.c test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442 Ramana Radhakrishnan changed: What|Removed |Added Keywords||ice-on-valid-code Target||aarch64-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-14 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 Build||x86_64-none-linux-gnu --- Comment #3 from Ramana Radhakrishnan --- Update target for searches to actually work.
[Bug c++/63532] New: Cannot increase access of member function template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63532
Bug ID: 63532
Summary: Cannot increase access of member function template.
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at qult dot net
The following code is rejected by GCC while it is accepted by Clang.
struct Foo {
template
voidmeth();
};
struct Bar : private Foo {
using Foo::meth;
};
int main()
{
(void) &Bar::meth;
}
GCC accepts a variant where Foo::meth is a plain (i.e., non-template) member
function.
[Bug c++/63532] Cannot increase access of member function template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63532 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-14 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- G++ accepts the using declaration but it seems to have no effect when forming a pointer to member for a specialization: in.cc: In function ‘int main()’: in.cc:3:11: error: ‘void Foo::meth() [with = int]’ is inaccessible voidmeth(); ^ in.cc:12:16: error: within this context (void) &Bar::meth; ^
[Bug ipa/63533] New: Function splitter causes unnecessary splits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533 Bug ID: 63533 Summary: Function splitter causes unnecessary splits Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: y.gribov at samsung dot com CC: hubicka at gcc dot gnu.org, khlebnikov at openvz dot org, ryabinin.a.a at gmail dot com Created attachment 33712 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33712&action=edit Short repro The attached reprocase contains an innocent function which can not ever benefit from inlining. But fnsplit pass still jumps on it and splits it to two functions thus hurting performance and code size: gcc -O2 -fconserve-stack -S repro.i -o- ...g.part.0: ... g: ... callg.part.0 This can not be recovered later by inliner because of -fconserve-stack option. The reprocase is a reduced version of a real-world code (from Linux kernel).
[Bug ipa/63533] Function splitter causes unnecessary splits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533 Yury Gribov changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #1 from Yury Gribov --- Created attachment 33713 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33713&action=edit Draft patch Here is a draft patch. If this makes sense I'll regtest and send to gcc-patches.
[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 #22 from Oleg Endo --- (In reply to Oleg Endo from comment #21) > (In reply to Oleg Endo from comment #17) > > > > In the 'addsf3_i' pattern, I've tried replacing the > > > > (use (match_operand:PSI 3 "fpscr_operand" "c")) > > > > with > > > > (set (match_operand:PSI 3 "fpscr_operand" "=&c") > > (unspec:PSI [(match_dup 3)] UNSPEC_FPSCR_SET))] > > > > > > I haven't checked all the other side effects it could have, but at least the > > FMA combine patterns still seem work after that change. > > With those changes above applied to all the other FP insns, the FMA tests in > gcc.target/sh fail. As well as some of the FSCA tests. E.g. 'return sinf (x) + cosf (x)' would expand into two sincos patterns and normally combine would fold them into one. However, it doesn't understand the unspec:PSI stuff and tries to nest it such as: Failed to match this instruction: (parallel [ (set (reg:SI 174) (fix:SI (reg:SF 167))) (set (reg/v:PSI 151 ) (unspec:PSI [ (unspec:PSI [ (reg/v:PSI 151 ) ] UNSPEC_FPSCR) ] UNSPEC_FPSCR)) ]) I've tried adding a predicate that recursively matches those nested unspec:PSI things, which makes combine happy, but then reload would bail out for some reason. Moreover, fp insns that do this (set (match_operand:PSI 3 "fpscr_operand" "=&c") (unspec:PSI [(match_dup 3)] UNSPEC_FPSCR_SET))] won't get eliminated even if their results are unused/dead. I'm trying to come up with some alternative approach.
[Bug target/63534] New: [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Bug ID: 63534
Summary: [5 Regression] Bootstrap failure on x86_64/i686-linux
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: ian at gcc dot gnu.org, kyukhin at gcc dot gnu.org, law at
gcc dot gnu.org,
vmakarov at gcc dot gnu.org
r216154 broke bootstrap on x86_64-linux and i686-linux for me, pretty much
everything in libgo ICEs, including as simple testcases as:
void foo (void) {}
with -m32 -fsplit-stack -fpic (with or without -O?).
Seems the pro_and_epilogue pass adds insn like:
(insn 14 13 15 3 (set (reg:SI 3 bx)
(reg:SI 83)) g2.i:3 90 {*movsi_internal}
(nil))
before a call to __morestack added during the prologue expansion, which of
course isn't right, this is after reload and using a pseudo is not allowed.
Also, looking at a simple testcase like:
void foo (void) { bar (); bar (); }
I see wrong-code for -m32 -O2 -fpic -p:
there is
call*mcount@GOT(%ebx)
before set_got is invoked, so if e.g. the routine is called from executable,
where %ebx can contain pretty much anything, it will crash, or if it is called
from a different shared library, it will access unrelated pointer in that other
shared library's got rather than current library's got.
And lastly, I'm seeing on the same testcase significant code quality regression
with just -m32 -O2 -fpic:
.cfi_startproc
- pushl %ebx
+ pushl %esi
.cfi_def_cfa_offset 8
- .cfi_offset 3, -8
- call__x86.get_pc_thunk.bx
- addl$_GLOBAL_OFFSET_TABLE_, %ebx
- subl$8, %esp
+ .cfi_offset 6, -8
+ pushl %ebx
+ .cfi_def_cfa_offset 12
+ .cfi_offset 3, -12
+ call__x86.get_pc_thunk.si
+ addl$_GLOBAL_OFFSET_TABLE_, %esi
+ subl$4, %esp
.cfi_def_cfa_offset 16
+ movl%esi, %ebx
callbar@PLT
callbar@PLT
- addl$8, %esp
- .cfi_def_cfa_offset 8
+ addl$4, %esp
+ .cfi_def_cfa_offset 12
popl%ebx
.cfi_restore 3
+ .cfi_def_cfa_offset 8
+ popl%esi
+ .cfi_restore 6
.cfi_def_cfa_offset 4
ret
.cfi_endproc
Here, the register allocator makes a bad decision (load the got into %esi
rather than %ebx, both are call saved registers, but we need it in %ebx), and
nothing after LRA fixes it up (postreload, etc.).
Can the problematic commit be reverted and all these issues analyzed and fixed
before it is reapplied?
[Bug libstdc++/59807] mutex misses destructor if non-function call initialization is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807 --- Comment #8 from Jonathan Wakely --- If the target for this is only mingw-w64 then PR 57440 is a dup
[Bug libstdc++/57440] Memory usage with future and std containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #13 from Jonathan Wakely --- dup of PR 59807
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-14 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- It sounds like it would work fine for leaf functions though (really leafs, accounting for things like __morestack or _mcount calls). Confirmed btw.
[Bug libstdc++/59807] mutex misses destructor if non-function call initialization is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Kai Tietz --- Agreed, this bug is duplicate of PR/57440 *** This bug has been marked as a duplicate of bug 57440 ***
[Bug libstdc++/57440] Memory usage with future and std containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 Kai Tietz changed: What|Removed |Added CC||ahanins at gmail dot com --- Comment #14 from Kai Tietz --- *** Bug 59807 has been marked as a duplicate of this bug. ***
[Bug libstdc++/57440] Memory usage with future and std containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #15 from Kai Tietz --- Posted patch to ML for defining _GTHREAD_USE_MUTEX_INIT_FUNC in mingw-w64, and mingw32 case. It is true that posix-threading support for Windows is right now only provided by mingw-w64 based toolchains, nevertheless is the issue a general one on native Windows platforms using posix-threading.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Stupachenko Evgeny changed:
What|Removed |Added
CC||evstupac at gmail dot com
--- Comment #2 from Stupachenko Evgeny ---
Before the changes there were potential bug as morestack call was emitted with
dependency on ebx (which was not set):
(call_insn 28 27 29 3 (call (mem:QI (symbol_ref:SI ("__morestack")) [0 S1 A8])
(const_int 4 [0x4])) ../../../../gcc/libgo/runtime/go-assert.c:15 -1
(nil)
(expr_list (use (reg:SI 3 bx))
(nil)))
Treating morestack as SYMBOL_FLAG_LOCAL resolves the issue.
The following patch should fix go bootstrap:
(bootstaped with --enable-languages=c,c++,fortran,lto,go)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a3ca2ed..6235c4f 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -11999,7 +11999,10 @@ ix86_expand_split_stack_prologue (void)
REG_BR_PROB_BASE - REG_BR_PROB_BASE / 100);
if (split_stack_fn == NULL_RTX)
-split_stack_fn = gen_rtx_SYMBOL_REF (Pmode, "__morestack");
+{
+ split_stack_fn = gen_rtx_SYMBOL_REF (Pmode, "__morestack");
+ SYMBOL_REF_FLAGS (split_stack_fn) |= SYMBOL_FLAG_LOCAL;
+}
fn = split_stack_fn;
/* Get more stack space. We pass in the desired stack space and the
@@ -12044,9 +12047,11 @@ ix86_expand_split_stack_prologue (void)
gcc_assert ((args_size & 0x) == args_size);
if (split_stack_fn_large == NULL_RTX)
- split_stack_fn_large =
- gen_rtx_SYMBOL_REF (Pmode, "__morestack_large_model");
-
+ {
+ split_stack_fn_large =
+ gen_rtx_SYMBOL_REF (Pmode, "__morestack_large_model");
+ SYMBOL_REF_FLAGS (split_stack_fn_large) |= SYMBOL_FLAG_LOCAL;
+ }
if (ix86_cmodel == CM_LARGE_PIC)
{
rtx_code_label *label;
[Bug middle-end/61558] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #13 from Jason Merrill --- (In reply to Jan Hubicka from comment #12) > the problem here is that grokdeclarator call set_decl_tls_model on variable > that is uninstantiated template. > this triggers creation of symbol node for it that is not correct, because > uninstantiated var decls do not correspond to any variables. Right. And this wasn't a problem when the TLS model was stored in the DECL. > I guess similar case may be triggered by section attribute. I would think so; it's just less common. > I wonder if there is reasonably easy way to avoid setting these properties on > DECLs that are not real variables/functions. I suppose the front end could use a different encoding for these properties in templates than in non-templates. Annoying, but probably not that hard. > Other alternative would be to arrange symtab_node::real_symbol_p > to return false on those and make them to bypass assembler name hash. Is > there a way to recognize them from a middle-end? Not currently, I think; perhaps it would make sense to set DECL_ABSTRACT_P on them.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #21 from Kai Tietz --- (In reply to xur from comment #20) > Thanks for the comments. I'll work on this to get it fixed this time. > > Let me understand your idea correctly: > We will have two patches: The first one will check FTW-API and make > the gcov-tool build configurable. > if -disable-gcov-tool is specified, we will not build gcov-tool. > if -enable-gcov-tool is specified, we will build gcov-tool > if neither specified, we will check the FTW-API and build gcovtool if > FTW-API is available. No, we always check if FTW-API is present. The presence of FTW-API should have no impact on case that gcov-tool gets built, or not. Instead gcov-tool should take care that for cases where FTW-API isn't used the specific part of functionality (it is used for file-unlinking) is simply disabled. Otherwise the standard code-path should be used. Btw, as I already mentioned has mingw-w64 flavor the ftw/nftw API on its master version. And it works OOTB with current code. So no need to break that by assuming wild things in configure. > The second patch is to emulate FTW in libiberty for MINGW32? > I'm a little confused here. libiberty is built after the configure. Do > we need to a special handling of MINGW32 in config? Well, if we put that into libiberty, or put it in gcov-tool directly - I would assume that you alway have dependency to libiberty, otherwise you should add it for this tool, as it prevents you from reinventing the wheel again. Anyway this part is something different and should be handled via the ML and not via the bug-tracker. > Thanks, > > -Rong
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #3 from Jakub Jelinek --- For -fsplit-stack you are right, __morestack seems to have hidden visibility, so even if gcc emits call __morestack@plt, the linker should transform that into a direct call __morestack which doesn't need %ebx set up. Profiling -fpic code would still remain broken though.
[Bug debug/63285] [4.9 Regression] -fcompare-debug scheduler related failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63285 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug target/62025] [4.9/5 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #24 from Jakub Jelinek --- Should be fixed for 4.9.2+.
[Bug fortran/63535] New: SELECT TYPE shouldn't pass ALLOCATABLE/POINTER attribute through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63535 Bug ID: 63535 Summary: SELECT TYPE shouldn't pass ALLOCATABLE/POINTER attribute through Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org >From https://groups.google.com/forum/#!topic/comp.lang.fortran/mv0SN_T_2xI The following compiles and write "1", but it should be rejected. (Printing 1 instead of "2" is also odd from a user perspective.) Quoting Wolfgang Kilian: "The attributes of the associating entity are listed in 8.1.3.3 of the F2008 standard. (Maybe some other clauses also apply.) The ALLOCATABLE attribute is not among the possible attributes for the associating entity. (Neither is POINTER.)" program test class(*), allocatable :: a(:) allocate(real :: a(1)) select type(a) type is(real) deallocate(a) allocate(a(2)) class default stop "error" end select print *,size(a) end
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #4 from Stupachenko Evgeny ---
Profiling implementation has hard coded "%ebx" use.
There are at least 2 quick solutions to resolve this:
1. Disable the changes for PIC profiling
Lead to different behavior with and without profiling of code with EBX asm
insertions. However could be applied as temporary solution as there are no EBX
asm insertions right now.
2.
print:
push %ebx
call__x86.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
and pop %ebx at the end
Here:
else if (flag_pic)
{
#ifndef NO_PROFILE_COUNTERS
fprintf (file, "\tleal\t%sP%d@GOTOFF(%%ebx),%%" PROFILE_COUNT_REGISTER
"\n",
LPREFIX, labelno);
#endif
fprintf (file, "1:\tcall\t*%s@GOT(%%ebx)\n", mcount_name);
}
Lower profiling performance in PIC mode.
I vote for the second solution and can prepare patch for this.
[Bug target/62308] A bug with aarch64 big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308 --- Comment #8 from Vladimir Makarov --- (In reply to Venkataramanan from comment #7) > Where reload gets > > (set (reg:DI 0 x0 [76]) (reg:DI 1 x1 [ args+8 ])) > (set (reg:TI 0 x0 [74]) (reg:TI -1 [+-8 ]) > > Looks same issue to me. > > Vladimir can you please confirm. Now as I am less busy with the rematerialization pass, I'll look at this problem on this week. Thanks.
[Bug ipa/63533] Function splitter causes unnecessary splits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-14 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Jan Hubicka --- If g is called with argument that is usually 0, then the partial inlining makes sense. I guess it is a problem that we try to apply stack size limit to prevent inlining of .part into the original function body. Pehraps inliner should special case this and bypass the limits?
[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432 --- Comment #29 from Teresa Johnson --- On Mon, Oct 13, 2014 at 2:32 PM, Teresa Johnson wrote: > On Mon, Oct 13, 2014 at 8:53 AM, hjl.tools at gmail dot com > wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432 >> >> --- Comment #27 from H.J. Lu --- >> (In reply to Teresa Johnson from comment #24) >> >>> Arg, looks very similar so maybe another instance of the duplicate >>> threading is slipping through? My own lto profiled bootstrap succeeded >>> with my patch. I will try updating to r216039 and redo it to see if I >>> can provoke the same failure. >>> >> >> I sent you another testcase against r216150. > > Thanks for the testcase, I reproduced it. It is a case of garbage in / > garbage out. The fre2 pass is introducing some big profile count > insanities, leading to the probability insanity being introduced when > we try to use the counts to compute the new probability in > recompute_probabilities. There is already handling for really large > probabilities due to this issue, and we need to add the same thing for > negative probabilities - essentially the patch you had originally > suggested for the first problem which wasn't necessary for that one > since that was an actually jump threading induced issue. Actually, I traced the initial profile insanity back to inlining. FRE merely propagated it further. I have a better overflow test done before the scaling, running it through LTO profiledbootstrap then will send for review. Teresa > > Will test that and send for review. > >> >> -- >> You are receiving this mail because: >> You are on the CC list for the bug. > > > > -- > Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
[Bug ipa/63533] Function splitter causes unnecessary splits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533 --- Comment #3 from Yury Gribov --- > If g is called with argument that is usually 0, > then the partial inlining makes sense. But note that there are zero callers of g in the file so no inlining can happen anyway. Frankly I was surprised to see this !address_taken there, what's the reasoning behind it? > I guess it is a problem that we try to apply stack size limit > to prevent inlining of .part into the original function body. Exactly. > Perhaps inliner should special case this and bypass the limits? You mean ignore stack limits if we somehow know that callee was originally part of the caller? Probably could be done but looks somewhat hacky.
[Bug bootstrap/63536] New: [5 Regression] bootstrap failed when configured with --with-cpu=slm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63536 Bug ID: 63536 Summary: [5 Regression] bootstrap failed when configured with --with-cpu=slm Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: evstupac at gmail dot com On Linux/x86, r216154 failed to bootstrap when configured with --with-cpu=slm: .../configure --with-arch=corei7 --with-cpu=intel --prefix=/usr/5.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld i686-linux --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,ob ../../../src-trunk/libjava/jvmti.cc: In function âjvmtiError _Jv_JVMTI_AddToBootstrapClassLoaderSearch(jvmtiEnv*, const char*)â: make[6]: *** [classpath/tools/libgcj_tools_la-tools.lo] Error 1 make[5]: *** [all-recursive] Error 1 make[4]: *** [all-target-libjava] Error 2 make[3]: *** [bootstrap] Error 2 make[2]: *** [bootstrap] Error 2 from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Main.java:144, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Main.java:202, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Messages.java:64, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Entry.java:68, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Main.java:114, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Main.java:209, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Main.java:235, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Lister.java:111, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Action.java:47, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Main.java:172, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Updater.java:96, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Main.java:242, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Creator.java:250, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/tnameserv/Main.java:62, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/tnameserv/Main.java:75, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/tnameserv/Main.java:85, from ../../../../../src-trunk/libjava/classpath/tools/gnu/classpath/tools/tnameserv/Messages.java:65, from ../../../../../src-trunk/libjava/classpath/tools/sun/rmi/rmic/Main.java:58, from ../../../../../src-trunk/libjava/classpath/tools/sun/rmi/rmic/Messages.java:64, from com/sun/javadoc/SerialFieldTag.java:1, from com/sun/javadoc/ConstructorDoc.java:1, from com/sun/javadoc/ThrowsTag.java:1, from com/sun/javadoc/Doc.java:1, from com/sun/javadoc/Doclet.java:95, from com/sun/javadoc/MemberDoc.java:1, from com/sun/javadoc/DocErrorReporter.java:0, from com/sun/javadoc/TypeVariable.java:0, from com/sun/javadoc/RootDoc.java:1, from com/sun/javadoc/ParamTag.java:2, from com/sun/javadoc/PackageDoc.java:1, from com/sun/javadoc/Tag.java:1, from com/sun/javadoc/SeeTag.java:0, from com/sun/javadoc/SourcePosition.java:2, from com/sun/javadoc/ClassDoc.java:1, from com/sun/javadoc/Type.java:1, from com/sun/javadoc/ProgramElementDoc.java:1, from com/sun/javadoc/FieldDoc.java:0, from com/sun/javadoc/ExecutableMemberDoc.java:1, from com/sun/javadoc/MethodDoc.java:0, from com/sun/javadoc/Parameter.java:5, from com/sun/tools/javadoc/Main.java:45, from ../../../../../src-trunk/libjava/classpath/tools/com/sun/tools/javac/Main.java:157, from ../../../../../src-trunk/libjava/classpath/tools/com/sun/tools/javac/Messages.java:64, from ../../../../../src-trunk/libjava/classpath/tools/com/sun/tools/javah/Main.java:57, from com/sun/tools/doclets/Taglet.java:1, from :3: ../../../../../src-trunk/libjava/classpath/tools/external/asm/org/objectweb/asm/xml/ASMContentHandler.java
[Bug bootstrap/63536] [5 Regression] bootstrap failed when configured with --with-cpu=slm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63536 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-14 Target Milestone|--- |5.0 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 #5 from Jakub Jelinek --- Double set_got doesn't make sense, if you want to keep the current model, I'd emit a set_got insn forced into %ebx before the mcount call in the prologue and see if early after the prologue isn't a set_got insn, if there is, see if %ebx isn't clobbered in between the second set_got and end of prologue (or the reg in that second set_got), and if it isn't, just replace the second set_got with a move from %ebx to the reg used there (or, if %ebx is clobbered and the second reg isn't, move in the prologue into that register). Keep the double set_got only in uncommon case where you don't find it or both regs are clobbered early.
[Bug ipa/63533] Function splitter causes unnecessary splits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533 --- Comment #4 from Andrew Pinski --- Note the section of the split function is also different from the original function if the user had supplied a section.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #6 from iverbin at gcc dot gnu.org --- Author: iverbin Date: Tue Oct 14 16:26:57 2014 New Revision: 216208 URL: https://gcc.gnu.org/viewcvs?rev=216208&root=gcc&view=rev Log: PR target/63534 gcc/ * config/i386/i386.c (ix86_expand_split_stack_prologue): Make __morestack local. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug lto/61048] compiling with -fsanitize=address crashes GCC if pointers are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61048 --- Comment #2 from Ilya Palachev --- Suggested a patch that fixes this issue. https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01264.html
[Bug lto/61048] compiling with -fsanitize=address crashes GCC if pointers are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61048 --- Comment #3 from Ilya Palachev --- Created attachment 33714 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33714&action=edit Patch that fixes the ICE.
[Bug libstdc++/57440] Memory usage with future and std containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #16 from Kai Tietz --- Author: ktietz Date: Tue Oct 14 16:58:37 2014 New Revision: 216210 URL: https://gcc.gnu.org/viewcvs?rev=216210&root=gcc&view=rev Log: 2014-10-14 Kai Tietz PR libstdc++/57440 * config/os/mingw32/os_defines.h (_GTHREAD_USE_MUTEX_INIT_FUNC): Define to avoid leak. * config/os/mingw32-w64/os_defines.h: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/os/mingw32-w64/os_defines.h trunk/libstdc++-v3/config/os/mingw32/os_defines.h
[Bug lto/61048] compiling with -fsanitize=address crashes GCC if pointers are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61048 --- Comment #4 from Ilya Palachev --- > g++ test.o -o test -Wl,-flto > /tmp/ccEhycoY.ltrans0.ltrans.o:ccEhycoY.ltrans0.o:function > __static_initialization_and_destruction_0(int, int): error: undefined > reference to '__asan_before_dynamic_init' > /tmp/ccEhycoY.ltrans0.ltrans.o:ccEhycoY.ltrans0.o:function > __static_initialization_and_destruction_0(int, int): error: undefined > reference to '__asan_after_dynamic_init' > collect2: error: ld returned 1 exit status Such error is usual when option -fsanitize=address is not specified at the 2nd stage. For example, without option -flto gcc prints the following error: g++ -c test.cpp -fsanitize=address -o test_nolto.o g++ test_nolto.o -o test_nolto test_nolto.o:test.cpp:function main: error: undefined reference to '__asan_report_load4' test_nolto.o:test.cpp:function __static_initialization_and_destruction_0(int, int): error: undefined reference to '__asan_before_dynamic_init' test_nolto.o:test.cpp:function __static_initialization_and_destruction_0(int, int): error: undefined reference to '__asan_after_dynamic_init' test_nolto.o:test.cpp:function _GLOBAL__sub_D_00099_0_main: error: undefined reference to '__asan_unregister_globals' test_nolto.o:test.cpp:function _GLOBAL__sub_I_00099_1_main: error: undefined reference to '__asan_init_v4' test_nolto.o:test.cpp:function _GLOBAL__sub_I_00099_1_main: error: undefined reference to '__asan_register_globals' collect2: error: ld returned 1 exit status So it seems that above patch provides that gcc produces correct output.
[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54354 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Tue Oct 14 17:01:25 2014 New Revision: 216211 URL: https://gcc.gnu.org/viewcvs?rev=216211&root=gcc&view=rev Log: 2014-10-14 Rüdiger Sonderfeld PR libstdc++/54354 * include/std/iomanip (_Put_time): New struct. (put_time): New manipulator. (operator<<): New overloaded function. * testsuite/27_io/manipulators/extended/put_time/char/1.cc: New. * testsuite/27_io/manipulators/extended/put_time/char/2.cc: New. * testsuite/27_io/manipulators/extended/put_time/wchar_t/1.cc: New. * testsuite/27_io/manipulators/extended/put_time/wchar_t/2.cc: New. Added: trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/put_time/ trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/put_time/char/ trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/put_time/char/1.cc trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/put_time/char/2.cc trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/put_time/wchar_t/ trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/put_time/wchar_t/1.cc trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/put_time/wchar_t/2.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/iomanip
[Bug libstdc++/57440] Memory usage with future and std containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #17 from Kai Tietz --- Author: ktietz Date: Tue Oct 14 17:05:04 2014 New Revision: 216212 URL: https://gcc.gnu.org/viewcvs?rev=216212&root=gcc&view=rev Log: PR libstdc++/57440 * config/os/mingw32/os_defines.h (_GTHREAD_USE_MUTEX_INIT_FUNC): Define to avoid leak. * config/os/mingw32-w64/os_defines.h: Likewise. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/config/os/mingw32-w64/os_defines.h branches/gcc-4_9-branch/libstdc++-v3/config/os/mingw32/os_defines.h
[Bug libstdc++/57440] Memory usage with future and std containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #18 from Kai Tietz --- Author: ktietz Date: Tue Oct 14 17:06:27 2014 New Revision: 216213 URL: https://gcc.gnu.org/viewcvs?rev=216213&root=gcc&view=rev Log: PR libstdc++/57440 * config/os/mingw32/os_defines.h (_GTHREAD_USE_MUTEX_INIT_FUNC): Define to avoid leak. * config/os/mingw32-w64/os_defines.h: Likewise. Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/config/os/mingw32-w64/os_defines.h branches/gcc-4_8-branch/libstdc++-v3/config/os/mingw32/os_defines.h
[Bug libstdc++/57440] Memory usage with future and std containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Kai Tietz --- Applied patch to trunk, and all open branches (4.9, 4.8). Closed as fixed.
[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529
--- Comment #5 from russelldub at gmail dot com ---
> With ifort, are you compiling with whatever flag enforces
> standards conformance. I need to go hunting through the
> standard to see if assumed size arrays are allowed in the
> declaration section of a module.
ifort doesn't complain with -standard-semantics. If I add
-std{f90,f95,f03,f08} then I get a warning about the POINTER statement being
dis-allowed, but it still compiles.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #7 from Jeffrey A. Law --- I'd strongly recommend against option #1 to deal with PIC vs profiling. We don't want to have two distinct implementations for PIC support in 32 bit mode. I've got no strong opinions on Jakub's proposal, or emitting a second set_got after the profiling bits.
[Bug rtl-optimization/63475] Postreload CSE propagates aliased memory operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475 --- Comment #6 from uros at gcc dot gnu.org --- Author: uros Date: Tue Oct 14 18:40:59 2014 New Revision: 216217 URL: https://gcc.gnu.org/viewcvs?rev=216217&root=gcc&view=rev Log: PR rtl-optimization/63475 * alias.c (true_dependence_1): Always use get_addr to extract true address operands from x_addr and mem_addr. Use extracted address operands to check for references with alignment ANDs. Use extracted address operands with find_base_term and base_alias_check. For noncanonicalized operands call canon_rtx with extracted address operand. (write_dependence_1): Ditto. (may_alias_p): Ditto. Remove unused calls to canon_rtx. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c
[Bug tree-optimization/63537] New: Missed optimization: Loop unrolling adds extra copy when returning aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63537
Bug ID: 63537
Summary: Missed optimization: Loop unrolling adds extra copy
when returning aggregate
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Created attachment 33715
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33715&action=edit
Reproducer
At -O2 and above on x86_64, this manually unrolled loop generates much better
code than the automatically unrolled one:
struct vec {
double n[3];
};
struct vec mul_unrolled(struct vec lhs, double rhs) {
struct vec ret;
ret.n[0] = lhs.n[0]*rhs;
ret.n[1] = lhs.n[1]*rhs;
ret.n[2] = lhs.n[2]*rhs;
return ret;
}
This generates the beautiful:
movsd16(%rsp), %xmm2
movq%rdi, %rax
movsd24(%rsp), %xmm1
mulsd%xmm0, %xmm2
mulsd%xmm0, %xmm1
mulsd8(%rsp), %xmm0
movsd%xmm2, 8(%rdi)
movsd%xmm1, 16(%rdi)
movsd%xmm0, (%rdi)
ret
In contrast, at -O2 this:
struct vec mul_loop(struct vec lhs, double rhs) {
struct vec ret;
for (int i = 0; i < 3; ++i) {
ret.n[i] = lhs.n[i]*rhs;
}
return ret;
}
generates this:
movsd8(%rsp), %xmm1
movq%rdi, %rax
mulsd%xmm0, %xmm1
movsd%xmm1, -40(%rsp)
movq-40(%rsp), %rdx
movsd16(%rsp), %xmm1
mulsd%xmm0, %xmm1
movq%rdx, (%rdi)
mulsd24(%rsp), %xmm0
movsd%xmm1, -32(%rsp)
movq-32(%rsp), %rdx
movsd%xmm0, -24(%rsp)
movq%rdx, 8(%rdi)
movq-24(%rsp), %rdx
movq%rdx, 16(%rdi)
ret
which puts the result in -40(%rsp) and then copies it to (%rdi). At -O3 it
gets vectorized but the extra copy is still there:
movapd%xmm0, %xmm1
mulsd24(%rsp), %xmm0
movupd8(%rsp), %xmm2
movq%rdi, %rax
unpcklpd%xmm1, %xmm1
mulpd%xmm1, %xmm2
movsd%xmm0, -24(%rsp)
movaps%xmm2, -40(%rsp)
movq-40(%rsp), %rdx
movq%rdx, (%rdi)
movq-32(%rsp), %rdx
movq%rdx, 8(%rdi)
movq-24(%rsp), %rdx
movq%rdx, 16(%rdi)
[Bug c++/63419] verify_gimple failed: "vector CONSTRUCTOR element is not a GIMPLE value"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63419 Pat Haugen changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #6 from Pat Haugen --- (In reply to Richard Biener from comment #5) > > * g++.dg/torture/pr63419.C: New testcase. The new testcase fails on PowerPC with -m32. From https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg01455.html: FAIL: g++.dg/torture/pr63419.C -O0 (test for excess errors) FAIL: g++.dg/torture/pr63419.C -O1 (test for excess errors) FAIL: g++.dg/torture/pr63419.C -O2 (test for excess errors) ... Simple compile shows warning msgs generated. [pthaugen@igoo testsuite]$ ~/install/gcc/trunk/bin/g++ -c -O0 ~/src/gcc/trunk/gcc/gcc/testsuite/g++.dg/torture/pr63419.C -m32 /home/pthaugen/src/gcc/trunk/gcc/gcc/testsuite/g++.dg/torture/pr63419.C: In member function ‘void I::packet(typename traits >::Index) [with int LoadMode = 0; UnaryOp = D; XprType = L >; typename traits >::Index = int]’: /home/pthaugen/src/gcc/trunk/gcc/gcc/testsuite/g++.dg/torture/pr63419.C:181:5: warning: GCC vector returned by reference: non-standard ABI extension with no compatibility guarantee derived ().functor ().packetOp ( ^ /home/pthaugen/src/gcc/trunk/gcc/gcc/testsuite/g++.dg/torture/pr63419.C: In member function ‘void D::packetOp(C::type)’: /home/pthaugen/src/gcc/trunk/gcc/gcc/testsuite/g++.dg/torture/pr63419.C:39:3: warning: GCC vector passed by reference: non-standard ABI extension with no compatibility guarantee packetOp (C::type) ^
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #21 from Jeffrey A. Law --- It's annoying, but I suspect others see this as so low priority as not to care. As for just committing my patch, I could make an argument that I ought to be able to do that, but we (the project) make a conscious decision to avoid that kind of behaviour, except for well defined areas. I'd consider this on the borderline and I believe it's particularly important that I adhere to the policies the project has put in place over time.
[Bug tree-optimization/62053] [5 Regression] ICE: in remap_type_1, at tree-inline.c:540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62053 --- Comment #7 from Alexander Ivchenko --- The patch fixed the issue for me, thanks!
[Bug target/63538] New: [X86_64] With -mcmodel=medium .lrodata accesses do not use 64-bit addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538
Bug ID: 63538
Summary: [X86_64] With -mcmodel=medium .lrodata accesses do not
use 64-bit addresses
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tmsriram at google dot com
CC: davidxl at google dot com
foo.cc
==
#include
const char *str = "Hello World";
int main() {
printf("str = %p %s\n",str, str);
return 0;
}
$ g++ --save-temps foo.cc -mcmodel=medium -mlarge-data-threshold=0 -O2
Linked with gold linker.
Look at foo.s:
===
.section.lrodata,"a",@progbits
.LC0:
.string "str = %p %s\n"
.
main:
...
movl $.LC0, %edi
This is the problem, it treats .LC0 as a 32-bit address when it should a 64-bit
address since it is placed in .lrodata
Now this bug will not manifest until .lrodata exceeds the 2GB limit. That can
be done by linking with -Wl,-Ttext=0x7000 which moves the start address of
.text to be very close to 2GB and enough to throw .lrodata out of the limit.
Program segfaults.
[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503 --- Comment #8 from Evandro Menezes --- (In reply to Ramana Radhakrishnan from comment #7) > As Evandro doesn't mention flags it's hard to say whether there really is a > problem here or not. Both GCC and LLVM were given "-O3 -ffast-math".
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #22 from Marc Glisse --- There were some comments by Florian: https://gcc.gnu.org/ml/gcc-patches/2014-02/msg00149.html I don't think the patch was ever pinged during stage 1, worth another try...
[Bug ada/62019] [5 Regression] gnat.dg/weak2.adb fails everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62019 --- Comment #5 from Eric Botcazou --- Author: ebotcazou Date: Tue Oct 14 21:04:05 2014 New Revision: 216223 URL: https://gcc.gnu.org/viewcvs?rev=216223&root=gcc&view=rev Log: PR ada/62019 * tree-eh.c (tree_could_trap) : Revamp and really do not choke on null node. : Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-eh.c
[Bug ada/62019] [5 Regression] gnat.dg/weak2.adb fails everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62019 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Botcazou --- .
[Bug sanitizer/59758] [4.9/5 Regression] bootstrap failure in libsanitizer/asan on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758 davem at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from davem at gcc dot gnu.org --- Fixed in 4.9 branch and the trunk.
[Bug tree-optimization/63530] GCC generates incorrect aligned store on ARM after the loop is unrolled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63530
Carrot changed:
What|Removed |Added
CC||carrot at google dot com
--- Comment #1 from Carrot ---
The problem is in 116t.vect pass.
...
67 vector(16) unsigned char * vectp_b.15;
68
70 unsigned SI
71 size
72 unit size
73 align 32 symtab 0 alias set -1 canonical type 0x7f1361b56e70>
74 used unsigned ignored SI file t3.c line 8 col 8
75 size
76 unit size
77 align 32 context >
78 vector(16) unsigned char * vectp_b.14;
79
81 unsigned SI
82 size
83 unit size
84 align 32 symtab 0 alias set -1 canonical type 0x7f1361b56e70>
85 used unsigned ignored SI file t3.c line 8 col 8
86 size
87 unit size
88 align 32 context >
...
100 vector(16) unsigned char vect__7.12;
101
103 unsigned V16QI
104 size
105 unit size
106 align 64 symtab 0 alias set 0 canonical type
0x7f1361b56540 nunits 16
107 pointer_to_this >
108 used unsigned ignored V16QI file t3.c line 8 col 8
109 size
110 unit size
111 align 64 context >
...
223 unsigned char _7;
224 unsigned int _11;
225 unsigned int _15;
226 unsigned int _16;
227 unsigned char _20;
228 unsigned int _23;
229 unsigned int _24;
230 int _32;
231 sizetype _48;
232 unsigned int ivtmp_56;
233 unsigned int ivtmp_57;
234
235 :
236 b_5 = calloc (1, 260);
237 if (n_6(D) <= 255)
238 goto ;
239 else
240 goto ;
241
242 :
243 return b_5;
244
245 :
246 _11 = (unsigned int) n_6(D);
247 niters.3_2 = 256 - _11;
248 _15 = niters.3_2 + 4294967280;
249 _16 = _15 >> 4;
250 bnd.4_10 = _16 + 1;
251 ratio_mult_vf.5_17 = bnd.4_10 << 4;
252 _23 = (unsigned int) n_6(D);
253 _24 = 255 - _23;
254 if (_24 <= 14)
255 goto ;
256 else
257 goto ;
258
259 :
260 stmp_var_.7_33 = n_6(D) + 1;
261 stmp_var_.7_34 = stmp_var_.7_33 + 1;
262 stmp_var_.7_35 = stmp_var_.7_34 + 1;
263 vect_cst_.8_36 = {n_6(D), stmp_var_.7_33, stmp_var_.7_34,
stmp_var_.7_35};
264 vect_cst_.9_37 = { 16, 16, 16, 16 };
265 vect_cst_.11_40 = { 4, 4, 4, 4 };
266 _48 = (sizetype) n_6(D);
267 vectp_b.15_47 = b_5 + _48;
268 vect_cst_.17_8 = { 1, 1, 1, 1 };
269
270 :
271 # n_12 = PHI
272 # vect_vec_iv_.10_38 = PHI
273 # vectp_b.14_49 = PHI
274 # ivtmp_56 = PHI <0(5), ivtmp_57(13)>
275 vect_vec_iv_.10_39 = vect_vec_iv_.10_38 + vect_cst_.9_37;
276 vect_vec_iv_.10_41 = vect_vec_iv_.10_38 + vect_cst_.11_40;
277 vect_vec_iv_.10_42 = vect_vec_iv_.10_41 + vect_cst_.11_40;
278 vect_vec_iv_.10_43 = vect_vec_iv_.10_42 + vect_cst_.11_40;
279 vect__7.13_44 = VEC_PACK_TRUNC_EXPR ;
280 vect__7.13_45 = VEC_PACK_TRUNC_EXPR ;
281 vect__7.12_46 = VEC_PACK_TRUNC_EXPR ;
282 _7 = (unsigned char) n_12;
283 MEM[(unsigned char[256] *)vectp_b.14_49] = vect__7.12_46;
284 vect_n_9.16_52 = vect_vec_iv_.10_38 + vect_cst_.17_8;
285 vect_n_9.16_53 = vect_vec_iv_.10_41 + vect_cst_.17_8;
286 vect_n_9.16_54 = vect_vec_iv_.10_42 + vect_cst_.17_8;
287 vect_n_9.16_55 = vect_vec_iv_.10_43 + vect_cst_.17_8;
288 n_9 = n_12 + 1;
289 vectp_b.14_50 = vectp_b.14_49 + 16;
290 ivtmp_57 = ivtmp_56 + 1;
291 if (ivtmp_57 < bnd.4_10)
292 goto ;
293 else
294 goto ;
295
296 :
297 # n_18 = PHI
298 _20 = (unsigned char) n_18;
299 b_5->map[n_18] = _20;
300 n_22 = n_18 + 1;
301 if (n_22 <= 255)
302 goto ;
303 else
304 goto ;
305
306 :
307 goto ;
308
309 :
310 # n_26 = PHI
311 _32 = (int) ratio_mult_vf.5_17;
312 tmp.6_31 = n_6(D) + _32;
313 if (niters.3_2 == ratio_mult_vf.5_17)
314 goto ;
315 else
316 goto ;
317
318 :
319 # n_25 = PHI
320 goto ;
321
322 :
323
324 :
325 goto ;
326
327 :
328 goto ;
329
330 }
vectp_b is assigned a value a line 267,
267 vectp_b.15_47 = b_5 + _48;
_48 is a passed in parameter, so the pointer value of vectp_b should be
unaligned.
But the declaration of vectp_b is a pointer to type , that is 64bit aligned at line 106.
So the backend generates a 64bit aligned memory access instruction accordingly.
[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503 --- Comment #9 from Evandro Menezes --- (In reply to Wilco from comment #6) > I ran the assembler examples on A57 hardware with identical input. The FMADD > code is ~20% faster irrespectively of the size of the input. This is not a > surprise given that the FMADD latency is lower than the FADD and FMUL > latency. I ran the same Geekbench binaries on A53 and the result is about the same between the GCC and the LLVM code, if with a slight (< 1%) advantage for GCC.
[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 Oleg Endo changed: What|Removed |Added Attachment #33691|0 |1 is obsolete|| --- Comment #23 from Oleg Endo --- Created attachment 33716 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33716&action=edit Using virtual FPSCR registers to model insn dependencies This is a somewhat larger patch which does a couple of things to address the deficits of the previous approach. 1) The hard reg set is extended by two more registers: - FPSCR_MODES_REG represents any mode bits in FPSCR, which are used by fp insns. - FPSCR_STAT_REG represents the status bits in FPSCR, which are written by fp insns. All fp insns that previously had a (use (match_operand:PSI 2 "fpscr_operand" "") now get a (use (reg:SI FPSCR_MODES_REG)) 2) The 'fpu_switch' insn, which is just a FPSCR load/store, now uses and sets the virtual regs FPSCR_MODES_REG and FPSCR_STAT_REG. This creates a sort of reordering barrier due to the reg uses/sets. 3) Two new dummy insns extend_psi_si and truncate_si_psi are added to convert PSIMode <-> SImode, because we can do only logic on SImode, but FPSCR is described as PSImode. This hack could be removed later maybe. 4) The insns toggle_sz and toggle_pr are now also setting the virtual reg FPSCR_MODES_REG. 5) The fsca insn needed some adjustments for the operand matching, as combine started going different paths. Some of the fsca tests in gcc.target/sh were failing and are fixed by this. 6) sh_emit_set_t_insn is adjusted to emit the correct comparison insns with use/set of virtual FPSCR regs. 7) calc_live_regs is adjusted to ignore virtual regs FPSCR_MODES_REG and FPSCR_STAT_REG, or else it will try to generate push/pop insns for those regs. 8) sh_emit_mode_set now emits the FPSCR store-modify-load insn sequence instead of loading FPSCR from __fpscr_values. 9) Some redundant fp insns and related functions are deleted. I've tried to keep the patch as short as possible and not do too many unrelated changes. I haven't fully tested the patch, so there are probably a couple of fallouts. There are two regressions with this patch. The FPSCR loads are not put into delay slots anymore. Probably because the 'fpu_switch' pattern now has too many sets and the DBR rejects that as a slot candidate. The other thing are the failures in gcc.target/sh w.r.t. interrupt functions, which can be addressed later. Kaz, could you please have an early look at it?
[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 --- Comment #35 from Andrew Pinski --- Author: pinskia Date: Wed Oct 15 00:38:03 2014 New Revision: 216229 URL: https://gcc.gnu.org/viewcvs?rev=216229&root=gcc&view=rev Log: 2014-10-14 Andrew Pinski Revert: 2011-08-19 H.J. Lu PR middle-end/49721 * explow.c (convert_memory_address_addr_space): Also permute the conversion and addition of constant for zero-extend. Modified: trunk/gcc/ChangeLog trunk/gcc/explow.c
[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 Oleg Endo changed: What|Removed |Added Attachment #33716|0 |1 is obsolete|| --- Comment #24 from Oleg Endo --- Created attachment 33717 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33717&action=edit Using virtual FPSCR registers to model insn dependencies sh_emit_set_t_insn was producing nested parallel patterns. When compiling libgcc (for -m4 -mb) memory consumption goes up a lot. Either there is a bug in the patch, or it's triggering a bug somewhere else which seems to cause an infinite alloc cycle somewhere.
[Bug go/63539] New: libgo does not use the newly built objcopy when doing a combined build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63539 Bug ID: 63539 Summary: libgo does not use the newly built objcopy when doing a combined build Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: pinskia at gcc dot gnu.org CC: cmang at google dot com I was trying build a go compiler for aarch46 and ran into this issue. I was doing a full combined build with all of GCC/binutils from the trunk. f=`echo container/ring.lo | sed -e 's/.lo$/.o/'`; objcopy -j .go_export $f container/ring.gox.tmp && mv -f container/ring.gox.tmp container/ring.gox objcopy: Unable to recognise the format of the input file `container/ring.o' In this case container/ring.o is an aarch64 elf binary and my host objcopy (2.20) does not understand aarch64 elf files.
[Bug go/63539] libgo does not use the newly built objcopy when doing a combined build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63539 --- Comment #1 from Andrew Pinski --- ranlib works since the toplevel does: checking where to find the target ranlib... just compiled But there is no check for objcopy.
[Bug go/63539] libgo does not use the newly built objcopy when doing a combined build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63539 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-15 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- I think I have a fix which I am going to test.
[Bug c++/63540] New: Erroneous "'Derived' declares a move constructor or move assignment operator" in error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63540
Bug ID: 63540
Summary: Erroneous "'Derived' declares a move constructor or
move assignment operator" in error.
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
Consider the following reduced testcase:
template (0) = 0)> int
break_it();
template int break_it();
struct Base {
Base(const Base &);
void operator=(Base &&);
};
struct Derived : Base {
using Base::operator=;
};
int a = break_it();
Derived v(v);
With a recent 4.9, it fails with an erroneous error:
$ gcc-archive/4.9/215880/bin/g++ --std=gnu++11 t.cc -c -o t.o
t.cc:13:12: error: use of deleted function ‘Derived::Derived(const Derived&)’
Derived v(v);
^
t.cc:8:8: note: ‘Derived::Derived(const Derived&)’ is implicitly declared as
deleted because ‘Derived’ declares a move constructor or move assignment
operator
struct Derived : Base {
^
The same erroneous error occurs on trunk.
The call to 'Derived::operator=' in a SFINAE context within break_it seems to
be confusing GCC about which special members Derived declares.
[Bug c++/63540] Erroneous "'Derived' declares a move constructor or move assignment operator" in error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63540 Paul Pluzhnikov changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #1 from Paul Pluzhnikov --- Google ref: b/17785687
[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 #25 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #23) > Kaz, could you please have an early look at it? The idea looks OK to me. Build fails on sh4-linux with the patch, though. Maybe a wrong version? There is a typo divdf3 expand. s/gen_divdf3 /gen_divdf3_i / - expand_df_binop (&gen_divdf3_i, operands); + emit_insn (gen_divdf3 (operands[0], operands[1], operands[2])); With fixing it, yet segfaults during compiling libgcc2.c __powidf2 at #0 0x089706b4 in sh_adjust_cost (insn=0xb7f767e0, link=0xb7f79380, dep_insn=0xb7f762d0, cost=25) at trunk/gcc/config/sh/sh.c:10908 10908 SET_SRC (use_pat))) (gdb) l 10903cycle earlier. */ 10904 else if (reload_completed 10905 && get_attr_dfp_comp (dep_insn) == DFP_COMP_YES 10906 && (use_pat = single_set (insn)) 10907 && ! regno_use_in (REGNO (SET_DEST (single_set (dep_insn))), 10908 SET_SRC (use_pat))) It looks - (use (match_operand:PSI 3 "fpscr_operand" "c"))] + (set (reg:SI FPSCR_STAT_REG) (const_int 0)) + (use (reg:SI FPSCR_MODES_REG))] breaks the assumption of sh_adjust_cost which divdf3_i has only one set insn.
[Bug ada/38009] Assert_Failure sinfo.adb:1002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38009 --- Comment #2 from Scott Worley --- Update for 4.6.4: $ gnatmake assert_failure_sinfo_1002.adb gnatgcc -c assert_failure_sinfo_1002.adb +===GNAT BUG DETECTED==+ | 4.6.4 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:1061| | Error detected at assert_failure_sinfo_1002.adb:11:10| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.6/adainclude/system.ads assert_failure_sinfo_1002.adb compilation abandoned gnatmake: "assert_failure_sinfo_1002.adb" compilation error $ nl --body-numbering=all /usr/src/debug/dev-lang/gnat-gcc-4.6.4/gcc-4.6.4/gcc/ada/sinfo.adb ... 1056 function End_Span 1057(N : Node_Id) return Uint is 1058 begin 1059pragma Assert (False 1060 or else NT (N).Nkind = N_Case_Statement 1061 or else NT (N).Nkind = N_If_Statement); 1062return Uint5 (N); 1063 end End_Span; ...
[Bug inline-asm/63541] New: gcc compilation error: The register specified for 'variable' is not general enough to be used as a register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63541
Bug ID: 63541
Summary: gcc compilation error: The register specified for
'variable' is not general enough to be used as a
register variable
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: vinitha_kv at rediffmail dot com
For the following code gcc throws error and do not compile (for arm-*-gnueabi*)
Test code:
$ cat test.c
void foo()
{
register unsigned int curr_pc asm ("pc");
unsigned int arm_pc;
arm_pc = curr_pc;
}
Observed the issue with gcc-4.8.0 onwards.(Works fine with 4.7.2)
Checked with latest with gcc 5.0 (GNU C (GCC) version 5.0.0 20141014 ) also,
getting the following error.
...
xgcc -v
Using built-in specs.
COLLECT_GCC=~/gcc-git/official-gcc/objdir/gcc/xgcc
Target: arm-none-linux-gnueabi
Configured with: ../configure --host=x86_64-pc-linux-gnu
--target=arm-none-linux-gnueabi --build=x86_64-pc-linux-gnu
--prefix=/usr/local/arm-none-linux-gnueabi/cross --disable-nls
--enable-__cxa_atexit --enable-languages=c,c++ --disable-multilib
--enable-threads=posix --enable-shared --enable-symvers=gnu
Thread model: posix
gcc version 5.0.0 20141014 (experimental) (GCC)
...
test.c: In function 'foo':
test.c:3:24: error: the register specified for 'curr_pc' is not general enough
to be used as a register variable
register unsigned int curr_pc asm ("pc");
...
Digged a little and the error seems to occur after commit,
[https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bffbb863ff0f267b5111bfa95b42c99cd0474424]
in 4.8.0.
Regards,
Vinitha Vijayan
[Bug inline-asm/63541] gcc compilation error: The register specified for 'variable' is not general enough to be used as a register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63541
--- Comment #1 from Andrew Pinski ---
pc is not general enough in all of armv7. If you want to read the PC do this
instead or something like this:
asm("mov pc, %0":"=r"arm_pc);
[Bug go/63539] libgo does not use the newly built objcopy when doing a combined build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63539 Andrew Pinski changed: What|Removed |Added CC||ian at airs dot com Assignee|ian at airs dot com|pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- .
[Bug go/63539] libgo does not use the newly built objcopy when doing a combined build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63539 --- Comment #4 from Andrew Pinski --- Created attachment 33718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33718&action=edit Patch which I need to submit I already tested this patch but I need to submit it still. ChangeLog: * Makefile.def (flags_to_pass): Pass OBJCOPY_FOR_TARGET also. * Makefile.tpl (HOST_EXPORTS): Add OBJCOPY_FOR_TARGET. (BASE_TARGET_EXPORTS): Add OBJCOPY. (OBJCOPY_FOR_TARGET): New variable. (EXTRA_TARGET_FLAGS): Add OBJCOPY. * Makefile.in: Regenerate. * configure.ac: Check for already installed target objcopy. Also GCC_TARGET_TOOL on objcopy. * configure: Regenerate.
[Bug target/63542] New: My build log is full of "non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63542 Bug ID: 63542 Summary: My build log is full of "non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location" Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org /home/pinskia/src/local/gcc/libgcc/config/libbid/bid128_compare.c: In function ‘__bid128_quiet_not_equal’: /home/pinskia/src/local/gcc/libgcc/config/libbid/bid_conf.h:315:32: note: non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location #define bid128_quiet_not_equal __bid128_quiet_not_equal ^ /home/pinskia/src/local/gcc/libgcc/config/libbid/bid_conf.h:1056:6: note: in definition of macro ‘BID128_FUNCTION_ARG2_NORND_CUSTOMRESTYPE’ fn_name (UINT128 bid_##arg_name1, \ ^ /home/pinskia/src/local/gcc/libgcc/config/libbid/bid128_compare.c:1675:48: note: in expansion of macro ‘bid128_quiet_not_equal’ BID128_FUNCTION_ARG2_NORND_CUSTOMRESTYPE (int, bid128_quiet_not_equal, ^ /home/pinskia/src/local/gcc/libgcc/config/libbid/bid_conf.h:315:32: note: non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location #define bid128_quiet_not_equal __bid128_quiet_not_equal ^ /home/pinskia/src/local/gcc/libgcc/config/libbid/bid_conf.h:1056:6: note: in definition of macro ‘BID128_FUNCTION_ARG2_NORND_CUSTOMRESTYPE’ fn_name (UINT128 bid_##arg_name1, \ ^ /home/pinskia/src/local/gcc/libgcc/config/libbid/bid128_compare.c:1675:48: note: in expansion of macro ‘bid128_quiet_not_equal’ BID128_FUNCTION_ARG2_NORND_CUSTOMRESTYPE (int, bid128_quiet_not_equal, etc.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #47 from Jakub Jelinek --- .
