Snapshot gcc-8-20181123 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/8-20181123/
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
GCC currently accepts the declaration of f0 below but ignores
the attribute. On aarch64 (and I presume on other targets with
a default function alignment greater than 1), GCC rejects f1
with an error, even though it accepts -falign-functions=1
without as much as a warning.
Clang, on the other ha
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.
On Mon, Nov 19, 2018 at 11:33 PM Franz Sirl <
franz.sirl-ker...@lauterbach.com> wrote:
> Am 2018-11-19 um 15:36 schrieb Lokesh Jangh
Hi Sirl,
As you mention in Bugzilla (comment 13),
aix_return( return in memory)
svr4_return(in registers)
what is the semantics of *svr4gnu* w.r.t return .
On Mon, Nov 19, 2018 at 11:33 PM Franz Sirl <
franz.sirl-ker...@lauterbach.com> wrote:
> Am 2018-11-19 um 15:36 schrieb Lokesh Janghel:
>
Hi Arseny,
On Fri, Nov 23, 2018 at 06:15:47PM +0700, Arseny Solokha wrote:
> I've found recently that rs6000 and powerpcspe backends can easily trip over
> various gcc_unreachable()'s and gcc_assert()'s in their respective copies of
> print_operand() when provided with some invalid assembly (i.e.
Hi,
I've found recently that rs6000 and powerpcspe backends can easily trip over
various gcc_unreachable()'s and gcc_assert()'s in their respective copies of
print_operand() when provided with some invalid assembly (i.e. assembly written
for other architectures). For example, when feeding
gcc/te
