Re: Is optimize attribute on fndecl handled differently?
On Mon, Sep 29, 2014 at 12:09 AM, FX wrote:
Filed as PR63401: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63401
This is easy to see with a simple C test case:
//__attribute__ ((optimize(strength-reduce)))
int foo (float x) { return __builtin_isnan(x); }
Compiled with -O3 -ffast-math, the isnan is simplified out (fast math means
no NaNs). If you uncomment the attribute (chosen because it’s actually
useless), and compile again with -O3 -ffast-math: the isnan test is not
simplified any more. This is because the codepath through
default_options_optimization() has overwritten the value of the flags
handled in set_fast_math_flags(): flag_finite_math_only, flag_signed_zeros,
flag_trapping_math and flag_unsafe_math_optimizations.
I’m CC’ing the maintainers who added the optimize attribute in the first
place, as they might have an idea how to fix this. This is way beyond my
league!
Perhaps Joseph can help, in his position as maintainer of the option
handling subsystem.
Ciao!
Steven
GCC 4.9 internal compiler error
Hi all!
It was found that OA fails to build with GCC 4.9 on amd64 [1]
I can confirm this with r3094 on bare metal too.
# gcc --version
gcc-4.9.real (Debian 4.9.1-14) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I can imaging that this is a bug in OpenAxiom, but GCC should not crash.
GCC complains on this line
https://sourceforge.net/p/open-axiom/code/HEAD/tree/trunk/src/include/storage.H#l273
Quoting [1]:
g++ -DHAVE_CONFIG_H -I. -I../../../src/syntax -I../../config
-I../../../src/include -I../../x86_64-pc-linux-gnu/include
-D_FORTIFY_SOURCE=2 -m64 -D_GNU_SOURCE -std=c++11 -g -O2
-fstack-protector-strong -Wformat -Werror=format-security -O2 -Wall -c -o
libsyntax_a-sexpr.o `test -f 'sexpr.cc' || echo
'../../../src/syntax/'`sexpr.cc
In file included from ../../x86_64-pc-linux-gnu/include/open-axiom/sexpr:47:0,
from ../../../src/syntax/sexpr.cc:39:
../../x86_64-pc-linux-gnu/include/open-axiom/storage: In instantiation of 'T*
OpenAxiom::Memory::FactoryT::make(const Args ...) [with Args =
{std::vectorconst OpenAxiom::Sexpr::Syntax*, std::allocatorconst
OpenAxiom::Sexpr::Syntax* , bool}; T = OpenAxiom::Sexpr::ListSyntax]':
../../../src/syntax/sexpr.cc:341:37: required from here
../../x86_64-pc-linux-gnu/include/open-axiom/storage:275:52: internal
compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2066
return new(this-allocate(1)) T{args...};
^
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions.
Preprocessed source stored into /tmp/cc6mQYS6.out file, please attach this to
your bugreport.
make[3]: *** [libsyntax_a-sexpr.o] Error 1
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761549
Re: [Patch, Fortran] Add CO_BROADCAST
Dominique Dhumieres wrote: The failures for the gfortran.dg/coarray_collectives_9.f90 are fixed with the following patch: Looks good to me. The patch is OK with a ChangLog. Thanks for the patch and sorry for the test fails. Tobias
Re: GCC 4.9 internal compiler error
On Mon, Sep 29, 2014 at 11:43:47AM +0400, Игорь Пашев wrote: Hi all! It was found that OA fails to build with GCC 4.9 on amd64 [1] I can confirm this with r3094 on bare metal too. # gcc --version gcc-4.9.real (Debian 4.9.1-14) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I can imaging that this is a bug in OpenAxiom, but GCC should not crash. GCC complains on this line https://sourceforge.net/p/open-axiom/code/HEAD/tree/trunk/src/include/storage.H#l273 Please provide a preprocessed source and file a bug. https://gcc.gnu.org/bugs/ Marek
Re: Issue with __builtin_remainder expansion on i386
Hello!
I have just submitted a patch emitting some new floating-point code from the
Fortran front-end,
improving our IEEE support there:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02444.html
However, in one of the cases where we emit a call to __builtin_remainderf(),
we get wrong code
generation on i386. It is peculiar because:
- the wrong code occurs at all optimization levels, and the following flags
(any or all) do not
affect it:
-mfpmath=sse -msse2 -fno-unsafe-math-optimizations -frounding-math
-fsignaling-nans
- the wrong code does not occur with -ffloat-store
- the code generate looks fine by every aspect I could try. I could not
generate a direct C
testcase, unfortunately, but it is equivalent to:
The __builtin_remainderf on x86 expands to x87 fprem1 instruction [1].
According to the table in [1], +inf is not handled, and generates
division-by-zero exception.
IMO, we have to add flag_finite_math_only to expander enable
condition of remainder{sf,df,xf}3 expanders in i386.md
[1] http://x86.renejeschke.de/html/file_module_x86_id_108.html
Uros.
Re: Issue with __builtin_remainder expansion on i386
The __builtin_remainderf on x86 expands to x87 fprem1 instruction [1].
According to the table in [1], +inf is not handled, and generates
division-by-zero exception.
IMO, we have to add flag_finite_math_only to expander enable
condition of remainder{sf,df,xf}3 expanders in i386.md
I can confirm that the patch below indeed fixes the issue.
Index: gcc/config/i386/i386.md
===
--- gcc/config/i386/i386.md (revision 215645)
+++ gcc/config/i386/i386.md (working copy)
@@ -13893,7 +13893,7 @@
[(use (match_operand:XF 0 register_operand))
(use (match_operand:XF 1 general_operand))
(use (match_operand:XF 2 general_operand))]
- TARGET_USE_FANCY_MATH_387
+ TARGET_USE_FANCY_MATH_387 flag_finite_math_only
{
rtx_code_label *label = gen_label_rtx ();
@@ -13916,7 +13916,7 @@
[(use (match_operand:MODEF 0 register_operand))
(use (match_operand:MODEF 1 general_operand))
(use (match_operand:MODEF 2 general_operand))]
- TARGET_USE_FANCY_MATH_387
+ TARGET_USE_FANCY_MATH_387 flag_finite_math_only
{
rtx (*gen_truncxf) (rtx, rtx);
RE: Listing a maintainer for libcilkrts, and GCC's Cilk Plus implementation generally?
Hi! On Tue, 23 Sep 2014 11:02:30 +, Zamyatin, Igor igor.zamya...@intel.com wrote: Jeff Law wrote: The original plan was for Balaji to take on this role; however, his assignment within Intel has changed and thus he's not going to have time to work on Cilk+ anymore. Igor Zamyatin has been doing a fair amount of Cilk+ maintenance/bugfixing and it might make sense for him to own it in the long term if he's interested. That's right. Thanks! Can I add 2 records (cilk plus and libcilkrts) to Various Maintainers section? I understand Jeff's email as a pre-approval of such a patch. Grüße, Thomas pgpackQZ5h0jQ.pgp Description: PGP signature
Re: Listing a maintainer for libcilkrts, and GCC's Cilk Plus implementation generally?
On Mon, Sep 29, 2014 at 12:56:06PM +0200, Thomas Schwinge wrote: Hi! On Tue, 23 Sep 2014 11:02:30 +, Zamyatin, Igor igor.zamya...@intel.com wrote: Jeff Law wrote: The original plan was for Balaji to take on this role; however, his assignment within Intel has changed and thus he's not going to have time to work on Cilk+ anymore. Igor Zamyatin has been doing a fair amount of Cilk+ maintenance/bugfixing and it might make sense for him to own it in the long term if he's interested. That's right. Thanks! Can I add 2 records (cilk plus and libcilkrts) to Various Maintainers section? I understand Jeff's email as a pre-approval of such a patch. I think only SC can appoint maintainers, and while Jeff is in the SC, my reading of that mail wasn't that it was the SC that has acked that, but rather a question if Igor is willing to take that role, which then would need to be acked by SC. Jakub
Re: Enable EBX for x86 in 32bits PIC code
On Wed, Sep 24, 2014 at 03:20:44PM -0600, Jeff Law wrote: On 09/24/14 14:32, Ilya Enkovich wrote: 2014-09-24 19:27 GMT+04:00 Jeff Law l...@redhat.com: On 09/24/14 00:56, Ilya Enkovich wrote: After register allocation we have no idea where GOT address is and therefore delegitimize_address target hook becomes less efficient and cannot remove UNSPECs. That's what I see now when build GCC with patch applied: In theory this shouldn't be too hard to fix. I haven't looked at the code, but it might be something looking explicitly for ebx by register #, or something similar. Which case within delegitimize_address isn't firing as it should after your changes? It is the case I had to fix: @@ -14415,7 +14433,8 @@ ix86_delegitimize_address (rtx x) ... movl foo@GOTOFF(%ecx), %edx in which case we return (%ecx - %ebx) + foo. */ - if (pic_offset_table_rtx) + if (pic_offset_table_rtx + (!reload_completed || !ix86_use_pseudo_pic_reg ())) result = gen_rtx_PLUS (Pmode, gen_rtx_MINUS (Pmode, copy_rtx (addend), pic_offset_table_rtx), result); Originally if there is a UNSPEC_GOTOFFSET but no EBX usage then we just remove this UNSPEC and substract EBX value. With pseudo PIC reg we should use PIC register instead of EBX but it is unclear what to use after register allocation. What's the RTL before after allocation? Feel free to just pass along the dump files for sum_r4 that you referenced in a prior message. I wonder if during/after reload we just couldn't look at ORIGINAL_REGNO of hard regs if ix86_use_pseudo_pic_reg. Or is that the other case, where you don't have any PIC register replacement around, and want to subtract something? Perhaps in that case we could just subtract the value of _GLOBAL_OFFSET_TABLE_ symbol if we have nothing better around. Jakub
Re: Listing a maintainer for libcilkrts, and GCC's Cilk Plus implementation generally?
Hi! On Mon, 29 Sep 2014 13:00:19 +0200, Jakub Jelinek ja...@redhat.com wrote: On Mon, Sep 29, 2014 at 12:56:06PM +0200, Thomas Schwinge wrote: On Tue, 23 Sep 2014 11:02:30 +, Zamyatin, Igor igor.zamya...@intel.com wrote: Jeff Law wrote: The original plan was for Balaji to take on this role; however, his assignment within Intel has changed and thus he's not going to have time to work on Cilk+ anymore. Igor Zamyatin has been doing a fair amount of Cilk+ maintenance/bugfixing and it might make sense for him to own it in the long term if he's interested. That's right. Thanks! Can I add 2 records (cilk plus and libcilkrts) to Various Maintainers section? I understand Jeff's email as a pre-approval of such a patch. I think only SC can appoint maintainers, and while Jeff is in the SC, my reading of that mail wasn't that it was the SC that has acked that, but rather a question if Igor is willing to take that role, which then would need to be acked by SC. I see. Thanks for clarifying that formal process. Grüße, Thomas pgpB4uisWeWXK.pgp Description: PGP signature
RE: MIPS Maintainers
-Original Message- From: Jeff Law [mailto:l...@redhat.com] Sorry this has taken so long, the delays have been totally mine in not following-up to get votes, then tally them from the steering committee. I'm pleased to announce that Catherine Moore and Matthew Fortune have been appointed as maintainers for the MIPS port. Catherine Matthew, please update the MAINTAINERS file appropriately. Thanks for everyone's patience, Thank you. I've now updated the MAINTAINERS file.
Re: Problems with gcc-bugs
On 27 September 2014 22:13, George R Goffe wrote: Hi, I'm having trouble getting email to Christoph who manages(?) the gcc-bugs mailing list. My emails are rejected. I'm not an email guy so the messages are rather indecipherable to me. Below is what I'm seeing. Regards, George... Sorry, we were unable to deliver your message to the following address. cgf-use-the-mailinglist-ple...@gnu.org: That looks like a suggestion to use the mailing list, instead of mailing him directly. Have you tried mailing the overseers list at gcc.gnu.org instead? Remote host said: 550 Previous (cached) callout verification failure [RCPT_TO]
Re: Is optimize attribute on fndecl handled differently?
On Mon, 29 Sep 2014, Steven Bosscher wrote:
On Mon, Sep 29, 2014 at 12:09 AM, FX wrote:
Filed as PR63401: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63401
This is easy to see with a simple C test case:
//__attribute__ ((optimize(strength-reduce)))
int foo (float x) { return __builtin_isnan(x); }
Compiled with -O3 -ffast-math, the isnan is simplified out (fast math
means no NaNs). If you uncomment the attribute (chosen because it’s
actually useless), and compile again with -O3 -ffast-math: the isnan test
is not simplified any more. This is because the codepath through
default_options_optimization() has overwritten the value of the flags
handled in set_fast_math_flags(): flag_finite_math_only,
flag_signed_zeros, flag_trapping_math and flag_unsafe_math_optimizations.
I’m CC’ing the maintainers who added the optimize attribute in the first
place, as they might have an idea how to fix this. This is way beyond my
league!
Perhaps Joseph can help, in his position as maintainer of the option
handling subsystem.
Bug 38716 is a similar issue.
I think of this as being about which options take priority in determining
the final setting of some gcc_options field. You want options implied by
-Osomething not to override anything set explicitly.
Properly, this requires the opts_set gcc_options structure to be used to
store not booleans (explicitly set / not) but information about the
priority with which something was set (distance as in appendix 1 of
https://gcc.gnu.org/ml/gcc/2010-01/msg00063.html). (This mainly shows
up with the optimize attribute because otherwise the optimization level
gets processed before other options.) You may however be able to fix some
cases with smaller changes:
* Avoid reprocessing the existing optimization level if the attribute
doesn't specify any optimization level.
* Don't override any option that was explicitly set when processing the
optimization level. (By itself this won't help with -ffast-math because
the issue is overriding all the other options implicitly set with
-ffast-math. But as long as -ffast-math itself doesn't respect the rule
that more specific options override less specific ones, whatever the
command-line ordering, you could just as well change set_fast_math_flags
to take opts_set as well and mark the options in question explicitly set,
unless any other code checks if they were explicitly set and so would
regress from such a change.)
--
Joseph S. Myers
jos...@codesourcery.com
Re: Dijkstra's Methodology for Secure Systems Development
The following is a response to what some may think an implausible suggestion made here: http://lists.gnu.org/archive/html/guile-devel/2014-09/msg00124.html The suggestion is that the system of education has been subverted so that there are unknown physical laws which give the unseen enemy strange powers over the semantics of computer hardware and software. http://livelogic.blogspot.com/2014/09/subverting-laws-of-physics.html I make what I think most people will see to be a convincing argument that this is in fact the case.
Re: Is optimize attribute on fndecl handled differently?
Thanks for the analysis. FYI: I don’t intend to follow up on that middle-end part, it’s much out of my league, and I focus my limited hacking time to the Fortran front-end and runtime library. I’ve filed the PR, so at least the problem is documented. I will affect gfortran in the form of missed optimizations in routines using the IEEE modules, so at least it’s not wrong code for us :) Cheers, FX
Re: Problems with gcc-bugs
Jonathan, I'll give it a try. Thanks. What is the problem with the mailing list software? Can't handle rich-text? What a pain! George... From: Jonathan Wakely jwakely@gmail.com To: George R Goffe grgo...@yahoo.com Cc: gcc@gcc.gnu.org gcc@gcc.gnu.org Sent: Monday, September 29, 2014 6:14 AM Subject: Re: Problems with gcc-bugs On 27 September 2014 22:13, George R Goffe wrote: Hi, I'm having trouble getting email to Christoph who manages(?) the gcc-bugs mailing list. My emails are rejected. I'm not an email guy so the messages are rather indecipherable to me. Below is what I'm seeing. Regards, George... Sorry, we were unable to deliver your message to the following address. cgf-use-the-mailinglist-ple...@gnu.org: That looks like a suggestion to use the mailing list, instead of mailing him directly. Have you tried mailing the overseers list at gcc.gnu.org instead? Remote host said: 550 Previous (cached) callout verification failure [RCPT_TO]
Problems with the gcc-bugs mailing list.
Hi, I'm trying to get some help here. I have two problems with the mailing list software. #1) I have tried to get into digest mode by unsubscribing and re-subscribing to the list but that's not working. #2) I'm trying to get some help from the owner of the list but emails to him are bouncing. What is the problem with sending rich-text emails? Old software? Anyone have any ideas? Please help me. Regards, George...
Re: Problems with gcc-bugs
On Sep 29, 2014, at 7:59 PM, George R Goffe grgo...@yahoo.com wrote: Jonathan, I'll give it a try. Thanks. What is the problem with the mailing list software? Can't handle rich-text? What a pain! I don’t know if that is true, but if so, a lot of people would argue that is a feature. (I’m inclined to agree). paul
[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302 --- Comment #14 from Zhenqiang Chen zhenqiang.chen at arm dot com --- Created attachment 33608 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33608action=edit patch After investigation, I found I mis-use tree_log2. Please try the attached patch. If it works, I will run all tests and send it for community review. Thanks!
[Bug middle-end/35545] tracer pass is run too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545 --- Comment #20 from rguenther at suse dot de rguenther at suse dot de --- On Fri, 26 Sep 2014, law at redhat dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545 --- Comment #14 from Jeffrey A. Law law at redhat dot com --- This feels like the kind of situation where I've always wanted a pass to be able to say something like I've done some set of transformations, schedule the appropriate cleanup passes to run. It's heavyweight, but making the tracer imply a later DOM or VRP pass might make sense. Uh that idea will lead to very big compile-time increases. One thing I'd liked to do at some point is make the SSA propagators and/or DOM work on MEME regions so we can schedule them on a sub-CFG. Richard.
[Bug tree-optimization/47413] Constant Propagation and Virtual Function Tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47413
--- Comment #3 from rguenther at suse dot de rguenther at suse dot de ---
On Fri, 26 Sep 2014, hubicka at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47413
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org ---
Current mainline gets pretty close:
;; Function int f1337(obj*) (_ZL5f1337P3obj, funcdef_no=19, decl_uid=3418,
cgraph_uid=19, symbol_order=19)
int f1337(obj*) (struct obj * obj)
{
bb 2:
return 1337;
}
;; Function int main() (main, funcdef_no=22, decl_uid=3427, cgraph_uid=22,
symbol_order=22) (executed once)
Removing basic block 5
int main() ()
{
struct obj * obj;
int _1;
int _10;
bb 2:
obj_7 = malloc (8);
if (obj_7 == 0B)
goto bb 4;
else
goto bb 3;
bb 3:
obj_7-vtab = vtab1337;
_10 = f1337 (obj_7);
printf (%d\n, _10);
bb 4:
# _1 = PHI 0(2), 1(3)
return _1;
}
So we are down to one missing inline. After FRE we get:
bb 2:
obj_13 = malloc (8);
if (obj_13 == 0B)
goto bb 4;
else
goto bb 3;
bb 3:
obj_13-vtab = vtab1337;
bb 4:
# _14 = PHI 0B(2), obj_13(3)
if (_14 == 0B)
goto bb 6;
else
goto bb 5;
bb 5:
_4 = _14-vtab;
_15 = _4-f;
_16 = _15 (_14);
printf (%d\n, _16);
So purely local problem. I suppose FRE could propagate through by knowing that
on the other path program with segfault?
Not in the way value-numbering works (it value-numbers _14 as VARYING
obviously). The above feels like a missed jump-threading opportunity
to me. Eventually we could also help DOM/copyprop with replacing
the test by _14 != ohj_13 ...
In my view DOM should be able to figure out a value for _14
on the else edge as well (doesn't exactly fit DOM but certainly
most easily implemented there)
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2014-09-29 CC||jiwang at gcc dot gnu.org, ||trippels at gcc dot gnu.org Ever confirmed|0 |1 Summary|gcc 5 miscompiles linux |[5 Regression] gcc 5 |block layer |miscompiles linux block ||layer Target Milestone|--- |5.0 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r215563.
[Bug fortran/37173] Check whether intrinsic assignment between character kind=1 / 4 is allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173 --- Comment #5 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #3) We still might add a -std=f2008 check there. I find the same wording in my local copy of F2003, actually: If variable and expr have different kind type parameters, each character c in expr is converted to the kind type parameter of variable by ACHAR(IACHAR(c),KIND(variable)). (ISO/IEC JTC1/SC22/WG5 N1578 dated 2003-10-8) (In reply to Dominique d'Humieres from comment #4) (5) if the variable is of type character and of ISO 10646, ASCII, or default character kind, expr shall be of ISO 10646, ASCII, or default character kind, (6) otherwise if the variable is of type character expr shall have the same kind type parameter, I think there is a reasonable interpretation where it does not conflict: it means ISO 10646 and ASCII and default interconvert, but not necessarily other character kinds. It does not say, for example, expr shall be of ISO 10646, ASCII, or default character kind (*respectively*).
[Bug fortran/37173] Check whether intrinsic assignment between character kind=1 / 4 is allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #6 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- So, given the clear change in wording since the 2008 interp, I close this report as INVALID.
[Bug fortran/36534] Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36534 Bug 36534 depends on bug 37173, which changed state. Bug 37173 Summary: Check whether intrinsic assignment between character kind=1 / 4 is allowed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID
[Bug libstdc++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Piotr Dziwinski from comment #1) I would also second the proposal to fix this issue by implementing flat version of std::tuple. Perhaps the existing std::tr1::tuple implementation can be re-used here? GCC's std::tr1:tuple is not a flat implementation, and does not conform to the C++11 requirements, so no, that's not an option.
[Bug c++/51385] Unnecessary instantiation converting to pointer to template class instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in 4.9.0, I'm adding the testcase and closing the bug.
[Bug c++/63405] New: Internal compiler error when building OpenAxiom on linux/amd64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405
Bug ID: 63405
Summary: Internal compiler error when building OpenAxiom on
linux/amd64
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pashev.igor at gmail dot com
Created attachment 33609
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33609action=edit
Preprocessed file
Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761549
Error message:
make[3]: Entering directory
'/home/pashev/work/projects/pkg-open-axiom/build-tree/src/syntax'
g++ -DHAVE_CONFIG_H -I. -I../../../src/syntax -I../../config
-I../../../src/include -I../../x86_64-pc-linux-gnu/include -D_FORTIFY_SOURCE=2
-m64 -D_GNU_SOURCE -std=c++11 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -O2 -Wall -c -o libsyntax_a-sexpr.o `test -f 'sexpr.cc'
|| echo '../../../src/syntax/'`sexpr.cc
In file included from ../../x86_64-pc-linux-gnu/include/open-axiom/sexpr:47:0,
from ../../../src/syntax/sexpr.cc:39:
../../x86_64-pc-linux-gnu/include/open-axiom/storage: In instantiation of 'T*
OpenAxiom::Memory::FactoryT::make(const Args ...) [with Args =
{std::vectorconst OpenAxiom::Sexpr::Syntax*, std::allocatorconst
OpenAxiom::Sexpr::Syntax* , bool}; T = OpenAxiom::Sexpr::ListSyntax]':
../../../src/syntax/sexpr.cc:345:37: required from here
../../x86_64-pc-linux-gnu/include/open-axiom/storage:273:52: internal compiler
error: in cp_perform_integral_promotions, at cp/typeck.c:2066
return new(this-allocate(1)) T{args...};
^
# g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.9.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-14'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-14)
[Bug c++/51385] Unnecessary instantiation converting to pointer to template class instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Sep 29 09:06:31 2014 New Revision: 215680 URL: https://gcc.gnu.org/viewcvs?rev=215680root=gccview=rev Log: 2014-09-29 Paolo Carlini paolo.carl...@oracle.com PR c++/51385 * g++.dg/template/pr51385.C: New. Added: trunk/gcc/testsuite/g++.dg/template/pr51385.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/51385] Unnecessary instantiation converting to pointer to template class instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c/63307] [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307
--- Comment #1 from Igor Zamyatin izamyatin at gmail dot com ---
Would like to ask here first - will something like following be ok:
diff --git a/gcc/c-family/cilk.c b/gcc/c-family/cilk.c
index bf549ad..f453bc5 100644
--- a/gcc/c-family/cilk.c
+++ b/gcc/c-family/cilk.c
@@ -36,6 +36,7 @@ along with GCC; see the file COPYING3. If not see
#include toplev.h
#include cgraph.h
#include diagnostic.h
+#include vec.h
#include cilk.h
enum add_variable_type {
@@ -332,15 +333,23 @@ create_cilk_helper_decl (struct wrapper_data *wd)
return fndecl;
}
+typedef struct
+{
+ tree parm;
+ tree arg;
+} decl_pair;
+
+static vecdecl_pair vec_arglist;
+
/* A function used by walk tree to find wrapper parms. */
static bool
wrapper_parm_cb (const void *key0, void **val0, void *data)
{
- struct wrapper_data *wd = (struct wrapper_data *) data;
tree arg = * (tree *)key0;
tree val = (tree)*val0;
tree parm;
+ decl_pair dp;
if (val == error_mark_node || val == arg)
return true;
@@ -370,25 +379,48 @@ wrapper_parm_cb (const void *key0, void **val0, void
*data)
}
else
parm = val;
- TREE_CHAIN (parm) = wd-parms;
- wd-parms = parm;
- wd-argtypes = tree_cons (NULL_TREE, TREE_TYPE (parm), wd-argtypes);
- wd-arglist = tree_cons (NULL_TREE, arg, wd-arglist);
+
+ dp.parm = parm;
+ dp.arg = arg;
+ vec_arglist.safe_push(dp);
return true;
}
/* This function is used to build a wrapper of a certain type. */
+static int
+compare_decls (const void *a, const void *b)
+{
+const decl_pair* t1 = (const decl_pair*) a;
+const decl_pair* t2 = (const decl_pair*) b;
+
+return DECL_UID(t1-arg) DECL_UID(t2-arg);
+}
+
static void
build_wrapper_type (struct wrapper_data *wd)
{
+ unsigned int j;
+ decl_pair * c;
wd-arglist = NULL_TREE;
wd-parms = NULL_TREE;
wd-argtypes = void_list_node;
- pointer_map_traverse (wd-decl_map, wrapper_parm_cb, wd);
+ vec_arglist.create (0);
+ pointer_map_traverse (wd-decl_map, wrapper_parm_cb, NULL);
gcc_assert (wd-type != CILK_BLOCK_FOR);
+ vec_arglist.qsort(compare_decls);
+
+ FOR_EACH_VEC_ELT (vec_arglist, j, c)
+{
+ TREE_CHAIN (c-parm) = wd-parms;
+ wd-parms = c-parm;
+ wd-argtypes = tree_cons (NULL_TREE, TREE_TYPE (c-parm), wd-argtypes);
+ wd-arglist = tree_cons (NULL_TREE, c-arg, wd-arglist);
+}
+ vec_arglist.release();
+
/* Now build a function.
Its return type is void (all side effects are via explicit parameters).
Its parameters are WRAPPER_PARMS with type WRAPPER_TYPES.
Bootstrapped successfully with GCC_COMPARE_DEBUG=1
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target||mingw-w64 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Which of macros are defined on mingw-w64? Preprocessing this should tell you #include chrono #ifdef _GLIBCXX_USE_CLOCK_REALTIME #ifdef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL #warning system_clock using syscall(SYS_clock_gettime, CLOCK_REALTIME, tp); #else #warning system_clock using clock_gettime(CLOCK_REALTIME, tp); #endif #elif defined(_GLIBCXX_USE_GETTIMEOFDAY) #warning system_clock using gettimeofday(tv, 0); #else #warning system_clock using std::time(0); #endif #ifdef _GLIBCXX_USE_CLOCK_MONOTONIC #ifdef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL #warning steady_clock using syscall(SYS_clock_gettime, CLOCK_MONOTONIC, tp); #else #warning steady_clock using clock_gettime(CLOCK_MONOTONIC, tp); #endif #else #warning steady_clock using time_point(system_clock::now().time_since_epoch()); #endif
[Bug c/63307] [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Igor Zamyatin from comment #1)
Would like to ask here first - will something like following be ok:
+typedef struct
+{
+ tree parm;
+ tree arg;
+} decl_pair;
+
+static vecdecl_pair vec_arglist;
Just use struct cilk_decl_pair, no need for typedef in C++ here, and
try to avoid ODR issues. Also, why a static variable? Then you supposedly
would need to GTY handle it etc., which is IMHO undesirable.
static bool
wrapper_parm_cb (const void *key0, void **val0, void *data)
{
- struct wrapper_data *wd = (struct wrapper_data *) data;
tree arg = * (tree *)key0;
tree val = (tree)*val0;
tree parm;
+ decl_pair dp;
if (val == error_mark_node || val == arg)
return true;
@@ -370,25 +379,48 @@ wrapper_parm_cb (const void *key0, void **val0, void
*data)
}
else
parm = val;
- TREE_CHAIN (parm) = wd-parms;
- wd-parms = parm;
- wd-argtypes = tree_cons (NULL_TREE, TREE_TYPE (parm), wd-argtypes);
- wd-arglist = tree_cons (NULL_TREE, arg, wd-arglist);
+
+ dp.parm = parm;
+ dp.arg = arg;
+ vec_arglist.safe_push(dp);
Formatting, missing space before (. But more importantly, the diagnostics
still be in random order. So, I'd strongly suggest to move also the
diagnostics and ADDR_EXPR building etc. into a loop that walks the sorted
vector.
return true;
}
/* This function is used to build a wrapper of a certain type. */
+static int
+compare_decls (const void *a, const void *b)
+{
+const decl_pair* t1 = (const decl_pair*) a;
+const decl_pair* t2 = (const decl_pair*) b;
+
+return DECL_UID(t1-arg) DECL_UID(t2-arg);
Formatting. Space before *, not after, space before (, indentation 2 columns
rather than 4.
+}
+
static void
build_wrapper_type (struct wrapper_data *wd)
{
+ unsigned int j;
+ decl_pair * c;
wd-arglist = NULL_TREE;
wd-parms = NULL_TREE;
wd-argtypes = void_list_node;
- pointer_map_traverse (wd-decl_map, wrapper_parm_cb, wd);
+ vec_arglist.create (0);
+ pointer_map_traverse (wd-decl_map, wrapper_parm_cb, NULL);
gcc_assert (wd-type != CILK_BLOCK_FOR);
+ vec_arglist.qsort(compare_decls);
Formatting.
+
+ FOR_EACH_VEC_ELT (vec_arglist, j, c)
+{
+ TREE_CHAIN (c-parm) = wd-parms;
+ wd-parms = c-parm;
+ wd-argtypes = tree_cons (NULL_TREE, TREE_TYPE (c-parm),
wd-argtypes);
+ wd-arglist = tree_cons (NULL_TREE, c-arg, wd-arglist);
+}
As I said earlier, I'd do diagnostics and ADDR_EXPR creation in this loop too.
+ vec_arglist.release();
Formatting. You could use auto_vec, perhaps with some stack allocated initial
buffer if you think say 16 vector elements would be typically enough.
Also, what about all the remaining 3 callbacks that create or may create decls
and have the same problem? for_local_cb, wrapper_local_cb and
declare_one_free_variable.
[Bug tree-optimization/63406] New: -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63406
Bug ID: 63406
Summary: -Warray-bounds false positive with -O3
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
int total_objs = 0;
#ifndef N
#define N 2
#endif
void *objs[N];
void
del_obj (void *obj)
{
int i = 0;
while (i total_objs objs[i] != obj)
++i;
if (i = total_objs)
return;
while (++i total_objs)
objs[i - 1] = objs[i];
--total_objs;
}
Both loops seem to be unrolled N times (although the second loop clearly could
be
only executed N-1 times, because otherwise it triggers undefined behavior in
the loop), and after unrolling the misdesigned -Warray-bounds warning complains
on the last iteration of the unrolled loop.
[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 Julian Taylor jtaylor.debian at googlemail dot com changed: What|Removed |Added CC||jtaylor.debian at googlemail dot c ||om --- Comment #21 from Julian Taylor jtaylor.debian at googlemail dot com --- this fix causes another ICE, see PR63342 but it doesn't seem to affect the current 4.9 and 4.8 branches, so there is probably some other interaction with a 5.0 change causing it.
[Bug middle-end/35545] tracer pass is run too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #21 from rguenther at suse dot de rguenther at suse dot de ---
nOn Sat, 27 Sep 2014, hubicka at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||mliska at suse dot cz
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #16 from Jan Hubicka hubicka at gcc dot gnu.org ---
I have moved tracer before the late cleanups that seems to be rather obbious
thing to do. This lets us to optimize the testcase (with -O2):
int main() ()
{
struct A * ap;
int i;
int _6;
bb 2:
bb 3:
# i_29 = PHI i_22(6), 0(2)
_6 = i_29 % 7;
if (_6 == 0)
goto bb 4;
else
goto bb 5;
bb 4:
ap_8 = operator new (16);
ap_8-i = 0;
ap_8-_vptr.A = MEM[(void *)_ZTV1A + 16B];
goto bb 6;
bb 5:
ap_13 = operator new (16);
MEM[(struct B *)ap_13].D.2244.i = 0;
MEM[(struct B *)ap_13].b = 0;
MEM[(struct B *)ap_13].D.2244._vptr.A = MEM[(void *)_ZTV1B + 16B];
bb 6:
# ap_4 = PHI ap_13(5), ap_8(4)
operator delete (ap_4);
i_22 = i_29 + 1;
if (i_22 != 1)
goto bb 3;
else
goto bb 7;
bb 7:
return 0;
}
Martin, I do not have SPEC setup, do you think you can benchmark the attached
patch with SPEC and profile feedback and also non-FDO -O3 -ftracer compared to
-O3, please?
It would be nice to know code size impact, too.
Index: passes.def
===
--- passes.def (revision 215651)
+++ passes.def (working copy)
@@ -155,6 +155,7 @@ along with GCC; see the file COPYING3.
NEXT_PASS (pass_dce);
NEXT_PASS (pass_call_cdce);
NEXT_PASS (pass_cselim);
+ NEXT_PASS (pass_tracer);
NEXT_PASS (pass_copy_prop);
NEXT_PASS (pass_tree_ifcombine);
NEXT_PASS (pass_phiopt);
@@ -252,7 +253,6 @@ along with GCC; see the file COPYING3.
NEXT_PASS (pass_cse_reciprocals);
NEXT_PASS (pass_reassoc);
NEXT_PASS (pass_strength_reduction);
- NEXT_PASS (pass_tracer);
NEXT_PASS (pass_dominator);
NEXT_PASS (pass_strlen);
NEXT_PASS (pass_vrp);
Doing it at same approximately the same place as loop header copying seems to
make most sense to me. It benefits from early cleanups and DCE definitly and
it should enable more fun with the later scalar passes that are almost all
rerun then.
We need to make sure tracer doesn't mess too much with loops then.
Btw, useless tracing may be undone again by tail-merging.
Tracer seems to consume only profile information and thus doesn't
rely on any other transforms (well, apart from cleanups which could
affect its cost function). Why not schedule it even earlier?
Like to before pass_build_alias? (the pipeline up to loop transforms
is quite a mess...)
[Bug rtl-optimization/32629] missing CSE for constant in registers / inefficient memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- We could also make $0 a not legitimate constant on x86... (and undo that late with a peephole2)
[Bug rtl-optimization/61605] Potential optimization: Keep unclobbered argument registers live across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-29 CC||vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from vries at gcc dot gnu.org --- If a function is known to not clobber an argument register then the caller shouldn't have to save/reload that register across the function call. If a function is known to not clobber an call_used_reg then the caller can use it as a non-call_used_reg across the function call. This diff shows the example with -fno-use-caller-save vs -fuse-caller-save: ... foo: .LFB1: .cfi_startproc -pushq%rbx -.cfi_def_cfa_offset 16 -.cfi_offset 3, -16 -movl%edi, %ebx +movl%edi, %edx callbar -addl%ebx, %eax -popq%rbx -.cfi_def_cfa_offset 8 +addl%edx, %eax ret .cfi_endproc .LFE1: ... -fuse-caller-save removes the entry/exit save/restore pair 'pushq %rbx'/'popq %rbx'. The 'movl %edi, %edx' is indeed non-optimal, but it's not a 'save' in the sense of save/restore pair generated at function entry/exit or around function calls. It's a copy at function entry of a hard reg argumument to a pseudo reg, generated at expand, which is followed by a copy of the pseudo reg to the same register to set the argument for the function call: ... (insn 2 4 3 2 (set (reg/v:SI 86 [ yD.1755 ]) (reg:SI 5 di [ yD.1755 ])) test.c:9 -1 (nil)) (note 3 2 6 2 NOTE_INSN_FUNCTION_BEG) (insn 6 3 7 2 (set (reg:SI 5 di) (reg/v:SI 86 [ yD.1755 ])) test.c:10 -1 (nil)) ... The second insn is removed in pass_fast_rtl_dce. The reg-alloc choiche for pseudo 86 in the first insn is dx, and the insn remains. I think there could be two ways to address this: 1. Teach a pass after ira, like pass_cprop_hardreg or pass_gcse2 to use the information collected by fuse-calller-save. 2. Teach ira to prefer the dx to di in this case. My guess would be pass_cprop_hardreg.
[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Andi Kleen from comment #9)
Any progress on fixing the test case, so that this can be finally fixed?
I have no idea how to do that without making the testcase test sth different.
We could of course simply turn off SRA for it ...
That said, the difference the optimization may cause might be surprising to
people. That is, that the following may abort()
struct f { char c; int i; };
struct f2 { int i; int j; };
int main()
{
struct f f;
struct f2 f2;
memset(f, 0, sizeof (f));
memcpy(f2, f, sizeof (f));
if (memcmp (f, f2) != 0)
abort ();
return 0;
}
because suddenly the semantics of a memset and a memcpy depend on the
type (_what_ type?!) of the pointed-to type.
Note we can simply circumvent the issue by using a char[n] typed
CONSTRUCTOR / type for the copy. Sth I wanted to followup with
now that the folding happens always on GIMPLE.
It seems to me that SRA may not simply omit padding for aggregate
copies if it cannot prove that the padding is not used. At least
on GIMPLE the semantics of an aggregate assignment is that of a
memmove, not of a field-wise copy. Martin - can you look into this
wrong-code bug? Basically if SRA decides it needs to re-materialize
the object (here before the memcmp call) then it has to re-materialize
padding as well.
[Bug middle-end/63383] internal compiler error: in expand_expr_real_1, at expr.c:9389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63383 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-29 Component|c++ |middle-end Version|unknown |4.8.3 Ever confirmed|0 |1 Known to fail||4.8.3, 4.9.2, 5.0 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 --- Comment #4 from Jiong Wang jiwang at gcc dot gnu.org --- sorry for causing the trouble. the reason might be the flag is an implified register while it's not take into account in current shrink-wrap reg read/write analysis. I will revert my patch temperarily if I couldn't find a proper fix today.
[Bug c++/63386] Release version of CB wont compile Bullet (-o2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Please provide preprocessed source of the file crashing the compiler.
[Bug other/63387] Optimize pairs of isnan() calls into a single isunordered()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-29 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. I hope to get the branch merged (partially) soon.
[Bug other/63395] Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- You can also try -fexcess-precision=standard on Cygwin, -mpc64 might not be implemented there.
[Bug ipa/63403] [5.0 Regression] ICE: in relative_time_benefit at ipa-inline.c:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63403 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |5.0
[Bug tree-optimization/63406] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63406 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I think we have similar dups elsewhere (warning for last unrolled iteration which is never executed). My previous naiive attempts dropped warnings from VRP2 and only warn from VRP1 (but that regresses some cases in the testsuite).
[Bug tree-optimization/63406] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63406 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- I'd say it would still be worthwhile, if it was just a matter of XFAILing a few testcases, because the number of false positives is more important, if the warning is too unreliable, people just will ignore it completely. And people can combine it with -fsanitize=undefined, Fortran -fbounds-check etc.
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 --- Comment #5 from Jiong Wang jiwang at gcc dot gnu.org --- we need to check the following else if (GET_CODE == CLOBBER || GET_CODE (x) == USE || GET_CODE (x) == ASM_INPUT) I will post the fix after pass x86 bootstrap and regression
[Bug ada/34117] enable overflow checks by default (-gnato)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34117 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org --- overflow checks will be enabled by default in the 5.x series.
[Bug c++/63405] [5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-09-29
CC||trippels at gcc dot gnu.org
Known to work||4.8.3, 4.9.2
Version|4.9.1 |5.0
Target Milestone|--- |5.0
Summary|Internal compiler error |[5 regression] ICE in
|when building OpenAxiom on |cp_perform_integral_promoti
|linux/amd64 |ons, at cp/typeck.c:2084
Ever confirmed|0 |1
Known to fail||5.0
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
I can only reproduce this on trunk. 4.9 branch is fine.
markus@x4 tmp % cat sex.ii
struct ListSyntax {
ListSyntax(int, bool);
};
struct A {
template typename... Args
ListSyntax *m_fn1(Args ... args) {
return new ListSyntax{args...};
}
};
struct B {
const ListSyntax *m_fn2(const int , bool);
A lists;
};
const ListSyntax *B::m_fn2(const int elts, bool dot) {
return lists.m_fn1(elts, dot);
}
markus@x4 tmp % /var/tmp/gcc_test/usr/local/bin/g++ -std=c++11 -c sex.ii
sex.ii: In instantiation of ‘ListSyntax* A::m_fn1(Args ...) [with Args =
{const int, bool}]’:
sex.ii:15:31: required from here
sex.ii:7:34: internal compiler error: in cp_perform_integral_promotions, at
cp/typeck.c:2084
return new ListSyntax{args...};
^
0x6b79d1 cp_perform_integral_promotions(tree_node*, int)
../../gcc/gcc/cp/typeck.c:2084
0x57335a convert_for_arg_passing(tree_node*, tree_node*, int)
../../gcc/gcc/cp/call.c:6799
0x577b83 build_over_call
../../gcc/gcc/cp/call.c:7211
0x5835f5 build_new_method_call_1
../../gcc/gcc/cp/call.c:8098
0x5835f5 build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:8168
0x584569 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7712
0x6e564b build_new_1
../../gcc/gcc/cp/init.c:2846
0x6e5d16 build_new(vectree_node*, va_gc, vl_embed**, tree_node*, tree_node*,
vectree_node*, va_gc, vl_embed**, int, int)
../../gcc/gcc/cp/init.c:3086
0x5fc209 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14848
0x5db056 tsubst_expr
../../gcc/gcc/cp/pt.c:14272
0x5dc89c tsubst_expr
../../gcc/gcc/cp/pt.c:13679
0x5dbe60 tsubst_expr
../../gcc/gcc/cp/pt.c:13855
0x5d90fd instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:20227
0x61f727 instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:20343
0x65c9e4 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4367
Please submit a full bug report,
[Bug rtl-optimization/61605] Potential optimization: Keep unclobbered argument registers live across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605
--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 33610
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33610action=edit
proof-of-concept patch
Using this proof-of-concept patch, we manage to get the desired code. The patch
uses the fuse-caller-save information in cprop-hardreg, and runs cprop-hardreg
one more time, after pass_fast_rtl_dce.
Obviously it's not desirable to run cprop-hardreg twice. But the pass has
problems with this code:
...
(insn 2 18 3 2 (set (reg/v:SI 1 dx [orig:86 yD.1749 ] [86])
(reg:SI 5 di [ yD.1749 ])) test.c:9 90 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 5 di [ yD.1749 ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (reg:SI 5 di)
(reg/v:SI 1 dx [orig:86 yD.1749 ] [86])) test.c:10 90 {*movsi_internal}
(nil))
...
The first time cprop-hardreg runs, it manages to propagate the first copy (insn
2) to the second (insn 6):
...
rescanning insn with uid = 6.
insn 6: replaced reg 1 with 5
...
So insn 6 looks like:
...
(insn 6 3 7 2 (set (reg:SI 5 di)
(reg:SI 5 di [orig:86 yD.1749 ] [86])) test.c:10 90 {*movsi_internal}
(nil))
...
That insn is remove by pass_fast_rtl_dce:
...
DCE: Deleting insn 6
deleting insn with uid = 6.
...
And only the second time we run it, we propagate the first copy to the add:
...
insn 9: replaced reg 1 with 5
rescanning insn with uid = 9.
...
which then looks like this:
...
(insn 9 7 15 2 (parallel [
(set (reg:SI 0 ax [orig:87 D.1767 ] [87])
(plus:SI (reg:SI 0 ax [orig:83 D.1767 ] [83])
(reg:SI 5 di [orig:86 yD.1749 ] [86])))
(clobber (reg:CC 17 flags))
]) test.c:10 220 {*addsi_1}
(expr_list:REG_DEAD (reg/v:SI 1 dx [orig:86 yD.1749 ] [86])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
...
That leaves insn 2 dead, which is deleted by dce during sched2:
...
DCE: Deleting insn 2
deleting insn with uid = 2.
...
I'm not sure yet why the cprop-hardreg doesn't work for both cases the first
time, but it's probably that the store to di by insn 6 is registered as a kill
by cprop-hardreg, not taking into account that it's the same value.
[Bug c++/63262] internal compiler error including math.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63262 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #1 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Could you come up with a preprocessed source file showing the bug? Rerun your command (/usr/local/bin/g++ -o gmic gmic.cpp ...) adding the -save-temps option. This should generate a gmic.ii file, which you can attach here. It will allow us to reproduce the issue without having to download and set up the full gmic source code.
[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302 --- Comment #15 from dave.anglin at bell dot net --- On 29-Sep-14, at 2:43 AM, zhenqiang.chen at arm dot com wrote: Please try the attached patch. If it works, I will run all tests and send it for community review. The patch appears to fix the testcase. I've started a full build and check with 4.9 branch. I'll also test it on hpux starting this evening. Thanks very much for investigating. Dave -- John David Anglindave.ang...@bell.net
[Bug c++/19808] miss a warning about uninitialized members in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #22 from Jason Merrill jason at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #21)
I just got hit by this bug. This can obviously be warned in the FE as clang
does:
test.cc:4:11: warning: field 'j' is uninitialized when used here
[-Wuninitialized]
S() : i(j), j(1) {}
^
simply by marking the members somehow as initialized or not, and when using
them realizing that they are still uninitialized.
Marek, Paolo, Jason? Any idea how to do this?
It could be done specifically for uses in mem-initializers by walking the
initializer in perform_mem_init to look for any references to members that
haven't been marked yet.
A more general warning that would cover, say,
X x;
x.x = x.y;
would need support in the existing back end -Wuninitialized code.
[Bug c++/62164] 5.0: ICE: error: Both section and comdat group is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62164 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #2) The sections for COMDAT functions are used to drive code unification. I wonder, do we want to support something like this (and expect that user knows what he is doing and he won't, for example, drop multiple COMDATs into one section) or just reject the attribute? What's wrong with dropping multiple COMDATs into one section? Don't we normally stick lots of COMDATs into .text?
[Bug other/63407] New: xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 Bug ID: 63407 Summary: xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: nheghathivhistha at gmail dot com Gentoo dev-cpp/xsd-3.3.0-r3 compiled (without troubles) with -flto=4 -fuse-linker-plugin aborts itself during processing of net-libs/libkolabxml-1.0.1 xsd files with message: terminate called after throwing an instance of 'Cult::MM::Absent'. When LTO is not used to compile xsdcxx program problem is not present. -rwxr-xr-x 1 root root 3911616 Sep 29 15:00 /usr/bin/xsdcxx -rwxr-xr-x 1 root root 4527928 Sep 29 14:15 /usr/bin/xsdcxx.nolto gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2-alpha20140928/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140928/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.9.2_alpha20140928/work/gcc-4.9-20140928/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2-alpha20140928 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140928/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140928 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140928/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140928/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140928/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140928/python --enable-languages=c,c++,go,objc,obj-c++,fortran,ada --enable-obsolete --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.2_alpha20140928' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --enable-lto --with-cloog --disable-isl-version-check Thread model: posix gcc version 4.9.2-alpha20140928 20140929 (prerelease) [gcc-4_9-branch revision 215679] (Gentoo 4.9.2_alpha20140928) C(XX)FLAGS -flto=4 -fuse-linker-plugin -O2 -g -pipe -march=core2 -mtune=core2 I am going to try version 5 from svn. Should I post disassemble diff output or how to continue please? I not enabled static libraries on my system so upload of binaries itself will be problem.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #11 from boger at us dot ibm.com --- On ppc64 BE, the call to make_code_func_reference returns the function pointer in the .opd and not the actual address of the function. That is what causes the failures with this patch https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00710.html The information in this reply fixes the regressions from this patch on ppc64 BE: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02282.html Essentially the change is to dereference the function pointer in __go_set_defering_fn when building for ppc64 BE as follows: +#if defined(__powerpc64__) _CALL_ELF != 2 +g-defer-__defering_fn = *(void **)defering_fn; +#else +g-defer-__defering_fn = defering_fn; +#endif
[Bug other/63407] xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 --- Comment #1 from David Kredba nheghathivhistha at gmail dot com --- gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.10.0-alpha20140928/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.10.0-alpha20140928/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.10.0_alpha20140928/work/gcc-4.10-20140928/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.10.0-alpha20140928 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.10.0-alpha20140928/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-alpha20140928 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-alpha20140928/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-alpha20140928/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.10.0-alpha20140928/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-alpha20140928/python --enable-languages=c,c++,fortran,ada --enable-obsolete --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.10.0_alpha20140928' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --enable-lto --with-cloog --disable-isl-version-check Thread model: posix gcc version 4.10.0-alpha20140928 20140929 (experimental) [trunk revision 215679] (Gentoo 4.10.0_alpha20140928) fails the same way: terminate called after throwing an instance of 'Cult::MM::Absent' what(): N4Cult2MM6AbsentE /bin/sh: řádek 1: 16792 Neúspěšně ukončen (SIGABRT)/usr/bin/xsdcxx cxx-tree --generate-polymorphic --generate-serialization --namespace-map http://kolab.org=KolabXSD --root-element icalendar --root-element vcards --root-element note --root-element configuration --root-element file --output-dir /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1_build/bindings /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/ical/kolabformat-xcal.xsd /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/ical/iCalendar-params.xsd /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/ical/iCalendar-props.xsd /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/ical/iCalendar-valtypes.xsd /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/kolabformat-xcard.xsd /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/xCard.xsd /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/kolabformat.xsd
[Bug other/63407] xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 --- Comment #2 from David Kredba nheghathivhistha at gmail dot com --- Created attachment 33611 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33611action=edit xsd files with folder structure
[Bug other/63407] xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 --- Comment #3 from David Kredba nheghathivhistha at gmail dot com --- objdump -d produced 24 and 30 MiB files and diff -u is 50 MiB, diff 55 MiB. Even 7z can compress it to uploadable size.
[Bug c++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #3 from Piotr Dziwinski piotrdz at gmail dot com --- (In reply to Jonathan Wakely from comment #2) (In reply to Piotr Dziwinski from comment #1) I would also second the proposal to fix this issue by implementing flat version of std::tuple. Perhaps the existing std::tr1::tuple implementation can be re-used here? GCC's std::tr1:tuple is not a flat implementation, and does not conform to the C++11 requirements, so no, that's not an option. Oh, you're right - somehow I got convinced that std::tr1::tuple was a flat implementation since it compiles so much faster. But this raises a question - why do the two recursive implementations have such different compile times? Perhaps by analyzing the differences between std::tr1::tuple and std::tuple, we can learn something to our advantage?
[Bug c++/19808] miss a warning about uninitialized members in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 --- Comment #23 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jason Merrill from comment #22) It could be done specifically for uses in mem-initializers by walking the initializer in perform_mem_init to look for any references to members that haven't been marked yet. Great! If I find some time in the following weeks, I will give it a try. A more general warning that would cover, say, X x; x.x = x.y; would need support in the existing back end -Wuninitialized code. That is PR2972 and I think fixing this one is a prerequisite for fixing that one. So let's go step by step.
[Bug c++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- tr1::tuple doesn't support perfect-forwarding or move semantics tr1::tuple doesn't support uses-allocator construction tr1::tuple doesn't support 'final' classes tr1::tuple doesn't have correct exception specifications tr1::tuple doesn't prevent implicit conversions that would use explicit constructors tr1::tuple doesn't support tuple concatenation If you can add all those features to the tr1/tuple implementation so that it meets the C++11 requirements and it still compiles faster then I'd be interested in your analysis of the remaining differences. Otherwise I'm going to assume the difference is because the tuple header contains more than twice as many lines of code and several additional features.
[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #20) Perhaps a better alternative is to warn only if the uninitialized member is used in a mem-initializer. Then, when building the constructor call, mark the uninitialized members somehow as uninitialized for the middle-end, and let the middle-end handle the cases in the body of the constructor. The first part would already fix PR19808. The second part will fix this bug with fewer false positives than the proposed patch. And this comment gives some ideas: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808#c9 Richard B, you say that: using error-mark [for marking undefined memory] is just a random (and probably bad) idea. Intuitively this seems more scalable, since one could propagate the undefined value like VRP does. The other alternative Introducing a SSA name default definition for A (even though not of register type), however, seems possible already. no? We do already check for default definitions in virtual operands, tree-ssa-uninit.c says: /* For memory the only cheap thing we can do is see if we have a use of the default def of the virtual operand. So what is missing here?
[Bug target/63408] New: GCC emits incorrect FMA instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408
Bug ID: 63408
Summary: GCC emits incorrect FMA instruction
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: itay at phobotic dot com
When compiling the following function
float f(float a, int b)
{
return a - (((float)b / 0x7fff) * 100);
}
with the following command-line options
arm-none-eabi-gcc -O2 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
-mcpu=cortex-m4
I get this code for f:
fmsrs14, r1@ int
fldss15, .L2
vcvt.f32.s32s14, s14, #31
fmsrs13, r0
vfma.f32s13, s14, s15
fmrsr0, s13
bxlr
.L3:
.align2
.L2:
.word1120403456
The resulting code clearly adds the parenthesized expression to a rather than
subtracting it.
Replacing the minus sign with a plus sign results in the same code.
[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63342 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 --- Created attachment 33612 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33612action=edit gcc5-pr63342.patch Untested fix. When because of r214899 mem_loc_descriptor (correctly) gives up (previously we were generating wrong debug info), we retry by trying to generate debug info from the MEM_EXPR of the MEM, but in this case it contains a TARGET_MEM_REF which we weren't handling at all. Perhaps we should just return NULL for TARGET_MEM_REF though, because we can't do anything for SSA_NAMEs anyway, and I doubt there could be a TARGET_MEM_REF in MEM_EXPR which would not mention SSA_NAMEs. The ultimate reason for not generating debug info is that the TLSLD model base address is precomputed into some register (as it is used multiple times in the function) and ix86_delegitimize_tls_address can't know which hard register holds the base address, so the delegitimization fails. In theory we probably could emit the symbol@DTPOFF into assembly, but as we right now reject all UNSPECs that weren't successfully delegitimized, we reject it anyway.
[Bug rtl-optimization/63340] [5.0 regression] FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63340 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-29 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Sorry for the slow response to this. Been looking for a way out that looks reasonable, think I finally have one. The problem is to do with the union class GR_AND_FR_REGS. Before my patch this was rejected if a register underwant a mode change that is forbidden by FR_REGS, whereas after the patch it is accepted. Testing a patch now, but I expect it will need a couple of revisions.
[Bug debug/63285] [4.9 Regression] -fcompare-debug scheduler related failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63285
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Vlad, do you plan to apply this to 4.9 and 4.8 branches too?
For 4.9, I've bootstrapped/regtested it on {x86_64,i686,armv7hl,aarch64}-linux.
[Bug other/63407] xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 --- Comment #4 from David Kredba nheghathivhistha at gmail dot com --- Created attachment 33613 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33613action=edit all ii files compressed by 7zip tar.bz2 file size was 8.2 MiB.
[Bug other/63407] xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 --- Comment #5 from David Kredba nheghathivhistha at gmail dot com --- Link command to produce a binary, Boost is 1.56: x86_64-pc-linux-gnu-g++ -flto=4 -fuse-linker-plugin -O2 -g -save-temps -march=core2 -mtune=core2 -Wl,-flto -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,--sort-common -Wl,--hash-style=gnu -O2 -g -pipe -march=core2 -mtune=core2 -Wl,-flto -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,--sort-common -Wl,--hash-style=gnu -O2 -g -pipe -march=core2 -mtune=core2 -o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/xsd /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/xsd.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/elements.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/literal-map.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/elements.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/validator.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/name-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/type-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/state-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/generator.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/parser-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/parser-inline.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/parser-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/parser-forward.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/impl-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/impl-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/driver-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/element-validation-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/attribute-validation-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/characters-validation-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/elements.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/validator.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/counter.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/name-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/polymorphism-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/default-value.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/generator.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/tree-forward.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/tree-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/tree-inline.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/tree-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/parser-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/parser-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/stream-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/stream-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/serialization-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/serialization-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/stream-insertion-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/stream-insertion-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/stream-extraction-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/type-map/lexer.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/type-map/parser.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/processing/cardinality/processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/processing/inheritance/processor.o /usr/lib/libxsd-frontend.so /usr/lib/libfrontend-elements.so /usr/lib/libcult.so /usr/lib/libboost_filesystem.so /usr/lib/libxerces-c.so /usr/lib/libboost_regex.so /usr/lib/libboost_system.so
[Bug lto/62061] [5 Regression] FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62061 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- The failure doesn't occur anymore, presumably fixed.
[Bug lto/63409] New: [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 Bug ID: 63409 Summary: [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 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com This can be triggered on Fedora20 with: make check-c++ RUNTESTFLAGS=--target_board=unix/-fno-use-linker-plugin lto.exp=pr63270_?.C spawn -ignore SIGHUP /ssd/uros/gcc-build/gcc/testsuite/g++/../../xg++ -B/ssd/uros/gcc-build/gcc/testsuite/g++/../../ cp_lto_pr63270_0.o cp_lto_pr63270_1.o -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/uros/gcc-svn/trunk/libstdc++-v3/libsupc++ -I/home/uros/gcc-svn/trunk/libstdc++-v3/include/backward -I/home/uros/gcc-svn/trunk/libstdc++-v3/testsuite/util -fmessage-length=0 -flto -O2 -Wno-odr -L/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -fno-use-linker-plugin -o g++-dg-lto-pr63270-01.exe cp_lto_pr63270_0.o: In function `v8::internal::fn1()': pr63270_0.C:(.text+0xa): undefined reference to `v8::internal::B::B(int)' pr63270_0.C:(.text+0x16): undefined reference to `v8::internal::B::B(int)' pr63270_0.C:(.text+0x22): undefined reference to `v8::internal::A::A(int)' pr63270_0.C:(.text+0x27): undefined reference to `v8::internal::G::m_fn1()' collect2: error: ld returned 1 exit status compiler exited with status 1 output is: cp_lto_pr63270_0.o: In function `v8::internal::fn1()': pr63270_0.C:(.text+0xa): undefined reference to `v8::internal::B::B(int)' pr63270_0.C:(.text+0x16): undefined reference to `v8::internal::B::B(int)' pr63270_0.C:(.text+0x22): undefined reference to `v8::internal::A::A(int)' pr63270_0.C:(.text+0x27): undefined reference to `v8::internal::G::m_fn1()' collect2: error: ld returned 1 exit status FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr UNRESOLVED: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o execute -flto -O2 -Wno-odr
[Bug c++/63306] [4.9 Regression] ICE: Segmentation fault in analyze_functions()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63306 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- This got fixed on the trunk with r213425 aka PR61510.
[Bug ipa/63270] [5 Regression] internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63270 --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to marxin from comment #5) Author: marxin Date: Mon Sep 22 09:39:20 2014 New Revision: 215451 URL: https://gcc.gnu.org/viewcvs?rev=215451root=gccview=rev Log: PR lto/63270 - new test * g++.dg/lto/pr63270_0.C: New test. * g++.dg/lto/pr63270_1.C: New test. The testcase fails with -fno-linker-plugin, please see PR 63409.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #2 from frankhb1989 at gmail dot com --- (In reply to Jonathan Wakely from comment #1) Which of macros are defined on mingw-w64? Preprocessing this should tell you #include chrono #ifdef _GLIBCXX_USE_CLOCK_REALTIME #ifdef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL #warning system_clock using syscall(SYS_clock_gettime, CLOCK_REALTIME, tp); #else #warning system_clock using clock_gettime(CLOCK_REALTIME, tp); #endif #elif defined(_GLIBCXX_USE_GETTIMEOFDAY) #warning system_clock using gettimeofday(tv, 0); #else #warning system_clock using std::time(0); #endif #ifdef _GLIBCXX_USE_CLOCK_MONOTONIC #ifdef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL #warning steady_clock using syscall(SYS_clock_gettime, CLOCK_MONOTONIC, tp); #else #warning steady_clock using clock_gettime(CLOCK_MONOTONIC, tp); #endif #else #warning steady_clock using time_point(system_clock::now().time_since_epoch()); #endif I've looked into c++config.h and I'm sure mingw-w64 4.9.1 distro of msys2 uses clock_gettime defined in winpthreads: /* Defined if clock_gettime syscall has monotonic and realtime clock support. */ /* #undef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL */ /* Defined if clock_gettime has monotonic clock support. */ #define _GLIBCXX_USE_CLOCK_MONOTONIC 1 /* Defined if clock_gettime has realtime clock support. */ #define _GLIBCXX_USE_CLOCK_REALTIME 1 /* Defined if gettimeofday is available. */ #define _GLIBCXX_USE_GETTIMEOFDAY 1 Here is the output (g++ -std=c++11): a.cc:7:2: warning: #warning system_clock using clock_gettime(CLOCK_REALTIME, tp); [-Wcpp] #warning system_clock using clock_gettime(CLOCK_REALTIME, tp); ^ a.cc:19:2: warning: #warning steady_clock using clock_gettime(CLOCK_MONOTONIC, tp); [-Wcpp] #warning steady_clock using clock_gettime(CLOCK_MONOTONIC, tp); ^
[Bug middle-end/35545] tracer pass is run too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #22 from Jan Hubicka hubicka at ucw dot cz ---
Doing it at same approximately the same place as loop header copying seems
to
make most sense to me. It benefits from early cleanups and DCE definitly
and
it should enable more fun with the later scalar passes that are almost all
rerun then.
We need to make sure tracer doesn't mess too much with loops then.
Btw, useless tracing may be undone again by tail-merging.
Tracer already does:
/* We have the tendency to duplicate the loop header
of all do { } while loops. Do not do that - it is
not profitable and it might create a loop with multiple
entries or at least rotate the loop. */
bb2-loop_father-header != bb2)
so it won't kill natural loops and peel (I should find time to update the
peeling pass). It also has:
if (bb_seen_p (bb2) || (e-flags (EDGE_DFS_BACK | EDGE_COMPLEX))
|| find_best_successor (bb2) != e)
break;
to not unroll. So i think it is safe for loop optimizer - all it can do
is expanding a loop that has control flow in it reducing its unrollability
later.
Tracer seems to consume only profile information and thus doesn't
rely on any other transforms (well, apart from cleanups which could
affect its cost function). Why not schedule it even earlier?
Like to before pass_build_alias? (the pipeline up to loop transforms
is quite a mess...)
It uses profile information and code size estiamtes. I expect that (especially
for C++ stuff) the early post inline passes will remove a lot of code and thus
improve traceability. This is why I looked for spot after first DCE/DSE.
David, can you please be more specific about how you tested? Was it with
profile feedback? What about code size metrics?
Honza
[Bug rtl-optimization/32629] missing CSE for constant in registers / inefficient memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629 --- Comment #6 from Jan Hubicka hubicka at ucw dot cz --- We could also make $0 a not legitimate constant on x86... (and undo that late with a peephole2) I tried that in 90's. At that time it increased register pressure and was not win... Honza
[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #33 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Mon Sep 29 16:47:31 2014 New Revision: 215685 URL: https://gcc.gnu.org/viewcvs?rev=215685root=gccview=rev Log: 2014-09-29 Charles Baylis charles.bay...@linaro.org Backport from mainline r212303 PR target/49423 * config/arm/arm-protos.h (arm_legitimate_address_p, arm_is_constant_pool_ref): Add prototypes. * config/arm/arm.c (arm_legitimate_address_p): Remove static. (arm_is_constant_pool_ref) New function. * config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6, arm_zero_extendqisi2_v6): Use Uh constraint for memory operand. (arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory operand and remove pool_range and neg_pool_range attributes. (arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove pool_range and neg_pool_range attributes. * config/arm/constraints.md (Uh): New constraint. (Uq): Don't allow constant pool references. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/arm/arm-protos.h branches/gcc-4_9-branch/gcc/config/arm/arm.c branches/gcc-4_9-branch/gcc/config/arm/arm.md branches/gcc-4_9-branch/gcc/config/arm/constraints.md
[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #34 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Mon Sep 29 17:07:47 2014 New Revision: 215686 URL: https://gcc.gnu.org/viewcvs?rev=215686root=gccview=rev Log: 2014-09-29 Charles Baylis charles.bay...@linaro.org Backport from mainline r212303 PR target/49423 * config/arm/arm-protos.h (arm_legitimate_address_p, arm_is_constant_pool_ref): Add prototypes. * config/arm/arm.c (arm_legitimate_address_p): Remove static. (arm_is_constant_pool_ref) New function. * config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6, arm_zero_extendqisi2_v6): Use Uh constraint for memory operand. (arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory operand and remove pool_range and neg_pool_range attributes. (arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove pool_range and neg_pool_range attributes. * config/arm/constraints.md (Uh): New constraint. (Uq): Don't allow constant pool references. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/arm/arm-protos.h branches/gcc-4_8-branch/gcc/config/arm/arm.c branches/gcc-4_8-branch/gcc/config/arm/arm.md branches/gcc-4_8-branch/gcc/config/arm/constraints.md
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- What libstdc++ is doing is sensible, why is the realtime clock so much coarser than the monotonic clock on mingw-w64?
[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #35 from cbaylis at gcc dot gnu.org --- Backports committed to 4.8 and 4.9
[Bug plugins/63410] New: [Regression] pass_instances.def is not installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63410 Bug ID: 63410 Summary: [Regression] pass_instances.def is not installed Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Created attachment 33614 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33614action=edit Trivial patch to add pass-instances.def to installed headers We install the header pass_manager.h, but it can't be included by a plugin, since it includes pass-instances.def, and we don't current install that. /home/david/coding/gcc-python/gcc-svn-4.9/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/plugin/include/pass_manager.h:123:30: fatal error: pass-instances.def: No such file or directory #include pass-instances.def Affects 4.9 branch (e.g. r215685), and, I believe, trunk. Marking as [Regression] since this currently makes it impossible to access the roots of the pass tree (all_passes et al) from a plugin in 4.9+, since they were moved from being globals to being member data of the pass_manager in 4.9, hence we need to include pass_manager.h for that. (My fault, sorry: I was the one who moved these from being globals to being member data. The gcc-python-plugin needs this, and hence this is one thing blocking that plugin from being built against 4.9) Am currently verifying the obvious patch.
[Bug target/63408] GCC emits incorrect FMA instruction on Cortex-M4 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Are you sure 1120403456 does not encode -100.0 ?
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #41 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Mon Sep 29 18:40:57 2014 New Revision: 215690 URL: https://gcc.gnu.org/viewcvs?rev=215690root=gccview=rev Log: PR target/61407 * config/darwin-c.c (version_as_macro): Added extra 0 for OS X 10.10 and above. * config/darwin-driver.c (darwin_find_version_from_kernel): Removed kernel version check to avoid incrementing it after every major OS X release. (darwin_default_min_version): Avoid static memory buffer. * gcc.dg/darwin-minversion-1.c: Fixed formatting * gcc.dg/darwin-minversion-2.c: Fixed formatting * gcc.dg/darwin-minversion-3.c: Fixed formatting * gcc.dg/darwin-minversion-4.c: Added test for OS X 10.10 Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/darwin-minversion-4.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/darwin-c.c branches/gcc-4_9-branch/gcc/config/darwin-driver.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/darwin-minversion-1.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/darwin-minversion-2.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/darwin-minversion-3.c
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #6 from Pat Haugen pthaugen at gcc dot gnu.org --- (In reply to Jiong Wang from comment #5) we need to check the following else if (GET_CODE == CLOBBER || GET_CODE (x) == USE || GET_CODE (x) == ASM_INPUT) I will post the fix after pass x86 bootstrap and regression r215563 also introduced a miscompare on PowerPC for cpu2000 benchmark 254.gap. Applying your patch proposed on the gcc-patches ml for this bug fixes the issue.
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 --- Comment #7 from Jiong Wang jiwang at gcc dot gnu.org --- (In reply to Pat Haugen from comment #6) (In reply to Jiong Wang from comment #5) we need to check the following r215563 also introduced a miscompare on PowerPC for cpu2000 benchmark 254.gap. Applying your patch proposed on the gcc-patches ml for this bug fixes the issue. thanks for reporting this, sorry for causing trouble.
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 --- Comment #8 from Jiong Wang jiwang at gcc dot gnu.org --- (In reply to Pat Haugen from comment #6) (In reply to Jiong Wang from comment #5) we need to check the following else if (GET_CODE == CLOBBER || GET_CODE (x) == USE || GET_CODE (x) == ASM_INPUT) I will post the fix after pass x86 bootstrap and regression r215563 also introduced a miscompare on PowerPC for cpu2000 benchmark 254.gap. Applying your patch proposed on the gcc-patches ml for this bug fixes the issue. and I am curious about whether there are any performance change since this insn sink change.
[Bug c/38716] Undocumented __attribute__((optimize)) behaviour when the attribute specifies no optimisation level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38716 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-29 CC||fxcoudert at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/63408] GCC emits incorrect FMA instruction on Cortex-M4 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408
--- Comment #2 from Itay Perl itay at phobotic dot com ---
Yes, I am certain.
1. Replacing the minus sign with a plus sign results in the same code
(including the constant)
2.
struct.unpack('I', struct.pack('f', 100))[0]
1120403456
[Bug middle-end/35545] tracer pass is run too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #23 from davidxl xinliangli at gmail dot com ---
(In reply to Jan Hubicka from comment #22)
Doing it at same approximately the same place as loop header copying
seems to
make most sense to me. It benefits from early cleanups and DCE definitly
and
it should enable more fun with the later scalar passes that are almost all
rerun then.
We need to make sure tracer doesn't mess too much with loops then.
Btw, useless tracing may be undone again by tail-merging.
Tracer already does:
/* We have the tendency to duplicate the loop header
of all do { } while loops. Do not do that - it is
not profitable and it might create a loop with multiple
entries or at least rotate the loop. */
bb2-loop_father-header != bb2)
so it won't kill natural loops and peel (I should find time to update the
peeling pass). It also has:
if (bb_seen_p (bb2) || (e-flags (EDGE_DFS_BACK | EDGE_COMPLEX))
|| find_best_successor (bb2) != e)
break;
to not unroll. So i think it is safe for loop optimizer - all it can do
is expanding a loop that has control flow in it reducing its unrollability
later.
Tracer seems to consume only profile information and thus doesn't
rely on any other transforms (well, apart from cleanups which could
affect its cost function). Why not schedule it even earlier?
Like to before pass_build_alias? (the pipeline up to loop transforms
is quite a mess...)
It uses profile information and code size estiamtes. I expect that
(especially
for C++ stuff) the early post inline passes will remove a lot of code and
thus
improve traceability. This is why I looked for spot after first DCE/DSE.
David, can you please be more specific about how you tested? Was it with
profile feedback? What about code size metrics?
It is with profile feedback. There is also reduction in code size, though very
tiny change.
David
Honza
[Bug inline-asm/62144] Frame pointer required, but reserved error with -fomit-frame-pointer but only with -m32 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144 --- Comment #2 from Brooks Moses brooks at gcc dot gnu.org --- Ping? Any updates on this?
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #4 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
What libstdc++ is doing is sensible, why is the realtime clock so much
coarser than the monotonic clock on mingw-w64?
It is not always true that the real time clock would have a higher resolution
than monotonic clock. At least I found nothing about resolution guaranteed by
POSIX, in fact, clock resolutions are implementation-defined.
With mingw-w64, the following program shows that the monotonic clock is far
more precise:
#include pthread_time.h
#include iostream
int main()
{
using namespace std;
timespec ts;
if(clock_getres(CLOCK_REALTIME, ts) == 0)
cout CLOCK_REALTIME: ts.tv_sec ',' ts.tv_nsec endl;
if(clock_getres(CLOCK_MONOTONIC, ts) == 0)
cout CLOCK_MONOTONIC: ts.tv_sec ',' ts.tv_nsec endl;
}
The result on my machine:
CLOCK_REALTIME: 0,15625000
CLOCK_MONOTONIC: 0,489
I then found the actual implementation in winpthreads (clock.c):
int clock_gettime(clockid_t clock_id, struct timespec *tp)
{
unsigned __int64 t;
LARGE_INTEGER pf, pc;
union {
unsigned __int64 u64;
FILETIME ft;
} ct, et, kt, ut;
switch(clock_id) {
case CLOCK_REALTIME:
{
GetSystemTimeAsFileTime(ct.ft);
t = ct.u64 - DELTA_EPOCH_IN_100NS;
tp-tv_sec = t / POW10_7;
tp-tv_nsec = ((int) (t % POW10_7)) * 100;
return 0;
}
case CLOCK_MONOTONIC:
{
if (QueryPerformanceFrequency(pf) == 0)
return lc_set_errno(EINVAL);
if (QueryPerformanceCounter(pc) == 0)
return lc_set_errno(EINVAL);
tp-tv_sec = pc.QuadPart / pf.QuadPart;
tp-tv_nsec = (int) (((pc.QuadPart % pf.QuadPart) * POW10_9 +
(pf.QuadPart 1)) / pf.QuadPart);
if (tp-tv_nsec = POW10_9) {
tp-tv_sec ++;
tp-tv_nsec -= POW10_9;
}
return 0;
}
case CLOCK_PROCESS_CPUTIME_ID:
{
if(0 == GetProcessTimes(GetCurrentProcess(), ct.ft, et.ft, kt.ft,
ut.ft))
return lc_set_errno(EINVAL);
t = kt.u64 + ut.u64;
tp-tv_sec = t / POW10_7;
tp-tv_nsec = ((int) (t % POW10_7)) * 100;
return 0;
}
case CLOCK_THREAD_CPUTIME_ID:
{
if(0 == GetThreadTimes(GetCurrentThread(), ct.ft, et.ft, kt.ft,
ut.ft))
return lc_set_errno(EINVAL);
t = kt.u64 + ut.u64;
tp-tv_sec = t / POW10_7;
tp-tv_nsec = ((int) (t % POW10_7)) * 100;
return 0;
}
default:
break;
}
return lc_set_errno(EINVAL);
}
For CLOCK_REALTIME, the Windows API GetSystemTimeAsFileTime is used.
GetSystemTimePreciseAsFileTime is an improved version which provide the
highest possible level of precision (1us). Unfortunately, the latter is only
available since Windows 8/Windows 2012, which is not suited for winpthreads for
compatibility reason IMO. See this MSDN page for details:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh706895(v=vs.85).aspx
For CLOCK_MONOTONIC, QPC(Query Performance Counter) APIs are used. This method
is reasonably portable (among different versions of Windows, since Windows
2000), and Microsoft strongly suggested it when high-resolution time stamps
needed, see
http://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx.
However, QPC is not suited for a system-wide clock.
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- For the record the test gfortran.dg/typebound_operator_3.f03 also failed with -O1 and -m64 (see https://gcc.gnu.org/ml/gcc-regression/2014-09/msg00226.html). This is fixed by the patch at https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02568.html.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #5 from frankhb1989 at gmail dot com --- BTW, what if the clock_gettime call failed? The current implementation does nothing about error handling... (Though for QPC on Windows it should rarely fail for machines within a decade.)
[Bug libstdc++/62313] Data race in debug iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313 --- Comment #12 from François Dumont fdumont at gcc dot gnu.org --- Author: fdumont Date: Mon Sep 29 21:22:17 2014 New Revision: 215693 URL: https://gcc.gnu.org/viewcvs?rev=215693root=gccview=rev Log: 2014-09-29 François Dumont fdum...@gcc.gnu.org PR libstdc++/62313 * include/debug/safe_base.h (_Safe_iterator_base(const _Safe_iterator_base)): Delete declaration. (_Safe_iterator_base operator=(const _Safe_iterator_base)): Likewise. * include/debug/safe_iterator.h (_Safe_iterator): Move normal iterator before _Safe_iterator_base in memory. Lock before modifying the iterator in numerous places. * include/debug/safe_local_iterator.h (_Safe_local_iterator_base(const _Safe_local_iterator_base)): Delete declaration. (_Safe_local_iterator_base operator=(const _Safe_local_iterator_base)): Likewise. * include/debug/safe_unordered_base.h (_Safe_local_iterator): Move normal iterator before _Safe_iterator_base in memory. Lock before modifying the iterator in numerous places. * include/debug/forward_list (_Safe_forward_list::_M_swap_aux): Adapt. * include/debug/safe_sequence.tcc (_Safe_sequence::_M_transfer_from_if): Adapt. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/debug/forward_list trunk/libstdc++-v3/include/debug/safe_base.h trunk/libstdc++-v3/include/debug/safe_iterator.h trunk/libstdc++-v3/include/debug/safe_local_iterator.h trunk/libstdc++-v3/include/debug/safe_sequence.tcc trunk/libstdc++-v3/include/debug/safe_unordered_base.h
[Bug libstdc++/62313] Data race in debug iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313 François Dumont fdumont at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #13 from François Dumont fdumont at gcc dot gnu.org --- A number of additional locks have been added to make sure we do not modify an iterator while the list of iterators might be checked through another thread.
[Bug tree-optimization/63411] New: [4.9/5 regression] ivopt produces wrong struct offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63411
Bug ID: 63411
Summary: [4.9/5 regression] ivopt produces wrong struct offset
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: critical
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Host: i686-linux-gnu
Target: sh*-*-*
Compiling the following as C or C++:
typedef struct
{
unsigned char sprindex;
unsigned char y;
unsigned char index;
unsigned char attr;
unsigned char x;
unsigned short pattern;
} oam;
extern oam OAM3[8];
int test2 (unsigned c, int r)
{
for (unsigned i = 0; i c; ++i)
{
oam* s = (OAM3[i]);
if (s-attr 0x40)
r += s-pattern;
}
return r;
}
on SH (big or little endian, any CPU type) with -O2 results in the following
wrong code:
_test2:
tst r4,r4
bt .L12
mov.l .L14,r1
.align 2
.L4:
mov.b @r1,r0
tst #64,r0
bt/s.L3
mov r1,r2
add #3,r2 wrong struct offset '3'
mov.w @r2,r2 should be '3*2', i.e. '6'.
extu.w r2,r2
add r2,r5
.L3:
dt r4
bf/s.L4
add #8,r1
.L12:
rts
mov r5,r0
.L15:
.align 2
.L14:
.long _OAM3+3
.size _test2, .-_test2
.ident GCC: (GNU) 4.9.2 20140929 (prerelease)
Disabling ivopt with '-fno-ivopts' produces correct code:
_test2:
tst r4,r4
bt .L12
mov #0,r2
mov.l .L14,r3
.align 2
.L4:
mov r2,r1
shll2 r1
add r1,r1
add r3,r1
mov.b @(3,r1),r0
tst #64,r0
bt .L3
mov.w @(6,r1),r0 correct struct offset '6'
extu.w r0,r1
add r1,r5
.L3:
dt r4
bf/s.L4
add #1,r2
.L12:
rts
mov r5,r0
.L15:
.align 2
.L14:
.long _OAM3
.size _test2, .-_test2
.ident GCC: (GNU) 4.9.2 20140929 (prerelease)
I haven't checked whether this happens on other targets, but I guess this is
not SH specific.
This happens on the current 4.9 branch and trunk. 4.8 branch is not affected.
[Bug tree-optimization/63411] [4.9/5 regression] ivopt produces wrong struct offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63411 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||amker.cheng at gmail dot com, ||ebotcazou at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- CC'ing some people who have recently worked on tree-ssa-loop-ivopts.c according to the 4.9 changelog.
[Bug c++/53025] [C++11] noexcept operator depends on copy-elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-09-29
Ever confirmed|0 |1
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com ---
In case we need something more for templates, eg:
templatetypename T
struct A {
A() noexcept {}
A(const A) noexcept(false) {}
};
templatetypename T
void a(AT) noexcept {}
templatetypename T
void f()
{
static_assert(!noexcept(a(AT{})), ); // Error
}
void g()
{
fint();
}
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #46 from Oleg Endo olegendo at gcc dot gnu.org --- newlib 1.2.0 now builds without errors here.
