On Fri, Sep 02, 2016 at 05:39:49PM -0500, Segher Boessenkool wrote:
> It seems to be a regression, anyway? Older versions built fine?
I see this warning, but only in stage1 of the build.
Segher
On Fri, 2016-09-02 at 16:55 -0600, Martin Sebor wrote:
> I've successfully tested the patch below by incorporating it into
> the -Wformat-length pass I've been working on. I'd like to submit
> the latest and hopefully close to final version of my work for
> review without duplicating this code and
On 9/2/16, Segher Boessenkool wrote:
> On Fri, Sep 02, 2016 at 05:08:34PM -0400, Eric Gallager wrote:
>> > The only way to know for sure what GCC is warning about is to look at
>> > the uninit dump.
>>
>> How exactly do I generate an uninit dump? I'm not seeing any relevant
>> options in the GCC m
I've successfully tested the patch below by incorporating it into
the -Wformat-length pass I've been working on. I'd like to submit
the latest and hopefully close to final version of my work for
review without duplicating this code and it might be helpful if
it was possible to build my latest pat
On Fri, Sep 02, 2016 at 05:08:34PM -0400, Eric Gallager wrote:
> > The only way to know for sure what GCC is warning about is to look at the
> > uninit dump.
>
> How exactly do I generate an uninit dump? I'm not seeing any relevant
> options in the GCC manual...
-fdump-tree-uninit
> > Moreover,
On 9/2/16, Manuel López-Ibáñez wrote:
> On 02/09/16 20:27, Segher Boessenkool wrote:
>> On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote:
>>> ../../gcc/combine.c: In function ‘int combine_instructions(rtx_insn*,
>>> unsigned int)’:
>>> ../../gcc/combine.c:1310:8: warning: ‘prev’ may b
On 02.09.2016 23:54, Jakub Jelinek wrote:
Sure, sorry.
gcc/
* ubsan.c (ubsan_use_new_style_p): Fix check for empty string.
--
Thanks, K
On 02.09.2016 23:56, Jakub Jelinek wrote:
On Fri, Sep 02, 2016 at 11:53:01PM +0300, Kirill Yukhin wrote:
gcc/
* gcc/ipa-devirt.c (get_odr_type): Check odr_types_ptr for
zero before dereferencing it.
I've already tested/posted
http://gcc.gnu.org/ml/gcc-patches/2016-09/msg00089.
On Fri, Sep 02, 2016 at 11:53:01PM +0300, Kirill Yukhin wrote:
> Hello,
> Looks like `get_odr_type ()` contains code which dereferences
> pointer before check it for zero. I moved the line under the check.
>
> Bootstrap/regtest on x?86|x86_64 in progress.
>
> Is it ok for trunk if pass?
>
> gcc/
On Fri, Sep 02, 2016 at 11:22:24PM +0300, Kirill Yukhin wrote:
> Hello,
> Patch in the bottom fixes typo in check of for string emptiness
>
> gcc/
> * gcc/ubsan.c (ubsan_use_new_style_p): Fix check for empty string.
No gcc/ in the ChangeLog entry.
> I'll bootstrap/regtest the patch and check
Hello,
Looks like `get_odr_type ()` contains code which dereferences
pointer before check it for zero. I moved the line under the check.
Bootstrap/regtest on x?86|x86_64 in progress.
Is it ok for trunk if pass?
gcc/
* gcc/ipa-devirt.c (get_odr_type): Check odr_types_ptr for
zero
On Fri, Sep 02, 2016 at 09:31:14PM +0100, Manuel López-Ibáñez wrote:
> Nevertheless, assignments within 'if' are one of the things that make
> reading GCC code harder than it needs to be (and combine.c is scary).
Yes and yes. But we really should not warn here.
Segher
On 02/09/16 20:27, Segher Boessenkool wrote:
On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote:
../../gcc/combine.c: In function ‘int combine_instructions(rtx_insn*,
unsigned int)’:
../../gcc/combine.c:1310:8: warning: ‘prev’ may be used uninitialized
in this function [-Wmaybe-uninit
Hello,
Patch in the bottom fixes typo in check of for string emptiness
gcc/
* gcc/ubsan.c (ubsan_use_new_style_p): Fix check for empty string.
I'll bootstrap/regtest the patch and check it into as obvious if no
objections.
--
Thanks, K
commit 57ad19906b808386220d628a1ba326e043e0d211
Auth
I plan to commit the following patch in the next day or two.
Objections?
2016-09-03 Steven G. Kargl
PR fortran/77460
* simplify.c (simplify_transformation_to_scalar): On error, result
may be NULL, simply return.
2016-09-03 Steven G. Kargl
PR fortran/77460
On 02.09.2016 20:00, Jakub Jelinek wrote:
On Fri, Sep 02, 2016 at 07:52:45PM +0300, Kirill Yukhin wrote:
Hi,
Remove identical conditions from AND
in return.
Will check-in after bootstrap/regtest on i386|x86_64 as obvious.
gcc/
* dwarf2out.c (dw_val_equal_p): Remove redundant condition in
On 9/2/16, David Malcolm wrote:
> On Fri, 2016-09-02 at 15:41 -0400, Eric Gallager wrote:
>> On 9/2/16, Segher Boessenkool wrote:
>> > On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote:
>> > > ../../gcc/combine.c: In function ‘int
>> > > combine_instructions(rtx_insn*,
>> > > unsigned
On 02/09/16 18:44, David Malcolm wrote:
Much better would be to have the formatting be done inside the
diagnostics subsystem's call into pp_format, with something like this:
warning_at_rich_loc_n (&richloc, OPT_Wrestrict,
arg_positions
.length (),
On Wed, 2016-08-24 at 21:13 -0400, David Malcolm wrote:
> Changed in v2: I dropped -fdiagnostics-apply-fixits
>
> This patch uses the edit_context machinery to provide a new
> -fdiagnostics-generate-patch option.
>
> If set an edit_context is created for global_dc, and any
> fix-it hints emitted
On Fri, 2016-09-02 at 15:41 -0400, Eric Gallager wrote:
> On 9/2/16, Segher Boessenkool wrote:
> > On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote:
> > > ../../gcc/combine.c: In function ‘int
> > > combine_instructions(rtx_insn*,
> > > unsigned int)’:
> > > ../../gcc/combine.c:1310:8
On 9/2/16, Segher Boessenkool wrote:
> On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote:
>> ../../gcc/combine.c: In function ‘int combine_instructions(rtx_insn*,
>> unsigned int)’:
>> ../../gcc/combine.c:1310:8: warning: ‘prev’ may be used uninitialized
>> in this function [-Wmaybe-un
On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote:
> ../../gcc/combine.c: In function ‘int combine_instructions(rtx_insn*,
> unsigned int)’:
> ../../gcc/combine.c:1310:8: warning: ‘prev’ may be used uninitialized
> in this function [-Wmaybe-uninitialized]
> if ((next = try_combi
On 2016-09-02 20:20, Eelis van der Weegen wrote:
On 2016-08-31 14:45, Jonathan Wakely wrote:
Is this significantly faster than just using
uniform_int_distribution<_IntType>{0, __bound - 1}(__g) so we don't
need to duplicate the logic? (And people maintaining the code won't
reconvince themselves
Hi!
As reported in PR77434 and PR77421 there should be a warning for
suspicious uses of conditional expressions with non-boolean arguments.
This warning triggers on conditional expressions in boolean context,
when both possible results are non-zero integer constants, so that
the resulting truth v
On 9/2/16, Segher Boessenkool wrote:
> On Fri, Sep 02, 2016 at 09:40:36AM -0400, Eric Gallager wrote:
>> --- a/gcc/combine.c
>> +++ b/gcc/combine.c
>> @@ -1122,7 +1122,7 @@ static int
>> combine_instructions (rtx_insn *f, unsigned int nregs)
>> {
>>rtx_insn *insn, *next;
>> - rtx_insn *prev
On 2016-08-31 14:45, Jonathan Wakely wrote:
Is this significantly faster than just using
uniform_int_distribution<_IntType>{0, __bound - 1}(__g) so we don't
need to duplicate the logic? (And people maintaining the code won't
reconvince themselves it's correct every time they look at it :-)
[..]
Changes in v3:
- Updated doc/invoke.texi.
- Renamed line_state to edited_line
- I rewrote content-tracking in terms of edited lines, rather than
tracking the whole file. This avoids the need to load the whole file,
instead fetching it as needed from input.c's cache. This required a
little fiddly
On Thu, 2016-09-01 at 14:55 +0530, Prathamesh Kulkarni wrote:
[...]
> The attached version passes bootstrap+test on ppc64le-linux-gnu.
> Given that it only looks if parameters are restrict qualified and not
> how they're used inside the callee,
> this can have false positives as in above test-cas
On 09/02/2016 02:35 AM, Uros Bizjak wrote:
> --q--
> /* Pass float and _Complex float variable arguments by reference.
> This avoids 64-bit store from a FP register to a pretend args save area
> and subsequent 32-bit load from the saved location to a FP register.
>
> Note that 32-
On 2 September 2016 at 15:49, Richard Biener wrote:
> On Fri, 2 Sep 2016, Prathamesh Kulkarni wrote:
>
>> Hi,
>> There appears to be a redundant second assignmeent bb_copy = NULL in
>> free_copy_original_tables(). I suppose it should be
>> bb_original = NULL instead ?
>> I found this mentioned on
On Fri, Sep 02, 2016 at 07:52:45PM +0300, Kirill Yukhin wrote:
> Hi,
> Remove identical conditions from AND
> in return.
> Will check-in after bootstrap/regtest on i386|x86_64 as obvious.
>
> gcc/
> * dwarf2out.c (dw_val_equal_p): Remove redundant condition in
> return statement.
This isn
Hi,
Remove identical conditions from AND
in return.
Will check-in after bootstrap/regtest on i386|x86_64 as obvious.
gcc/
* dwarf2out.c (dw_val_equal_p): Remove redundant condition in
return statement.
--
Thanks, K
commit 4c71ef36cda91edaef731e460a58fe09942b2d93
Author: Kirill Yukhin
D
On September 2, 2016 4:58:20 PM GMT+02:00, Jakub Jelinek
wrote:
>On Thu, Sep 01, 2016 at 09:58:44AM +0200, Richard Biener wrote:
>> Ah, so it expects sth _before_ before-dynamic-init? At least it
>seems
>> that globals are not only registered inbetween
>before/after-dynamic-init.
>
>Here is upda
On September 2, 2016 5:11:39 PM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>I've looked a little bit at svn blame and we had:
> tree steptype = type;
> if (POINTER_TYPE_P (type))
>steptype = sizetype;
>there initially and the
> steptype = unsigned_type_for (type);
>has been added later on in r
On Fri, Sep 2, 2016 at 3:46 PM, Yuri Rumyantsev wrote:
> Hi Jeff,
>
> I am trying to reduce cost of repeated call of if-conversion for
> epilogue vectorization. I'd like to clarify your recommendation -
> should I design additional support for versioning in
> vect_do_peeling_for_loop_bound or ligh
On Sep 02 2016, Andreas Schwab wrote:
> On Sep 02 2016, Ian Lance Taylor wrote:
>
>> On Fri, Sep 2, 2016 at 9:14 AM, Andreas Schwab wrote:
>>>
>>> That breaks libgo on ia64. The problem is that _ucontext_t isn't
>>> properly aligned.
>>
>> Interesting. Thanks for looking into it. What is the
On Sep 02 2016, Ian Lance Taylor wrote:
> On Fri, Sep 2, 2016 at 9:14 AM, Andreas Schwab wrote:
>>
>> That breaks libgo on ia64. The problem is that _ucontext_t isn't
>> properly aligned.
>
> Interesting. Thanks for looking into it. What is the required
> alignment? This code should be align
Hi!
I've committed as obvious the following change. I've tracked the redundant
stmt to appear in r216794, where just a bunch of new cases were added and
the redundant stmt together with those.
2016-09-02 Jakub Jelinek
PR other/77421
* config/i386/i386.c (ix86_expanded_args_bu
On Fri, Sep 2, 2016 at 9:14 AM, Andreas Schwab wrote:
>
> That breaks libgo on ia64. The problem is that _ucontext_t isn't
> properly aligned.
Interesting. Thanks for looking into it. What is the required
alignment? This code should be aligning it to a pointer boundary.
Ian
On Sep 2, 2016, at 6:31 AM, Joseph Myers wrote:
>
> On Fri, 2 Sep 2016, Uros Bizjak wrote:
>
>> It looks to me that we have no tests for _Complex float variable
>> arguments passing in g*.dg/compat/. There are no xfails for alpha* in
>> this directory, and these arguments would fail for sure for
That breaks libgo on ia64. The problem is that _ucontext_t isn't
properly aligned.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Sep 02 2016, Andreas Schwab wrote:
> On Aug 31 2016, Ian Lance Taylor wrote:
>
>> Index: libgo/runtime/runtime.c
>> ===
>> --- libgo/runtime/runtime.c (revision 239872)
>> +++ libgo/runtime/runtime.c (working copy)
>> @@ -272,7
On Aug 31 2016, Ian Lance Taylor wrote:
> Index: libgo/runtime/runtime.c
> ===
> --- libgo/runtime/runtime.c (revision 239872)
> +++ libgo/runtime/runtime.c (working copy)
> @@ -272,7 +272,14 @@ runtime_tickspersecond(void)
> vo
Hi,
> + r += !a == ~b;
> + r += !a == ~(int) b;
I don't understand why ~b should not be warned at -Wall.
Frankly I don't even understand why the above statements are
completely optimized away.
r += !a == ~b;
is optimized away, but
b = ~b;
r += !a == b;
Is not. Why?
Bernd.
On Fri, Sep 02, 2016 at 09:40:36AM -0400, Eric Gallager wrote:
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -1122,7 +1122,7 @@ static int
> combine_instructions (rtx_insn *f, unsigned int nregs)
> {
>rtx_insn *insn, *next;
> - rtx_insn *prev;
> + rtx_insn *prev = NULL;
>struct insn_
Hi!
The two ports that use define_subst (ix86 and visium) don't do anything in
this function, other than returning early - return insn_out, so all I could
do is look at the intent.
The *insn_out == '*' || *insn_out != '@' got flagged by some tool, the
"*insn_out == '*' || " part is unnecessary, si
Martin reported that -Wlogical-not-parentheses issues a bogus warning
for bit operations on booleans, because the warning didn't take integer
promotions into account. The following patch ought to fix this problem.
It's not exactly trivial because I had to handle even more complex
expressions and
Hi!
I've looked a little bit at svn blame and we had:
tree steptype = type;
if (POINTER_TYPE_P (type))
steptype = sizetype;
there initially and the
steptype = unsigned_type_for (type);
has been added later on in r209190, without cleaning up the earlier stmts.
I think for POINTER_TYPE_P i
Hi!
As mentioned in the PR, we have
static GTY(()) vec *odr_types_ptr;
#define odr_types (*odr_types_ptr)
and in the else block do
odr_types[val->id] = 0;
first (which is actually
(*odr_types_ptr)[val->id] = 0;
without the obfuscation) and then
if (odr_types_ptr)
...
odr_types_ptr is kn
Hi!
We have
#define DEPS_LIST_FIRST(L) ((L)->first)
and first is the field of the struct, so for the case when list is
NULL we do linkp = &list->first; which actually gives us NULL too, but with
UB. From my analysis of the scheduler code, we should never use linkp (or
anything else in the iterato
On Thu, Sep 01, 2016 at 09:58:44AM +0200, Richard Biener wrote:
> Ah, so it expects sth _before_ before-dynamic-init? At least it seems
> that globals are not only registered inbetween before/after-dynamic-init.
Here is updated patch, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for
Hi Jeff,
I am trying to reduce cost of repeated call of if-conversion for
epilogue vectorization. I'd like to clarify your recommendation -
should I design additional support for versioning in
vect_do_peeling_for_loop_bound or lightweight version of if-conversion
is sufficient? Any help in clarifi
While I was silencing some warnings about narrowing conversions, which
was https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02129.html (for
reference), I also silenced some warnings from -Wmaybe-uninitialized
in combine.c and varasm.c while I was at it. I took the easy way out
and simply initialized t
On Fri, 2 Sep 2016, Uros Bizjak wrote:
> It looks to me that we have no tests for _Complex float variable
> arguments passing in g*.dg/compat/. There are no xfails for alpha* in
> this directory, and these arguments would fail for sure for this
> target.
I suppose compat tests should be added for
On Fri, Sep 2, 2016 at 2:37 PM, Uros Bizjak wrote:
> On Fri, Sep 2, 2016 at 2:11 PM, Jakub Jelinek wrote:
>> On Fri, Sep 02, 2016 at 12:09:30PM +, Joseph Myers wrote:
>>> On Fri, 2 Sep 2016, Uros Bizjak wrote:
>>>
>>> > argument. Passing _Complex float as a variable argument never
>>> >
On Fri, Sep 2, 2016 at 2:11 PM, Jakub Jelinek wrote:
> On Fri, Sep 02, 2016 at 12:09:30PM +, Joseph Myers wrote:
>> On Fri, 2 Sep 2016, Uros Bizjak wrote:
>>
>> > argument. Passing _Complex float as a variable argument never
>> > worked on alpha. Thus, we have no backward compatibi
> Hi Honza,
>
> Here is a re-based version which also addresses the review comments.
>
> Do you mean the following, I was following other implementations.
>
> @@ -2264,6 +2430,11 @@ propagate_constants_accross_call (struct
> cgraph_edge *cs)
> &dest_plats->bits_lattice);
>ret |= prop
On Fri, Sep 02, 2016 at 12:09:30PM +, Joseph Myers wrote:
> On Fri, 2 Sep 2016, Uros Bizjak wrote:
>
> > argument. Passing _Complex float as a variable argument never
> > worked on alpha. Thus, we have no backward compatibility issues
>
> Presumably there should be an architecture
On Fri, 2 Sep 2016, Uros Bizjak wrote:
> argument. Passing _Complex float as a variable argument never
> worked on alpha. Thus, we have no backward compatibility issues
Presumably there should be an architecture-independent execution test of
passing _Complex float in variable argumen
Ramana Radhakrishnan wrote:
> Can you please file a PR for this and add some testcases ? This sounds like
> a serious enough problem that needs to be looked at probably going back since
> the dawn of time.
I've created PR77455. Updated patch below:
This patch simplifies the handling of the EH
On Fri, 2 Sep 2016, Robin Dapp wrote:
> This causes a performance regression in the xalancbmk SPECint2006
> benchmark on s390x. At first sight, the produced asm output doesn't look
> too different but I'll have a closer look. Is the fwprop order supposed
> to have major performance implications?
Hello!
I would like to propose an ABI adjustment for the aloha OSF/1 ABI. To
quote explanation in the patch:
--q--
/* Pass float and _Complex float variable arguments by reference.
This avoids 64-bit store from a FP register to a pretend args save area
and subsequent 32-bit load from
This causes a performance regression in the xalancbmk SPECint2006
benchmark on s390x. At first sight, the produced asm output doesn't look
too different but I'll have a closer look. Is the fwprop order supposed
to have major performance implications?
Regards
Robin
> This changes it from PRE on t
Committed as obvious after bootstrap+test on x86_64-unknown-linux-gnu.
Thanks,
Prathamesh
2016-09-02 Prathamesh Kulkarni
* ipa-cp.c (ipcp_store_bits_results): Change option name from
-fipa-cp-bit to -fipa-bit-cp.
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 9514dd1..5ff7bed
Ping ?
Thanks,
Kugan
On 23 August 2016 at 12:11, Kugan Vivekanandarajah
wrote:
> Hi,
>
> On 19 August 2016 at 21:41, Richard Biener wrote:
>> On Tue, Aug 16, 2016 at 9:45 AM, kugan
>> wrote:
>>> Hi Richard,
>>>
>>> On 12/08/16 20:43, Richard Biener wrote:
On Wed, Aug 3, 2016 at 3:17
Hi Richard,
On 25 August 2016 at 22:24, Richard Biener wrote:
> On Thu, Aug 11, 2016 at 1:09 AM, kugan
> wrote:
>> Hi,
>>
>>
>> On 10/08/16 20:28, Richard Biener wrote:
>>>
>>> On Wed, Aug 10, 2016 at 10:57 AM, Jakub Jelinek wrote:
On Wed, Aug 10, 2016 at 08:51:32AM +1000, kugan wrote
Hi all,
attached patch fixes the issue raised by PR72832. The issue was that
the array descriptor of the SOURCE= in an ALLOCATE () was used to
allocate an array object although an explicit array spec had been
given.
The initial test showed a second issue when a class array was copied.
Compiling t
67 matches
Mail list logo
