On December 19, 2016 11:25:49 PM GMT+01:00, Jeff Law wrote:
>On 12/14/2016 03:44 AM, Richard Biener wrote:
>>
>> The following implements Jasons suggestion of using a langhook to
>> return the size of an aggregate without tail padding that might
>> be re-used when it is inherited from.
>>
>> Using
This patch adds tests gcc.dg/memcmp-1.c and gcc.dg/strncmp-1.c that
test builtin expansion of memcmp and strncmp for short strings and also
varying alignment of one arg. The strncmp test checks that things work
when one of the strings crosses a 4k boundary as well.
I've included interested parties
On 12/19/16 11:33 AM, Janne Blomqvist wrote:
On Mon, Dec 19, 2016 at 6:43 PM, Bob Deen wrote:
Hi all...
I never saw any followup on this...?
It's one thing to break the ABI between the compiler and the gfortran
library; those can generally be expected to be in sync. It's another to
break the
On 11/16/2016 09:32 AM, Richard Sandiford wrote:
Later patches will make machmode.h rely on wide-int.h and the
new poly-int.h, so it needs to appear later in the coretypes.h
include list.
Previously machmode.h included insn-modes.h, which as well as
the main mode enum contains configuration info
On 12/16/2016 07:41 AM, Aldy Hernandez wrote:
BTW, I don't understand why we don't have auto_bitmap's, as we already
have auto_sbitmap's. I've implemented the former based on
auto_sbitmap's code we already have.
Trevor poked at it a bit. bitmaps are a bit more complex than sbitmaps
in terms o
On Mon, 2016-12-19 at 15:10 -0700, Jeff Law wrote:
> On 12/08/2016 01:39 PM, David Malcolm wrote:
> > Testing the patch kit on i686 showed numerous failures of this
> > assertion in set_mem_attributes_minus_bitpos in emit-rtl.c:
> >
> > 1821gcc_assert (!defattrs->offset_known_p);
> >
>
On Mon, Dec 19, 2016 at 11:29:45PM +0100, FX wrote:
> > Thinking out loud here. I wonder, however, if we want
> > to future proof the library against changes to the
> > options passed by having a few spare unused entried
> > available. This of course only helps if a new option
> > needs to be ad
On 12/14/2016 09:41 AM, Martin Sebor wrote:
- if (i < 0)
+ if (HOST_WIDE_INT_MIN == i)
nit. I think most folks would probably prefer this as
if (i == HOST_WIDE_INT_MIN).
HOST_WIDE_INT_MIN is a constant and when we can write an expression in
either order variable OP const is the pre
> Thinking out loud here. I wonder, however, if we want
> to future proof the library against changes to the
> options passed by having a few spare unused entried
> available. This of course only helps if a new option
> needs to be added. It does nothing for removal.
That’s actually the way gf
On 12/14/2016 03:44 AM, Richard Biener wrote:
The following implements Jasons suggestion of using a langhook to
return the size of an aggregate without tail padding that might
be re-used when it is inherited from.
Using this langhook we can fix the size of the representative for the
bitfield pr
On 12/12/2016 05:06 PM, Martin Sebor wrote:
+/* The lower bound when precision isn't specified is 8 bytes
+ ("1.23456" since precision is taken to be 6). When precision
+ is zero, the lower bound is 1 byte (e.g., "1"). Otherwise,
+ when precision is greater than zero, then
> -Original Message-
> From: Toma Tabacu [mailto:toma.tab...@imgtec.com]
> Sent: Thursday, December 15, 2016 9:51 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Matthew Fortune ; Moore,
> Catherine
> Subject: [PATCH, testsuite] MIPS: Relax instruction order check in msa-
> builtins.c.
>
> Hi,
>
On Mon, Dec 19, 2016 at 10:47:09PM +0100, FX wrote:
> For ABI compatibility, we kept some unused elements in the array argument to
> _gfortran_set_options (options that we have removed). With the current ABI
> breakage, we might as well remove those.
>
> Bootstrapped and regtested on x86_64-appl
On 12/08/2016 01:39 PM, David Malcolm wrote:
Testing the patch kit on i686 showed numerous failures of this
assertion in set_mem_attributes_minus_bitpos in emit-rtl.c:
1821gcc_assert (!defattrs->offset_known_p);
when expanding "main" in the rtl.exp test files, after parsing
an __RTL-t
On 12/19/2016 01:09 PM, Martin Sebor wrote:
By moving the warning earlier, we'll still warn for the most cases, but
won't warn in the more convoluted cases. We can perhaps work on it
further
in GCC 8. If we keep it as is, I think most users will just
-Wno-nonnull
as soon as they run into some w
For ABI compatibility, we kept some unused elements in the array argument to
_gfortran_set_options (options that we have removed). With the current ABI
breakage, we might as well remove those.
Bootstrapped and regtested on x86_64-apple-darwin16.3.0
OK to commit?
FX
set_options.ChangeLog
Desc
On 12/19/2016 08:44 AM, James Cowgill wrote:
Hi,
This patch fixes PR 65618 where ADA cannot be bootstrapped natively on
mips due to a bootstrap comparison failure. The PR is currently in the
target component, but should be in the rtl-optimization component.
The underlying bug is in gcc/emit-rtl
On Mon, Dec 19, 2016 at 01:24:34PM -0700, Jeff Law wrote:
> > PR middle-end/78519 - missing warning for sprintf %s with null pointer
> >
> > gcc/ChangeLog:
> >
> > PR middle-end/78519
> > * gimple-ssa-sprintf.c (format_string): Handle null pointers.
> > (format_directive): Diagnose nu
The patch updates the example dump in the comment for
print_rtx_function to reflect various changes:
- r241593: addition of insn UIDs
- r241908: removal of trailing "(nil)" and other default values
- r242023: addition of "param" directives
- r243798: change of format of regnos in non-virtual pseudo
On 12/15/2016 03:14 AM, Tamar Christina wrote:
On a high level, presumably there's no real value in keeping the old
code to "fold" fpclassify. By exposing those operations as integer
logicals for the fast path, if the FP value becomes a constant during
the optimization pipeline we'll see the r
Hello!
This patch just adds missing popcounthi2 insn and splitter to enable
POPCNTW generation from _builtin_popcount builtin with zero-extended
unsigned short argument.
2016-12-19 Uros Bizjak
* config/i386/i386.md (*popcounthi2_1): New insn_and_split pattern.
testsuite/ChangeLog:
2016-
This is the final part of the RTL "frontend" patch kit, implemented as
a special case for functions marked with __RTL within the C frontend.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu on top
of the rest of the RTL frontend patch kit.
OK for trunk?
Changed in v7:
- remove i?86-*-* f
On 12/14/2016 09:21 PM, Martin Sebor wrote:
I suppose setting a range seemed better than giving up. Then again,
since with this patch GCC will warn on null %s pointers there may
not be much point in trying to see if there's also some other
problem after that, except perhaps in code that delibera
On 12/16/2016 05:50 AM, Richard Biener wrote:
+ gimple *defstmt = SSA_NAME_DEF_STMT (vuse);
+ tree src2 = NULL_TREE, len2 = NULL_TREE;
+ HOST_WIDE_INT offset, offset2;
+ tree val = integer_zero_node;
+ if (gimple_store_p (defstmt)
+ && gimple_assign_single_p (defstmt)
+ && TREE_CO
I've checked in this patch to do some initial cleanup of bit-rotten
content in the CPP manual. I've rewritten some passages that made it
sound like C99 support is a brand-new thing, and removed text that
describes how the preprocessor used to work in ancient versions of GCC.
This is all routi
By moving the warning earlier, we'll still warn for the most cases, but
won't warn in the more convoluted cases. We can perhaps work on it
further
in GCC 8. If we keep it as is, I think most users will just -Wno-nonnull
as soon as they run into some warning that will be hard to figure out
what
i
On 12/16/2016 10:10 AM, Martin Sebor wrote:
On 12/16/2016 09:46 AM, Jakub Jelinek wrote:
On Fri, Dec 16, 2016 at 09:36:25AM -0700, Martin Sebor wrote:
It does for me with an allmodconf. At -O2 I get three warnings, and at
-O3 I get two additional warnings. Now these additional ones happen way
t
On Mon, Dec 19, 2016 at 12:50:00PM -0700, Jeff Law wrote:
> > Unrelated to where the warning is issued, it might be a good idea to use
> > %K to emit it with inlining stack, otherwise figuring out why it warns
> > will be harder than needed.
> I would think that would apply to any warning triggered
On 12/19/2016 12:12 PM, Jakub Jelinek wrote:
On Mon, Dec 19, 2016 at 07:58:54PM +0100, Jakub Jelinek wrote:
On Mon, Dec 19, 2016 at 11:54:06AM -0700, Jeff Law wrote:
I don't claim it can't be improved but it seems pretty good as
it is already. Among the 6 instances it's found in GCC three
look
On 12/19/2016 11:56 AM, Jakub Jelinek wrote:
On Mon, Dec 19, 2016 at 11:46:24AM -0700, Jeff Law wrote:
But I don't see that as inherently blocking this patch. It's pointing out a
bad API interface. It's no different than when I added teh NULL pointer
dereference warnings a while ago -- we had
On Mon, Dec 19, 2016 at 6:43 PM, Bob Deen wrote:
> Hi all...
>
> I never saw any followup on this...?
>
> It's one thing to break the ABI between the compiler and the gfortran
> library; those can generally be expected to be in sync. It's another to
> break the ABI between two *languages*, when t
On Mon, Dec 19, 2016 at 07:58:54PM +0100, Jakub Jelinek wrote:
> On Mon, Dec 19, 2016 at 11:54:06AM -0700, Jeff Law wrote:
> > > > I don't claim it can't be improved but it seems pretty good as
> > > > it is already. Among the 6 instances it's found in GCC three
> > > > look like real bugs.
> > >
On Mon, Dec 19, 2016 at 11:54:06AM -0700, Jeff Law wrote:
> > > I don't claim it can't be improved but it seems pretty good as
> > > it is already. Among the 6 instances it's found in GCC three
> > > look like real bugs.
> >
> > None look like real bugs to me.
> But is the warning rate so high th
On Mon, Dec 19, 2016 at 11:46:24AM -0700, Jeff Law wrote:
> But I don't see that as inherently blocking this patch. It's pointing out a
> bad API interface. It's no different than when I added teh NULL pointer
> dereference warnings a while ago -- we had the exact same kinds of problems.
>
> The
On 12/16/2016 09:46 AM, Jakub Jelinek wrote:
On Fri, Dec 16, 2016 at 09:36:25AM -0700, Martin Sebor wrote:
It does for me with an allmodconf. At -O2 I get three warnings, and at
-O3 I get two additional warnings. Now these additional ones happen way
too deep into the pipeline to be reliable. (Fo
The message passed to error_at should not end in \n; the diagnostics
machinery deals with inserting the newline.
--
Joseph S. Myers
jos...@codesourcery.com
On 12/19/2016 11:30 AM, Jakub Jelinek wrote:
On Mon, Dec 19, 2016 at 10:52:13AM -0700, Jeff Law wrote:
No, it highlights that the warning is done in a wrong place where it suffers
from too many false positives.
I don't inherently see this as generating "too many false positives". And as
Martin
On 12/19/2016 11:00 AM, Martin Sebor wrote:
On 12/19/2016 10:31 AM, Jeff Law wrote:
On 12/17/2016 02:55 PM, Martin Sebor wrote:
On 12/17/2016 01:01 PM, Markus Trippelsdorf wrote:
I agree that these warnings should probably not be issued, though
it's interesting to see where they come from. Th
On Mon, Dec 19, 2016 at 10:52:13AM -0700, Jeff Law wrote:
> > No, it highlights that the warning is done in a wrong place where it suffers
> > from too many false positives.
> I don't inherently see this as generating "too many false positives". And as
> Martin says, the warning works with precisel
On Mon, Dec 19, 2016 at 08:43:01AM -0800, Bob Deen wrote:
>
> It's one thing to break the ABI between the compiler and the gfortran
> library; those can generally be expected to be in sync. It's another to
> break the ABI between two *languages*, when there might be no such
> expectation (espe
On Mon, Dec 19, 2016 at 10:52:13AM -0700, Jeff Law wrote:
> > > > None look like real bugs to me.
> > >
> > > They do to me. There are calls in gengtype.c to a function decorated
> > > with attribute nonnull (lbasename) that pass to it a pointer that's
> > > potentially null. For example below.
Ping?
On 12/12/16 1:31 PM, Josh Conner wrote:
On 12/10/16 3:26 AM, Richard Earnshaw wrote:
On 08/12/16 22:55, Josh Conner wrote:
+arm*-*-fuchsia*)
+ tm_file="${tm_file} fuchsia.h arm/fuchsia-elf.h glibc-stdint.h"
+ tmake_file="${tmake_file} arm/t-bpabi"
+ ;;
This will lea
On 12/19/2016 10:31 AM, Jeff Law wrote:
On 12/17/2016 02:55 PM, Martin Sebor wrote:
On 12/17/2016 01:01 PM, Markus Trippelsdorf wrote:
I agree that these warnings should probably not be issued, though
it's interesting to see where they come from. The calls are in
the code emitted by GCC, are r
This patch copies the cgo support code from the Go 1.7 runtime to
libgo. The cgo support in gccgo is rather different, so all the code
in cgo_gccgo.go is gccgo-specific. The rest of the code is similar
but slightly different. This drops _cgo_allocate, which was removed
from the gc toolchain back
> On Thu, Dec 8, 2016 at 10:44 PM, Uros Bizjak wrote:
> > Hello!
> >
> > Attached patch fixes fall-out from excess-precision improvements
> > patch. As shown in the PR, the code throughout the compiler assumes
> > FLAG_PRECISION_FAST when flag_unsafe_math_optimizations flag is in
> > effect. The
On 16/12/16 17:52 +, Jonathan Wakely wrote:
On 09/11/16 23:26 +0200, Pauli wrote:
Compiling programs using std::future for old arm processors fails. The
problem is caused by preprocessor check for atomic lock free int.
Future can be changed to work correctly without lock free atomics with
m
On 12/16/2016 10:27 AM, Jakub Jelinek wrote:
On Fri, Dec 16, 2016 at 10:10:00AM -0700, Martin Sebor wrote:
No. The first call to sm_read_sector just doesn't exit. So it is warning
about dead code.
If the code is dead then GCC should eliminate it. With it eliminated
There is (especially wi
Hi Will,
On Mon, Dec 19, 2016 at 11:01:19AM -0600, Will Schmidt wrote:
> This patch implements folding of the vector Multiply built-ins.
>
> As part of this patch, I have also marked variables in an existing
> testcase (mult-even-odd-be-order.c) as volatile, to prevent their being
> optimized o
Hi, uh, Will,
On Mon, Dec 19, 2016 at 11:01:08AM -0600, Will Schmidt wrote:
> This patch implements folding of the vector subtract built-ins. This
> follows the form used by Bill in his previous "Fold vector addition
> built-ins in GIMPLE" patch. :-)
>
> Bootstrapped and tested on powerpc64le-
On 12/16/2016 01:17 PM, Jakub Jelinek wrote:
On Fri, Dec 16, 2016 at 01:01:13PM -0700, Jeff Law wrote:
Thanks. Reduced to something like:
int
foo (const char *name)
{
if (name)
return 6;
return __builtin_strlen (name);
}
This is warned about both with Martin's late warning and my after
On 12/19/2016 02:42 AM, Jakub Jelinek wrote:
The ubsan pass runs before IPA, so not sure how do you want to do that
(and it is needed to run it early).
One question is if we should perform path isolation in this case at all,
since the branches to __builtin___ubsan_handle_nonnull_arg are with
PR
On 12/17/2016 02:55 PM, Martin Sebor wrote:
On 12/17/2016 01:01 PM, Markus Trippelsdorf wrote:
I agree that these warnings should probably not be issued, though
it's interesting to see where they come from. The calls are in
the code emitted by GCC, are reachable, and end up taking place
with th
Hi Aaron,
On Mon, Dec 19, 2016 at 09:57:07AM -0600, Aaron Sawdey wrote:
> Bootstrap/regtest in progress on ppc64le -mcpu=power8, ok for trunk if
> results are clean?
> +/* Generate alignment check and branch code to set up for
> + strncmp when we don't have DI alignment.
> + STRNCMP_LABEL is
Hi,
For some future rs6000 vector folding patches, I will be needing
access to the create_tmp_reg_or_ssa_name() function in rs6000.c.
Thus...
Externalize the definition of create_tmp_reg_or_ssa_name
for use in rs6000.c. The actual usage will show up in later patches.
I'll note that I do not have
On 12/19/2016 09:51 AM, Jakub Jelinek wrote:
On Mon, Dec 19, 2016 at 09:34:44AM -0700, Martin Sebor wrote:
That would be just weird, have one behavior for selected subset of functions
and another for the rest? Ugh.
The selected set of the string built-ins are special -- they are
known not to
Hi All,
I've respun the patch with the feedback from Jeff and Joseph.
> I think an integer mode should always exist - even in the case of TFmode
> on 32-bit systems (32-bit sparc / s390, for example, use TFmode long
> double for GNU/Linux, and it's supported as _Float128 and __float128 on
> 32-bi
On Tue, 2016-12-06 at 09:59 +0100, Andreas Schwab wrote:
> On Dez 05 2016, Bill Schmidt wrote:
>
> > What's your target triple?
>
> http://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00471.html
>
> Andreas.
>
I *suspect* this is fixable with the addition of this dg- directive to
the fold-vec-ad
Hi,
This patch implements folding of the vector Multiply built-ins.
As part of this patch, I have also marked variables in an existing
testcase (mult-even-odd-be-order.c) as volatile, to prevent their being
optimized out, which happens once this vector multiply folding was able
to occur.
Boot
Hi,
This patch implements folding of the vector subtract built-ins. This
follows the form used by Bill in his previous "Fold vector addition
built-ins in GIMPLE" patch. :-)
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this ok for trunk?
Thanks,
-Will
On Mon, Dec 19, 2016 at 05:50:40PM +0100, Dominik Vogt wrote:
> * config/s390/s390-c.c (s390_cpu_cpp_builtins_internal): Define
> __S390_ARCH_LEVEL__.
> gcc/testsuite/ChangeLog-setmem
>
> * gcc.target/s390/md/setmem_long-1.c: Use "runnable".
> * gcc.target/s390/md/rXsbg_mod
On Tue, Dec 13, 2016 at 11:42:40AM +0100, Jakub Jelinek wrote:
> On Tue, Dec 13, 2016 at 11:18:31AM +0100, Dominik Vogt wrote:
> > > IMHO you want something like x86 avx_runtime effective target
> > > (z13_runtime?), which would stand for running on z13 capable hw and
> > > with z13 assembler suppo
Hi!
On Mon, Dec 19, 2016 at 11:51:29AM -0500, David Malcolm wrote:
> +/* Look for near matches for the scoped attribute with namespace NS and
> + name NAME.
> + Return the best matching attribute name, or NULL if none is found.
> + If it returns non-NULL then *UNDERSCORES is written to, with
On Mon, Dec 19, 2016 at 09:34:44AM -0700, Martin Sebor wrote:
> > That would be just weird, have one behavior for selected subset of functions
> > and another for the rest? Ugh.
>
> The selected set of the string built-ins are special -- they are
> known not to recover from null pointers so I thi
On Mon, Dec 19, 2016 at 03:28:06PM +0100, Dominik Vogt wrote:
> The attached patch is specific to S/390 but contains a small
> common code change in gcc-dg.exp. It fixes the notorious problem
> of md tests running on an S/390 machine that does not support the
> z13 instruction set.
>
> Bootstrapp
On Mon, Dec 19, 2016 at 05:43:38PM +0100, Markus Trippelsdorf wrote:
> On 2016.12.19 at 09:34 -0700, Martin Sebor wrote:
> > On 12/19/2016 09:17 AM, Jakub Jelinek wrote:
> > > Or apply the patch I've posted which doesn't suffer from this problem,
> > > or revert the -Wnonnull changes and resolve so
On 2016.12.19 at 09:34 -0700, Martin Sebor wrote:
> On 12/19/2016 09:17 AM, Jakub Jelinek wrote:
> > Or apply the patch I've posted which doesn't suffer from this problem,
> > or revert the -Wnonnull changes and resolve somehow in GCC 8.
>
> I would prefer your patch if it solves the problem. In
Hi all...
I never saw any followup on this...?
It's one thing to break the ABI between the compiler and the gfortran
library; those can generally be expected to be in sync. It's another to
break the ABI between two *languages*, when there might be no such
expectation (especially if gcc does
Note to i386 maintainters: this patch is part of the RTL frontend.
It adds selftests for verifying that the RTL dump reader works as
expected, with a mixture of real and hand-written "dumps" to
exercise various aspects of the loader. Many RTL dumps contain
target-specific features (e.g. names of
On 12/19/2016 09:17 AM, Jakub Jelinek wrote:
On Mon, Dec 19, 2016 at 08:52:44AM -0700, Martin Sebor wrote:
Another thing is that what the compiler does can very well just happen
in some generic function that is called by the function that calls these
strlen/strcpy etc. functions (fns with nonnul
On 19/12/16 14:34 +0200, Ville Voutilainen wrote:
On 19 December 2016 at 12:19, Jonathan Wakely wrote:
On 18/12/16 13:33 +0200, Ville Voutilainen wrote:
Andrzej Krzemienski pointed this out in a discussion related to any and
tags.
Our two-element tuple specialization doesn't make the perfect-
On Mon, Dec 19, 2016 at 6:15 PM, FX wrote:
>> Thanks, committed as r243799.
>
> I think something went wrong in your commit, as none of the “removed” files
> were removed: https://gcc.gnu.org/viewvc/gcc?view=revision&revision=243799
Indeed, thanks for bringing it up. Fixed by r243804.
--
Jann
> The patch you posted contains some apparently unrelated changes to
> gfortran.map. Without those, Ok.
Thanks for the reviews. Patches committed. Wiki updated. I’ll work tonight on
some of the remaining items on the “abi cleanup” list.
> As a minor cosmetic improvement, you could fold_convert
Our -Wattributes warnings can be rather cryptic. The following patch
improves this warning:
../../src/pr70186.c:1:8: warning: 'visbility' attribute directive ignored
[-Wattributes]
struct S *foo __attribute__ ((visbility("hidden")));
^
by adding suggestions when unrecognized attributes
On Mon, Dec 19, 2016 at 08:52:44AM -0700, Martin Sebor wrote:
> > Another thing is that what the compiler does can very well just happen
> > in some generic function that is called by the function that calls these
> > strlen/strcpy etc. functions (fns with nonnull attribute).
>
> For the string bu
> Thanks, committed as r243799.
I think something went wrong in your commit, as none of the “removed” files
were removed: https://gcc.gnu.org/viewvc/gcc?view=revision&revision=243799
FX
On Mon, Dec 19, 2016 at 12:59 PM, FX wrote:
>> Yes, I agree (in general, though I was thinking of making the new one
>> "GFORTRAN_7" to match the release series).
>
> Given that there will not be a 1-to-1 mapping of release series with major
> ABI versions (hopefully!), I don’t think this is a go
> No, this was actually part of r243799 which I just committed (after you Ok'd
> it. :) )
Oops. Sorry!
On Fri, 2016-12-16 at 17:14 -0600, Segher Boessenkool wrote:
> Please repost. Thanks,
Hi Segher,
Thanks for the review. Attached is an updated patch that should
address the issues you noted.
Bootstrap/regtest in progress on ppc64le -mcpu=power8, ok for trunk if
results are clean?
Thanks,
On 12/19/2016 02:42 AM, Jakub Jelinek wrote:
On Sat, Dec 17, 2016 at 02:55:15PM -0700, Martin Sebor wrote:
I agree that these warnings should probably not be issued, though
it's interesting to see where they come from. The calls are in
the code emitted by GCC, are reachable, and end up taking p
On Mon, Dec 19, 2016 at 4:48 PM, FX wrote:
> We implement the LEADZ and TRAILZ intrinsics in terms of the built-in clz()
> and ctz() functions. Since these are not available for 128-bit integer types,
> we used to have support functions _gfortran_clz128() and _gfortran_ctz128()
> in libgfortran
On Mon, Dec 19, 2016 at 3:54 PM, FX wrote:
> The ISO_C_BINDING procedures have been emitted directly by the front-end
> since 2012 (see for example
> https://gcc.gnu.org/ml/fortran/2012-06/msg00152.html and
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32600). Having now broken the
> library
Hi,
This patch fixes PR 65618 where ADA cannot be bootstrapped natively on
mips due to a bootstrap comparison failure. The PR is currently in the
target component, but should be in the rtl-optimization component.
The underlying bug is in gcc/emit-rtl.c:try_split and is a result of
the fix for PR
On Mon, Dec 19, 2016 at 4:13 PM, FX wrote:
> When support for F2008 requirements on numeric STOP statements was
> implemented, the old _gfortran_stop_numeric() runtime function was made
> obsolete and a new _gfortran_stop_numeric_f08() function was created, which
> is the only one used in the f
On Mon, Dec 19, 2016 at 4:31 PM, FX wrote:
> Since 2010, gfortran does not rely on library support functions to handle
> TRANSPOSE, but instead emits code directly in the front-end
> (https://gcc.gnu.org/ml/fortran/2010-09/msg00109.html). We have since kept
> the various _gfortran_transpose_* f
On Mon, Dec 19, 2016 at 4:44 PM, FX wrote:
>> Now that the libgfortran ABI major version has been bumped, we can
>> remove functions for which the frontend nowadays generates inline
>> code.
>>
>> This removes the malloc, free, exponent, fraction, nearest, rrspacing,
>> spacing, set_exponent and t
I'll consider myself agnostic as to whether this is a feature we want or
need, so I'll just comment on some style questions. There's a fair
amount of coding style violations, I'll point some of them out but
please read the documents we have linked on this page:
https://gcc.gnu.org/contribute.
On Thu, Dec 15, 2016 at 10:00:14AM +, Richard Earnshaw (lists) wrote:
> sorry, pasted the wrong bit of code.
>
> That should read when we generate:
>
> (insn 55 19 67 3 (parallel [
> (set (reg:SI 0 r0)
> (mem/u/c:SI (reg/f:SI 147) [2 c+0 S4 A32]))
> (se
We implement the LEADZ and TRAILZ intrinsics in terms of the built-in clz() and
ctz() functions. Since these are not available for 128-bit integer types, we
used to have support functions _gfortran_clz128() and _gfortran_ctz128() in
libgfortran. In 2010, I applied a patch to avoid this and emit
> Now that the libgfortran ABI major version has been bumped, we can
> remove functions for which the frontend nowadays generates inline
> code.
>
> This removes the malloc, free, exponent, fraction, nearest, rrspacing,
> spacing, set_exponent and transpose intrinsics. Also the unused
> store_exe_
Since 2010, gfortran does not rely on library support functions to handle
TRANSPOSE, but instead emits code directly in the front-end
(https://gcc.gnu.org/ml/fortran/2010-09/msg00109.html). We have since kept the
various _gfortran_transpose_* functions in libgfortran for ABI compatbility,
but w
On 12/16/2016 09:18 PM, David Malcolm wrote:
The following patch implements the change for print-rtl.c.
OK for trunk assuming it passes bootstrap®rtest?
Yes.
Bernd
The attached patch is specific to S/390 but contains a small
common code change in gcc-dg.exp. It fixes the notorious problem
of md tests running on an S/390 machine that does not support the
z13 instruction set.
Bootstrapped and tested on s390x biarch.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
When support for F2008 requirements on numeric STOP statements was implemented,
the old _gfortran_stop_numeric() runtime function was made obsolete and a new
_gfortran_stop_numeric_f08() function was created, which is the only one used
in the front-end nowadays. The old _gfortran_stop_numeric()
Tested on Linux-x64.
The perfect forwarder needs to sfinae out of the way of the in_place_t
signature,
and the in_place_t signature needs to check is_constructible. I also
did some housekeeping
to get rid of the int-pack constraints, because in case of empty packs
it's unclear
what a compiler is s
Jiong Wang writes:
> Jiong Wang writes:
>
>> On 16/11/16 14:02, Jakub Jelinek wrote:
>>> On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote:
On Wed, 2016-11-16 at 10:00 +, Jiong Wang wrote:
> The two operations DW_OP_AARCH64_paciasp and
> DW_OP_AARCH64_paciasp_deref
The ISO_C_BINDING procedures have been emitted directly by the front-end since
2012 (see for example https://gcc.gnu.org/ml/fortran/2012-06/msg00152.html and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32600). Having now broken the
library ABI, we can remove them from the library, where they we
In the case where CHMOD is called with a numeric mode, the current code assumes
that “mode_t” corresponds to an unsigned int. This is true on linux/glibc, but
not true on macOS (where mode_t is an unsigned short) and thus creates a
warning and possibly a runtime error. This had been spotted earl
Jason,
this patch fixes 78771, were an assert fires due to recursive
instantiation of an inheriting ctor. Normally when a recursive
instantiation is needed, we've already constructed and registered the
declaration, so simply return it. For ctors though we need to construct
the clones after w
Ramana Radhakrishnan wrote:
> On Wed, Dec 14, 2016 at 5:43 PM, Wilco Dijkstra
> wrote:
> > Yes, the reason to split the pattern was to introduce the '!' to discourage
> > Neon->int moves on Cortex-A8 (https://patches.linaro.org/patch/541/). I am
> > not removing the optimization for Cortex-A8,
Hi Paul,
Apologies for the delay in responding.
> I get the copyright assignment, it's ok for commit.
Thanks for going through copyright assignment, I can see you listed and
also you have commit access now. Is the trunk build failure still
present for you, if it is now resolved then please go ah
1 - 100 of 115 matches
Mail list logo