On Thu, Mar 14, 2019 at 1:28 AM Jakub Jelinek wrote:
>
> On Tue, Mar 12, 2019 at 09:36:32AM +0800, H.J. Lu wrote:
> > PR target/89650
> > * config/i386/i386.c (remove_partial_avx_dependency): Handle
> > REG_EH_REGION note.
> >
> > gcc/testsuite/
> >
> > PR target/89650
> >
Ok. Got it. And I will add some cases.
Thanks,
Feng
From: Kyrill Tkachov
Sent: Wednesday, March 13, 2019 5:40:37 PM
To: Feng Xue OS; Richard Biener
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Loop split upon semi-invariant condition (PR
On 3/13/19 6:37 PM, Jakub Jelinek wrote:
Hi!
When a variable template (both static data member of some class or at
namespace level) is accessed without template arguments,
finish_id_expression_1 handles it through:
/* If we didn't find anything, or what we found was a type,
then this
On 3/13/19 6:20 PM, Jakub Jelinek wrote:
On Mon, Mar 11, 2019 at 11:21:00PM +0100, Jakub Jelinek wrote:
The following testcase ICEs since my recent cxx_eval_loop_expr changes.
The problem is that the Forget saved values of SAVE_EXPRs. inside of the
loop can remove SAVE_EXPRs from new_ctx.values
PR 89688 points out a bogus warning about an unterminated
character array argument to strlen. The root cause is
an oversight in the transformation of braced initializer lists
to STRING_CSTs where the solution implemented last summer only
considers one-dimensional arrays and skips more complex
On 3/13/19 10:08 PM, Jason Merrill wrote:
On 3/11/19 6:21 PM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs since my recent cxx_eval_loop_expr changes.
The problem is that the Forget saved values of SAVE_EXPRs. inside of the
loop can remove SAVE_EXPRs from new_ctx.values and if that is
On 3/11/19 6:21 PM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs since my recent cxx_eval_loop_expr changes.
The problem is that the Forget saved values of SAVE_EXPRs. inside of the
loop can remove SAVE_EXPRs from new_ctx.values and if that is the last
iteration, we can also do the loop
On Wed, 13 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> The C FE sadly passes through some really bad prototypes of builtin
> functions as "harmless":
> /* Accept "harmless" mismatches in function types such
> as missing qualifiers or pointer vs same size integer
>
Hi Kelvin,
On Wed, Mar 13, 2019 at 04:43:35PM -0500, Kelvin Nilsen wrote:
[ snip ]
This looks great, thanks! Okay for trunk. A few more comments, do
with it as you like:
> (altivec_expand_vec_ext_builtin): Use modular arithmetic to
> computer index.
s/computer/compute/
> @@
This is an overlooked case in C++17 mandatory copy elision: We want overload
resolution to reflect that initializing an object from a prvalue does not
involve a copy or move constructor even when [over.match.ctor] says that
only constructors are candidates. Here I implement that by looking
On Thu, Mar 14, 2019 at 12:18:08AM +0100, Thomas Koenig wrote:
> Am 13.03.19 um 23:55 schrieb Steve Kargl:
> > On Wed, Mar 13, 2019 at 11:48:12PM +0100, Thomas Koenig wrote:
> >> Hello world,
> >>
> >> this doc patch adds the Q edit descriptor to the non-implemented
> >> extension list. Tested
Am 13.03.19 um 23:55 schrieb Steve Kargl:
On Wed, Mar 13, 2019 at 11:48:12PM +0100, Thomas Koenig wrote:
Hello world,
this doc patch adds the Q edit descriptor to the non-implemented
extension list. Tested with "make dvi", "make pdf" and "make info".
Suggestions? OK for trunk?
How about
On Wed, Mar 13, 2019 at 11:48:12PM +0100, Thomas Koenig wrote:
> Hello world,
>
> this doc patch adds the Q edit descriptor to the non-implemented
> extension list. Tested with "make dvi", "make pdf" and "make info".
>
> Suggestions? OK for trunk?
How about asttaching the patch? :-)
In all
Hello world,
this doc patch adds the Q edit descriptor to the non-implemented
extension list. Tested with "make dvi", "make pdf" and "make info".
Suggestions? OK for trunk?
Regards
Thomas
Hi!
The C FE sadly passes through some really bad prototypes of builtin
functions as "harmless":
/* Accept "harmless" mismatches in function types such
as missing qualifiers or pointer vs same size integer
mismatches. This is for the ffs and fprintf builtins.
Hi!
When a variable template (both static data member of some class or at
namespace level) is accessed without template arguments,
finish_id_expression_1 handles it through:
/* If we didn't find anything, or what we found was a type,
then this wasn't really an id-expression. */
if
On Wed, 13 Mar 2019, Richard Biener wrote:
> And that fortran support patch would need yet another iteration.
Fortran never uses the _finite names because it never uses the C header
that can declare the functions to use those asm names.
--
Joseph S. Myers
jos...@codesourcery.com
Hi!
create_dispatcher_calls iterates over ipa_ref *s referring the current node
and wants to remove them all and create new ones. The problem is
that if there are any ipa_ref objects where two or more of them are from the
same cgraph node to the current node (in the testcases there are both
On Mon, Mar 11, 2019 at 11:21:00PM +0100, Jakub Jelinek wrote:
> The following testcase ICEs since my recent cxx_eval_loop_expr changes.
> The problem is that the Forget saved values of SAVE_EXPRs. inside of the
> loop can remove SAVE_EXPRs from new_ctx.values and if that is the last
> iteration,
Am 13.03.19 um 18:50 schrieb Thomas Schwinge:
There are many ways to deal with it without bumping MOD_VERSION in a
backwards but not forwards compatible way, so that a newer compiler will be
able to parse old *.mod files, and newer compiler new ones as long as this
problematic stuff doesn't
An initial draft patch was distributed on 3/8/19. Thanks Segher for careful
review and detailed feedback. This second draft patch differs from the first
in the following regards:
1. Simplified dg directives in the new tests cases:
a) Removed { target { powerpc*-*-* } } from dg-do run
Committed as r269664.
Thanks for the review!
Harald
On 03/13/19 01:41, Steve Kargl wrote:
> On Sun, Mar 10, 2019 at 10:19:03PM +0100, Harald Anlauf wrote:
>> The code in the testcase died due to a run-time bounds-check
>> generated slightly too early, leading to a crash for deferred
>>
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 269662 to trunk and as rev. 269663 to gcc-8-branch.
Index: ChangeLog
On Wed, Mar 13, 2019 at 11:39 AM Andrew Burgess
wrote:
> gcc/ChangeLog:
>
> PR target/89627
> * config/riscv/riscv.c (riscv_pass_fpr_single): Add offset
> parameter, and make use of it.
> (riscv_get_arg_info): Pass offset to riscv_pass_fpr_single.
>
>
On Wed, Mar 13, 2019 at 11:53 AM Andrew Pinski wrote:
> This testcase seems generic, that is it has no ABI dependent values
> attached to it.
> Can it be moved to a more generic location instead? Maybe there are
> other targets which get this incorrect also.
I'm not aware of any other target
On 3/11/19 6:56 PM, Marek Polacek wrote:
My recent patch caused us to call convert_for_initialization for a std:move's
argument to see if it would have succeeded had the returned expression been
just that argument.
That caused a bogus error in this test, because convert_for_initialization
might
I have just committed the updated patch to trunk as r269658. If anyone
thinks this should be backported to 8-branch, please let me know.
Cheers,
Janus
Am Di., 12. März 2019 um 13:00 Uhr schrieb Janus Weil :
>
> Hi Steve,
>
> > > Technically the ICE is a regression, but since it happens on
On 3/12/19 7:51 AM, Jakub Jelinek wrote:
On Mon, Mar 04, 2019 at 11:35:50PM +0100, Jakub Jelinek wrote:
2019-03-04 Jakub Jelinek
PR debug/89498
* dwarf2out.c (size_of_die): For dw_val_class_view_list always use
DWARF_OFFSET_SIZE.
(value_format): For
On 3/13/19 3:32 PM, Marek Polacek wrote:
On Wed, Mar 13, 2019 at 02:15:25PM -0400, Jason Merrill wrote:
On 3/12/19 5:42 PM, Marek Polacek wrote:
On Tue, Mar 12, 2019 at 04:07:56PM -0400, Jason Merrill wrote:
On 3/12/19 3:59 PM, Marek Polacek wrote:
As Barry explained in the PR, lambda
On Wed, Mar 13, 2019 at 02:15:25PM -0400, Jason Merrill wrote:
> On 3/12/19 5:42 PM, Marek Polacek wrote:
> > On Tue, Mar 12, 2019 at 04:07:56PM -0400, Jason Merrill wrote:
> > > On 3/12/19 3:59 PM, Marek Polacek wrote:
> > > > As Barry explained in the PR, lambda capture is one of
> > > >
> > >
On Wed, Mar 13, 2019 at 11:40 AM Andrew Burgess
wrote:
>
> Jim,
>
> Sorry for the delay in sending this patch.
>
> Thanks,
> Andrew
>
> ---
>
> This fixes PR target/89627.
>
> The RISC-V ABI document[1] says:
>
>For the purposes of this section, "struct" refers to a C struct
>with its
Jim,
Sorry for the delay in sending this patch.
Thanks,
Andrew
---
This fixes PR target/89627.
The RISC-V ABI document[1] says:
For the purposes of this section, "struct" refers to a C struct
with its hierarchy flattened, including any array fields. That is,
struct { struct { float
On Wed, Mar 13, 2019 at 02:32:36PM -0400, Jason Merrill wrote:
> On 3/13/19 1:25 PM, Marek Polacek wrote:
> > This PR points out that our P0634 implementation misses constructor
> > parameters
> > and still requires 'typename'. I'm not 100% sure if the standard really
> > says
> > we should
On 3/13/19 1:25 PM, Marek Polacek wrote:
This PR points out that our P0634 implementation misses constructor parameters
and still requires 'typename'. I'm not 100% sure if the standard really says
we should also handle constructors. Does a constructor have a function type?
Not that we can
On 3/12/19 5:42 PM, Marek Polacek wrote:
On Tue, Mar 12, 2019 at 04:07:56PM -0400, Jason Merrill wrote:
On 3/12/19 3:59 PM, Marek Polacek wrote:
As Barry explained in the PR, lambda capture is one of
simple-capture ...[opt]
...[opt] init-capture
where init-capture requires an
Hi!
On Thu, 28 Feb 2019 22:17:01 +0100, Jakub Jelinek wrote:
> On Thu, Feb 28, 2019 at 10:12:00PM +0100, Thomas Schwinge wrote:
> > On Wed, 15 Jun 2016 20:12:15 -0700, Cesar Philippidis
> > wrote:
> > The code changes now are actually very simple. The "problem" is that
> > we're incrementing
On Tue, Mar 12, 2019 at 09:36:32AM +0800, H.J. Lu wrote:
> PR target/89650
> * config/i386/i386.c (remove_partial_avx_dependency): Handle
> REG_EH_REGION note.
>
> gcc/testsuite/
>
> PR target/89650
> * g++.target/i386/pr89650.C: New test.
> ---
>
This PR points out that our P0634 implementation misses constructor parameters
and still requires 'typename'. I'm not 100% sure if the standard really says
we should also handle constructors. Does a constructor have a function type?
But I guess it makes sense, so this patch handles it. To
A recent change (r269633 AFAICS) introduced the constexpr keyword
into go which breaks bootstrap with a C++ 98 compiler. I fixed
it like this in my tree but haven't fully tested it. I just
thought I'd send a heads up before others run into it.
Martin
On Wed, 2019-03-13 at 14:38 +, Joseph Myers wrote:
>
> ---
> ---
> On Wed, 13 Mar 2019, Jakub Jelinek wrote:
>
> > If the finite only doesn't buy anything, then another option is to drop the
> > math-finite.h stuff or portions
On Wed, 13 Mar 2019, Jakub Jelinek wrote:
> If the finite only doesn't buy anything, then another option is to drop the
> math-finite.h stuff or portions thereof.
Well, finite-only entry points avoid wrappers for the scalar functions -
it's just that suitable optimized implementations could
I am testing the following with additional hunks in
tree-ssa-loop-ivcanon.c.
Bootstrap / regtest running on x86_64-unknown-linux-gnu (gcc-8-branch).
Richard.
2019-03-14 Richard Biener
PR middle-end/89572
* tree-scalar-evolution.c (get_loop_exit_condition): Use
Hi!
The following testcase is miscompiled on powerpc64le-linux.
As mentioned in the PR, the problem is with a REG_EQUAL note which
expand_mult_const attaches to:
(insn 17 16 18 2 (set (reg:SI 140)
(plus:SI (subreg:SI (reg:HI 138) 0)
(subreg:SI (reg:HI 136) 0)))
On Wed, Mar 13, 2019 at 02:07:29PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 13, 2019 at 01:00:58PM +, Joseph Myers wrote:
> > > Yeah, an alias doesn't really cost much, and has the advantage that if in
> > > the vector version you need at some point to differentiate between the
> > > finite
On Wed, Mar 13, 2019 at 01:00:58PM +, Joseph Myers wrote:
> > Yeah, an alias doesn't really cost much, and has the advantage that if in
> > the vector version you need at some point to differentiate between the
> > finite only vs. full implementations, you can just by tweaking libmvec
> >
On Wed, 13 Mar 2019, Jakub Jelinek wrote:
> Yeah, an alias doesn't really cost much, and has the advantage that if in
> the vector version you need at some point to differentiate between the
> finite only vs. full implementations, you can just by tweaking libmvec
> implementation, the callers
Hi Thomas,
I am not so convinced that "plain english" messages are the way to go,
even if they appear better readable at first sight, if conciseness is
lost. The main reason is that there three variants of the messages,
depending on context. One of them refers to expecting either a
On 3/13/19 12:07 PM, Richard Biener wrote:
On Wed, Mar 13, 2019 at 10:40 AM Kyrill Tkachov
wrote:
Hi Feng,
On 3/13/19 1:56 AM, Feng Xue OS wrote:
Richard,
Thanks for your comment. Yes, it is like kind of jump threading
with knowledge of loop structure. And what is rough time for GCC
On Wed, Mar 13, 2019 at 10:40 AM Kyrill Tkachov
wrote:
>
> Hi Feng,
>
> On 3/13/19 1:56 AM, Feng Xue OS wrote:
> > Richard,
> >
> > Thanks for your comment. Yes, it is like kind of jump threading
> > with knowledge of loop structure. And what is rough time for GCC 10?
> >
> >
>
> GCC 10 will
On Wed, Mar 13, 2019 at 01:01:54PM +0100, Richard Biener wrote:
> On Wed, Mar 13, 2019 at 12:40 AM Jakub Jelinek wrote:
> >
> > On Tue, Mar 12, 2019 at 11:21:26PM +, Steve Ellcey wrote:
> > > I like this idea. I have prototyped something, I created 'vector_asm'
> > > as an aarch64 attribute
On Wed, Mar 13, 2019 at 12:40 AM Jakub Jelinek wrote:
>
> On Tue, Mar 12, 2019 at 11:21:26PM +, Steve Ellcey wrote:
> > I like this idea. I have prototyped something, I created 'vector_asm'
> > as an aarch64 attribute because I couldn't find where to put global
> > attributes like __simd__.
On Tue, Mar 12, 2019 at 5:36 PM Martin Sebor wrote:
>
> On 3/12/19 2:20 AM, Richard Biener wrote:
> > On Mon, Mar 11, 2019 at 9:16 PM Martin Sebor wrote:
> >>
> >> A -Warray-bounds enhancement committed last year into GCC 9
> >> introduced an assumption that the MEM_REF type argument has
> >> a
Hi,
After also testing on the gcc-7 branch I committed a backport of r269499
including the testism fix 269596 to gcc-7 branch in r269647.
Cheers,
Andre
gcc/ChangeLog:
2019-03-13 Andre Vieira
Backport from mainline
2019-03-08 Andre Vieira
* config/arm/arm.h
Our beloved condition combining code to BIT_FIELD_REFs miscompiles
the testcase because it relies on operand_equal_p to detect equal
bases. For some reason that very same operand_equal_p is
treating any dereference of a pointer based on the same pointer
or decl the same - idependent on the
This fixes a missed optimization in the testcase in PR89698
where we fail to fold an access to a virtual table slot because
it is (int (*) ()) 0 - yes, an unfolded INTEGER_CST. Callers
are not happy with this so the following makes sure to
return a properly folded constant via
On Wed, Mar 13, 2019 at 12:21:15PM +0100, Eric Botcazou wrote:
> > So, when using the MemToShadow(addr) (1UL << 43) + ((addr << 12) >> (12 +
> > 3)) mapping, the first valid address above the hole will have shadow at:
> > 0x00020700UL (will not work, as it is inside of the VA hole)
> >
> So, when using the MemToShadow(addr) (1UL << 43) + ((addr << 12) >> (12 +
> 3)) mapping, the first valid address above the hole will have shadow at:
> 0x00020700UL (will not work, as it is inside of the VA hole)
> 0x0001f800UL (will not work, as it is inside of the VA hole)
>
> It actually is something that works with all the VA sizes that are
> supported.
Well, there were changes in the past that seem to indicate that this has not
always been true but, of course, the very specific VM layout on SPARC 64-bit
(apparently inherited from Solaris) makes things much more
On Wed, Mar 13, 2019 at 11:17:49AM +0100, Jakub Jelinek wrote:
> On Wed, Mar 13, 2019 at 10:58:41AM +0100, Eric Botcazou wrote:
> > > Is the size of the virtual address space hole constant though (and will it
> > > remain constant)?
> >
> > The kernel sources say that it's constant and with this
On Wed, Mar 13, 2019 at 10:58:41AM +0100, Eric Botcazou wrote:
> > Is the size of the virtual address space hole constant though (and will it
> > remain constant)?
>
> The kernel sources say that it's constant and with this position for SPARC-T4
> and later. It's different (larger hole) for
Greetings,
Please allow me to recommend ourselves IKSON Mould to you as the company
specializing in exporting all kinds of molds in the world.
We offer as followings:
-ALUMINUM DIE CASTING
-ZINC DIE CASTING
-CNC MACHINING
-TOOL & DIE
-INJECTION MOLDING
-PRODUCT DEVELOPMENT
If you are
> Is the size of the virtual address space hole constant though (and will it
> remain constant)?
The kernel sources say that it's constant and with this position for SPARC-T4
and later. It's different (larger hole) for SPARC-T3 and earlier but I cannot
really test. I don't think that it will
The following makes
int foo (int i)
{
int j = -1 + i;
return j + i;
}
-gimple dumps consumable by -fgimple without hand-editing the
non-obvious error.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-03-14 Richard Biener
* tree-pretty-print.c
The following makes SCEV not throw FP expressions at tree-affine
which really isn't prepared for that.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-03-13 Richard Biener
PR middle-end/89677
* tree-scalar-evolution.c (simplify_peeled_chrec): Do not
Hi Feng,
On 3/13/19 1:56 AM, Feng Xue OS wrote:
Richard,
Thanks for your comment. Yes, it is like kind of jump threading
with knowledge of loop structure. And what is rough time for GCC 10?
GCC 10 will be released once the number of P1 regressions gets down to
zero. Past experience
On Mon, Mar 11, 2019 at 11:29:39AM +0100, Eric Botcazou wrote:
> ASAN was enabled for the SPARC architecture during GCC 9 development but it
> doesn't really work on SPARC64/Linux because of the specific layout of the
> virtual memory address space. Fortunately this is (easily) fixable and the
This patch contains the bits required to make the AddressSanitizer work on
SPARC64/Linux (SPARC-T4 and later). It only affects the SPARC ports and has
been tested on SPARC/Solaris and SPARC64/Linux.
It merges r355980 of the LLVM repository. Installed on the mainline.
2019-03-13 Eric
This patch contains a fixlet for the AddressSanitizer on the SPARC with GCC,
which would otherwise generate a problematic call to the intercepted memcpy
routine. It only affects the SPARC ports and has been tested on SPARC/Solaris
and SPARC64/Linux.
It merges r355979 of the LLVM repository.
This patch contains the bits required to make the common 32-bit allocator work
on SPARC64/Linux. It only affects the SPARC ports and has been tested on
SPARC/Solaris and SPARC64/Linux.
It merges r355978 of the LLVM repository. Installed on the mainline.
2019-03-13 Eric Botcazou
This patch contains various fixes for the unwinding and backtrace machinery
on the SPARC, which doesn't work correctly in some cases. It only affects the
SPARC ports and has been tested on SPARC/Solaris and SPARC64/Linux.
It merges r355965 of the LLVM repository. Installed on the mainline.
On Wed, 13 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> This field seems to have been unused since it has been added 10 years ago,
> the patch had just some comments about it in the code, but even those are
> long gone now. https://gcc.gnu.org/ml/gcc-patches/2009-07/msg00514.html
>
> Can we remove
On Wed, 13 Mar 2019, Bin.Cheng wrote:
> On Wed, Mar 13, 2019 at 3:58 AM Richard Biener wrote:
> >
> >
> > This makes an attempt at fixing the most annoying parts of the GIMPLE
> > FE unit testing - the lack of proper CFG preservation and hoops you
> > need to jump through to make the CFG and SSA
Hi!
As the testcase shows (not really useful example of what simd functions
should be used for though), I forgot to adjust PHI arguments. They can
contain and if the parm is to be passed as vector, we want to replace
it with [iter_N]. That is not a valid gimple invariant though,
so we need to
Hi!
This field seems to have been unused since it has been added 10 years ago,
the patch had just some comments about it in the code, but even those are
long gone now. https://gcc.gnu.org/ml/gcc-patches/2009-07/msg00514.html
Can we remove it now and only add if we ever need it for something?
Hi Steve,
Regressoin-tested. OK for trunk?
Looks good to me.
Committed as r269635, with one correction: When checking with SVN, I
found that I had misnumbered the test cases - I have now committed
them as binding_label_tests_30.f90 to binding_label_tests_33.f90.
Thanks for the review!
On Wed, Mar 13, 2019 at 3:58 AM Richard Biener wrote:
>
>
> This makes an attempt at fixing the most annoying parts of the GIMPLE
> FE unit testing - the lack of proper CFG preservation and hoops you
> need to jump through to make the CFG and SSA builders happy.
>
> Due to this the __GIMPLE
76 matches
Mail list logo
