On March 20, 2018 7:32:46 AM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>We use incorrect type for the NULL return value, the builtin is
>char *strpbrk (const char *, const char *), so the first argument
>is cast to const char * and we return (const char *) 0, while we
>really should return (char *) 0
Hi!
We use incorrect type for the NULL return value, the builtin is
char *strpbrk (const char *, const char *), so the first argument
is cast to const char * and we return (const char *) 0, while we
really should return (char *) 0. fold_builtin_n then adds:
ret = build1 (NOP_EXPR, TREE_TYPE
Hi!
In this code, both bitpos and bitsize are poly_int64, but we know that
bitpos is >= 0 and bitsize. On the testcase mentioned in the PR (but even
without -mavx512f, so we already invoke it during testing) we would overflow
the computation, 0x7ffsomething + 0x20 (and then cast i
On 3/12/18 1:55 PM, Segher Boessenkool wrote:
> On Sun, Mar 11, 2018 at 10:23:02AM -0500, Peter Bergner wrote:
>> +; The following patterns embody what lvx should usually look like.
>> +(define_expand "altivec_lvx_"
>> + [(set (match_operand:VM2 0 "register_operand" "")
>> +(match_operand:VM2
The -Wclass-memaccess warning makes an exception for ctors and
dtors of non-trivial classes with no bases to avoid triggering
for uses of raw memory functions with this as the destination.
All other members as well as non-members trigger the warning.
In bug 84850 the reporter shows that some code
Also check the { dg-skip-if } directive.
https://gcc.gnu.org/onlinedocs/gccint/Directives.html
On 03/19/2018 06:14 PM, Michael Eager wrote:
Hi Andrew --
Please take a look at the test case description:
https://gcc.gnu.org/wiki/HowToPrepareATestcase
and see if you can do one of the following:
Hi Andrew --
Please take a look at the test case description:
https://gcc.gnu.org/wiki/HowToPrepareATestcase
and see if you can do one of the following:
- Modify the regex expression in the scan-assembler to accept
either format of generated output
or
- Add { dg-option } directives to tur
The attached patch fixes an accepts-invalid while enforcing
C1560 (R1530) If RESULT appears, the function-name shall not appear
in any specification statement in the scoping unit of the function
subprogram.
Regression tested on x86_64-*-freebsd. OK to commit?
2018-03-19 Steven G. Kargl
Hi Honza,
thanks for putting this together. Below you'll find a number of
simple suggestions. This patch is fine if you make those changes;
no need to review again, though posting the final patch would be
good.
On Mon, 19 Mar 2018, Jan Hubicka wrote:
> +Reworked runtime estimation metrics
Richard Biener writes:
> On Sat, Mar 17, 2018 at 11:45 AM, Richard Sandiford
> wrote:
>> Index: gcc/tree-data-ref.c
>> ===
>> --- gcc/tree-data-ref.c 2018-02-14 13:14:36.268006810 +
>> +++ gcc/tree-data-ref.c 2018-03-17 10:43:42.
Hi,
this patch adds some documentation for what is new in IPA and x86.
For lto we should mention early-debug. Richard, perhaps you can suggest
wording?
Honza
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.ht
On March 19, 2018 9:05:23 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>In this code, both bitpos and bitsize are poly_int64, but we know that
>bitpos is >= 0 and bitsize. On the testcase mentioned in the PR (but
>even
>without -mavx512f, so we already invoke it during testing) we would
>overflow
>t
Hi,
On Mon, 19 Mar 2018, Jakub Jelinek wrote:
> > Blaeh. Note that "1p" is actually invalid:
> >
> > --
> > `0', `1', `2', ... `9'
> > An operand that matches the specified operand number is allowed.
> > If a digit is used together with letters within the same
> > alt
Hi!
As mentioned in the PR, libsanitizer cheats and attempts to call
@GLIBC_PRIVATE functions which are reserved to glibc and can change
anytime. They have changed on i?86 in particular in glibc 2.27, where
internal_function attribute has been dropped, so the functions for some
reason sadly aren'
On March 19, 2018 8:39:20 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>The enum memmodel doesn't declare the target specific enumerators,
>which are just defines in i386.h, but as those are above any
>enumerators in the generic enum, it is strictly speaking UB when
>values with that enum memmodel ty
Hi!
The inline-asm here has "1p" constraint and we end up with
(plus (frame) (const_int ...))
as input; even when the matching output is a REG, I'm not really
sure emit_move_insn can handle arbitrary expressions (consider e.g.
"1X" constraint), and calling reg_overlap_mentioned_p on something othe
On Mon, Mar 19, 2018 at 08:09:00PM +, Michael Matz wrote:
> Hi,
>
> On Mon, 19 Mar 2018, Jakub Jelinek wrote:
>
> > The inline-asm here has "1p" constraint and we end up with
> > (plus (frame) (const_int ...))
>
> Blaeh. Note that "1p" is actually invalid:
>
> --
> `0', `1', `2
On Mon, Mar 19, 2018 at 07:28:11PM +0300, Maxim Ostapenko wrote:
> Yes, it works, attaching the patch.
Can you please add a short comment why we do this? Also, the testcase
needs work, see below. Ok for trunk with those changes and after a
while for affected release branches as well.
Thanks.
>
On March 19, 2018 8:57:22 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>As mentioned in the PR, libsanitizer cheats and attempts to call
>@GLIBC_PRIVATE functions which are reserved to glibc and can change
>anytime. They have changed on i?86 in particular in glibc 2.27, where
>internal_function attr
On March 19, 2018 9:01:53 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>When Maxim posted his patch today, I had a look and found that we emit
>these indirect constants into .data sections, even when they always
>contain
>just some pointer that needs relocation, but shouldn't be changed
>afterwards;
Hi,
On Mon, 19 Mar 2018, Jakub Jelinek wrote:
> The inline-asm here has "1p" constraint and we end up with
> (plus (frame) (const_int ...))
Blaeh. Note that "1p" is actually invalid:
--
`0', `1', `2', ... `9'
An operand that matches the specified operand number is allowed.
Hi Andrew --
Good work.
Please submit your updated patch. Check that you follow
GNU coding standards. Also make sure that the new options
are documented in gcc/doc/invoke.texi.
On 03/18/18 03:27, Andrew Sadek wrote:
Hello Michael,
I have run the test using the new PIC options.
Actually, I h
Hi!
When Maxim posted his patch today, I had a look and found that we emit
these indirect constants into .data sections, even when they always contain
just some pointer that needs relocation, but shouldn't be changed
afterwards; after all, the indirect constants have TREE_READONLY set.
The proble
Here we set "lost" and then returned error_mark_node without ever
actually giving an error, because the comment that !arg only occurred
with a previous error was wrong (and lacked an assert (seen_error())).
We already had code for dealing with the case of fixed packs and too
many arguments, but no
Hi!
We instantiate FIX_TRUNC_EXPR using cp_build_unary_op, but that function
doesn't look like a good match for this tree, what it really does for it is:
1) handle error_operand_p
2) on ia64 only diagnose __fpreg uses (I believe a cast of __fpreg to int is
fine, so we shouldn't warn)
3) and the
Hi!
The enum memmodel doesn't declare the target specific enumerators,
which are just defines in i386.h, but as those are above any
enumerators in the generic enum, it is strictly speaking UB when
values with that enum memmodel type have the higher target dependent bits
set. This patch just makes
Hi!
As mentioned in the PR, this is another case where we've run into too many
separate feature bits issues on x86. unfortunately in this case it affects
ABI. __cpu_model variable contains just 32 bits for the features, and we
now need 4 extra features that won't fit in there. The current code j
OK.
On Mon, Mar 19, 2018 at 7:55 AM, Marek Polacek wrote:
> Seems like with this testcase we end up in a scenario where, when counting the
> lambda count in enclosing_instantiation_of, we arrive at decl_function_context
> being null, so checking DECL_TEMPLATE_INFO then crashes. It appears that j
Hi
On 19/03/18 14:29, James Greenhalgh wrote:
On Fri, Dec 15, 2017 at 11:57:46AM +, Sudi Das wrote:
Hi
This patch fixes the inconsistent behavior observed at -O3 for the
unordered comparisons. According to the online docs
(https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gccint/Unary-and-Binary-Ex
In an extern "C" region the lambda member fns were getting C linkage.
and triggering an assert I added. I'm not sure why just the generic
case was being triggered, but the fix is to just force the language to
be C++ -- this is what we do in finish_member_declaration.
We were also not copying
OK.
On Mon, Mar 19, 2018 at 2:22 PM, Marek Polacek wrote:
> This nice test crashes in verify_constructor_flags because while the
> constructor as a whole is TREE_CONSTANT, one of its elements is not.
>
> We wound up in this situation because when we first get to
> cxx_eval_bare_aggregate, ctx->ct
This nice test crashes in verify_constructor_flags because while the
constructor as a whole is TREE_CONSTANT, one of its elements is not.
We wound up in this situation because when we first get to
cxx_eval_bare_aggregate, ctx->ctor is "{}", which is TREE_CONSTANT, while T is
"{.r=(int &) &j, .i=*(
This fixes the RISC-V bootstrap failure, based on a suggestion/question from
Serge Belyshev asking why the patch wasn't using PREFERRED_STACK_BOUNDARY,
which turns out to be a good solution. So the patch renames STACK_BOUNDARY to
PREFERRED_STACK_BOUNDARY, and renames MIN_STACK_BOUNDARY to STACK_BO
On 03/19/2018 10:02 AM, Tom de Vries wrote:
> On 03/19/2018 03:55 PM, Cesar Philippidis wrote:
>>> Note that this changes ordering of the vector-neutering jump and
>>> worker-neutering jump at the end. In principle, this should not be
>>> harmful, but it violates the invariant that vector-neutering
Hi Richard.
As discussed in the PR, the problem here is that we have two different
iterations of an IV live outside of a loop. This inhibits us from using
autoinc/dec addressing on ARM, and causes extra lea's on x86.
An abbreviated example is this:
loop:
# p_9 = PHI
p_20 = p_9 + 184467
On Mon, Mar 19, 2018 at 10:00 AM, H.J. Lu wrote:
> On Thu, Mar 15, 2018 at 1:00 PM, H.J. Lu wrote:
>> On Thu, Mar 15, 2018 at 12:54 PM, Jan Hubicka wrote:
On Thu, Mar 15, 2018 at 10:47 AM, Jan Hubicka wrote:
>> On Thu, Mar 15, 2018 at 9:03 AM, Jan Hubicka wrote:
>> >> > What is
On 03/19/2018 03:55 PM, Cesar Philippidis wrote:
Note that this changes ordering of the vector-neutering jump and
worker-neutering jump at the end. In principle, this should not be
harmful, but it violates the invariant that vector-neutering
branch-around code should be as short-lived as possible
On 03/19/2018 07:35 PM, Jakub Jelinek wrote:
On Mon, Mar 19, 2018 at 07:28:11PM +0300, Maxim Ostapenko wrote:
Yes, it works, attaching the patch.
Can you please add a short comment why we do this? Also, the testcase
needs work, see below. Ok for trunk with those changes and after a
while for
On Mon, Mar 19, 2018 at 06:44:39PM +0300, Maxim Ostapenko wrote:
> as noted in bugzilla, ASan inserts redzones for `.LDFCM*' variables and
> breaks internal ABI between GCC and libstdc++ because libstdc++ tries to
> obtain a pointer to `typeinfo for (anonymous namespace)::SomeRandomType'
> from a
On 03/19/2018 06:55 PM, Jakub Jelinek wrote:
On Mon, Mar 19, 2018 at 06:44:39PM +0300, Maxim Ostapenko wrote:
as noted in bugzilla, ASan inserts redzones for `.LDFCM*' variables and
breaks internal ABI between GCC and libstdc++ because libstdc++ tries to
obtain a pointer to `typeinfo for (anony
Hi,
as noted in bugzilla, ASan inserts redzones for `.LDFCM*' variables and
breaks internal ABI between GCC and libstdc++ because libstdc++ tries to
obtain a pointer to `typeinfo for (anonymous namespace)::SomeRandomType'
from a constant offset from `.LDFCM*' labels and hits these redzones.
On 03/19/2018 03:55 PM, Cesar Philippidis wrote:
Is your patch purely for debugging, or are you planning on committing it
to og7 and trunk?
I plan to commit it.
We have no test-cases testing the neutering code order explicitly. So
this check is the only thing that allows us to detect regressi
On 03/19/2018 07:04 AM, Tom de Vries wrote:
> On 03/09/2018 05:55 PM, Cesar Philippidis wrote:
>> On 03/09/2018 08:21 AM, Tom de Vries wrote:
>>> On 03/09/2018 12:31 AM, Cesar Philippidis wrote:
Nvidia Volta GPUs now support warp-level synchronization.
>>>
>>> Well, let's try to make that stat
On Sat, Mar 17, 2018 at 11:45 AM, Richard Sandiford
wrote:
> This PR is another regression caused by the removal of the simple_iv
> check in dr_analyze_innermost for BB analysis. Without splitting out
> the step, we weren't able to find an underlying object whose alignment
> could be increased.
>
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-8.1-b20180128.sv.po',
On Fri, Dec 15, 2017 at 11:57:46AM +, Sudi Das wrote:
> Hi
>
> This patch fixes the inconsistent behavior observed at -O3 for the
> unordered comparisons. According to the online docs
> (https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gccint/Unary-and-Binary-Expressions.html),
>
> all of the foll
On 03/09/2018 05:55 PM, Cesar Philippidis wrote:
On 03/09/2018 08:21 AM, Tom de Vries wrote:
On 03/09/2018 12:31 AM, Cesar Philippidis wrote:
Nvidia Volta GPUs now support warp-level synchronization.
Well, let's try to make that statement a bit more precise.
All Nvidia architectures have sup
This bug happens when the machinery to check for an implicit extern "C"
linkage on a local declaration, meets an ambiguous local lookup. I was
misled by a comment that implied TREE_LIST -> overload. That was true
way back, but now means ambiguous lookup.
I declined the opportunity to micro-o
The following fixes PR84933 without really tackling the underlying
issue of having out-of-bound ranges in the lattice (out-of-bound
with respect to TYPE_MIN/MAX_VALUE) which is not sth I'd like to
resolve at this point. It simply avoids the bogus transform
in set_and_canonicalize_value_range that
On Mon, Mar 19, 2018 at 08:19:18AM -0500, Bill Schmidt wrote:
> > Requiring power8 for it is weird and surprising. power8-vector doubly so.
> >
> > It does not seem to be a good idea to only enable the builtin for cases
> > where the current implementation is not broken.
> >
> > (The issue is th
> On Mar 19, 2018, at 8:19 AM, Bill Schmidt wrote:
>
> On Mar 16, 2018, at 5:51 PM, Segher Boessenkool
> wrote:
>>
>> Hi Carl,
>>
>> On Wed, Mar 14, 2018 at 08:27:08AM -0700, Carl Love wrote:
>>> The following patch fixes an ICE when compiling the test case
>>>
>>> gcc -mcpu=power7 builtin-
On Mar 16, 2018, at 5:51 PM, Segher Boessenkool
wrote:
>
> Hi Carl,
>
> On Wed, Mar 14, 2018 at 08:27:08AM -0700, Carl Love wrote:
>> The following patch fixes an ICE when compiling the test case
>>
>> gcc -mcpu=power7 builtin-fctid-fctiw-runnable.c
>>
>> The GCC compiler now gives a message
This fixes PR84929. analyze_siv_subscript_cst_affine chrec_convert()s
chrec_b but doesn't handle the case of that simply wrapping a NOP
around the CHREC.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-03-19 Richard Biener
PR tree-optimization/84929
On Wed, Mar 14, 2018 at 05:40:49PM +, Sudi Das wrote:
> Hi
>
> This patch is another partial fix for PR 84521. This is adding a
> definition to one of the target hooks used in the SJLJ implemetation so
> that AArch64 defines the hard_frame_pointer_rtx as the
> TARGET_BUILTIN_SETJMP_FRAME_VA
On Tue, Mar 13, 2018 at 01:35:56PM +, Ramana Radhakrishnan wrote:
> 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 bot
On Fri, Mar 16, 2018 at 03:08:17PM +0100, Richard Biener wrote:
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok?
Ok, thanks.
Jakub
Seems like with this testcase we end up in a scenario where, when counting the
lambda count in enclosing_instantiation_of, we arrive at decl_function_context
being null, so checking DECL_TEMPLATE_INFO then crashes. It appears that just
the following does the right thing, but I'm not too sure about
On Fri, 16 Mar 2018, Tom de Vries wrote:
> On 03/16/2018 12:55 PM, Richard Biener wrote:
> > On Fri, 16 Mar 2018, Tom de Vries wrote:
> >
> > > On 02/27/2018 01:42 PM, Richard Biener wrote:
> > > > Index: gcc/testsuite/gcc.dg/tree-ssa/pr84512.c
> > > >
Sending to list
Thu 03/19/2018 08:48, Tamar Christina wrote:
> Hi Christophe,
>
> The 03/16/2018 13:50, Christophe Lyon wrote:
> > On 15 March 2018 at 11:19, Kyrill Tkachov
> > wrote:
> > > Hi Tamar,
> > >
> > >
> > >> Regtested on armeb-none-eabi and no regressions.
> > >> Bootstrapped on arm
59 matches
Mail list logo
