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?
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_
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'v
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.
>
>
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)
>>> {
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
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
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 i
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 --gi
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
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);
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)
12 matches
Mail list logo
