Hi!
Similar problem to the recently fixed UBSAN_VPTR lowering,
ubsan_expand_objsize_ifn sets *gsi to the first stmt in a new bb
after splitting block after UBSAN_OBJECT_SIZE, which is the next stmt
that should be processed, so we should always return no_next = true
to avoid gsi_next on it before i
Hi!
We pass the values after STRIP_NOPS to *ROTATE_EXPR build, which is
undesirable, as the testcase shows, the operand could very well end up being
a pointer rather than integer.
This patch fixes it by passing the original trees instead.
Alternatively we could fold_convert the STRIP_NOPS result t
On Wed, Feb 11, 2015 at 7:24 PM, Richard Biener
wrote:
> On Wed, Feb 11, 2015 at 9:23 AM, Bin.Cheng wrote:
>> On Tue, Feb 10, 2015 at 12:24 AM, Richard Biener
>> wrote:
>>
>> Previously, the computation of _1174 can be replaced by _629 in bb8 in
>> DOM2 pass, while it can't after patching. This
On Wed, Feb 11, 2015 at 4:55 AM, Jeff Law wrote:
>
> This PR was originally minor issue where we regressed on this kind of
> sequence:
>
> typedef struct toto_s *toto_t;
> toto_t add (toto_t a, toto_t b) {
> int64_t tmp = (int64_t)(intptr_t)a + ((int64_t)(intptr_t)b&~1L);
> return (toto_t)(int
On 02/10/2015 01:19 PM, Richard Henderson wrote:
> As an existing issue, I'm not sure why "specified" visibility is any different
> from unspecified visibility. As far as I'm aware, the "specified" bit simply
> means that the decl doesn't inherit inherit visibility from the class, or from
> the co
On 2/11/2015 1:22 AM, Arnaud Charlet wrote:
>> When building Ada for RTEMS, you need to pass in the CFLAGS_FOR_TARGET
>> to see OS specific .h files. This was already done for the RTS but needed to
>> be added to the process which extracts value settings from the .h files.
>>
>> This patch is agai
Thomas Schwinge wrote:
> To resolve the immediate problem: is my approval "enough" for Kaz to
> commit the patch, or does that need a "more authoritative approval"?
I'd like to commit my patch as a "quick fix" in a few days if
no one objects.
> I think I copied this approach from some other test
> > +@table @gcctabopt
> > +
> > +@item -mspace
> > +@opindex mspace
> > +Enable code-size optimizations.
> > +Some of these optimizations incur a minor performance penalty.
>
> We already have -Os, so why is an architecture-specific option for this
> needed?
Code compiled with -mspace is somewh
PR 63347 is a case where we can end up scheduling an insn into the
middle of a scheduling group.
Basically given two consecutive insns A & B, if B has SCHED_GROUP_P set,
then it must always be immediately after A.
The problem we ran into in this PR was that there was a cost to issue B,
so
On Wed, Feb 11, 2015 at 09:44:24AM -0800, Mike Stump wrote:
> On Feb 11, 2015, at 4:24 AM, Marek Polacek wrote:
> >
> > The following patch splits the test into C and C++ test cases, so
> > hopefully fixing the issue. Ok for trunk?
> >
> > 2015-02-11 Marek Polacek
> >
> > * g++.dg/ubsan
On Mon, 2015-02-09 at 09:10 -0800, Mike Stump wrote:
> On Feb 9, 2015, at 7:11 AM, Alex Velenko wrote:
> > The following patch makes atomic-op-consume.c XFAIL
> >
> > Is this patch ok?
>
> Ok.
>
> I’d shorten the comment above the xfail to be exceedingly short:
>
> /* PR59448 consume not imp
Hi,
On 12/01/2014 09:59 PM, Jason Merrill wrote:
On 12/01/2014 07:01 AM, Fabien Chêne wrote:
2014-11-03 21:18 GMT+01:00 Fabien Chêne :
2014-10-09 15:34 GMT+02:00 Jason Merrill :
[...]
If the USING_DECL is returned, the code below will be rejected as
expected, but the error message will not me
Hi,
this patch fixes ICE when building firefox reported by Markus:
>
> lto1: internal compiler error: Segmentation fault
> 0x106e1feb crash_signal
> ../../gcc/gcc/toplev.c:383
> 0x10589cd4 lto_get_decl_name_mapping(lto_file_decl_data*, char const*)
> ../../gcc/gcc/lto-section-in.c:
On 11-02-15 10:22, Dominique d'Humières wrote:
Le 10 févr. 2015 à 12:42, Tom de Vries a écrit :
I think we need to understand first what's going on.
Sure, my patch was mainly to silence the failures on my working tree.
In both test-cases, on Linux with -fpic the inlining of one funct ion
On 11/02/15 14:21, Kenneth Zadeck wrote:
On 02/11/2015 06:20 AM, Jiong Wang wrote:
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck :
however, since i am a nice person
loop-invariant solves the DF_UD_CHAIN which builds a data structure that
connects each use with all of the defs that reach it.
Dear Paul,
> Le 11 févr. 2015 à 17:57, Paul Richard Thomas
> a écrit :
>
> Dear Dominique,
>
>> The patch works as advertised! I have two remarks:
>
> Of course it does :-)
;-)
>>
>> (1) AFAIU there is no need for a temporary for
>
> Indeed not. I cannot see how that can be avoided withou
Hi!
In r220627, I have committed a merge from trunk r220584 (2015-02-10) into
gomp-4_0-branch.
Grüße,
Thomas
pgpwCbyTbYKcB.pgp
Description: PGP signature
On Feb 11, 2015, at 4:24 AM, Marek Polacek wrote:
>
> The following patch splits the test into C and C++ test cases, so
> hopefully fixing the issue. Ok for trunk?
>
> 2015-02-11 Marek Polacek
>
> * g++.dg/ubsan/shift-1.C: New test.
> * gcc.dg/ubsan/c-shift-2.c: New test.
>
On Tue, 10 Feb 2015, Jeff Law wrote:
> I think the way to go is to always convert the inner operands to an unsigned
> type. In fact, everything except the outer convert should be using an
> unsigned type of the same size/precision as @0's type. The outer convert
> should, of course, be the final
On 02/11/15 03:56, Richard Biener wrote:
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7f3816c..7a95029 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-02-10 Jeff Law
+
+ * match.pd (convert (plus/minus (convert @0) (convert @1): New
+ simplifier to
On Wed, 11 Feb 2015, James Bowman wrote:
> +@table @gcctabopt
> +
> +@item -mspace
> +@opindex mspace
> +Enable code-size optimizations.
> +Some of these optimizations incur a minor performance penalty.
We already have -Os, so why is an architecture-specific option for this
needed?
> +A 16-bit
Dear Dominique,
> The patch works as advertised! I have two remarks:
Of course it does :-)
>
> (1) AFAIU there is no need for a temporary for
Indeed not. I cannot see how that can be avoided without a much more
elaborate patch. Frankly, I do not see that it would be warranted.
Much better some
PING.
On Wed, Jan 28, 2015 at 8:05 AM, H.J. Lu wrote:
> PING.
>
> On Tue, Jan 13, 2015 at 3:25 PM, H.J. Lu wrote:
>> On Tue, Jan 13, 2015 at 5:03 AM, H.J. Lu wrote:
>>> On Mon, Jan 12, 2015 at 11:50:41PM +, Joseph Myers wrote:
On Mon, 12 Jan 2015, H.J. Lu wrote:
> +if test x$
On Wed, Feb 11, 2015 at 8:15 AM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
>> On Wed, Feb 11, 2015 at 7:19 AM, Rainer Orth
>> wrote:
>>> "H.J. Lu" writes:
>>>
On Wed, Feb 11, 2015 at 6:10 AM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
>>> The new proc is bogus, unfortunatel
Dear Paul,
The patch works as advertised! I have two remarks:
(1) AFAIU there is no need for a temporary for
PROGRAM Main
INTEGER :: i, index(5) = (/ (i, i = 1,5) /)
REAL :: tmp(5), array(5) = (/ (i+0.0, i = 1,5) /)
tmp = Fred(index,array)
array = tmp
PRINT *, array
CONT
"H.J. Lu" writes:
> On Wed, Feb 11, 2015 at 7:19 AM, Rainer Orth
> wrote:
>> "H.J. Lu" writes:
>>
>>> On Wed, Feb 11, 2015 at 6:10 AM, Rainer Orth
>>> wrote:
"H.J. Lu" writes:
>> The new proc is bogus, unfortunately: there's already an existing
>> check_effective_target_pie
On Wed, Feb 11, 2015 at 08:56:20AM -0700, Jeff Law wrote:
> On 02/11/15 04:16, Richard Biener wrote:
> >>
> >>Application of this pattern (and the one I posted for 47477) is a concern
> >>for targets that don't do sub-word arithmetic/logicals. But I just did a
> >>sniff test of one such target (v8
On 02/11/15 04:16, Richard Biener wrote:
Application of this pattern (and the one I posted for 47477) is a concern
for targets that don't do sub-word arithmetic/logicals. But I just did a
sniff test of one such target (v850-elf because it was handy) and I couldn't
spot a change in the end code
On Wed, Feb 11, 2015 at 7:19 AM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
>> On Wed, Feb 11, 2015 at 6:10 AM, Rainer Orth
>> wrote:
>>> "H.J. Lu" writes:
>>>
> The new proc is bogus, unfortunately: there's already an existing
> check_effective_target_pie that checks if a target can supp
On 11/02/15 11:14 +, Matthew Wahab wrote:
Attached the fixed patch.
Tested by running check-target-libstdc++-v3, with the modified tests,
for arm-none-eabi and aarch64-none-linux-gnu.
Ok to commit?
OK, thanks.
I vote for quiet.For three reasons:
1) it matches the expectation of what programmers expect. I view
people who do floating point as falling into two categories:
a) people who wish that there were no such thing as nans. These
people are happy to write programs with just < > <= >= ==
On 02/11/2015 03:44 PM, Thomas Schwinge wrote:
Note the global cold/hot labels. This confuses mkoffload, and it runs
into a busy loop due to what I understand to be a bug in skipping of
"strange" tokens, cited above, which such global labels would fall under.
Here is what might be a fix for this
"H.J. Lu" writes:
> On Wed, Feb 11, 2015 at 6:10 AM, Rainer Orth
> wrote:
>> "H.J. Lu" writes:
>>
The new proc is bogus, unfortunately: there's already an existing
check_effective_target_pie that checks if a target can support PIE. The
new one just overrides the previous one. O
On Wed, 11 Feb 2015, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes a thinko in -fsection-anchors alias handling code
> Honza added in r211357. Usually for aliases we don't create
> SYMBOL_REF_HAS_BLOCK_INFO_P, but in the following testcase we do,
> because the rtl is created through notice_glo
Hi!
This patch fixes a thinko in -fsection-anchors alias handling code
Honza added in r211357. Usually for aliases we don't create
SYMBOL_REF_HAS_BLOCK_INFO_P, but in the following testcase we do,
because the rtl is created through notice_global_symbol already
when the symbol wasn't an alias, onl
Hi!
I've bootstrapped/regtested these 3 backports from trunk to 4.9 branch
on x86_64-linux and i686-linux and installed.
Jakub
2015-02-11 Jakub Jelinek
Backported from mainline
2015-02-04 Jakub Jelinek
PR c/64824
PR c/64868
* c-omp.c (c_fini
Hi!
On Wed, 11 Feb 2015 15:44:26 +0100, I wrote:
> If -freorder-blocks-and-partition is active, this results in PTX code
> such as:
>
> // BEGIN PREAMBLE
> .version3.1
> .target sm_30
> .address_size 64
> // END PREAMBLE
>
> $LCOLDB0:
>
Hi Bernd!
On Sat, 1 Nov 2014 13:11:29 +0100, Bernd Schmidt
wrote:
> I'm sending this for reference more than anything else - this is the
> patch that adds the target support for offloading to the nvptx port.
(I committed this in r220209.)
> I actually expect this to change a little in the ne
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../gcc-5-20150211/gcc -I../../gcc-5-20150211/gcc/.
-I../../gcc-5-20150211/gcc/../include
-I../../gcc-5-20150211/gcc/../libcpp/include -I/sw/include
-I/sw/include -I
Hi Jeff,
On 9 Feb 2015, at 14:47, Jeff Law wrote:
> On 02/01/15 09:42, Iain Sandoe wrote:
>>
>> This is a GCC5 bootstrap regression on 32bit Darwin hosts ( I can raise a PR
>> if that is considered necessary).
> Has this been addressed or is it still pending?
I believe it's still awaiting rev
On 02/11/2015 06:20 AM, Jiong Wang wrote:
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck :
however, since i am a nice person
loop-invariant solves the DF_UD_CHAIN which builds a data structure that
connects each use with all of the defs that reach it. I believe that this
is the opposite of wh
On Wed, Feb 11, 2015 at 6:10 AM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
>>> The new proc is bogus, unfortunately: there's already an existing
>>> check_effective_target_pie that checks if a target can support PIE. The
>>> new one just overrides the previous one. On targets supporting PIE
>>>
Hi!
On Wed, 28 Jan 2015 18:05:25 +0100, I wrote:
> On Sat, 1 Nov 2014 13:11:29 +0100, Bernd Schmidt
> wrote:
> > I'm sending this for reference more than anything else - this is the
> > patch that adds the target support for offloading to the nvptx port. It
> > depends on the other offloading
Hi!
On Wed, 28 Jan 2015 20:59:45 +0300, Ilya Verbin wrote:
> On 28 Jan 18:05, Thomas Schwinge wrote:
> > + fprintf (out, "#define PTX_ID 1\n");
> > + fprintf (out, "static __attribute__((constructor)) void init
> > (void)\n{\n");
> > + fprintf (out, " GOMP_offload_register (__OPENMP_TARGET__
Hi!
On Wed, 28 Jan 2015 18:05:25 +0100, I wrote:
> On Sat, 1 Nov 2014 13:11:29 +0100, Bernd Schmidt
> wrote:
> > I'm sending this for reference more than anything else - this is the
> > patch that adds the target support for offloading to the nvptx port. It
> > depends on the other offloading
"H.J. Lu" writes:
>> The new proc is bogus, unfortunately: there's already an existing
>> check_effective_target_pie that checks if a target can support PIE. The
>> new one just overrides the previous one. On targets supporting PIE
>> (like Darwin), but not defaulting to it, the PIE tests sudde
On Tue, Feb 10, 2015 at 3:11 PM, Rainer Orth
wrote:
> Jeff Law writes:
>
>>> Subject: [PATCH 1/5] Add check_effective_target_pie
>>>
>>> Hi,
>>>
>>> This patch adds check_effective_target_pie to check if the current
>>> multilib generates PIE by default.
>>>
>>> Thanks.
>>>
>>> H.J.
>>> ---
>>> 2
Hi!
This patch fixes a thinko in POP macro in c_parser_binary_expression that
resulted in not triggering the build2 case if omp_atomic_lhs is non-NULL.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk so far, 4.9 testing in progress, 4.8 will follow at
some
On Wed, Feb 11, 2015 at 1:46 PM, Martin Liška wrote:
> On 02/10/2015 05:00 PM, Jakub Jelinek wrote:
>>
>> On Tue, Feb 10, 2015 at 04:56:40PM +0100, Martin Liška wrote:
>>>
>>> On 02/10/2015 01:50 PM, Richard Biener wrote:
On Tue, Feb 10, 2015 at 12:07 PM, Martin Liška wrote:
>
>
On Wed, 11 Feb 2015, Richard Biener wrote:
>
> Testing in progress.
>
> Ok?
So it was said that retaining something like is better.
Thus the following.
LTO bootstrapped & tested on x86_64-unknown-linux-gnu - ok?
Thanks,
Richard.
2015-02-11 Richard Biener
PR lto/65015
* d
On Wed, Feb 11, 2015 at 02:04:09PM +0100, Jakub Jelinek wrote:
> On Sun, Feb 08, 2015 at 05:10:44PM -0800, Jerry DeLisle wrote:
> > The attached patch fixes this by checking for the case when we are doing g0
> > editing and the exponent is 0.
> >
> > Regression tested on X86-64. For the larger ki
On 20/01/15 13:26, Maxim Kuvyrkov wrote:
On Jan 20, 2015, at 1:24 PM, Richard Earnshaw wrote:
...
In general, how should someone tuning the compiler for this parameter
select a value that isn't one of (-1, m_i_q_d+1)?
From my experiments it seems there are 4 reasonable values for the paramet
On Sun, Feb 08, 2015 at 05:10:44PM -0800, Jerry DeLisle wrote:
> The attached patch fixes this by checking for the case when we are doing g0
> editing and the exponent is 0.
>
> Regression tested on X86-64. For the larger kinds, we are on a different
> code path out of necessity, so we need to ad
On 02/10/2015 05:00 PM, Jakub Jelinek wrote:
On Tue, Feb 10, 2015 at 04:56:40PM +0100, Martin Liška wrote:
On 02/10/2015 01:50 PM, Richard Biener wrote:
On Tue, Feb 10, 2015 at 12:07 PM, Martin Liška wrote:
Hello.
Following patch is fix for PR ipa/64813. The patch was tested on a darwin
targ
On Sun, Jan 25, 2015 at 12:07:46PM -0800, Mike Stump wrote:
> On Dec 1, 2014, at 2:52 AM, Marek Polacek wrote:
> > On Sun, Nov 30, 2014 at 11:00:12PM -0500, Jason Merrill wrote:
> >> On 11/27/2014 08:57 AM, Marek Polacek wrote:
> >>> -/* { dg-error "is not a constant expression" "" { target c++ }
Testing in progress.
Ok?
Thanks,
Richard.
2015-02-11 Richard Biener
PR lto/65015
* dwarf2out.c (dwarf2out_finish): Do not emit DW_AT_name
on the comp unit DIE for LTO produced units.
Index: gcc/dwarf2out.c
The following drops tempfile names from the DW_AT_producer string
resulting from -fltrans-output-list and -fresolution.
Applied as obvious.
Richard.
2015-02-11 Richard Biener
PR lto/65015
* dwarf2out.c (gen_producer_string): Drop -fltrans-output-list
and -fresolution
On Wed, Feb 11, 2015 at 9:23 AM, Bin.Cheng wrote:
> On Tue, Feb 10, 2015 at 12:24 AM, Richard Biener
> wrote:
>> On February 9, 2015 11:09:49 AM CET, Bin Cheng wrote:
>>
>> Did you extract a testcase for it? Note that the IV step itself may be
>> expanded
>> Too much.
>>
>> I
>>>looked into
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck :
>
> however, since i am a nice person
>
> loop-invariant solves the DF_UD_CHAIN which builds a data structure that
> connects each use with all of the defs that reach it. I believe that this
> is the opposite of what you want here.
>
> if you reall
On Wed, Feb 11, 2015 at 7:43 AM, Jeff Law wrote:
> On 02/03/15 05:23, Joseph Myers wrote:
>>
>>
>>> +&& TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE
>>> (@1))
>>> +&& TYPE_UNSIGNED (TREE_TYPE (@0)) == TYPE_UNSIGNED (TREE_TYPE
>>> (@1))
>>> +&& TYPE_PRECISION
On 10/02/15 08:51, Matthew Wahab wrote:
On 09/02/15 23:17, Hans-Peter Nilsson wrote:
On Mon, 9 Feb 2015, Matthew Wahab wrote:
Attached a patch to replace the test for macro __NEWLIB__ with a test for
macro NEWLINE_IN_CLASS_BLANK, defined by
{ dg-additional-options "-DNEWLINE_IN_CLASS_BLANK"
On Tue, Feb 10, 2015 at 09:56:48PM +, Joseph Myers wrote:
> __FUNCTION__ and __func__ aren't macros (essentially they're built-in
> variables).
Oops, I must have been thinking of __STDC_VERSION__ when writing that.
Fixed, thanks.
Index: porting_to.html
===
Dear Paul, dear all,
first, sorry for the belate review.
Paul Thomas wrote:
> This is a slight development of the patch posted on the PR itself.
>
> class.c(finalize_component) is not able to deal correctly with
> non-allocatable, derived type array components that have allocatable
> components.
Here is a revised patch using '#'. Bootstrap + check-gcc natively on
aarch64-none-linux-gnu.
My feeling is still against including the testcase because even when it passes
it doesn't increase my confidence that the compiler is right very much (i.e. the
insn could still be reading which_alterna
On Tue, Feb 10, 2015 at 9:55 PM, Jeff Law wrote:
>
> This PR was originally minor issue where we regressed on this kind of
> sequence:
>
> typedef struct toto_s *toto_t;
> toto_t add (toto_t a, toto_t b) {
> int64_t tmp = (int64_t)(intptr_t)a + ((int64_t)(intptr_t)b&~1L);
> return (toto_t)(int
On 10 February 2015 at 16:06, James Greenhalgh wrote:
>
> Hi,
>
> As is already done for mips and hppa, we should XFAIL this test on
> AArch64 as we don't currently use the store_by_pieces infrastructure.
>
> We may in future want to tweak this, but for GCC 5.0 the safe thing
> to do is just to XF
On 8 February 2015 at 02:24, Andrew Pinski wrote:
> Here is the updated patch with Jakub's comments included and added a
> testcase for the 0, 0 case.
>
> Thanks,
> Andrew Pinski
> ChangeLog:
>
> PR target/64893
> * config/aarch64/aarch64-builtins.c (aarch64_init_simd_builtins
On Wed, Jan 28, 2015 at 9:05 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch rewrites the target pragma and target attribute handling in the
> i386 backend, so that outside of functions global_options and target globals
> reflect the currently active #pragma GCC target (if none active, obviously
> t
> Le 10 févr. 2015 à 12:42, Tom de Vries a écrit :
>
> I think we need to understand first what's going on.
Sure, my patch was mainly to silence the failures on my working tree.
> In both test-cases, on Linux with -fpic the inlining of one function into the
> other is not done, because we can
On Mon, Feb 09, 2015 at 11:16:56PM +, Jeff Law wrote:
> On 02/06/15 05:24, James Greenhalgh wrote:
> >
> > ---
> > 2015-02-06 James Greenhalgh
> >
> > * haifa-sched.c (recompute_todo_spec): After applying a
> > replacement and cancelling a dependency, also clear the
> > SCHED_GR
On Tue, Feb 10, 2015 at 12:24 AM, Richard Biener
wrote:
> On February 9, 2015 11:09:49 AM CET, Bin Cheng wrote:
>
> Did you extract a testcase for it? Note that the IV step itself may be
> expanded
> Too much.
>
> I
>>looked into the regression and thought it was because of passes after
>>IVO
71 matches
Mail list logo
