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::Factory::make(const Args& ...) [with Args =
> {std::vector 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 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" 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" > 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 : > >>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 wrote: > On Mon, Sep 29, 2014 at 12:56:06PM +0200, Thomas Schwinge wrote: > > On Tue, 23 Sep 2014 11:02:30 +, "Zamyatin, Igor" > > 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. > > : 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
). (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 To: George R Goffe Cc: "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. > > : 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 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
