Dear Paul,
Paul Richard Thomas wrote:
> The ChangeLog says it all. If the check is not done for components
> that are not procedure pointers,
> typebound_operator_9.f03 breaks. I am not entirely sure why this is
> the case but the fix works fine.
>
> Bootstraps and regtests on FC21/x86_64 - OK fo
> if (offset)
> {
> machine_mode address_mode;
> rtx offset_rtx = expand_expr (offset, NULL_RTX, VOIDmode,
> EXPAND_SUM);
>
> gcc_assert (MEM_P (op0));
>
> address_mode = get_address_mode (op0);
>
Dear Tobias,
I think that I have a partial understanding now and will attempt to
verify it tonight. Certainly to not build the components, when a
derived type is flagged to have proc_pointer components cannot be
right just because there can be other components as in the original
testcase. This led
> If we have BIGGEST_ALIGNMENT=16 that means we have likely a 16 bit
> architecture. I doubt that the strict alignment code makes any sense for
> modesize> BIGGEST_ALIGNMENT.
Note that m68k is a 32-bit port (UNITS_PER_WORD is 4) but, by definition of
BIGGEST_ALIGNMENT, not honoring an alignment l
A short-circuit was added in gigi for E_Abstract_State but it results in an
unbalanced handling of the context.
Tested on x86_64-suse-linux, applied on the mainline.
2015-03-16 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_entity) : Do not
short-circuit the regular handl
Hi,
For this trivial testcase:
extern int bar (int , int);
int foo (int *a, int *b)
{
return bar (*a, *b);
}
I noticed that GCC generate redundant zero-extension instructions under ILP32
(aarch64-linux-gnu-gcc -S -O2 -mabi=ilp32).
Assembly code:
.arch armv8-a+fp+simd
.fi
An obscur case with a limited-with clause and 'Class in a subprogram profile.
Tested on x86_64-suse-linux, applied on the mainline.
2015-03-16 Eric Botcazou
* gcc-interface/decl.c (is_from_limited_with_of_main): New predicate.
(gnat_to_gnu_entity) : Invoke it on return and
> On Mar 16, 2015, at 2:28 AM, Yangfei (Felix) wrote:
>
> Hi,
>
> For this trivial testcase:
>
> extern int bar (int , int);
>
> int foo (int *a, int *b)
> {
>return bar (*a, *b);
> }
>
> I noticed that GCC generate redundant zero-extension instructions under ILP32
> (aarch64-linux
On 16/03/15 05:36, Kugan wrote:
Hi Kugan,
AArch64 RTX cost for vector SET is causing PR65375. Lower subreg is
using this rtx_cost to compute the cost of moves, and splitting anything
larger than word size, 64-bits in this case. The aarch64 rtx_costs is
returning 2 * COST_N_INSNS(1) for vector
This fixes a regression present on all active branches at -O3, caused by a
call to fold_convert with an aggregate type.
Tested on x86_64-suse-linux, applied on all active branches.
2015-03-16 Eric Botcazou
* gcc-interface/utils2.c (gnat_invariant_expr): Return null if the type
Hi all,
This patch replaces manual swapping in synth_mult with std::swap.
Not much else to say about this. This code could arguably be refactored
a bit but that's another story.
I believe these are considered obvious at this point.
I'll apply it in 24 hours unless somebody objects
Tested aarch6
Hi all,
Eyeballing the mult_by_coeff_cost function I think it has a typo/bug.
It's supposed to return the cost of multiplying by a constant 'coeff'.
It calculates that by taking the cost of a MULT rtx by that constant
and comparing it to the cost of synthesizing that multiplication, and
returnin
On 12-03-15 11:51, Uros Bizjak wrote:
On Thu, Mar 12, 2015 at 11:41 AM, Tom de Vries wrote:
Attached patch adds nonpic target requirement for some (obvious)
cases, where data access or PIC register setup confuses scan-asms.
2015-01-30 Uros Bizjak
* gcc.target/i386/fuse-caller-save-
This is an ICE present on all active branches, a regression introduced by the
overhaul I applied throughout the RTL expander to avoid creating unnecessary
stack temporaries for return values. We enter the special block for MEM:BLK
in store_field with a PARALLEL:BLK and abort on the assertion.
Hi Tobias, hi all,
thanks for the review. Commited as r221455:
r221455 | vehre | 2015-03-16 11:29:59 +0100 (Mo, 16. Mär 2015) | 13 Zeilen
gcc/fortran/ChangeLog:
2015-03-16 Andre Vehreschild
* resolve.c: Prevent segfault on illegal input.
gcc/testsuite/ChangeLog:
2015-03-16 Andre
Hi,
when looking at the m68k I realized the following, which is
a general problem...
If the alignment of the structure is less than sizeof(field), the
strict volatile bitfields code may read beyond the end of the
structure!
Consider this example:
struct s
{
char x : 8;
volatile unsigned i
On Sat, Mar 14, 2015 at 4:24 PM, Jerry DeLisle wrote:
> Attachment on this one.
>
>
> On 03/14/2015 07:22 AM, Jerry DeLisle wrote:
>>
>> On 03/08/2015 04:58 PM, Steve Kargl wrote:
>>>
>>> On Mon, Mar 09, 2015 at 01:07:25AM +0200, Janne Blomqvist wrote:
So I would prefer if we just hardco
>> lower-subreg.c:compute_costs() only cares about the cost of a (set (reg)
>> (const_int )) move but I think the intention, at least for now, is to
>> return extra_cost->vect.alu for all the vector operations.
>
> Almost, what we want at the moment is COSTS_N_INSNS (1) +
> extra_cost->vect.alu
T
> From: Steven Bosscher [mailto:stevenb@gmail.com]
> Sent: Monday, March 09, 2015 7:48 PM
> To: Thomas Preud'homme
> Cc: GCC Patches; Eric Botcazou
> Subject: Re: [PATCH, stage1] Move insns without introducing new
> temporaries in loop2_invariant
New patch below.
>
> It looks like this would
On 16/03/15 23:32, Kugan wrote:
>>> lower-subreg.c:compute_costs() only cares about the cost of a (set (reg)
>>> (const_int )) move but I think the intention, at least for now, is to
>>> return extra_cost->vect.alu for all the vector operations.
>>
>> Almost, what we want at the moment is COSTS_N_I
OK.
Jason
Hi Eric,
Note that the very same code is in expand_assignment, so they probably should
be kept in sync.
Oops - I had missed that.
The patch adds a second call to expand_expr(), giving the address mode
as the suggested mode, and using a normal expansion, rather than
EXPAND_SUM. This
The PR points out DR 1688: volatile + constexpr is a valid combination.
This patch makes the compiler accept such a code.
There's a related problem:
constexpr volatile int a = 42;
constexpr int b = a;
the initialization of b should be rejected, but it is not. My patch does
not address this issue
This function is unused since matrix-reorg.c removal back in 2012. I think
there's no point in keeping it around.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-03-16 Marek Polacek
* cgraph.h (add_new_static_var): Remove declaration.
* varpool.c (add_new_static_va
Hi,
this patch avoids the attempt to create user-aligned-type for variants
original and main-variants type-alignment differ and original type
isn't user-aligned.
Not sure if this is the preferred variant, we could create for such
cases an aligned-type without setting user-align.
But as this should
Hi all,
this is the second part of the patch, substituting gfc_class_vtab_*_get() for
gfc_vtable_*_get () where needed.
Bootstraps and regtests ok on x86_64-linux-gnu/F20.
Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
vtab_access_rework2_v1.clog
Desc
Hi all,
I like to propose a rename and split of the function
trans-expr.c::gfc_vtable_*_get().
Background: During fixing an issue, I encountered the case, that I had a handle
to get the vptr already and now wanted to retrieve the size component using that
vtpr handle. There was no function to ea
On Fri, Mar 13, 2015 at 1:06 PM, H.J. Lu wrote:
> I am working on SHF_COMPRESSED support:
>
> http://www.sco.com/developers/gabi/latest/ch4.sheader.html
>
> I will import zlib from GCC source tree into binutils-gdb tree. But zlib
> failed to build as a target library in binutils-gdb. There is no
Dear all,
herewith I submit a patch to fix another issue on deferred length strings and
unlimited polymorphic objects. When an unlimited polymorphic object is allocated
to store a char array, the _len component was not in all cases set correctly in
gfc_allocate (). During analyzing the issue in gf
I checked in this patch to move cloog.m4 ChangeLog to config/ChangeLog.
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 221457)
+++ ChangeLog (working copy)
@@ -331,7 +331,6 @@
2014-11-11 Tobias Burnus
- * conf
Hi!
Trying to access *ctx->outer in delete_omp_context, which is called from
splay tree deletion and thus it is pretty much random if the outer context
is destructed before or after the child, is a very bad idea.
It seems a unique splay tree is assigned to ctx->reduction_map only for
the offloadin
Hi!
While looking at PR65431, I've noticed we leak memory for every
expand_omp_target called.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.
2015-03-16 Jakub Jelinek
* omp-low.c (expand_omp_target): Use auto_vec
instead of vec * with v
Hi!
On the following testcase, gimple LIM creates a vector COND_EXPR (scalar
condition, vector lhs, rhs2 and rhs3), but if we don't have corresponding
vector mode for it, we ICE trying to expand the BLKmode COND_EXPR, as it is
unprepared for that.
This patch lowers those (parallel or piecewise).
Resending, now that I've figured out how to make gmail send text email
instead of html.
> >> Almost, what we want at the moment is COSTS_N_INSNS (1) +
> >> extra_cost->vect.alu
This won't work, because extra_cost->vect.alu is COSTS_N_INSNS (1),
which means the total is COSTS_N_INSNS (2).
The low
On 16/03/15 13:15, Kugan wrote:
On 16/03/15 23:32, Kugan wrote:
lower-subreg.c:compute_costs() only cares about the cost of a (set (reg)
(const_int )) move but I think the intention, at least for now, is to
return extra_cost->vect.alu for all the vector operations.
Almost, what we want at the
I've been experimenting with revamping our diagnostics to better show
source locations. Some of the ideas are inspired by Clang's
diagnostics, but I'm going beyond what it does in some areas.
I'm attaching a patch (against r221423), which is very much a
work-in-progress, but in a "release early,
On 16 March 2015 at 17:52, David Malcolm wrote:
> I've been experimenting with revamping our diagnostics to better show
> source locations. Some of the ideas are inspired by Clang's
> diagnostics, but I'm going beyond what it does in some areas.
>
> I'm attaching a patch (against r221423), which
If there is an alignment mismatch without user intervention, there is a
problem, we can't just ignore it.
Where we run into trouble is with array types where the version built
earlier has not been laid out yet but the new one has been. I've been
trying to deal with that by making sure that we
OK for trunk, not for release branches.
Jason
On March 16, 2015 5:21:02 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>On the following testcase, gimple LIM creates a vector COND_EXPR
>(scalar
>condition, vector lhs, rhs2 and rhs3), but if we don't have
>corresponding
>vector mode for it, we ICE trying to expand the BLKmode COND_EXPR, as
>it is
>
On 03/16/15 07:36, Marek Polacek wrote:
This function is unused since matrix-reorg.c removal back in 2012. I think
there's no point in keeping it around.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-03-16 Marek Polacek
* cgraph.h (add_new_static_var): Remove declarati
This patch introduces a new avr specific command option '-nodevicelib' so that
linking of libdev.a can be bypassed.
The argument of -specs= is suffixed by %s instead of supplying the absolute
path. That way -specs= works with installation path that contains spaces.
avr_mct_t.library_name and
On Mon, Mar 16, 2015 at 07:15:59PM +0100, Richard Biener wrote:
> On March 16, 2015 5:21:02 PM GMT+01:00, Jakub Jelinek
> wrote:
> >On the following testcase, gimple LIM creates a vector COND_EXPR
> >(scalar
> >condition, vector lhs, rhs2 and rhs3), but if we don't have
> >corresponding
> >vector
On March 16, 2015 7:26:58 PM GMT+01:00, Jakub Jelinek wrote:
>On Mon, Mar 16, 2015 at 07:15:59PM +0100, Richard Biener wrote:
>> On March 16, 2015 5:21:02 PM GMT+01:00, Jakub Jelinek
> wrote:
>> >On the following testcase, gimple LIM creates a vector COND_EXPR
>> >(scalar
>> >condition, vector lhs
2015-03-16 19:07 GMT+01:00 Jason Merrill :
> If there is an alignment mismatch without user intervention, there is a
> problem, we can't just ignore it.
>
> Where we run into trouble is with array types where the version built
> earlier has not been laid out yet but the new one has been. I've been
On Wed, Mar 11, 2015 at 03:30:36PM -0600, Jeff Law wrote:
> +#ifndef GCC_GCSE__COMMONH
> +#define GCC_GCSE__COMMONH
GCC_GCSE_COMMON_H instead?
> @@ -1308,8 +1396,19 @@ gcse_after_reload_main (rtx f ATTRIBUTE_UNUSED)
>
>if (expr_table->elements () > 0)
> {
> + /* Knowing which MEMs
2015-03-16 20:22 GMT+01:00 Kai Tietz :
> 2015-03-16 19:07 GMT+01:00 Jason Merrill :
>> If there is an alignment mismatch without user intervention, there is a
>> problem, we can't just ignore it.
>>
>> Where we run into trouble is with array types where the version built
>> earlier has not been lai
On 03/16/15 13:27, Jakub Jelinek wrote:
On Wed, Mar 11, 2015 at 03:30:36PM -0600, Jeff Law wrote:
+#ifndef GCC_GCSE__COMMONH
+#define GCC_GCSE__COMMONH
GCC_GCSE_COMMON_H instead?
:-) Will fix.
@@ -1308,8 +1396,19 @@ gcse_after_reload_main (rtx f ATTRIBUTE_UNUSED)
if (expr_table->elem
On Fri, 13 Mar 2015, H.J. Lu wrote:
> I am working on SHF_COMPRESSED support:
>
> http://www.sco.com/developers/gabi/latest/ch4.sheader.html
>
> I will import zlib from GCC source tree into binutils-gdb tree. But zlib
> failed to build as a target library in binutils-gdb. There is no need to
>
On Mon, Mar 16, 2015 at 3:50 PM, Joseph Myers wrote:
> On Fri, 13 Mar 2015, H.J. Lu wrote:
>
>> I am working on SHF_COMPRESSED support:
>>
>> http://www.sco.com/developers/gabi/latest/ch4.sheader.html
>>
>> I will import zlib from GCC source tree into binutils-gdb tree. But zlib
>> failed to buil
On Mon, 16 Mar 2015, H.J. Lu wrote:
> On Mon, Mar 16, 2015 at 3:50 PM, Joseph Myers wrote:
> > On Fri, 13 Mar 2015, H.J. Lu wrote:
> >
> >> I am working on SHF_COMPRESSED support:
> >>
> >> http://www.sco.com/developers/gabi/latest/ch4.sheader.html
> >>
> >> I will import zlib from GCC source tre
On Mon, Mar 16, 2015 at 4:41 PM, Joseph Myers wrote:
> On Mon, 16 Mar 2015, H.J. Lu wrote:
>
>> On Mon, Mar 16, 2015 at 3:50 PM, Joseph Myers
>> wrote:
>> > On Fri, 13 Mar 2015, H.J. Lu wrote:
>> >
>> >> I am working on SHF_COMPRESSED support:
>> >>
>> >> http://www.sco.com/developers/gabi/lates
On Mon, 16 Mar 2015, Eric Botcazou wrote:
> > If we have BIGGEST_ALIGNMENT=16 that means we have likely a 16 bit
> > architecture. I doubt that the strict alignment code makes any sense for
> > modesize> BIGGEST_ALIGNMENT.
>
> Note that m68k is a 32-bit port (UNITS_PER_WORD is 4) but, by definition
Hans-Peter Nilsson writes:
> Q: So why not adjust the BIGGEST_ALIGNMENT definition in such
> targets to be at least the natural alignment of supported
> atomic types?
A: Because it's an ABI change.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 175
On Tue, 17 Mar 2015, Andreas Schwab wrote:
> Hans-Peter Nilsson writes:
>
> > Q: So why not adjust the BIGGEST_ALIGNMENT definition in such
> > targets to be at least the natural alignment of supported
> > atomic types?
>
> A: Because it's an ABI change.
I intended that to be included in "bad eff
On 17/03/15 03:48, Kyrill Tkachov wrote:
>
> On 16/03/15 13:15, Kugan wrote:
>> On 16/03/15 23:32, Kugan wrote:
> lower-subreg.c:compute_costs() only cares about the cost of a (set
> (reg)
> (const_int )) move but I think the intention, at least for now, is to
> return extra_cost
On Mon, Mar 16, 2015 at 4:43 PM, H.J. Lu wrote:
> On Mon, Mar 16, 2015 at 4:41 PM, Joseph Myers wrote:
>> On Mon, 16 Mar 2015, H.J. Lu wrote:
>>
>>> On Mon, Mar 16, 2015 at 3:50 PM, Joseph Myers
>>> wrote:
>>> > On Fri, 13 Mar 2015, H.J. Lu wrote:
>>> >
>>> >> I am working on SHF_COMPRESSED sup
On Mon, Mar 16, 2015 at 7:26 PM, H.J. Lu wrote:
> On Mon, Mar 16, 2015 at 4:43 PM, H.J. Lu wrote:
>> On Mon, Mar 16, 2015 at 4:41 PM, Joseph Myers
>> wrote:
>>> On Mon, 16 Mar 2015, H.J. Lu wrote:
>>>
On Mon, Mar 16, 2015 at 3:50 PM, Joseph Myers
wrote:
> On Fri, 13 Mar 2015, H
On Fri, Mar 13, 2015 at 7:56 PM, Ramana Radhakrishnan
wrote:
> On Fri, Mar 6, 2015 at 7:46 AM, Bin Cheng wrote:
>> Hi,
>> This patch is the second part fixing memset-inline-{4,5,6,8,9}.c failures on
>> cortex-a9. It adds a function checking CPU tuning information in dejagnu,
>> it also uses that
Dear Tobias,
As far as I can see, without the patch, gfc_get _derived_type goes
into a continuous loop trying to build the abstract type. Why this is
not the case with an additional non-procedure pointer component, I do
not know. I suspect that there is a corner case out there that will
challenge
2015-03-16 21:17 GMT+03:00 Georg-Johann Lay :
> This patch introduces a new avr specific command option '-nodevicelib' so
> that linking of libdev.a can be bypassed.
>
> The argument of -specs= is suffixed by %s instead of supplying the absolute
> path. That way -specs= works with installation pat
61 matches
Mail list logo
