Hi all,
I committed the attached patch, adding myself to the Write After Approval.
committed as r243789.
thanks,
paul
Index: ChangeLog
===
--- ChangeLog (revision 243788)
+++ ChangeLog (revision 243789)
@@ -1,3 +1,7 @@
+2016-12-19 C
I have committed the attached patch to add t-eh-dw2-dip to NetBSD libgcc
tmake_file.
Bootstrapped and tested on i386-unknown-netbsdelf6.1 and
x86_64-unknown-netbsd6.1.
/Krister
2016-12-19 Krister Walfridsson
* config.host (*-*-netbsd*): Add t-eh-dw2-dip to tmake_file.
*
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 place
> with the right Ubsan runtime recove
On Wed, Dec 14, 2016 at 5:43 PM, Wilco Dijkstra wrote:
> Kyrill Tkachov wrote:
>> On 14/12/16 16:37, Wilco Dijkstra wrote:
>>
>> > Merge the movdi_vfp_cortexa8 pattern into movdi_vfp and remove it to avoid
>> > unnecessary duplication and repeating bugs like PR78439 due to changes
>> > being
>> >
I have committed the attached to add a LINK_EH_SPEC enabling
--eh-frame-hdr in the NetBSD config.
Bootstrapped and tested on x86_64-unknown-netbsd6.1.
/Krister
2016-12-19 Krister Walfridsson
* config/netbsd.h (LINK_EH_SPEC): Define.Index: gcc/config/netbsd.h
===
On Wed, Dec 14, 2016 at 11:01:47AM +0100, Dominik Vogt wrote:
> gcc/ChangeLog-change_zero_ext-2
>
> * combine.c (change_zero_ext): Skip generation of redundant AND.
Applied. Thanks!
-Andreas-
On Mon, Dec 12, 2016 at 05:37:03PM +0100, Dominik Vogt wrote:
> gcc/ChangeLog-pr78748
>
> PR target/78748
> * config/s390/s390.md ("*andc_split_"): Allow memory destination
> only if it coincides with operand 2.
> gcc/testsuite/ChangeLog-pr78748
>
> PR target/78748
>
Hello.
Building mariadb with -flto exposes a bug which I also used to see in Firefox.
It's
caused by IPA CP starting from r236418, where the pass started to propagate
const
VAR_DECLs. Problem is that the pass does not update call graph by adding
IPA_REF_READ
of the propagated variable.
Patch c
Hi!
Just a nit, defer actual review to Honza or Richard.
On Mon, Dec 19, 2016 at 11:09:52AM +0100, Martin Liška wrote:
> + ipa_ref_use use_type
> + = TREE_CODE (map->new_tree) == VAR_DECL ? IPA_REF_ADDR : IPA_REF_LOAD;
= VAR_P (map->new_tree) ? IPA_REF_ADDR : IPA_REF_LOAD.
pleas
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-forwarding
constructor and the allocator constructor properly mutually exclusive; this
patch fixes that.
T
Hi all,
I have just committed some minor additions
(https://gcc.gnu.org/viewcvs?rev=243794&root=gcc&view=rev) to
Dominique's patch at
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=243785, so that
these documentation issued are finally resolved now.
Cheers,
Janus
2016-11-26 21:45 GMT+0
> 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 good idea. It will make people
confused.
> There's
Hi all,
attached is a patch to fix the incorrect computation of memory needed in a
polymorphic assignment. Formerly the memory required could not be determined
and therefore one byte was allocated. This is fixed now, by retrieving the
size needed from the _vptr->size.
Bootstraps and regtests ok o
Hi Andre,
> attached is a patch to fix the incorrect computation of memory needed in a
> polymorphic assignment. Formerly the memory required could not be determined
> and therefore one byte was allocated. This is fixed now, by retrieving the
> size needed from the _vptr->size.
>
> Bootstraps and
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-forwarding
>> constructor and the allocat
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
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,
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
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
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
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
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
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()
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
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
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
> 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_
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
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
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 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
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: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
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 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
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 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 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,
> No, this was actually part of r243799 which I just committed (after you Ok'd
> it. :) )
Oops. Sorry!
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
> 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 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
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
> 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
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
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 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
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
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
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
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 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 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
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 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
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
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
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
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 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 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,
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
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
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
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/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
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-
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
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
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 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
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 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
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 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.
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:
> > 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 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 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
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/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
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 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 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 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 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 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 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/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
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
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
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
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
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
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-
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
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 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
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
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
1 - 100 of 115 matches
Mail list logo
