On Tue, Jun 11, 2019 at 4:22 AM Feng Xue OS wrote:
>
> > For future reference, there should be two spaces at the end of the sentence
> > before */. You can use gcc/contrib/check_GNU_style.sh foo.patch to catch
> > stuff like this before posting a final patch.
>
> It's good. Thanks for pointing
Hi,
after spending some time on the view converting MEM_REFs, I noticed that
most of reasons we give up on view converts is not actually MEM_REF created
but test
same_type_for_tbaa (TREE_TYPE (dbase2), TREE_TYPE (base2))
in indirect_ref_may_alias_decl_p
Here base2 is VAR_DECL while dbase2 is
On Wed, Jun 12, 2019 at 11:33 PM Aldy Hernandez wrote:
>
> On 6/12/19 5:33 AM, Richard Biener wrote:
> > On Wed, Jun 12, 2019 at 1:57 AM Martin Sebor wrote:
> >>
> >> On 6/11/19 3:02 PM, Aldy Hernandez wrote:
> >>>
> >>>
> >>> On 6/11/19 12:52 PM, Martin Sebor wrote:
> On 6/11/19 10:26 AM,
LAST_UPDATED: Wed Jun 12 19:12:53 UTC 2019 (revision 272202)
=== acats tests ===
=== acats Summary ===
# of expected passes2320
# of unexpected failures0
Native configuration is x86_64-apple-darwin18
=== g++ tests ===
Running
On Thu, Jun 13, 2019 at 10:53:55AM +0200, Rainer Orth wrote:
> >> Even with that fixed, I see many failures:
> >>
> >> +FAIL: g++.dg/tree-ssa/pr31146.C -std=gnu++14 scan-tree-dump forwprop1
> >> "MEM[.*][j.*] =.* 1;"
> >> +FAIL: g++.dg/tree-ssa/pr31146.C -std=gnu++17
Hi Jakub,
> On Thu, Jun 13, 2019 at 10:53:55AM +0200, Rainer Orth wrote:
>> >> Even with that fixed, I see many failures:
>> >>
>> >> +FAIL: g++.dg/tree-ssa/pr31146.C -std=gnu++14 scan-tree-dump forwprop1
>> >> "MEM[.*][j.*] =.* 1;"
>> >> +FAIL: g++.dg/tree-ssa/pr31146.C
On Thu, Jun 13, 2019 at 12:45 PM Jakub Jelinek wrote:
>
> On Thu, Jun 13, 2019 at 10:53:55AM +0200, Rainer Orth wrote:
> > >> Even with that fixed, I see many failures:
> > >>
> > >> +FAIL: g++.dg/tree-ssa/pr31146.C -std=gnu++14 scan-tree-dump forwprop1
> > >> "MEM[.*][j.*] =.*
This builds upon the previously posted patch to re-use if-conversion
versioning versions from vect_loop_versioning. The patch is actually
combined, it doesn't seem worth to split after all.
The patch computes the outermost loop the combined versioning
condition is invariant in and applies
Hi!
The OpenMP specification isn't clear on this, I'll work on getting that
clarified for 5.1, but the agreement on omp-lang has been that it should
work the way the patch implements it, static block scope variables inside of
#pragma omp target or #pragma omp declare target routines are handled
Hi Martin,
>> The testsuite part cannot have been tested very thoroughly: for one,
>> this snippet
>
> Please try r272218.
this cured a couple of issues, like this one:
>> ERROR: (DejaGnu) proc "4" does not exist.
However...
>> Even with that fixed, I see many failures:
>>
>> +FAIL:
Thank you for your review,
Claudiu
On Wed, Jun 12, 2019 at 12:00 AM Andrew Burgess
wrote:
>
> * Claudiu Zissulescu [2019-06-06 10:37:09 +0300]:
>
> > Hi Sandra, Andrew
> >
> > Please find a small patch on the documentation which adds info about naked,
> > ilink and firq function attributes.
>
On Thu, 13 Jun 2019, Jan Hubicka wrote:
> Hi,
> after spending some time on the view converting MEM_REFs, I noticed that
> most of reasons we give up on view converts is not actually MEM_REF created
> but test
> same_type_for_tbaa (TREE_TYPE (dbase2), TREE_TYPE (base2))
> in
The following fixes SRA dropping address-space information when
reconstructing a reference from a model in a different address-space.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
PR tree-optimization/90856
* tree-sra.c (build_ref_for_model): Only use
pinging this with more changes:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01471.html
S A Free simulator does not exist.
HPPA and alpha are supported by QEMU.
https://wiki.qemu.org/Features/HPPA
https://wiki.qemu.org/Documentation/Platforms/Alpha
VAX is supported by SIMH.
Hi,
Similar to what already exists for TI msp430 or in TI compilers for
arm, this patch adds support for "noinit" attribute for arm. It's very
similar to the corresponding code in GCC for msp430.
It is useful for embedded targets where the user wants to keep the
value of some data when the
On 12-06-19 09:30, Jakub Jelinek wrote:
> Hi!
>
> While testing the second PR90811 patch with nvptx offloading, I've noticed 3
> warnings in nvptx.c.
> The first two hunks are obvious, the last warning is about unused mode_label
> variable.
> Either we can do what the patch does, or another
Hi,
i read all changes except for ipa-sra itself. Here are some comments,
I will look at the remaining file next.
Honza
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 9a19d83fffb..3f838c08e76 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
struct GTY(()) cgraph_clone_info
{
+ /* Constants
On Thu, Jun 13, 2019 at 09:50:16AM -0600, Martin Sebor wrote:
> On 6/13/19 9:34 AM, Jakub Jelinek wrote:
> > On Thu, Jun 13, 2019 at 09:30:37AM -0600, Martin Sebor wrote:
> > > The size of the access above doesn't look right. The test is:
> >
> > It is correct. You have MEM [(int *)], which is
On Thu, Jun 13, 2019 at 03:59:33PM +, Michael Matz wrote:
> without running the risk of unlimited stack use. But of course this would
> promote a programming style that'd only work with our alloca (and not even
> C-alloca), and we want to avoid that. I thought it a cute idea, but was
>
The C++17 library was rebased on C11 by https://wg21.link/p0063r3 so
these nine macros are needed for C++17 conformance.
gcc:
* ginclude/float.h (FLT_DECIMAL_DIG, DBL_DECIMAL_DIG, LDBL_DECIMAL_DIG)
(FLT_HAS_SUBNORM, DBL_HAS_SUBNORM, LDBL_HAS_SUBNORM, FLT_TRUE_MIN)
On Thu, Jun 13, 2019 at 09:30:37AM -0600, Martin Sebor wrote:
> The size of the access above doesn't look right. The test is:
It is correct. You have MEM [(int *)], which is
the same thing as i itself, and on this you apply an ARRAY_REF,
which is printed after it, with index j_1(D). ARRAY_REF
On 6/13/19 9:34 AM, Jakub Jelinek wrote:
On Thu, Jun 13, 2019 at 09:30:37AM -0600, Martin Sebor wrote:
The size of the access above doesn't look right. The test is:
It is correct. You have MEM [(int *)], which is
the same thing as i itself, and on this you apply an ARRAY_REF,
which is
Hi,
On Thu, 13 Jun 2019, Jeff Law wrote:
> > (In fact I think our builtin_alloca implementation could benefit when we
> > added that behaviour as well; it's a natural wish to be able to free
> > memory that you allocated).
>
> Also note that simply sprinkling alloca(0) calls won't magically
On 6/12/19 10:40 AM, Jakub Jelinek wrote:
> On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote:
>> But GCC doesn't support such an implementation, does it?
>
> Why would that be relevant? The warning would cause people to make portable
> code less portable (by removing the alloca (0)
On 6/13/19 4:44 AM, Jakub Jelinek wrote:
On Thu, Jun 13, 2019 at 10:53:55AM +0200, Rainer Orth wrote:
Even with that fixed, I see many failures:
+FAIL: g++.dg/tree-ssa/pr31146.C -std=gnu++14 scan-tree-dump forwprop1
"MEM[.*][j.*] =.* 1;"
+FAIL: g++.dg/tree-ssa/pr31146.C
> > 1) indirect_refs_may_alias_decl_p passing ref2_is_decl as true to
> > aliasing_component_refs_p.
> >
> > This makes aliasing_component_refs_p to assume that all access paths
> > conflicting with REF2 must start by type of BASE2 or its subtype.
> >
> > IMO this is not quite
On Jun 12, 2019, Alexandre Oliva wrote:
> I'm looking into a regression between gcc-7 and gcc-8 that causes
> compilation with -mfloat-abi=hard to fail on arm-eabi with:
> $ arm-eabi-gcc -c -mfloat-abi=hard t.c
> cc1: error: -mfloat-abi=hard: selected processor lacks an FPU
> Per the
Hi all,
There was previously no backend pattern to utilise the scvtf fbits option.
Where a fixed point is converted to a float, and divided by a power of 2, (or
multiplied by the reciprocal of a power of 2), this can be combined into a
single scvtf with fbits operation. This patch adds a
On 6/12/19 9:25 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 12 Jun 2019, Martin Sebor wrote:
>
>>> Otherwise LGTM as the patch, but I'd like to hear from others whether
>>> it is kosher to add such a special case to the warn_unused_result
>>> attribute warning. And if the agreement is yes, I
Here is a new proposal which I think take into account all your remarks.
I discovered the great "%.*s" printf format so I was able to do some
cleanup on the function name without any allocation.
I also agree that counting the '>' or '<' is not reliable so I remove
this and limit the cleanup
Hi,
I am testing the following patch which solves the bogus warning in
tree-ssa-forwprop.c and -m32 and plan to commit it as obvoius to unbreak
bootstrap once testing converges. Previously we did not get here wince
we got mismatch between TMR type and decl type but same code is present
in
> Hi!
>
> Since this was committed (r272247), I've noticed a failure to build
> glibc-2.29 for aarch64:
> #'target_mem_ref' not supported by expression#'pmap_rmt.c: In function
> 'clnt_broadcast':
> pmap_rmt.c:298:19: error: may be used uninitialized in this function
>
Attached patch converts a bunch of indirect function calls to use
generic gen_{add2,sub3,extend}_insn functions. The patch corrects
and3 expander, which generated invalid RTX (non-existent
QI/HImode->DImode extend instructions for 32bit STV targets), so fake
insn-and-split patterns were necessary.
Hi Christophe,
> Since this was committed (r272247), I've noticed a failure to build
> glibc-2.29 for aarch64:
> #'target_mem_ref' not supported by expression#'pmap_rmt.c: In function
> 'clnt_broadcast':
> pmap_rmt.c:298:19: error: may be used uninitialized in this function
>
Case values are converted constant expressions, so narrowing conversion is not
permitted. This patch adds detecting narrowing to case_conversion; it's a
handy spot because we have both the value and the (adjusted) type of the
condition.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
Hi,
On Wed, 12 Jun 2019 at 16:54, Jonathan Wakely wrote:
>
> The std::to_chars functions from C++17 can be used to implement
> std::to_string with much better performance than calling snprintf. Only
> the __detail::__to_chars_len and __detail::__to_chars_10 functions are
> needed for to_string,
Hi,
actually since Rainer's testcase has TARGET_MEM_REF I think the problem
may be due to fact that we now can get TARGET_MEM_REF ofsetting the
array housed in decl while previously we gave up on types mismatch.
Does the following help?
Index: tree-ssa-alias.c
Attached is a fix for the fold_build call with inconsistent
argument types introduced in a recent commit of mine.
Tested on x86_64-linux.
Martin
PR tree-optimization/90662 - strlen of a string in a vla plus offset not folded
gcc/ChangeLog:
PR tree-optimization/90662
* tree-ssa-strlen.c
On 6/13/19 10:46 AM, Tom Tromey wrote:
"Jeff" == Jeff Law writes:
Jeff> I'd like to move C-alloca support to the ash heap of history. But I'm
Jeff> not sure we can realistically do that.
Are there still platforms or compilers in use where it's needed?
For gdb I was planning to just remove
On Thu, 13 Jun 2019 at 14:29, Jan Hubicka wrote:
>
> > > 1) indirect_refs_may_alias_decl_p passing ref2_is_decl as true to
> > > aliasing_component_refs_p.
> > >
> > > This makes aliasing_component_refs_p to assume that all access paths
> > > conflicting with REF2 must start by type
Hi,
On Thu, Jun 13 2019, Richard Biener wrote:
> On Tue, Jun 11, 2019 at 4:22 AM Feng Xue OS
> wrote:
>>
>> > For future reference, there should be two spaces at the end of the sentence
>> > before */. You can use gcc/contrib/check_GNU_style.sh foo.patch to catch
>> > stuff like this before
On 6/3/19 11:28 PM, Jiufu Guo wrote:
>
> Hi,
>
> This patch implements a new opportunity of jump threading for PR77820.
> In this optimization, conditional jumps are merged with unconditional
> jump. And then moving CMP result to GPR is eliminated.
>
> This version is based on the proposal of
On 6/13/19 8:44 AM, co...@sdf.org wrote:
> pinging this with more changes:
> https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01471.html
>
> S A Free simulator does not exist.
>
> HPPA and alpha are supported by QEMU.
> https://wiki.qemu.org/Features/HPPA
>
> "Jeff" == Jeff Law writes:
Jeff> I'd like to move C-alloca support to the ash heap of history. But I'm
Jeff> not sure we can realistically do that.
Are there still platforms or compilers in use where it's needed?
For gdb I was planning to just remove these calls.
Tom
This test fails on Darwin, because it doesn’t support symbol aliases.
Fixed by adding the dg-requires line,
tested on x86_64-darwin16, applied as obvious,
thanks
Iain
gcc/testsuite/
2019-06-13 Iain Sandoe
* gcc.dg/pr90760.c: Require alias support.
diff --git
For PR target/63810 some improvements were made in the parsing of the version
string
at the point it's used to define the built-in
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__.
This is fine, but the specs processing also uses the version, and specs
version-compare
doesn't like leading zeros
Hi Sylvia,
-(define_insn "ldr_got_tiny"
+(define_insn "ldr_got_tiny_di"
[(set (match_operand:DI 0 "register_operand" "=r")
- (unspec:DI [(match_operand:DI 1 "aarch64_valid_symref" "S")]
- UNSPEC_GOTTINYPIC))]
+ (unspec:DI
+ [(match_operand:DI 1
Committed revision 272254.
I'm sure that when you authored the code, it wasn't confusing at all.
--
steve
On Thu, Jun 13, 2019 at 06:14:59AM +0100, Paul Richard Thomas wrote:
> Hi Steve,
>
> As the original author of the confusing code, I want to thank you for
> de-confusing it!
>
> OK
>
>
Newer OS versions (10.14+) do not provide some of the CRTs that are used for
older ones (e.g. 10.5), and thus link tests that specify targeting such a
revision fail.
For the two tests affected, we retain the testing of the correct defined OS
version
number but switch to compile-only testing. A
This test fails for Darwin m32 because it's scanning for absence of an
instruction
that's validly used in PIC code. Fixed, in this case, by using non-PIC codegen.
tested on x86_64-darwin16, x86_64-linux-gnu (m32, m64).
applied to mainline
thanks
Iain
2019-06-13 Iain Sandoe
*
Hi Joel,
A few comments below:
+/* If X is a positive CONST_DOUBLE with a value that is the reciprocal of a
+ power of 2 (i.e 1/2^n) return the number of float bits. e.g. for x==(1/2^n)
+ return log2 (n). Otherwise return 0. */
+int
+aarch64_fpconst_pow2_recip (rtx x)
+{
+ REAL_VALUE_TYPE
The attached patch suppresses the spurious warnings that
would otherwise occur for the testcase. Regression
tested cleanly on x86_64-*-freebsd. OK to commit?
2019-06-13 Steven G. Kargl
PR fortran/89646
* dependency.c (gfc_check_argument_var_dependency): Suppress spurious
While integrating the strlen and sprintf passes and investigating
optimization opportunities that it opens up I noticed a few related
to a strcmp optimization implemented in GCC 9. One is to take
advantage of the fact that a nul-terminated string of a known
length cannot be equal to a string
Hi,
should all be rather straightforward but I spent quite a bit of time on
the testsuite changes... Tested x86_64-linux, as usual.
Thanks, Paolo.
PS: at some point we should start talking about all the error, error_at,
etc, which are *never* exercised by our testsuite. I'm coming to the
As Jon points out in the PR, emitting -Wunused warnings in unevaluated contexts
doesn't make a whole lot of sense, because in such contexts, we're not reading
the values in any case. Disabling this particular warning is trivial. There
are likely other warnings like this, but I haven't audited
On 6/13/19 10:46 AM, Tom Tromey wrote:
>> "Jeff" == Jeff Law writes:
>
> Jeff> I'd like to move C-alloca support to the ash heap of history. But I'm
> Jeff> not sure we can realistically do that.
>
> Are there still platforms or compilers in use where it's needed?
>
> For gdb I was
On 6/13/19 1:10 PM, Martin Sebor wrote:
> Attached is a fix for the fold_build call with inconsistent
> argument types introduced in a recent commit of mine.
>
> Tested on x86_64-linux.
>
> Martin
>
> gcc-90662.diff
>
> PR tree-optimization/90662 - strlen of a string in a vla plus offset not
On Thu, Jun 13, 2019 at 11:50:23PM +0200, Harald Anlauf wrote:
>
> it was already discussed in the above PRs that the testcase
> lrshift_1.f90 needs to be corrected because it invokes negative
> values of the SHIFT argument. This is fixed, as well as the
> related documentation, which did not
Dear all,
it was already discussed in the above PRs that the testcase
lrshift_1.f90 needs to be corrected because it invokes negative
values of the SHIFT argument. This is fixed, as well as the
related documentation, which did not match e.g. the Fortran standard.
Looking closer at the actual
On Sat, Jun 8, 2019 at 12:14 AM Richard Sandiford
wrote:
>
> "H.J. Lu" writes:
> > On Fri, Jun 7, 2019 at 1:22 AM Richard Biener wrote:
> >>
> >> On Fri, 7 Jun 2019, Richard Sandiford wrote:
> >>
> >> > "H.J. Lu" writes:
> >> > > locate_and_pad_parm is called when expanding function call from
60 matches
Mail list logo
