[Bug c/63462] [RFC] gcc should prevent from overwriting source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63462 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org --- Agreed this would be a useful feature. Happened to me at least once too.
[Bug driver/63462] [RFC] gcc should prevent from overwriting source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63462 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-06 CC||mpolacek at gcc dot gnu.org Component|c |driver Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed then.
[Bug driver/36312] should refuse to overwrite input file with output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||wkoszek at gmail dot com --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 63462 has been marked as a duplicate of this bug. ***
[Bug driver/63462] [RFC] gcc should prevent from overwriting source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63462 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Dup of bug 36312. *** This bug has been marked as a duplicate of bug 36312 ***
[Bug preprocessor/61386] inaccurate location for missing headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61386 --- Comment #2 from Akim Demaille akim.demaille at gmail dot com --- Well, I never hacked in GCC. I can try, time permitting...
[Bug c/63461] Inconsistent behaviour on ARM64 when inline assembly with .text directive is followed by a static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63461 --- Comment #6 from Akos Kiss akiss at inf dot u-szeged.hu --- Thanks for the feedback!
[Bug pch/63429] [Regression 5] Cannot build compiler with --enable-gather-detailed-mem-stats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63429 Martin Liška mliska at suse dot cz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Liška mliska at suse dot cz --- Works for me.
[Bug other/63465] New: Demangler crash (GDB PR 17455)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63465 Bug ID: 63465 Summary: Demangler crash (GDB PR 17455) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gbenson at redhat dot com The demangler crashes when given this symbol: _ZSt1aIRPZN1bII1cIcEEE1dIZN1eIIS2_EE1fEOS3_EUlRT_E_EEvOT_E1gEOS8_RNSt1hIS8_E1iE See https://sourceware.org/bugzilla/show_bug.cgi?id=17455
[Bug preprocessor/61386] inaccurate location for missing headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61386 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Akim Demaille from comment #2) Well, I never hacked in GCC. I can try, time permitting... Never too late to try. This one should be easy if you know how to use a debugger. Just add a breakpoint in c_cpp_error, then go up in the backtrace until you find a place where the correct location is known (in libcpp, location_t is called source_location but they are the same thing), pass that location to c_cpp_error. You can use expand_location(location) to see what locations point to. No hurries. You have all the time in the world :)
[Bug middle-end/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 Clément Péron peron.clem at gmail dot com changed: What|Removed |Added CC||peron.clem at gmail dot com --- Comment #12 from Clément Péron peron.clem at gmail dot com --- The Bugs is still present in GCC 4.6.4 and 4.8.2. .strX.X try to optimize string constants but when you disable it the var are moved into .rodata instead of .rodata.__function when the -fdata-sections is enabled. I post a question on StackOverflow : http://stackoverflow.com/questions/26100976/var-declare-inside-a-printf-cant-be-garbage-collected-by-gcc?answertab=oldest#tab-top And i sent a message on GCC-Help mailing list : https://gcc.gnu.org/ml/gcc-help/2014-10/msg0.html It's really annoying when you try to optimize the size of the executable. Thanks
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 --- Comment #4 from Jonathan Larmour jifl-bugzilla at jifvik dot org --- I have just double-checked, and my gcc 4.8.3 definitely doesn't generate the 'tstl', but it looks like you're bang on right about how gcc was configured: I configured it with --with-arch=cf. Sorry I should have realised the importance of this before and included it! So I think you should be able to reproduce it if you add -mcpu=5206 (or any other coldfire cpu) to the compile line.
[Bug tree-optimization/63464] compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-06
CC||jakub at gcc dot gnu.org,
||rguenth at gcc dot gnu.org,
||steven at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
We have this optimization implemented for switches, if you compile
char*f3(char*s){
do
{
switch (*s)
{
case ' ':
case ',':
case '\r':
case '\n':
++s;
continue;
default:
return s;
}
}
while (1);
}
then it will do the bit test, see r189173 (and various follow-up fixes for
that).
Now, we can argue whether in this case it is beneficial to perform the
MINUS_EXPR or if maxval is small enough (e.g. when maxval is smaller than
BITS_PER_WORD), just assume minval is 0.
And then the question is, if we should teach reassoc range optimizations to
reuse emit_case_bit_tests, or convert such tests into a GIMPLE_SWITCH and
expand as such.
Richard/Steven, thoughts about this?
[Bug tree-optimization/63464] compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #2 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 6 Oct 2014, jakub at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-06
CC||jakub at gcc dot gnu.org,
||rguenth at gcc dot gnu.org,
||steven at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
We have this optimization implemented for switches, if you compile
char*f3(char*s){
do
{
switch (*s)
{
case ' ':
case ',':
case '\r':
case '\n':
++s;
continue;
default:
return s;
}
}
while (1);
}
then it will do the bit test, see r189173 (and various follow-up fixes for
that).
Now, we can argue whether in this case it is beneficial to perform the
MINUS_EXPR or if maxval is small enough (e.g. when maxval is smaller than
BITS_PER_WORD), just assume minval is 0.
And then the question is, if we should teach reassoc range optimizations to
reuse emit_case_bit_tests, or convert such tests into a GIMPLE_SWITCH and
expand as such.
Richard/Steven, thoughts about this?
Factoring out the code-gen part of switch-conversion and use it
from reassoc range optimization?
I don't think creating a GIMPLE_SWITCH from reassoc is a good idea
(given that switch conversion runs early).
Richard.
[Bug tree-optimization/63380] [5 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63380 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 tree-optimization/63381] [5 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63381 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 #4 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug other/63440] -Og does enable -fmerge-constants too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63440 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-06 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. Do you think it is ok to enable -fmerge-constants with -Og? Note that the various Enabled at levels ... were not updated for -Og.
[Bug testsuite/63439] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect Alignment of access forced using peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||armv7-a Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-06 Component|target |testsuite Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Please attach the vectorizer dump file. The testsuite needs adjustment after the vectorizer now figures out that peeling for alignment isn't profitable if then the vectorized loop doesn't run at all.
[Bug middle-end/63434] builtins.c has incorrect parameters for GEN_CALL_VALUE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63434 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Patches should be sent to gcc-patches@
[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846 --- Comment #9 from Yvan Roux yroux at gcc dot gnu.org --- Author: yroux Date: Mon Oct 6 12:25:14 2014 New Revision: 215929 URL: https://gcc.gnu.org/viewcvs?rev=215929root=gccview=rev Log: /libstdc++-v3/ 2014-10-06 Yvan Roux yvan.r...@linaro.org Backport from trunk r215101. 2014-09-10 Tony Wang tony.w...@arm.com PR target/56846 * libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): Return with CONTINUE_UNWINDING when the state pattern contains: _US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND Modified: branches/linaro/gcc-4_9-branch/libstdc++-v3/ChangeLog.linaro branches/linaro/gcc-4_9-branch/libstdc++-v3/libsupc++/eh_personality.cc
[Bug target/63209] [ARM] Wrong conditional move generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63209 --- Comment #3 from Yvan Roux yroux at gcc dot gnu.org --- Author: yroux Date: Mon Oct 6 12:40:10 2014 New Revision: 215932 URL: https://gcc.gnu.org/viewcvs?rev=215932root=gccview=rev Log: /gcc/ 2014-10-06 Yvan Roux yvan.r...@linaro.org Backport from trunk r215136. 2014-09-10 Xinliang David Li davi...@google.com PR target/63209 * config/arm/arm.md (movcond_addsi): Handle case where source and target operands are the same. /gcc/testsuite/ 2014-10-06 Yvan Roux yvan.r...@linaro.org Backport from trunk r215136. 2014-09-10 Xinliang David Li davi...@google.com PR target/63209 * gcc.c-torture/execute/pr63209.c: New test. Added: branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr63209.c Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/config/arm/arm.md branches/linaro/gcc-4_9-branch/gcc/testsuite/ChangeLog.linaro
[Bug testsuite/63439] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect Alignment of access forced using peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439 --- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 33652 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33652action=edit vect-33.c.116t.vect
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- Comment 7 confirms my guess that there is a rounding problem on i386-sun-solaris2.11 (the test is three-year old and succeeds on all the revisions I have used on darwin, and all the tests I have looked at https://gcc.gnu.org/ml/gcc-testresults/2014-09/). This may be related to problems found with solaris during the fix for PR60128. Note that there is no point to post assembly files: the problem is either in libgfortran or (more probably) in the C library. This seems to be an Illumos-specific problem to me: on Solaris 11.2/x86, I get the same output for Dominique's testcase with gcc 4.9 and 4.8, and both testcases Richard sees failing PASS for me. Rainer
[Bug rtl-optimization/62265] [4.8/4.9/5 regression] FAIL: gcc.dg/20111227-2.c scan-rtl-dump ree Elimination opportunities = 3 realized = 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62265 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #3 from Teresa Johnson tejohnson at google dot com --- I believe this was fixed by the following commit: r214848 | uros | 2014-09-03 00:58:17 -0700 (Wed, 03 Sep 2014) | 4 lines Changed paths: M /trunk/gcc/testsuite/ChangeLog M /trunk/gcc/testsuite/gcc.dg/20111227-2.c M /trunk/gcc/testsuite/gcc.dg/20111227-3.c * gcc.dg/20111227-2.c: Compile only for x86 targets. * gcc.dg/20111227-3.c: Ditto. Seems so: at least on Solaris/SPARC, the failures went away between 20140831 and 20140908, as expected. Rainer
[Bug other/63440] -Og does enable -fmerge-constants too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63440 --- Comment #2 from R. Diez rdiezmail-gcc at yahoo dot de --- Yes, I would enable -fmerge-constants with -Og. I would do it even for -O0. Merging constants should be safe, and it saves precious program space when generating debug builds for small embedded targets. Besides, in my opinion, it does not make sense that the addresses of some literal strings suddenly change when you enable optimisations, because they get collapsed. Any bugs because of such shared addresses should be apparent in debug builds too. Note that GCC already seems to apply some optimisations when building with -O0. Specifically, I believe that at least some dead code elimination does occur. That would make sense, as you do not want to bloat your debug builds unnecessary.
[Bug objc++/61759] internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 --- Comment #4 from Douglas Mencken dougmencken at gmail dot com --- In 4.9.1, it's not :2792 but :2793 --- vcl/osx/a11yselectionwrapper.cxx:31:61: internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2793
[Bug libstdc++/62022] [5 regression] 27_io/basic_ofstream/pthread2.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62022 Bug 62022 depends on bug 62023, which changed state. Bug 62023 Summary: [5 regression] 30_threads/condition_variable_any/50862.cc FAILs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62023 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/62023] [5 regression] 30_threads/condition_variable_any/50862.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62023 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Rainer Orth ro at gcc dot gnu.org --- Between 20140908 and 20140912, this failure (and the one reported in PR libstdc++/62022) vanished again. Rainer
[Bug libstdc++/62022] [5 regression] 27_io/basic_ofstream/pthread2.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62022 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Rainer Orth ro at gcc dot gnu.org --- Vanished between 20140908 and 20140912, caused by the same patch as PR libstdc++/62023. Rainer
[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|x86_64-*-* |x86_64-*-*, ||i386-pc-solaris2.1[01], ||sparc-sun-solaris2.1[01] CC||ro at gcc dot gnu.org --- Comment #6 from Rainer Orth ro at gcc dot gnu.org --- Same failure on both i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01]. Rainer
[Bug c++/63459] operator new and returns_nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- I think a method call always has this != NULL so you'd infer this != NULL after the call with a ASSERT_EXPR. With the pattern stuff you can't really write any call with some nonnull attribute on it so you need a tree predicate for this.
[Bug c/63450] Optimizing -O3 generates rep ret on an almost empty function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63450 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- feature.
[Bug c++/63454] [5 Regression] internal compiler error: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63454 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-06 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed with some old cc1plus and trunk.
[Bug rtl-optimization/63448] ICE when compiling atlas 3.10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ra Target||i?86-gnu Status|UNCONFIRMED |NEW Last reconfirmed|2014-10-03 00:00:00 |2014-10-06 CC||vmakarov at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.9.2, 5.0 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- From the attachment: /usr/lib/gcc/i586-gnu/4.9/cc1 -quiet -I /home/srs/DEBs/atlas/atlas-3.10.2/build/atlas-base/include -I /home/srs/DEBs/atlas/atlas-3.10.2/build/atlas-base/../..//include -I /home/srs/DEBs/atlas/atlas-3.10.2/build/atlas-base/../..//include/contrib -imultilib . -imultiarch i386-gnu -D L2SIZE=4194304 -D Add_ -D F77_INTEGER=int -D StringSunStyle -D ATL_OS_Linux -D ATL_ARCH_x86x87 -D ATL_GAS_x8632 -D WALL ATL_cNCCUmmNN.c -quiet -dumpbase ATL_cNCCUmmNN.c -mfpmath=387 -m32 -mtune=generic -march=i586 -auxbase ATL_cNCCUmmNN -O2 -std=c99 -fomit-frame-pointer -falign-loops=4 -fPIC -o - -frandom-seed=0 Reproducible with just -std=c99 -m32 -O on x86_64-linux. Confirmed on 4.9 branch and trunk.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #14 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
I'm not really happy with Dominik's patch because 1) it doesn't work when
configuring with --enable-sjlj-exceptions;
Why is that important?
2) the current code almost always works, even on S/390, but the patch
forces us to do a lookup in the FDE table every time we call recover.
The current code works unreliably as s390 uses memcopy to copy call arguments
to the stack. The control flow introduced by the function call triggers basic
block reordering that may result in anything.
I'd like to propose a different patch, that keeps the current code
that almost always works, does a quick exit when there is no defer in
the call stack, and does an unwind to check for a specific function
in other cases.
I've not tested the patch yet, but see some potential problems:
* On systems that use a leading underscore on symbol names, the test for
functions beginning with __go_ or _go_ would yield true from user
functions named _go_... (because the system adds one '_' and the patch strips
it).
* Wouldn't the new patch re-introduce the bug that
func foo(n int) {
if (n == 0) { recover(); } else { foo(0); }
}
func main() {
defer foo(1)
panic(...)
}
would recover although it should not?
* The code is even more expensive than the approach I had chosen because now it
needs to fetch a two level backtrace instead of just one level (and probably
each level is more expensive than the one _Unwind_FindEnclosingFunc()).
Digging deeper at the issue that causes Lynn's problems on Power surfaces more
problems with the current implementation of __go_can_recover() and the thunk,
also with the patch I've posted. Here's a summary of all the problems I am
aware of (some new, some known, skipping the bugs introduced by the patch):
Problems with the current implementation only:
--
1) Calculation of the label address in the thunk does not work if the basic
block reordering is done (that's the issue why this bug report was created)
2) The current checks for return address + 16 may point into a different
function, allowing recover() in weird situations.
Problems with the current implementation and the proposed patch:
3) Quote from http://golang.org/ref/spec:
The return value of recover is nil if any of the following conditions holds:
...
*recover was not called directly by a deferred function.
According to the spec, the following code should recover the panic but does
not:
func main() { defer foo(); panic(...); }
func foo() { defer bar(); }
func bar() { recover(); }
Note that this is also also broken in Golang (well, at least in the old
version that comes with Ubuntu). This may be an effect of imprecise wording of
the spec.
4) __go_can_recover assumes that any call through libffi is allowed to recover.
Quote from the sources:
/* If the function calling recover was created by reflect.MakeFunc,
then RETADDR will be somewhere in libffi. Our caller is
permitted to recover if it was called from libffi. */
This violates the specification. An example that recovers the panic in a
nested function but should not:
--snip--
package main
import reflect
func main() {
// generate foo() and bar()
fn := reflect.ValueOf(interface{}(foo)).Elem()
val := reflect.MakeFunc(fn.Type(), recover_reflect1)
fn.Set(val)
fn = reflect.ValueOf(interface{}(bar)).Elem()
val = reflect.MakeFunc(fn.Type(), recover_reflect2)
fn.Set(val)
defer foo()
panic(...)
}
var foo func()
func recover_reflect1(args []reflect.Value) (results []reflect.Value) {
bar()
return results
}
var bar func()
func recover_reflect2(args []reflect.Value) (results []reflect.Value) {
recover()
return results
}
--snip--
Actually, I think this may also happen if bar is not a function created through
reflection but any foreign language function
* from a stripped object file
(no name in the backtrace is guessed as called by libffi),
* if the name begins with [_]ffi_
(But perhaps it's impossible to construct such an example.)
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #15 from boger at us dot ibm.com --- The testcase recover.go continues to fail on both ppc64 LE BE with the new patch https://codereview.appspot.com/153950043.
[Bug libstdc++/59987] [C++11]: Missing ios_base::hexfloat format specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59987 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Oct 6 15:55:53 2014 New Revision: 215952 URL: https://gcc.gnu.org/viewcvs?rev=215952root=gccview=rev Log: 2014-10-06 Rüdiger Sonderfeld ruedi...@c-plusplus.de Jonathan Wakely jwak...@redhat.com PR libstdc++/59987 * doc/xml/manual/status_cxx2011.xml: Remove hexfloat from notes. * doc/html/manual/status.html: Regenerate. * include/bits/ios_base.h (hexfloat): New function. (defaultfloat): New function. * src/c++98/locale_facets.cc (__num_base::_S_format_float): Support hexadecimal floating point format. * testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc: New file. Added: trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/manual/status.html trunk/libstdc++-v3/doc/xml/manual/status_cxx2011.xml trunk/libstdc++-v3/include/bits/ios_base.h trunk/libstdc++-v3/src/c++98/locale_facets.cc
[Bug libstdc++/59987] [C++11]: Missing ios_base::hexfloat format specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59987 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- std::hexfloat and std::defaultfloat support is committed now. Parsing hexadecimal floats is not supported in C++, that is a known issue, see http://cplusplus.github.io/LWG/lwg-active.html#2381
[Bug c++/55250] [C++0x] enum declarations within constexpr function are allowed, constexpr declarations are not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55250 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Oct 6 16:13:41 2014 New Revision: 215954 URL: https://gcc.gnu.org/viewcvs?rev=215954root=gccview=rev Log: /cp 2014-10-06 Paolo Carlini paolo.carl...@oracle.com PR c++/55250 * semantics.c (check_constexpr_bind_expr_vars): New. (check_constexpr_ctor_body, massage_constexpr_body): Use it. (build_constexpr_constructor_member_initializers): Handle BIND_EXPR in the main conditional. /testsuite 2014-10-06 Paolo Carlini paolo.carl...@oracle.com PR c++/55250 * g++.dg/cpp0x/constexpr-type-decl1.C: New. * g++.dg/cpp0x/constexpr-type-def1.C: Likewise. * g++.dg/cpp1y/constexpr-type-def1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-type-decl1.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-type-def1.C trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-type-def1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/55250] [C++0x] enum declarations within constexpr function are allowed, constexpr declarations are not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55250 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 55250, which changed state. Bug 55250 Summary: [C++0x] enum declarations within constexpr function are allowed, constexpr declarations are not https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55250 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409 --- Comment #7 from Martin Liška mliska at suse dot cz --- Yeah, sorry for wrong dg argument. There's new version that should work correctly. If not regression will be seen, I will commit the patch.
[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409 --- Comment #8 from Martin Liška mliska at suse dot cz --- Created attachment 33653 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33653action=edit Fix patch2
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #16 from Ian Lance Taylor ian at airs dot com ---
I'm not really happy with Dominik's patch because 1) it doesn't work when
configuring with --enable-sjlj-exceptions;
Why is that important?
It's not very important but it's still a point to consider. Some targets
default to SJLJ exceptions, albeit not very important ones.
2) the current code almost always works, even on S/390, but the patch
forces us to do a lookup in the FDE table every time we call recover.
The current code works unreliably as s390 uses memcopy to copy call
arguments to the stack. The control flow introduced by the function
call triggers basic block reordering that may result in anything.
Sure, I understand, and it can obviously cause a false negative: some cases
that should recover will fail to do so. However, I don't see any way that it
can ever cause a false positive: I don't see any way that it can cause recover
to succeed when it should not.
* On systems that use a leading underscore on symbol names, the test
for functions beginning with __go_ or _go_ would yield true from user
functions named _go_... (because the system adds one '_' and the patch
strips it).
Yes. We are already going to have trouble on such systems. Really the library
needs to learn which systems use a leading underscore and which do not. This
is actually available as __USER_LABEL_PREFIX__, and we should use that.
* Wouldn't the new patch re-introduce the bug that
func foo(n int) {
if (n == 0) { recover(); } else { foo(0); }
}
func main() {
defer foo(1)
panic(...)
}
would recover although it should not?
Hmmm, I hadn't fully internalized that issue. Your new withoutRecoverRecursive
test doesn't fail for me on x86_64. I'll have to figure out why.
* The code is even more expensive than the approach I had chosen because
now it needs to fetch a two level backtrace instead of just one level
(and probably each level is more expensive than the one
_Unwind_FindEnclosingFunc()).
Yes, but the expensive case only happens in the rare cases where either recover
should not work or when the existing code has a false negative. In the normal
case, where recover is permitted and the existing code works, we save the FDE
lookup.
2) The current checks for return address + 16 may point into a
different function, allowing recover() in weird situations.
It's a potential problem but I'm not too worried about it.
The return value of recover is nil if any of the following conditions holds:
...
*recover was not called directly by a deferred function.
According to the spec, the following code should recover the panic but
does not:
func main() { defer foo(); panic(...); }
func foo() { defer bar(); }
func bar() { recover(); }
Note that this is also also broken in Golang (well, at least in the old
version that comes with Ubuntu). This may be an effect of imprecise
wording of the spec.
In this case, the call to recover in bar is supposed to return nil; it should
not recover the panic. If you read the paragraph before the one you quote, you
will see that recover only returns non-nil if it was called by a function that
was deferred before the call to panic. In your example, the defer of bar
happens after the call to panic. The reason Go works this way is to that the
deferred function foo can itself call a function that panics and recovers
without that function being confused by the earlier panic, one that it may not
know anything about.
4) __go_can_recover assumes that any call through libffi is allowed
to recover.
Thanks for the example. Does your patch fix this problem?
[Bug c/59717] better warning when using functions without including appropriate header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59717 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- On it.
[Bug libstdc++/63466] New: sstream is very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63466
Bug ID: 63466
Summary: sstream is very slow
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
sstream is very slow. Comparing two simple programs that parse a stream with C
and with sstream. The sstream version is an order of magnitude slower.
gcc version 4.9.1 20140423 (prerelease) (GCC)
# C++
% time ./a.out testfile
real0m0.893s
user0m0.888s
sys0m0.004s
# C
time ./tstream-c testfile
real0m0.032s
user0m0.030s
sys0m0.001s
Here's a profile.
16.13%a.out libc-2.18.so [.] _IO_getc
10.39%a.out libc-2.18.so [.] _IO_ungetc
9.15%a.out libstdc++.so.6.0.20 [.] std::basic_istreamchar,
std::char_traitschar std::getlinechar, std::char_traitschar,
std::allocatorchar (std::basic_istreamchar, std::char_traitschar ,
std::basic_stringchar, std::char_traitschar, std::allocatorchar , char)
7.87%a.out libstdc++.so.6.0.20 [.] __dynamic_cast
4.99%a.out libc-2.18.so [.] __GI___strcmp_ssse3
3.95%a.out libstdc++.so.6.0.20 [.] std::basic_istreamchar,
std::char_traitschar std::operatorchar, std::char_traitschar,
std::allocatorchar (std::basic_istreamchar, std::char_traitschar ,
std::basic_stringchar, std::char_traitschar, std::allocatorchar )
3.89%a.out libc-2.18.so [.] _int_free
2.79%a.out libstdc++.so.6.0.20 [.]
__cxxabiv1::__vmi_class_type_info::__do_dyncast(long,
__cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info
const*, void const*, __cxxabiv1::__class_type_info const*, void const*,
__cxxabiv1::__class_type_info::__dyncast_result) const
2.65%a.out a.out[.] main
2.58%a.out libc-2.18.so [.] malloc
2.30%a.out libstdc++.so.6.0.20 [.]
__cxxabiv1::__si_class_type_info::__do_dyncast(long,
__cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info
const*, void const*, __cxxabiv1::__class_type_info const*, void const*,
__cxxabiv1::__class_type_info::__dyncast_result) const
1.96%a.out libc-2.18.so [.] _int_malloc
1.86%a.out libstdc++.so.6.0.20 [.]
std::istream::sentry::sentry(std::istream, bool)
1.55%a.out libc-2.18.so [.] _IO_sputbackc
1.51%a.out libstdc++.so.6.0.20 [.]
__gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::underflow()
Test case:
Generate test file:
perl -e 'for($i=0;$i100;$i++) { printf(%d %d\n, $i, $i); } ' testfile
C++ version:
#include iostream
#include string
#include sstream
using namespace std;
void __attribute__((noinline, noclone)) func(string , string )
{
}
int main()
{
string line;
while (getline(cin, line)) {
istringstream iss(line);
string index, s;
if (!(iss index s))
continue;
func(index, s);
}
return 0;
}
C version:
#define _GNU_SOURCE 1
#include stdio.h
#include string.h
void __attribute__((noinline, noclone)) func(char *a, char *b)
{
}
int main()
{
char *line = NULL;
size_t linelen = 0;
while (getline(line, linelen, stdin) 0) {
char *p = line;
char *a = strsep(p, \t\n);
char *b = strsep(p, \t\n);
func(a, b);
}
return 0;
}
[Bug tree-optimization/63464] compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33654 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33654action=edit gcc5-pr63464.patch Untested patch to avoid the subtraction of info.range_min from index. Might not always be a net win, if the mask constant(s) is(are) more costly if we don't subtract minval than when we do. E.g. on x86_64, if without subtracting we need to use movabsq + and with a reg, while with subtracting just sub + and with an immediate mask. So perhaps we need to build all the masks for both cases and sum up rtx cost of all the masks and the sub. This is for the switch opt. In tree-ssa-reassoc, I'll see what can be reused, but probably not very much (perhaps the rtx_cost code if we add it for the switch conversion).
[Bug tree-optimization/63467] New: should have asm statement that does not prevent vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
Bug ID: 63467
Summary: should have asm statement that does not prevent
vectorization
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Currently any inline asm statement in a loop prevents vectorization, like
#define N 100
int a[N], b[N], c[N];
main()
{
int i;
for (i = 0; i N; i++) {
asm();
a[i] = b[i] + c[i];
}
}
Without the asm the loop vectorizes fine.
This is a problem if you want to add markers into the loop body for static
assembler code analysis (for example with IACA,
https://software.intel.com/en-us/articles/intel-architecture-code-analyzer)
Should have some way to tell the compiler that a particular inline asm
statement does not have any side effects that prevent vectorization or other
loop transformations.
Perhaps an asm const ?
[Bug tree-optimization/63467] should have asm statement that does not prevent vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Try asm volatile (:::); instead. Asms without any ::: are considered clobbering memory.
[Bug tree-optimization/63467] should have asm statement that does not prevent vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467 --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org --- It's the same with asm( :::); At least the vectorizer bombs out on any asm.
[Bug middle-end/63418] false positive with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63418 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 --- Generally, ensuring that -Wmaybe-uninitialized has no false positives is NP-complete problem. We have since 2010 in tree-ssa-uninit.c an attempt to handle the most common cases (predicate aware uninit), which has been improved over time. I guess you can look at *.uninit pass verbose dumps (-fdump-tree-uninit-details) to see why it failed in this case.
[Bug c/63420] GCC 4.8.2: Bitshift second operand range not as per manual.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63420 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- What matters is what the C and C++ standards (differs between different versions thereof) say, the documentation is certainly wrong, but even some shifts where shift count is smaller than bitsize can be invalid in some standards (for signed types)).
[Bug tree-optimization/63467] should have asm statement that does not prevent vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Ok doing this works: asm(:+r(t)::); But it looks like it should not vectorize due to the number of iterations happening for that asm has changed.
[Bug c/63420] GCC 4.8.2: Bitshift second operand range not as per manual.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63420 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Can you explain where in the documentation you find it though? I can't find any wording like that.
[Bug tree-optimization/63467] should have asm statement that does not prevent vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #3)
Ok doing this works:
asm(:+r(t)::);
But it looks like it should not vectorize due to the number of iterations
happening for that asm has changed.
Ok, actually if the asm result is used outside the loop, the vectorizer does
not happen but if is not used, then it happens so no wrong code.
You need some output to the inline-asm to cause it to vectorizer:
This:
{int t; asm (:+r(t)::); }
Otherwise if it is volatile, it does not work as that requires that many
iterations of asm to be called.
[Bug tree-optimization/63467] should have asm statement that does not prevent vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467 --- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org --- For the marker case it's enough if it just stays in the same position in the basic block and does get duplicated if the BB gets too. That's somewhat special semantics, that is why I think it would need some way to annotate (asm const?) Ok maybe Andrew's trick works, but it seems fragile. Would that work for other loop transformations (like graphite) too?
[Bug tree-optimization/63467] should have asm statement that does not prevent vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467 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 --- How would that work though? How exactly would you vectorize inline-asm? Duplicate it VF times, something else?
[Bug libstdc++/63466] sstream is very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63466 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- To be a bit less unfair, you could pull the declarations of the 3 variables out of the loop. Even if optimizations are possible, I doubt we can go anywhere near the C perf...
[Bug libstdc++/63466] sstream is very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63466 --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org --- Looking at the profile there's plenty of room for optimization. e.g. not using getc/ungetc, but directly accessing the buffer, or maybe even some kind of template specialization. With the variables pulled out it's faster, but still a lot slower than C: % time ./a.out testfile real0m0.400s user0m0.397s sys0m0.002s % time ./tstream-c testfile real0m0.033s user0m0.028s sys0m0.004s
[Bug rtl-optimization/63448] [4.9/5 Regression] ICE when compiling atlas 3.10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.9.2
Summary|ICE when compiling atlas|[4.9/5 Regression] ICE when
|3.10.2 |compiling atlas 3.10.2
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
int a, d, e, g, h, j;
float b, c, k, l, m, n;
int *__restrict i;
void
foo (void)
{
int o = e;
int *p;
float *q, *r = (float *) 0x1234000;
float s, t, u, v, w, x;
do
{
for (a = o; a; a--)
{
s += m;
t += n;
u += m;
v += n;
w += d;
x += d;
n = l;
s += r[1];
t += n;
v += r[1];
m = k * r[4];
n = q[0] * r[4];
s += m;
m = q[1] * r[4];
t += n;
q += g;
k = *q;
n = q[1] * r[4];
s += m;
t += n;
u += r[4];
m = q[8] * r[4];
q += 1;
n = q[1] * r[4];
s += m;
m = q[4];
t += n;
q += g;
w += m;
m = k * r[4];
s += m;
t += q[0];
m = q[1] * r[4];
v += q[0];
n = q[10] * r[4];
s += m;
t += n;
u += b;
m = q[8] * r[4];
n = q[2] * r[4];
s += m;
m = q[4] * r[4];
t += n;
q++;
n = q[2] * r[16];
s += m;
m = q[4];
t += n;
s += m;
t += r[6];
q += g;
k = *q;
w += m;
m = k * r[20];
x += r[16];
n = q[1] * r[20];
s += m;
t += n;
q += g;
k = *q;
w += m;
m = k * r[2];
n = q[1] * r[22];
s += m;
m = q[4];
t += n;
q += g;
s += m;
t += q[0];
s += m;
u += m;
n = q[1] * r[22];
s += m;
m = q[4] * r[22];
t += n;
q += g;
k = 1;
w += m;
c = q[10];
x += r[22];
s += m;
t += r[22];
u += m;
v += r[22];
n = q[10] * r[30];
d = r[32];
l = q[1];
b = 0;
w += m;
m = r[32];
x += n;
r = 0;
}
*i = s;
p[0] = t;
p[1] = u;
p[6] = v;
p[8] = w;
p[10] = x;
}
while (j);
}
at -O -m32 -std=c99 ICE started at r210824 aka PR60969 fix.
[Bug target/63435] Bad code with weak vs localalias on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz --- There are three problems in 4.9 and earlier - the aliases are produced incorrectly because AIX's as alias keyword does not do what is expected (it does kind of syntactic replacement combined with something else) - MAKE_ONE_ONLY is not defined making compiler to believe that linker does not perfrom garbage collection - Linker's garbage collection was disabled, so in particular all duplicated comdats stays in the code. Lack of MAKE_ONE_ONLY makes GCC to produce a lot more local aliases, because it makes sense to refer to a function by local relocation instead of lgobal when we know it is going to stay. Together with the as issue this leads to wrong code. You can work around by forcing local alias to return NULL for AIX to disable some of local aliases. There are other two cases where GCC produce such symbols (in addition of user declaring it by hand in source code via the alias attribute). It is the thunk generation (I suppose this one works as it is there for ages) and the new comdat local code in C++ (that is used only by -Os codegen path at 4.9).
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #11 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
this patch implements the lowring. Each call with warn attribute triggers code
in cgraphunit that inserts call to bulitin_warning/error that is output at
expansion time.
Do we have way to define bulitin that is not user accessible?
Also we do not have way to define LOOPING_CONST bulitin, so I am simply forcing
the flag in cgraphunit.c that is somewhat ugly.
One of consequences of this approach is that indirect calls to functions with
warn attributes will not produce warning. I think it is sort of acceptable
because we also do not warn when the indirect call is produced late by RTL
backend.
Honza
Index: expr.c
===
--- expr.c(revision 215901)
+++ expr.c(working copy)
@@ -10346,21 +10346,7 @@ expand_expr_real_1 (tree exp, rtx target
if (CALL_EXPR_VA_ARG_PACK (exp))
error (%Kinvalid use of %__builtin_va_arg_pack ()%, exp);
{
-tree fndecl = get_callee_fndecl (exp), attr;
-
-if (fndecl
- (attr = lookup_attribute (error,
- DECL_ATTRIBUTES (fndecl))) != NULL)
- error (%Kcall to %qs declared with attribute error: %s,
- exp, identifier_to_locale (lang_hooks.decl_printable_name (fndecl,
1)),
- TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
-if (fndecl
- (attr = lookup_attribute (warning,
- DECL_ATTRIBUTES (fndecl))) != NULL)
- warning_at (tree_nonartificial_location (exp),
- 0, %Kcall to %qs declared with attribute warning: %s,
- exp, identifier_to_locale (lang_hooks.decl_printable_name
(fndecl, 1)),
- TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
+tree fndecl = get_callee_fndecl (exp);
/* Check for a built-in function. */
if (fndecl DECL_BUILT_IN (fndecl))
Index: builtin-types.def
===
--- builtin-types.def(revision 215901)
+++ builtin-types.def(working copy)
@@ -581,3 +581,5 @@ DEF_FUNCTION_TYPE_2 (BT_FN_VOID_VPTR_LDO
BT_VOLATILE_PTR, BT_LONGDOUBLE)
DEF_FUNCTION_TYPE_2 (BT_FN_VOID_VPTR_SIZE, BT_VOID,
BT_VOLATILE_PTR, BT_SIZE)
+DEF_FUNCTION_TYPE_2 (BT_FN_VOID_CONST_STRING_CONST_STRING,
+ BT_VOID, BT_CONST_STRING, BT_CONST_STRING)
Index: builtins.c
===
--- builtins.c(revision 215901)
+++ builtins.c(working copy)
@@ -59,6 +59,8 @@ along with GCC; see the file COPYING3.
#include builtins.h
#include ubsan.h
#include cilk.h
+#include pretty-print.h
+#include print-tree.h
static tree do_mpc_arg1 (tree, tree, int (*)(mpc_ptr, mpc_srcptr, mpc_rnd_t));
@@ -6816,6 +6818,31 @@ expand_builtin (tree exp, rtx target, rt
expand_builtin_cilk_pop_frame (exp);
return const0_rtx;
+case BUILT_IN_WARNING:
+ const char * arg0;
+ const char * arg1;
+ if (!validate_arglist (exp, POINTER_TYPE, POINTER_TYPE, VOID_TYPE)
+ || (arg0 = c_getstr (CALL_EXPR_ARG (exp, 0))) == NULL
+ || (arg1 = c_getstr (CALL_EXPR_ARG (exp, 1))) == NULL)
+warning_at (tree_nonartificial_location (exp), 0,
+%K__builtin_warning used without both arguments being string
constants,
+exp);
+ else
+warning_at (tree_nonartificial_location (exp),
+0, %Kcall to %qs declared with attribute warning: %s,
+exp, arg0, identifier_to_locale (arg1));
+ return const0_rtx;
+case BUILT_IN_ERROR:
+ if (!validate_arglist (exp, POINTER_TYPE, POINTER_TYPE, VOID_TYPE)
+ || (arg0 = c_getstr (CALL_EXPR_ARG (exp, 0))) == NULL
+ || (arg1 = c_getstr (CALL_EXPR_ARG (exp, 1))) == NULL)
+error (%K__builtin_error used without both arguments being string
constants,
+ exp);
+ else
+error (%Kcall to %qs declared with attribute warning: %s,
+ exp, arg0, identifier_to_locale (arg1));
+ return const0_rtx;
+
default:/* just do library call, if unknown builtin */
break;
}
Index: cgraphunit.c
===
--- cgraphunit.c(revision 215901)
+++ cgraphunit.c(working copy)
@@ -211,6 +211,7 @@ along with GCC; see the file COPYING3.
#include tree-nested.h
#include gimplify.h
#include dbgcnt.h
+#include expr.h
/* Queue of cgraph nodes scheduled to be added into cgraph. This is a
secondary queue used during optimization to accommodate passes that
@@ -976,8 +977,30 @@ analyze_functions (void)
cnode-analyze ();
for (edge = cnode-callees; edge; edge = edge-next_callee)
-if (edge-callee-definition)
- enqueue_node (edge-callee);
+{
+ tree attr, err_attr = NULL;
+ if (edge-callee-definition)
+ enqueue_node (edge-callee);
+
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #12 from Jakub Jelinek jakub at redhat dot com --- On Mon, Oct 06, 2014 at 10:22:21PM +0200, Jan Hubicka wrote: this patch implements the lowring. Each call with warn attribute triggers code in cgraphunit that inserts call to bulitin_warning/error that is output at expansion time. Do we have way to define bulitin that is not user accessible? internal-fn* builtins are not user accessible. Jakub
[Bug middle-end/63468] New: ICE in decompose_normal_address, at rtlanal.c:5933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63468 Bug ID: 63468 Summary: ICE in decompose_normal_address, at rtlanal.c:5933 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rmansfield at qnx dot com Target: arm-unknown-linux-gnueabi Created attachment 33655 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33655action=edit reduced preprocess source $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: arm-unknown-linux-gnueabi Configured with: ../configure --target=arm-unknown-linux-gnueabi --prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi --with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root --disable-multilib --with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 --enable-long-long --enable-target-optspace target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-libmudflap --disable-libssp --enable-checking Thread model: posix gcc version 5.0.0 20141006 (experimental) [trunk revision 215958] (GCC) $ ./xgcc -B. ~/ice.i -O3 -mfpu=neon -march=armv7-a -mfloat-abi=softfp /home/ryan/ice.i: In function 'bar': /home/ryan/ice.i:52:1: internal compiler error: in decompose_normal_address, at rtlanal.c:5933 } ^ 0x96ffe5 decompose_normal_address ../../gcc/rtlanal.c:5933 0x96ffe5 decompose_address(address_info*, rtx_def**, machine_mode, unsigned char, rtx_code) ../../gcc/rtlanal.c:6010 0x89ee6b process_address_1 ../../gcc/lra-constraints.c:2771 0x8a2d16 process_address ../../gcc/lra-constraints.c:2978 0x8a2d16 curr_insn_transform ../../gcc/lra-constraints.c:3262 0x8a534c lra_constraints(bool) ../../gcc/lra-constraints.c:4203 0x895ced lra(_IO_FILE*) ../../gcc/lra.c:2198 0x853e99 do_reload ../../gcc/ira.c:5311 0x853e99 execute ../../gcc/ira.c:5470 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 driver/36312] should refuse to overwrite input file with output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Created attachment 33656 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33656action=edit Possible fix The attached patch implements this for the driver and toplev.c. Probably the final version needs to move canonical_filename_eq to libiberty. It builds but I haven't tested it beyond a few quick tests. Perhaps it needs testcases.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #13 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
I am testing this variant of the patch.
For gcc-4.9 branch it may make sense to enable the new patch for LTO only.
Index: internal-fn.c
===
--- internal-fn.c(revision 215958)
+++ internal-fn.c(working copy)
@@ -37,6 +37,8 @@ along with GCC; see the file COPYING3.
#include stringpool.h
#include tree-ssanames.h
#include diagnostic-core.h
+#include builtins.h
+#include pretty-print.h
/* The names of each internal function, indexed by function number. */
const char *const internal_fn_name_array[] = {
@@ -915,6 +917,26 @@ expand_BUILTIN_EXPECT (gimple stmt)
emit_move_insn (target, val);
}
+static void
+expand_OUTPUT_ERROR (gimple stmt)
+{
+ const char * arg0 = c_getstr (gimple_call_arg (stmt, 0));
+ const char * arg1 = c_getstr (gimple_call_arg (stmt, 1));
+ error_at (gimple_location (stmt),
+Call to %qs declared with attribute error: %s,
+arg0, identifier_to_locale (arg1));
+}
+
+static void
+expand_OUTPUT_WARNING (gimple stmt)
+{
+ const char * arg0 = c_getstr (gimple_call_arg (stmt, 0));
+ const char * arg1 = c_getstr (gimple_call_arg (stmt, 1));
+ warning_at (gimple_location (stmt),
+ 0, call to %qs declared with attribute warning: %s,
+ arg0, identifier_to_locale (arg1));
+}
+
/* Routines to expand each internal function, indexed by function number.
Each routine has the prototype:
Index: cgraphunit.c
===
--- cgraphunit.c(revision 215958)
+++ cgraphunit.c(working copy)
@@ -211,6 +211,8 @@ along with GCC; see the file COPYING3.
#include tree-nested.h
#include gimplify.h
#include dbgcnt.h
+#include expr.h
+#include internal-fn.h
/* Queue of cgraph nodes scheduled to be added into cgraph. This is a
secondary queue used during optimization to accommodate passes that
@@ -976,8 +978,29 @@ analyze_functions (void)
cnode-analyze ();
for (edge = cnode-callees; edge; edge = edge-next_callee)
-if (edge-callee-definition)
- enqueue_node (edge-callee);
+{
+ tree attr, err_attr = NULL;
+ if (edge-callee-definition)
+ enqueue_node (edge-callee);
+ if ((attr = lookup_attribute (warning,
+DECL_ATTRIBUTES (edge-callee-decl))) != NULL
+ || (err_attr = lookup_attribute (warning,
+DECL_ATTRIBUTES (edge-callee-decl
+{
+ gimple_stmt_iterator gsi = gsi_for_stmt (edge-call_stmt);
+ const char *arg0 = lang_hooks.decl_printable_name
(edge-callee-decl, 1);
+ const char *arg1= TREE_STRING_POINTER
+ (TREE_VALUE (TREE_VALUE (attr ? attr : err_attr)));
+
+ gimple call = gimple_build_call_internal
+ (attr ? IFN_OUTPUT_WARNING : IFN_OUTPUT_ERROR, 2,
+ build_string_literal (strlen (arg0), arg0),
+ build_string_literal (strlen (arg1), arg1));
+ gsi_insert_before (gsi, call, GSI_SAME_STMT);
+ gimple_set_location (call, gimple_location (edge-call_stmt));
+ gimple_set_block (call, gimple_block (edge-call_stmt));
+}
+}
if (optimize flag_devirtualize)
{
cgraph_edge *next;
Index: expr.c
===
--- expr.c(revision 215958)
+++ expr.c(working copy)
@@ -10346,21 +10346,7 @@ expand_expr_real_1 (tree exp, rtx target
if (CALL_EXPR_VA_ARG_PACK (exp))
error (%Kinvalid use of %__builtin_va_arg_pack ()%, exp);
{
-tree fndecl = get_callee_fndecl (exp), attr;
-
-if (fndecl
- (attr = lookup_attribute (error,
- DECL_ATTRIBUTES (fndecl))) != NULL)
- error (%Kcall to %qs declared with attribute error: %s,
- exp, identifier_to_locale (lang_hooks.decl_printable_name (fndecl,
1)),
- TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
-if (fndecl
- (attr = lookup_attribute (warning,
- DECL_ATTRIBUTES (fndecl))) != NULL)
- warning_at (tree_nonartificial_location (exp),
- 0, %Kcall to %qs declared with attribute warning: %s,
- exp, identifier_to_locale (lang_hooks.decl_printable_name
(fndecl, 1)),
- TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
+tree fndecl = get_callee_fndecl (exp);
/* Check for a built-in function. */
if (fndecl DECL_BUILT_IN (fndecl))
Index: internal-fn.def
===
--- internal-fn.def(revision 215958)
+++ internal-fn.def(working copy)
@@ -56,3 +56,5 @@ DEF_INTERNAL_FN (UBSAN_CHECK_MUL, ECF_CO
DEF_INTERNAL_FN
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #14 from Jakub Jelinek jakub at redhat dot com --- On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote: Hi, I am testing this variant of the patch. For gcc-4.9 branch it may make sense to enable the new patch for LTO only. Not printing the inlining backtrace would be IMHO a significant regression. Jakub
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com --- I can reproduce, choosing a CF family cpu causes the needed tstl to disappear.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #15 from Jan Hubicka hubicka at ucw dot cz --- On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote: Hi, I am testing this variant of the patch. For gcc-4.9 branch it may make sense to enable the new patch for LTO only. Not printing the inlining backtrace would be IMHO a significant regression. OK, how do I print it? I keep the BLOCK of the original expresison, so it is there. Honza Jakub
[Bug fortran/63469] New: Automatic reallocation of allocatable scalar length even when substring implicitly specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63469 Bug ID: 63469 Summary: Automatic reallocation of allocatable scalar length even when substring implicitly specified Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: davidgkinniburgh at yahoo dot co.uk CHARACTER(:), ALLOCATABLE :: s ALLOCATE (character(32) :: s) s(1:32) = 'string' print *, 'Length of ', s, ' with substring = ', LEN(s) s(:) = 'string' print *, 'Length of ', s, ' with substring = ', LEN(s) s = 'string' print *, 'Length of ', s, ' without substring = ', LEN(s) gfortran (4.9.1 and earlier) gives: Length of string with substring = 32 Length of string with substring =6 Length of string without substring =6 IVF (15.0) gives: Length of string with substring = 32 Length of string with substring = 32 Length of string without substring =6 which I think is correct. It is the implicit definition of both the beginning and the ending of 's' that seems to do the damage.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #16 from Jakub Jelinek jakub at redhat dot com --- On Tue, Oct 07, 2014 at 12:18:24AM +0200, Jan Hubicka wrote: On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote: Hi, I am testing this variant of the patch. For gcc-4.9 branch it may make sense to enable the new patch for LTO only. Not printing the inlining backtrace would be IMHO a significant regression. OK, how do I print it? I keep the BLOCK of the original expresison, so it is there. %K in the format string, assuming the call has locus with the right block, should do that. At least with -g, without -g or with LTO it will be less accurate. Jakub
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #17 from Jan Hubicka hubicka at ucw dot cz --- %K in the format string, assuming the call has locus with the right block, should do that. At least with -g, without -g or with LTO it will be less accurate. Yep, for that I need a tree to pass in. Do I need to build something or is there way to pass in gimple statmeent? Honza
[Bug fortran/49766] Fortran w/ CPP: Add tracking locations of tokens resulting from macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49766 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- As explained in PR53934, the main show-stopper in implementing this is that the Fortran compiler needs to call the preprocessor in-process in order to re-use the line-table generated by CPP. The rest of the things mentioned by Dodji are already implemented or are trivial to implement. *** This bug has been marked as a duplicate of bug 53934 ***
[Bug fortran/53934] Better CPP macro diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53934 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 49766 has been marked as a duplicate of this bug. ***
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #53 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #52)
Created attachment 33632 [details]
Reduced case of error: in assign_by_spills, at lra-assigns.c:1335 with -m4
-ml -O2
.ira dump of the test case has the lines
(insn 145 144 148 8 (set (reg/v:SI 245 [ qval ])
(mem:SI (plus:SI (reg/v/f:SI 345 [orig:213 divisors ] [213])
(reg:SI 349 [orig:259 ivtmp.27 ] [259])) [7 MEM[base:
divisors_17, index: ivtmp.27_119, offset: 0B]+0 S4 A32])) jcdctmgr.i:87 258
{movsi_ie}
(nil))
(insn 148 145 149 8 (set (reg/v:SI 246 [ temp ])
(mem:SI (plus:SI (reg:SI 349 [orig:259 ivtmp.27 ] [259])
(reg:SI 334)) [7 MEM[symbol: workspace, index: ivtmp.27_119,
offset: 0B]+0 S4 A32])) jcdctmgr.i:88 258 {movsi_ie}
(nil))
which correspond to the lines
qval = divisors[i];
temp = workspace[i];
of the test case. r349 is the index variable i and r334 is the pointer
variable workspace. LRA assigns R0_REGS to r349 at insn 145 because
rtlanal.c:decompose_mem_address guesses r345 would be base and r349 index.
Unfortunately, that function also guesses r349 would be base and r334 index
at insn 148. LRA tries to assign R0_REGS to r334 according to this guess
result. .reload dump says:
Changing address in insn 148 r349:SI+r334:SI on equiv r349:SI+sfp:SI
Creating newreg=384 from oldreg=153, assigning class R0_REGS to address
r384
Creating newreg=385 from oldreg=349, assigning class R0_REGS to address
r385
Thus regclass of r384 and r385 corrides at insn
148: r246:SI=[r385:SI+r384:SI]
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #54 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Created attachment 33657 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33657action=edit A possible workaround The patch is trying to fix the result of decompose_mem_address so as not to assign INDEX_REG_CLASS to both base and index regs when INDEX_REG_CLASS has one register only.
[Bug c++/63454] [5 Regression] internal compiler error: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63454 --- Comment #3 from Ai Azuma ai.azuma at gmail dot com --- (In reply to Daniel Krügler from comment #1) I don't see any ICE for gcc 5.0.0 20141004 (experimental). Could you retry that one? I am still seeing the ICE with 5.0.0 20141005 (experimental).
[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #17 from Teresa Johnson tejohnson at google dot com ---
I'm going to finish testing my patch, which passes regular
x86_64-unknown-linux-gnu bootstrap + regression tests. I am still
trying to get the lto profiledbootstrap to work. I found some
workarounds for the undefined reference issue on Honza's blog, and I
am trying to get that working. Then I will send to gcc-patches for
review.
In the meantime, H.J. do you want to try the patch? It is below.
Thanks,
Teresa
2014-10-06 Teresa Johnson tejohn...@google.com
* tree-ssa-threadupdate.c (estimated_freqs_path): New function.
(ssa_fix_duplicate_block_edges): Invoke it.
(mark_threaded_blocks): Make two passes to avoid ordering dependences.
Index: tree-ssa-threadupdate.c
===
--- tree-ssa-threadupdate.c (revision 215830)
+++ tree-ssa-threadupdate.c (working copy)
@@ -959,6 +959,43 @@ update_joiner_offpath_counts (edge epath, basic_bl
}
+/* Check if the paths through RD all have estimated frequencies but zero
+ profile counts. This is more accurate than checking the entry block
+ for a zero profile count, since profile insanities sometimes creep in. */
+
+static bool
+estimated_freqs_path (struct redirection_data *rd)
+{
+ edge e = rd-incoming_edges-e;
+ vecjump_thread_edge * *path = THREAD_PATH (e);
+ edge ein;
+ edge_iterator ei;
+ bool non_zero_freq = false;
+ FOR_EACH_EDGE (ein, ei, e-dest-preds)
+{
+ if (ein-count)
+return false;
+ non_zero_freq |= ein-src-frequency != 0;
+}
+
+ for (unsigned int i = 1; i path-length (); i++)
+{
+ edge epath = (*path)[i]-e;
+ if (epath-src-count)
+return false;
+ non_zero_freq |= epath-src-frequency != 0;
+ edge esucc;
+ FOR_EACH_EDGE (esucc, ei, epath-src-succs)
+{
+ if (esucc-count)
+return false;
+ non_zero_freq |= esucc-src-frequency != 0;
+}
+}
+ return non_zero_freq;
+}
+
+
/* Invoked for routines that have guessed frequencies and no profile
counts to record the block and edge frequencies for paths through RD
in the profile count fields of those blocks and edges. This is because
@@ -1058,9 +1095,11 @@ ssa_fix_duplicate_block_edges (struct redirection_
data we first take a snapshot of the existing block and edge frequencies
by copying them into the empty profile count fields. These counts are
then used to do the incremental updates, and cleared at the end of this
- routine. */
+ routine. If the function is marked as having a profile, we still check
+ to see if the paths through RD are using estimated frequencies because
+ the routine had zero profile counts. */
bool do_freqs_to_counts = (profile_status_for_fn (cfun) != PROFILE_READ
- || !ENTRY_BLOCK_PTR_FOR_FN (cfun)-count);
+ || estimated_freqs_path (rd));
if (do_freqs_to_counts)
freqs_to_counts_path (rd);
@@ -2077,35 +2116,48 @@ mark_threaded_blocks (bitmap threaded_blocks)
/* Now iterate again, converting cases where we want to thread
through a joiner block, but only if no other edge on the path
- already has a jump thread attached to it. */
+ already has a jump thread attached to it. We do this in two passes,
+ to avoid situations where the order in the paths vec can hide overlapping
+ threads (the path is recorded on the incoming edge, so we would miss
+ cases where the second path starts at a downstream edge on the same
+ path). First record all joiner paths, deleting any in the unexpected
+ case where there is already a path for that incoming edge. */
for (i = 0; i paths.length (); i++)
{
vecjump_thread_edge * *path = paths[i];
if ((*path)[1]-type == EDGE_COPY_SRC_JOINER_BLOCK)
+{
+ /* Attach the path to the starting edge if none is yet recorded. */
+ if ((*path)[0]-e-aux == NULL)
+(*path)[0]-e-aux = path;
+ else if (dump_file (dump_flags TDF_DETAILS))
+ dump_jump_thread_path (dump_file, *path, false);
+}
+}
+ /* Second, look for paths that have any other jump thread attached to
+ them, and either finish converting them or cancel them. */
+ for (i = 0; i paths.length (); i++)
+{
+ vecjump_thread_edge * *path = paths[i];
+ edge e = (*path)[0]-e;
+
+ if ((*path)[1]-type == EDGE_COPY_SRC_JOINER_BLOCK e-aux == path)
{
unsigned int j;
-
- for (j = 0; j path-length (); j++)
+ for (j = 1; j path-length (); j++)
if ((*path)[j]-e-aux != NULL)
break;
/* If we iterated through the entire path without exiting the loop,
-then we are good to go, attach the path to the starting edge. */
+then we are good to go,
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #18 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
actually I can just add the location to the first argument to avoid the need
to build extra tree...
Somewhat ugly, but seems to work.
Index: internal-fn.c
===
--- internal-fn.c(revision 215958)
+++ internal-fn.c(working copy)
@@ -37,6 +37,8 @@ along with GCC; see the file COPYING3.
#include stringpool.h
#include tree-ssanames.h
#include diagnostic-core.h
+#include builtins.h
+#include pretty-print.h
/* The names of each internal function, indexed by function number. */
const char *const internal_fn_name_array[] = {
@@ -915,6 +917,28 @@ expand_BUILTIN_EXPECT (gimple stmt)
emit_move_insn (target, val);
}
+static void
+expand_OUTPUT_ERROR (gimple stmt)
+{
+ const char * arg0 = c_getstr (gimple_call_arg (stmt, 0));
+ const char * arg1 = c_getstr (gimple_call_arg (stmt, 1));
+ error_at (gimple_location (stmt),
+%KCall to %qs declared with attribute error: %s,
+gimple_call_arg (stmt, 0),
+arg0, identifier_to_locale (arg1));
+}
+
+static void
+expand_OUTPUT_WARNING (gimple stmt)
+{
+ const char * arg0 = c_getstr (gimple_call_arg (stmt, 0));
+ const char * arg1 = c_getstr (gimple_call_arg (stmt, 1));
+ warning_at (gimple_location (stmt),
+ 0, %Kcall to %qs declared with attribute warning: %s,
+ gimple_call_arg (stmt, 0),
+ arg0, identifier_to_locale (arg1));
+}
+
/* Routines to expand each internal function, indexed by function number.
Each routine has the prototype:
Index: cgraphunit.c
===
--- cgraphunit.c(revision 215958)
+++ cgraphunit.c(working copy)
@@ -211,6 +211,8 @@ along with GCC; see the file COPYING3.
#include tree-nested.h
#include gimplify.h
#include dbgcnt.h
+#include expr.h
+#include internal-fn.h
/* Queue of cgraph nodes scheduled to be added into cgraph. This is a
secondary queue used during optimization to accommodate passes that
@@ -976,8 +978,33 @@ analyze_functions (void)
cnode-analyze ();
for (edge = cnode-callees; edge; edge = edge-next_callee)
-if (edge-callee-definition)
- enqueue_node (edge-callee);
+{
+ tree attr, err_attr = NULL;
+ if (edge-callee-definition)
+ enqueue_node (edge-callee);
+ if ((attr = lookup_attribute (warning,
+DECL_ATTRIBUTES (edge-callee-decl))) != NULL
+ || (err_attr = lookup_attribute (warning,
+DECL_ATTRIBUTES (edge-callee-decl
+{
+ gimple_stmt_iterator gsi = gsi_for_stmt (edge-call_stmt);
+ const char *arg0 = lang_hooks.decl_printable_name
(edge-callee-decl, 1);
+ const char *arg1= TREE_STRING_POINTER
+ (TREE_VALUE (TREE_VALUE (attr ? attr : err_attr)));
+ tree arg0_expr = build_string_literal (strlen (arg0), arg0);
+
+ gimple call = gimple_build_call_internal
+ (attr ? IFN_OUTPUT_WARNING : IFN_OUTPUT_ERROR, 2,
+ arg0_expr,
+ build_string_literal (strlen (arg1), arg1));
+ gsi_insert_before (gsi, call, GSI_SAME_STMT);
+ gimple_set_location (call, gimple_location (edge-call_stmt));
+ gimple_set_block (call, gimple_block (edge-call_stmt));
+ /* Disgnostic code needs tree to pick inline stack from. */
+ SET_EXPR_LOCATION (arg0_expr, gimple_location
(edge-call_stmt));
+ TREE_SET_BLOCK (arg0_expr, gimple_block (edge-call_stmt));
+}
+}
if (optimize flag_devirtualize)
{
cgraph_edge *next;
Index: builtin-types.def
===
--- builtin-types.def(revision 215958)
+++ builtin-types.def(working copy)
@@ -581,3 +581,5 @@ DEF_FUNCTION_TYPE_2 (BT_FN_VOID_VPTR_LDO
BT_VOLATILE_PTR, BT_LONGDOUBLE)
DEF_FUNCTION_TYPE_2 (BT_FN_VOID_VPTR_SIZE, BT_VOID,
BT_VOLATILE_PTR, BT_SIZE)
+DEF_FUNCTION_TYPE_2 (BT_FN_VOID_CONST_STRING_CONST_STRING,
+ BT_VOID, BT_CONST_STRING, BT_CONST_STRING)
Index: expr.c
===
--- expr.c(revision 215958)
+++ expr.c(working copy)
@@ -10346,21 +10346,7 @@ expand_expr_real_1 (tree exp, rtx target
if (CALL_EXPR_VA_ARG_PACK (exp))
error (%Kinvalid use of %__builtin_va_arg_pack ()%, exp);
{
-tree fndecl = get_callee_fndecl (exp), attr;
-
-if (fndecl
- (attr = lookup_attribute (error,
- DECL_ATTRIBUTES (fndecl))) != NULL)
- error (%Kcall to %qs declared with attribute error: %s,
- exp, identifier_to_locale (lang_hooks.decl_printable_name
