Re: PROPOSAL: Extend inline asm syntax with size spec
On November 29, 2018 1:25:02 PM GMT+01:00, Segher Boessenkool wrote: >This will only be fixed from GCC 9 on, if the compiler adopts it. The >kernel wants to support ancient GCC, so it will need to have a >workaround >for older GCC versions anyway. What about backporting it, like Richard says? -- Sent from a small device: formatting sux and brevity is inevitable.
Re: Help Out with Gcc
On Fri, 30 Nov 2018 at 05:59, nick wrote: > > Greetings All, > > I assume you get lots of these but I was wondering what's the > areas where gcc needs help the most these days that are good > for a new developer to gcc. There's a relevant section on the wiki, see https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development The https://gcc.gnu.org/wiki/LibstdcxxTodo page also includes some easy hacks suitable for new contributors. > The only other question I have > is the gcc internal manual here up to date for gcc 8 or > not? > https://gcc.gnu.org/onlinedocs/gccint/index.html#SEC_Contents Those docs cover the development trunk, and were last updated *after* gcc-8 branched, but are still relevant for gcc-8.
Re: Bug 84762 - GCC for PowerPC32 violates the SysV ABI spec for small struct returns
Am 2018-11-26 um 06:13 schrieb Lokesh Janghel: Hi Sirl, As you mentioned in Bugzilla (comment 13), aix_return ( return in memory) svr4_return (return in register) what is the semantics of svr4gnu w.r.t. return. Hi Lokesh, I don't quite understand what you are asking me here? In comment 13 I've talked about the option naming, which I was unsure about. In the end (before I was stuffed with other work again) I was settling for -msvr4-struct-return=standard and -msvr4-struct-return=gnu (which would be the default and is equal the current behaviour), leaving -maix-struct-return unchanged. What else do you want to know? Franz
Re: Help Out with Gcc
On Fri, 2018-11-30 at 10:04 +, Jonathan Wakely wrote: > On Fri, 30 Nov 2018 at 05:59, nick wrote: > > > > Greetings All, > > > > I assume you get lots of these but I was wondering what's the > > areas where gcc needs help the most these days that are good > > for a new developer to gcc. > > There's a relevant section on the wiki, see > https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development > > The https://gcc.gnu.org/wiki/LibstdcxxTodo page also includes some > easy hacks suitable for new contributors. > > > The only other question I have > > is the gcc internal manual here up to date for gcc 8 or > > not? > > https://gcc.gnu.org/onlinedocs/gccint/index.html#SEC_Contents > > Those docs cover the development trunk, and were last updated *after* > gcc-8 branched, but are still relevant for gcc-8. FWIW I've put together my own guide for new GCC developers, based on my experiences: https://dmalcolm.fedorapeople.org/gcc/newbies-guide/index.html I hope to merge this into the website somehow in the next few months. Hope this is helpful Dave
Re: Gimpel lowering question.
On 11/30/18 12:39 AM, Richard Biener wrote:
> On Wed, Nov 28, 2018 at 6:10 PM Jeff Law wrote:
>>
>> On 11/28/18 10:00 AM, Michael Eager wrote:
>>> I have a small test case which generates poor quality code on my target.
>>> Here is the original:
>>>
>>> if (cond1 == 2048 || cond2 == 8)
>>> {
>>> x = x + y;
>>> }
>>> return x;
>>>
>>> This ends up generating a series of instructions to compute a flag with
>>> the result of the condition followed by a single compare with zero and
>>> a jump. Better code would be two compares and two jumps.
>>>
>>> The gimple is
>>>
>>> _1 = cond1 == 2048;
>>> _2 = cond2 == 8;
>>> _3 = _1 | _2;
>>> if (_3 != 0) goto ; else goto ;
>>> ...
>>>
>>> so this poor code sequence is essentially a correct translation.
>>>
>>> On MIPS, for the same test case, the gimple is different:
>>>
>>> if (cond1 == 2048) goto ; else goto ;
>>> :
>>> if (cond2 == 8) goto ; else goto ;
>>> :
>>> ...
>>>
>>> which generates the better code sequence.
>>>
>>> Can someone give me a pointer where to find where the lowering
>>> pass decides to break up a condition into multiple tests? Is
>>> there a target configuration option which I have overlooked or
>>> maybe set incorrectly?
>> BRANCH_COST, which comes into play during generation of the initial
>> trees
>
> Sth I don't like very much... maybe we can revisit removing
> the few cases in fold-const.c (thus GENERIC folding) and rely
> on later GIMPLE passes instead plus on RTL expansion to
> do the reverse transform.
>
> Not for GCC 9 of course.
Agreed, 100%. That was supposed to be where Kai's work was headed, but
we never seemed to make significant headway. Getting BRANCH_COST out
of the tree generation/folding would be a good thing at many levels.
There'll be fallout, of course.
jeff
Re: Gimpel lowering question.
On Fri, Nov 30, 2018 at 09:08:34AM -0700, Jeff Law wrote:
> > Sth I don't like very much... maybe we can revisit removing
> > the few cases in fold-const.c (thus GENERIC folding) and rely
> > on later GIMPLE passes instead plus on RTL expansion to
> > do the reverse transform.
> >
> > Not for GCC 9 of course.
> Agreed, 100%. That was supposed to be where Kai's work was headed, but
> we never seemed to make significant headway. Getting BRANCH_COST out
> of the tree generation/folding would be a good thing at many levels.
>
> There'll be fallout, of course.
Note, for the GCC 9 timeframe, for PR85368 I wrote today
--param logical-op-non-short-circuit={0,1} support that allows
to override LOGICAL_OP_NON_SHORT_CIRCUIT, because clearly it is impossible
to handle it in testcases otherwise, just -mbranch-cost= and the defaults
aren't good enough, as some targets override LOGICAL_OP_NON_SHORT_CIRCUIT
and figuring out all the details is too hard in tcl.
I prefer a param to make it clear that it won't last too long if we
implement the above for GCC 10 or 11.
Jakub
Re: Gimpel lowering question.
On 11/30/18 9:14 AM, Jakub Jelinek wrote:
> On Fri, Nov 30, 2018 at 09:08:34AM -0700, Jeff Law wrote:
>>> Sth I don't like very much... maybe we can revisit removing
>>> the few cases in fold-const.c (thus GENERIC folding) and rely
>>> on later GIMPLE passes instead plus on RTL expansion to
>>> do the reverse transform.
>>>
>>> Not for GCC 9 of course.
>> Agreed, 100%. That was supposed to be where Kai's work was headed, but
>> we never seemed to make significant headway. Getting BRANCH_COST out
>> of the tree generation/folding would be a good thing at many levels.
>>
>> There'll be fallout, of course.
>
> Note, for the GCC 9 timeframe, for PR85368 I wrote today
> --param logical-op-non-short-circuit={0,1} support that allows
> to override LOGICAL_OP_NON_SHORT_CIRCUIT, because clearly it is impossible
> to handle it in testcases otherwise, just -mbranch-cost= and the defaults
> aren't good enough, as some targets override LOGICAL_OP_NON_SHORT_CIRCUIT
> and figuring out all the details is too hard in tcl.
Yea, that sounds quite reasonable. The target conditions in those tests
are just insane and obviously unmaintainable. A param to control
behavior seems like a good idea.
The param also makes it easier to experiment with this stuff as we try
to kill the BRANCH_COST and LOGICAL_OP_NON_SHORT_CIRCUIT bits early.
jeff
Re: Gimpel lowering question.
On 11/29/18 10:28, Michael Eager wrote:
On 11/28/18 14:37, Andrew Pinski wrote:
On Wed, Nov 28, 2018 at 9:47 AM Michael Eager wrote:
On 11/28/18 09:10, Jeff Law wrote:
On 11/28/18 10:00 AM, Michael Eager wrote:
I have a small test case which generates poor quality code on my
target.
Here is the original:
if (cond1 == 2048 || cond2 == 8)
{
x = x + y;
}
return x;
This ends up generating a series of instructions to compute a flag
with
the result of the condition followed by a single compare with zero and
a jump. Better code would be two compares and two jumps.
The gimple is
_1 = cond1 == 2048;
_2 = cond2 == 8;
_3 = _1 | _2;
if (_3 != 0) goto ; else goto ;
...
so this poor code sequence is essentially a correct translation.
On MIPS, for the same test case, the gimple is different:
if (cond1 == 2048) goto ; else goto ;
:
if (cond2 == 8) goto ; else goto ;
:
...
which generates the better code sequence.
Can someone give me a pointer where to find where the lowering
pass decides to break up a condition into multiple tests? Is
there a target configuration option which I have overlooked or
maybe set incorrectly?
BRANCH_COST, which comes into play during generation of the initial
trees as well in passes which try to optimize branchy code into
straighter code.
Thanks. I did look at BRANCH_COST, and played with the values, but it
didn't seem to have any affect. I'll take a closer look.
Look at LOGICAL_OP_NON_SHORT_CIRCUIT . By defualt, it is defined as:
(BRANCH_COST (optimize_function_for_speed_p (cfun), \
false) >= 2)
But MIPS defines it as 0.
Changing LOGICAL_OP_NON_SHORT_CIRCUIT to 0 will disable this
optimization.
LOGICAL_OP_NON_SHORT_CIRCUIT controls both places where (cond1 == 2048
|| cond2 == 8) would remove the branch.
NOTE I think MIPS defines LOGICAL_OP_NON_SHORT_CIRCUIT incorrectly but
that is a different story.
Thanks,
Andrew Pinski
I set BRANCH_COST to 1 for both predicted and non-predicted branches.
This generates the shorter sequence with a compare, but I'm concerned
that it will adversely affect code generation elsewhere. Branches are
higher cost than simple instructions.
Looking at the code generated with BRANCH_COST > 1, it doesn't do what
I indicated above. This did not reduce the number of branches.
In both cases there are two branches in this short test case. When
BRANCH_COST > 1, there are three instructions to do a compare vs one
when BRANCH_COST = 1. I'm at a loss to see where there is any benefit.
I'll take a look at the LOGICAL_OP_NON_SHORT_CIRCUIT settings and see
if this makes a difference.
Setting LOGICAL_OP_NON_SHORT_CIRCUIT to zero generates the better code
sequence. Thanks for the pointer.
I stepped through the code at the two places where
LOGICAL_OP_NON_SHORT_CIRCUIT is tested, with it set both to 0 and 1, and
it is not clear what the code is trying to do. Or what this parameter
is really supposed to mean. I'll have to go back and look again.
Setting LOGICAL_OP_NON_SHORT_CIRCUIT to 0 or 1 does not change the
number of branches. Why this would depend on BRANCH_COST is not clear,
and especially why it would depend on the costs of branches which are
predicted to fail makes no sense to me.
Is there a use case which would help this make some sense?
--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
[PATCH] Add missing noexpect causes in tuple for move functions
This adds the remainging noexcept causes required for this cause
to meet the spec as dicussed last year and documented here:
http://cplusplus.github.io/LWG/lwg-active.html#2899.
Signed-off-by: Nicholas Krause
---
libstdc++-v3/include/std/tuple | 4
1 file changed, 4 insertions(+)
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 56b97c25eed..d17512a1b7e 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -214,6 +214,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
enable_if::type>
explicit
constexpr _Tuple_impl(_UHead&& __head, _UTail&&... __tail)
+noexcept(__and_,
+ is_nothrow_move_constructible<_Inherited>>::value)
: _Inherited(std::forward<_UTail>(__tail)...),
_Base(std::forward<_UHead>(__head)) { }
@@ -237,6 +239,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
constexpr _Tuple_impl(_Tuple_impl<_Idx, _UHead, _UTails...>&& __in)
+noexcept(__and_,
+ is_nothrow_move_constructible<_Inherited>>::value)
: _Inherited(std::move
(_Tuple_impl<_Idx, _UHead, _UTails...>::_M_tail(__in))),
_Base(std::forward<_UHead>
--
2.17.1
gcc-8-20181130 is now available
Snapshot gcc-8-20181130 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20181130/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 266693 You'll find: gcc-8-20181130.tar.xzComplete GCC SHA256=8d1c72c1416e3ac931a5ec6627d6564aced39d84ec0e58a84e962f0aea293aff SHA1=e32ec7d8e273b4ffd365e8e1a4a35bfbbf0ffd7f Diffs from 8-20181123 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: question about attribute aligned for functions
On 11/29/18 8:34 AM, Martin Sebor wrote: > > GCC does disallow decreasing the function alignment -- but only > for functions that were already declared with a more restrictive > one. Like this: > > __attribute__ ((aligned (4))) void f (void); > > __attribute__ ((aligned (2))) void f (void); > > warning: ignoring attribute ‘aligned (2)’ because it conflicts with > attribute ‘aligned (4)’ > > It doesn't warn about going from the default (say 16 on i86) > to something smaller, and it honors that lower alignment up > to the supported minimum. It's probably worth clarifying in > the manual. Let me propose something. Please do. Thanks. > Whether or not to warn in general if the alignment attribute is smaller than the default may be subject to debate. I guess it depends on the general intent that we'd find in real world codes. >>> >>> I would expect real world code to care about achieving at least >>> the specified alignment. >> If we only allow increasing, yes. At which point what do the values 0 >> or 1 realistically mean? > > If we only allowed increasing then both 0 and 1 would be > meaningless. > >> >> If we allow decreasing, then the user may be asking for a smaller >> alignment to achieve better code density. > > Yes, that's definitely possible (I just opened pr88231 - > aligned functions laid down inefficiently, as I noticed this > doesn't work as well as it could and arguably should). But they > can't get it if the target doesn't support it. In which case I > think adding a new warning to point it out might be useful. At > the same time, users wanting maximum density across all their > targets shouldn't have to worry about what the minimum alignment > is on each of them and hardwire different constants into > the attribute. I think they should be able to specify 1 and > have GCC round it up as necessary, with no warning. So I'd make > the new warning off by default. That seems like a better UI than forcing the user to know what their target actually supports. So, yea I think I'm in agreement with where you're going. jeff
Working on GCC Tuple Issues
Greetings All,
Seems the code has changed and may actually require a better fix than just the
functions
mentioned on this page, http://cplusplus.github.io/LWG/lwg-active.html#2899.
I am wondering if these are the functions or one of them firstly:
constexpr tuple(tuple<_UElements...>&& __in)
_Inherited(static_cast<_Tuple_impl<0, _UElements...>&&>(__in)) { }
and why not just do all rvalue functions that are like this for
all operators? Seems the spec is only mentioned a few functions
but noexpect on move is normally a good idea unless the C++
standard or the C++ library needs it for other template parsing
reasons.
Regards,
Nick
