Hi:
The vect-strided-shift-1.c test fails on MIPS target.
FAIL: gcc.dg/vect/vect-strided-shift-1.c -mpaired-single
scan-tree-dump-times vect "vectorized 1 loops in function" 1 (found 0
times)
FAIL: gcc.dg/vect/vect-strided-shift-1.c -flto -ffat-lto-objects
-mpaired-single scan-tree-dump-times v
Hi,
Just to update from my side,
this patch fixes the issues I had reported in PR83789 and there are no new
regression in my testing.
Best Regards,
Kaushik M. Phatak
-Original Message-
From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
Sent: Tuesday, March 13, 2018 12:25 AM
To
On 03/13/2018 03:56 PM, dave.pa...@oracle.com wrote:
> This patch fixes ICE when statement expression used in old-style
> function declaration parameter list. See
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30552
>
> In c_parser_postfix_expression (), after seeing a left paren followed by
>
On Mar 13, 2018, at 10:12 AM, Thomas Preudhomme
wrote:
>
> scan-assembler-times and scan-tree-dump-times dejagnu directives show a
> different output in the summary files depending on whether they PASS or
> FAIL. This means that dg-cmp-results would not show a regression because
> it would not s
As analyzed by Nathan and Paolo, the problem here is that the test
conversion in check_default_arg is changing the expression, but then
we discard the result. Excessive sharing of CONSTRUCTORs is an
ongoing issue, due to past decisions motivated by memory savings. For
the time being, we can speci
On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote:
>
> int val = kill (pid, signal);
> return (val == 0): 0 ? errno;
>
> like it already does for the optional status argument for kill_sub.
>
Committed as r258511 with your suggested change.
--
Steve
The issue raised in PR fortran/61775 seemed to be fixed.
I've read the tree dump for -fdump-tree-optimized, and
gfortran seems to be generating the expected code.
Valgrind also finishes without errors. I committed to
code as a testcase.
2018-03-13 Steven G. Kargl
PR fortran/61775
OK.
On Tue, Mar 13, 2018 at 6:18 PM, Marek Polacek wrote:
> On Tue, Mar 13, 2018 at 01:33:45PM -0400, Jason Merrill wrote:
>> On Tue, Mar 13, 2018 at 11:07 AM, Marek Polacek wrote:
>> > Here's another case of a template code leaking into cxx_constant_value.
>> > While I recently added the requir
On Tue, Mar 13, 2018 at 01:33:45PM -0400, Jason Merrill wrote:
> On Tue, Mar 13, 2018 at 11:07 AM, Marek Polacek wrote:
> > Here's another case of a template code leaking into cxx_constant_value.
> > While I recently added the require_rvalue_constant_expression check, it
> > doesn't help here, bec
This patch fixes ICE when statement expression used in old-style
function declaration parameter list. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30552
In c_parser_postfix_expression (), after seeing a left paren followed by
a left curly brace, in addition to checking for existing stateme
This is one more try to fix PR83712:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
The patch was successfully bootstrapped and tested on x86-64, i686,
and ppc64.
Committed as rev. 258504.
Index: ChangeLog
===
--- Chan
On 03/13/18 00:56, Andrew Sadek wrote:
Ok, so you mean with '-fPIC -mpic-data-text-relative' as I do in my test
case ?
If all is Ok, execution and compilation shall ideally pass for the test
cases.
Correct.
I want to make sure of two things:
-- Your patch doesn't break anything (i.e., cause
On Tue, Mar 13, 2018 at 04:19:21PM +0100, Martin Liška wrote:
> > Yes, see e.g. TARGET_LIBC_HAS_FUNCTION target hook,
> > where in particular linux_libc_has_function deals with various C libraries.
> > Of course, in this case you need another target hook, that is dependent both
> > on the target ba
Hi!
As mentioned in bugzilla, when e.g. sel-sched queries (indirectly) before reload
some attributes like get_attr_type that depend on alternatives, GCC attempts
to constrain the operands in non-strict mode, which implies that if
reg_class_for_constraint doesn't return NO_REGS, it is ok, otherwise
Hi!
If we return olddecl on an (invalid) builtin function redefinition rather
than redeclaration, we ICE shortly afterwards, because we assume we have
non-NULL DECL_INITIAL on whatever is returned (except for error_mark_node).
The following patch errors unconditionally for definitions of builtin
OK.
On Tue, Mar 13, 2018 at 4:17 PM, Jakub Jelinek wrote:
> Hi!
>
> If we return olddecl on an (invalid) builtin function redefinition rather
> than redeclaration, we ICE shortly afterwards, because we assume we have
> non-NULL DECL_INITIAL on whatever is returned (except for error_mark_node).
>
Hi!
The sanopt maybe_optimize_ubsan_ptr_ifn optimization behaves differently
on 32-bit and on 64-bit targets when using similar arguments maximum or
minimum of ptrdiff_t or values close to it.
The problem is that UHWI is 64-bit, regardless of whether addresses are
64-bit or 32-bit, so for 32-bit
Here, trying to evaluate the constraints of the test::visit template
led us to instantiating the generic lambda function; this ends up with
us trying to instantiate it with processing_template_decl still set.
A simple way to fix this case in GCC 8 is to not treat the lambda as a
nested function, b
On Tue, Mar 13, 2018 at 6:08 AM, Steve Kargl
wrote:
> On Mon, Mar 12, 2018 at 09:05:09PM +0200, Janne Blomqvist wrote:
>>
>> Yes, I understand that -fdefault-integer-8 (or whatever the equivalent
>> option was called on g77) is the original motivation. Like I said, I
>> don't have any particular o
The comment says that the parameter pack is being used in an
unevaluated context, but at the point where we're substituting the
pack, we aren't necessarily actually in that unevaluated context, so
let's set the flag here.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0999f196019abd26f2409f
In this testcase, we were crashing because we decided that the int&&
template parameter wasn't a valid argument for itself, which is wrong.
It's unclear to me that it is ever possible to instantiate a template
taking an rvalue ref parameter, but I guess we might as well handle it
properly.
Tested
Avoid issuing a bogus warning when the source of strncpy is bound by a
constant known to be less than the minimum size of the destination.
Changes from v1:
- Use range-info instead of the MIN_EXPR hack
- Get the minimum size of dst and check for NULL_TREE return
The patch bootstraps successfully
Thanks, committed.
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, Mar 13, 2018 at 11:07 AM, Marek Polacek wrote:
> Here's another case of a template code leaking into cxx_constant_value.
> While I recently added the require_rvalue_constant_expression check, it
> doesn't help here, because the problem is that we have a MODOP_EXPR (a
> template code), whos
Hi,
scan-assembler-times and scan-tree-dump-times dejagnu directives show a
different output in the summary files depending on whether they PASS or
FAIL. This means that dg-cmp-results would not show a regression because
it would not see a connection between the two output.
The difference comes
On 13 March 2018 at 15:55, Jean-Baptiste Daval wrote:
> Hi,
>
> Currently when a value is extracted from a stream into a unsigned type,
> there is no test to check if the value is negative, in which case there
> is an overflow and failbit is not set (the correct behavior would be to
> read a zero a
On 9 March 2018 at 00:41, Jonathan Wakely wrote:
> In order to meet the total order requirements of [comparisons] p2 we
> need to cast unrelated pointers to uintptr_t before comparing them.
> Those casts aren't allowed in constant expressions, so only cast
> when __builtin_constant_p says the resul
On Mon, Mar 12, 2018 at 08:02:39PM -0500, Aaron Sawdey wrote:
> Looking at CPU2017 results for different reassociation widths, things
> have shifted since I last looked at this with CPU2006 in early gcc7
> timeframe. Best thing to do seems to be to set reassociation width to 1
> for all integer mod
On Mon, 2018-03-12 at 14:44 +0100, Svante Signell wrote:
> On Mon, 2018-03-12 at 13:29 +0100, Svante Signell wrote:
>
>
> > The patches really changed are only four:
> > src_libgo_runtime.diff
> > src_libgo_go_go_build_syslist.go.diff
> > src_libgo_go_runtime.diff
> > src_libgo_build.diff
>
> Co
Hi,
Currently when a value is extracted from a stream into a unsigned type,
there is no test to check if the value is negative, in which case there
is an overflow and failbit is not set (the correct behavior would be to
read a zero and set failbit). This patch add a condition to check when
we are
It doesn't make sense to use an 'auto' parameter type outside of an
implicit template declaration; conveniently, default_arg_ok_p already
tracks whether we are in a suitable context.
As Jakub points out in the PR, this extension really shouldn't be
silently accepted, given that it still isn't part
Hi,
On Tue, 13 Mar 2018, Andreas Krebbel wrote:
> Leaving history aside don't you agree that it would have been more
> sensible to require a -m option only if you want to build for an ABI
> different from what is currently mandated by the personality setting?
I agree with you. But we can't le
While working to assure rs6000 documentation of built-in functions is
consistent with the implementation of built-in functions, I discovered
some apparent typographic errors in the definitions of the
ST_INTERNAL_4sf and ST_INTERNAL_2df built-in functions. As I endeavored
to fix these definitions a
On 03/12/2018 05:13 PM, Jeff Law wrote:
On 03/05/2018 01:54 PM, Martin Sebor wrote:
Attribute nonstring is currently only allowed on arrays and
pointers to plain char, but -Wstringop-truncation triggers
even for strncpy calls whose arguments are arrays of signed
or unsigned char (with or without
Ramana Radhakrishnan writes:
> I am pleased to announced that the GCC Steering Committee has
> appointed Richard Sandiford as SVE maintainer in the AArch64 port.
>
> Please join me in congratulating Richard on his additional role.
>
> Richard, please update your listing in the MAINTAINERS file.
T
On 03/13/2018 09:32 AM, Jakub Jelinek wrote:
On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote:
On 03/12/2018 10:39 AM, Marc Glisse wrote:
On Mon, 12 Mar 2018, Martin Liška wrote:
This is fix for the PR that introduces a new target macro. Using the macro
one can say that a target h
Here's another case of a template code leaking into cxx_constant_value.
While I recently added the require_rvalue_constant_expression check, it
doesn't help here, because the problem is that we have a MODOP_EXPR (a
template code), whose op1 is a TRUNC_DIV_EXPR without a type, so it's
considered dep
This should fix the endless PRE antic iterations for good. OK, it's
somewhat of a hack but unless I fix another two or three parts of the
antic algorithm to not prune values that may later re-appear I see
no other way to guarantee this. And this isn't the time to fiddle
with PRE further...
Boot
Jakub commented here that
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01325.html we don't turn
on fasynchronous-unwind-tables for AArch64. I note that x86_64 turns on
funwind-tables as well. Thus this patch turns on both.
Note that this doesn't increase code size but will likely increase
binary
On Tue, Mar 13, 2018 at 04:59:58AM -0700, H.J. Lu wrote:
> >> The testcase still ICEs on i686-linux (preexisting bug, ICEs the same
> >> without this patch or even before the previous patch), will handle that
> >> tomorrow.
> I got:
See the above?
Or do you get this with -m64 too, rather than -m3
Hi.
This fixed issue where we have an ifunc function called from another ifunc
function.
One needs to properly make a reference redirection.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
MVC tests on x86_64 also work fine.
Ready for trunk?
Thanks,
Martin
gcc/Chang
On 03/10/2018 07:28 PM, H.J. Lu wrote:
On Wed, Mar 7, 2018 at 1:41 AM, Martin Liška wrote:
Hi.
Sending GCC 6 branch backports.
Patches can bootstrap on ppc64le-redhat-linux and survives regression tests.
I'm going to install the patches.
Martin
I am going to backport:
Thank you for the pa
Hi.
This is a fix for situation where we use -fno-guess-branch-probability and
fnsplit happens.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2018-03-13 Martin Liska
PR ipa/84825
* predict.c (rebu
On Tue, Mar 13, 2018 at 5:02 AM, Jakub Jelinek wrote:
> On Tue, Mar 13, 2018 at 04:59:58AM -0700, H.J. Lu wrote:
>> >> The testcase still ICEs on i686-linux (preexisting bug, ICEs the same
>> >> without this patch or even before the previous patch), will handle that
>> >> tomorrow.
>
>> I got:
>
>
On Tue, Mar 13, 2018 at 12:55 AM, Uros Bizjak wrote:
> On Mon, Mar 12, 2018 at 10:10 PM, Jakub Jelinek wrote:
>> Hi!
>>
>> As Martin reported, the same testcase added recently ICEs differently
>> with different options on x86_64-linux, the problem is that we
>> sometimes emit insns before a CODE_
On Tue, Mar 13, 2018 at 9:32 AM, Jakub Jelinek wrote:
> On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote:
>> On 03/12/2018 10:39 AM, Marc Glisse wrote:
>> > On Mon, 12 Mar 2018, Martin Liška wrote:
>> >
>> > > This is fix for the PR that introduces a new target macro. Using the
>> > >
On 03/12/2018 06:50 PM, Jakub Jelinek wrote:
> On Mon, Mar 12, 2018 at 06:42:15PM +0100, Andreas Krebbel wrote:
>> On 03/12/2018 06:31 PM, Jakub Jelinek wrote:
>>> On Mon, Mar 12, 2018 at 06:28:09PM +0100, Andreas Krebbel wrote:
Currently the default ABI option for a GCC built on a 64 bit syst
On Tue, Mar 13, 2018 at 12:06 AM, Eric Botcazou wrote:
> Hi,
>
> this is an ICE in LTO mode on code violating the ODR rule: get_odr_type checks
> that there is a sensible internal order between base, type and derived types
> but this can be easily messed up by incomplete types. Hence the attached
On Monday 12 March 2018 03:26 PM, Richard Biener wrote:
> Please use tree_int_cst_lt (rhs1, dstsize) instead.
>
>> + {
>> + gimple_set_no_warning (stmt, true);
>
> Why this? There's only a single bit -- where do we warn from if you
> don't do this here?
I incorrectly thoug
Hi!
Since r237074 the 387 rounding insns are guarded with
(flag_fp_int_builtin_inexact || !flag_trapping_math), and the
round2 expander is enabled for 387 fancy math whenever
flag_unsafe_math_optimizations; as the testcase shows, the latter
doesn't imply the former, so this patch adds another guar
On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote:
> On 03/12/2018 10:39 AM, Marc Glisse wrote:
> > On Mon, 12 Mar 2018, Martin Liška wrote:
> >
> > > This is fix for the PR that introduces a new target macro. Using the macro
> > > one can say that a target has a fast mempcpy and thus i
On 03/12/2018 10:39 AM, Marc Glisse wrote:
On Mon, 12 Mar 2018, Martin Liška wrote:
This is fix for the PR that introduces a new target macro. Using the macro
one can say that a target has a fast mempcpy and thus it's preferred to be used
if possible.
Patch can bootstrap on ppc64le-redhat-linu
Hi.
When having a weak alias that points to a multi-versioning function, one
needs to redirect the alias properly.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2018-03-12 Martin Liska
PR ipa/84722
On 03/12/2018 11:06 AM, Richard Biener wrote:
On Mon, Mar 12, 2018 at 9:42 AM, Martin Liška wrote:
Hi.
This is what I was recommended in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658#c18.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
On Mon, 12 Mar 2018, Aaron Sawdey wrote:
> Looking at CPU2017 results for different reassociation widths, things
> have shifted since I last looked at this with CPU2006 in early gcc7
> timeframe. Best thing to do seems to be to set reassociation width to 1
> for all integer modes, which is what th
On Mon, 12 Mar 2018, Jakub Jelinek wrote:
> Hi!
>
> The following two match.pd spots assume that integer_pow2p will return
> true only for INTEGER_CSTs (it uses wi::to_wide on it), but as the testcase
> shows, that is not always the case, we can get there with COMPLEX_CSTs.
>
> Fixed by requirin
On Mon, 12 Mar 2018, Jakub Jelinek wrote:
> Hi!
>
> I thought the vregs pass is the first one to analyze constraints,
> but I was wrong, already before that parse_{output,input}_constraint
> are called, already during GIMPLE passes. They don't really fail miserably
> if , appears in the middle o
Ok, so you mean with '-fPIC -mpic-data-text-relative' as I do in my test
case ?
If all is Ok, execution and compilation shall ideally pass for the test
cases.
But I have noticed that there are some output pattern checks done in some
test cases and this may fail since the output assembly is differen
On Mon, Mar 12, 2018 at 10:10 PM, Jakub Jelinek wrote:
> Hi!
>
> As Martin reported, the same testcase added recently ICEs differently
> with different options on x86_64-linux, the problem is that we
> sometimes emit insns before a CODE_LABEL of the next bb rather than after
> the last insn in the
On Mon, Mar 12, 2018 at 9:52 PM, Jakub Jelinek wrote:
> Hi!
>
> For TARGET_AVX512F && !TARGET_AVX512VL, the RA ensures that
> 128-bit and 256-bit vectors aren't allocated in %xmm16+ registers,
> but not so for scalar modes. In that case we use avx512vl isa attribute,
> or TARGET_AVX512VL guards,
On Mon, Mar 12, 2018 at 10:14 PM, Jakub Jelinek wrote:
> Hi!
>
> Since r237074 the 387 rounding insns are guarded with
> (flag_fp_int_builtin_inexact || !flag_trapping_math), and the
> round2 expander is enabled for 387 fancy math whenever
> flag_unsafe_math_optimizations; as the testcase shows, t
Fixed invoke.texi. Here is the new version.
gcc/
* config.gcc (icelake-client, icelake-server): New.
(icelake): Remove.
* config/i386/i386.c (initial_ix86_tune_features): Extend to 64 bit.
(initial_ix86_arch_features): Ditto.
(ix86_option_override_internal):
62 matches
Mail list logo
