> Huh? If they have DECL_FIELD_BIT_OFFSET of zero they are at a byte
> boundary, no? Wait - the RECORD_TYPE itself is at non-zero
> DECL_FIELD_BIT_OFFSET and thus a zero DECL_FIELD_BIT_OFFSET for its
> fields does not mean anything?!
DECL_FIELD_BIT_OFFSET is relative to the enclosing record type
> Btw, now checking with gdb, DECL_OFFSET_ALIGN is always 128 for
> all of the fields - that looks bogus. DECL_ALIGN is 1, but that
> doesn't mean DECL_OFFSET_ALIGN should not be 1 as well, no?
DECL_OFFSET_ALIGN is set to BIGGEST_ALIGNMENT for the first field, see
start_record_layout. If DECL_F
On Sat, Mar 24, 2012 at 9:25 PM, Steven Bosscher wrote:
> Hello,
>
> This patch tightens the conditions on when assemble_external() may be
> called. It also removes a comment that "most platforms do not define
> ASM_OUTPUT_EXTERNAL", because hasn't been true since r119764 added a
> definition of A
On Mon, Mar 26, 2012 at 1:27 AM, Steven Bosscher wrote:
> Hello,
>
> This patch removes all calls to assemble_external from places other
> than final.c and MI-thunk generators.
>
> This is step 2 toward addressing PR17982 on the trunk for GCC 4.8. The
> next, and final, step will be to change pend
On Mon, Mar 26, 2012 at 9:18 AM, Eric Botcazou wrote:
>> Btw, now checking with gdb, DECL_OFFSET_ALIGN is always 128 for
>> all of the fields - that looks bogus. DECL_ALIGN is 1, but that
>> doesn't mean DECL_OFFSET_ALIGN should not be 1 as well, no?
>
> DECL_OFFSET_ALIGN is set to BIGGEST_ALIGNM
> Isn't DECL_OFFSET_ALIGN completely useless if it is "relative"?
Good question.
> But I wonder how we can even detect non-byte-alignment? I see the field has
> DECL_ALIGN of 1, but isn't that "relative" as well? At least I'm totally
> confused with DECL_OFFSET_ALIGN being "relative".
DECL_ALI
On Mon, Mar 26, 2012 at 9:43 AM, Eric Botcazou wrote:
>> Isn't DECL_OFFSET_ALIGN completely useless if it is "relative"?
>
> Good question.
The only use of DECL_OFFSET_ALIGN I see is in stor-layout.c itself:
/* If this field ended up more aligned than we thought it would be (we
approximat
> I think we indeed can't really in stor-layout, so the only place is very
> likely get_bit_range.
Something like that for example. I think the expmed.c hunk should be applied
to the 4.7 branch as well, because the new code in store_bit_field is quite
dangerous without it.
* expmed.c
> OTOH if DECL_ALIGN is absolute then if the first field of a record type has
> DECL_ALIGN that is a multiple of BITS_PER_UNIT we know we can use
> the present stor-layout code? So we can check that and give up computing
> representatives at all for a record type if that does not hold.
I don't th
On Mon, Mar 26, 2012 at 10:17 AM, Eric Botcazou wrote:
>> OTOH if DECL_ALIGN is absolute then if the first field of a record type has
>> DECL_ALIGN that is a multiple of BITS_PER_UNIT we know we can use
>> the present stor-layout code? So we can check that and give up computing
>> representatives
This is an out-of-bounds access in count_spilled_pseudo: we can enter the
function for a pseudo without hard reg but we immediately use the hard reg
number as an index:
static void
count_spilled_pseudo (int spilled, int spilled_nregs, int reg)
{
int freq = REG_FREQ (reg);
int r = reg_renumbe
On Mar 22, 2012, at 11:06 AM, Paolo Bonzini wrote:
> Il 22/03/2012 09:30, Tristan Gingold ha scritto:
>> Hi,
>>
>> this is version 2 of the patch.
>>
>> The initial problem is that libgfortran configure.ac used AC_CHECK_LIB([m]…)
>> to check wether several math functions are available. That d
On Mon, 26 Mar 2012, Eric Botcazou wrote:
> > I think we indeed can't really in stor-layout, so the only place is very
> > likely get_bit_range.
>
> Something like that for example. I think the expmed.c hunk should be applied
> to the 4.7 branch as well, because the new code in store_bit_field
Hi,
there was duplicated code for dealing with -mdebug-main in ia64_start_function
and alpha_start_function. This patch consolidates that.
The pointer size is recorded for function 'main', so that crt0 now expand
argv[] if needed; likewise of the return status code.
Manually tested on both ia
And the corresponding path is below...
On Mar 26, 2012, at 11:37 AM, Tristan Gingold wrote:
> Hi,
>
> there was duplicated code for dealing with -mdebug-main in
> ia64_start_function and alpha_start_function. This patch consolidates that.
>
> The pointer size is recorded for function 'main',
On 28/02/12 17:45, Andrew Stubbs wrote:
Hi all,
This patch adds a DImode negate pattern for NEON.
Unfortunately, the NEON vneg instruction only supports vectors, not
singletons, so there's no direct way to do it in DImode, and the
compiler ends up moving the value back to core registers, negati
>> Passes bootstrap and regression test powerpc64-linux.
>
> Thanks a lot, Alan!
>
> So, Aurelien, you only need to adjust the formatting of the patch and post a
> ChangeLog entry along with it. TIA.
>
Thanks Alan!
Bootstrap and regression test for m68k-elf ok, but I have trouble cross
compi
On Fri, 23 Mar 2012, Martin Jambor wrote:
> Hi,
>
> since we now should be able to expand misaligned MEM_REFs properly and
> both SRA and IPA-SRA now tag the memory accesses with the appropriate
> alignment information, we should now be able to get rid off the SRA
> disabling in the face of poten
Hi,
This is (hopefully) a permanent fix to pr46886.c
I removed the condition preventing parallelization of do_while loops, as
it
was blocking parallelizing important loops in spec-2006.
The patch fixes the number of iterations for cases where the body could
appear in the latch, as in pr46886.c
On Mon, 26 Mar 2012, Razya Ladelsky wrote:
> Hi,
>
> This is (hopefully) a permanent fix to pr46886.c
> I removed the condition preventing parallelization of do_while loops, as
> it
> was blocking parallelizing important loops in spec-2006.
> The patch fixes the number of iterations for cases
[sorry, I'm resending this because inadvertently I had some html and the
message got rejected]
Hi,
thus, I have been working on c++/50043, which boils down to this:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3204.htm
My basic idea so far is very simple:
--- class.c (revision 18
http://gcc.gnu.org/viewcvs?view=revision&revision=185793
http://gcc.gnu.org/viewcvs?view=revision&revision=185794
This adds LTO tests to avr-torture.exp:
* gcc.target/avr/torture/avr-torture.exp (AVR_TORTURE_OPTIONS):
Add "-Os -flto" to list.
Johann
On Fri, 23 Mar 2012, David Edelsohn wrote:
> The build process of libquadmath sometimes encounters problems on AIX
> due to multilib and LD_LIBRARY_PATH interfering with GCC's own library
> dependencies. Libquadmath is not used on AIX, so this patch adds it
> to noconfigdirs.
Please include this
On Sun, 25 Mar 2012, H.J. Lu wrote:
> Hi Joseph,
>
> I need to support InverseMask(XXX) in options without the corresponding
> Mask(XXX) since XXX is never set directly via a command line option. This
> patch adds a MaskNeeded property which turns InverseMask(XXX) into
> the inverse version of Ma
Hello,
one of Ira's vectorizer patches I recently committed seems to have exposed
a pre-existing bug in handling WIDEN_LSHIFT_EXPR, which now causes ICEs
in SLP due to out-of-bounds memory accesses.
The underlying cause is that vect_get_smallest_scalar_type does not handle
WIDEN_LSHIFT_EXPR as it
Richard Guenther wrote on 26/03/2012 01:23:15 PM:
> From: Richard Guenther
> To: Razya Ladelsky/Haifa/IBM@IBMIL
> Cc: gcc-patches@gcc.gnu.org
> Date: 26/03/2012 01:23 PM
> Subject: Re: [PATCH] Permanent Fix for PR46886
>
> On Mon, 26 Mar 2012, Razya Ladelsky wrote:
>
> > Hi,
> >
> > This is (
On Mon, Mar 26, 2012 at 1:57 PM, Ulrich Weigand wrote:
> Hello,
>
> one of Ira's vectorizer patches I recently committed seems to have exposed
> a pre-existing bug in handling WIDEN_LSHIFT_EXPR, which now causes ICEs
> in SLP due to out-of-bounds memory accesses.
>
> The underlying cause is that v
This fixes PR52701, we need to unconditionally remember the evolution
as irrelevant PHIs (apart from their final value) are not detected
as induction with variable step.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-03-26 Richard Guenther
PR tr
This fixes PR52721, vect_init_vector is appearantly also used to
init scalars ... the following patch fixes the ICE and adjusts
the comments/implementation to not suggest we are dealing with
vectors only.
Bootstrapped and tested on x86_64-unknown-linux-gnu, appplied to trunk.
Richard.
2012-03-2
This implements TARGET_BUILTIN_DECL which is needed to make
LTO work with target-specific built-ins.
struct avr_builtin_description gets a new field .fndecl which is
initialized during avr_init_builtins and looked up in new hook
avr_builtin_decl.
The built-ins are initialized in such a way that t
Hi All,
This patch fixes an ICE that occurs when attempting to fold nested INDIRECT_REF
trees that have conversions in between the indirect references. For example:
constexpr unsigned long b = *((ul_ptr)(*((ul_ptr)0x0)));
What happens is that 'cxx_fold_indirect_ref' gets the top indirect refere
Hi,
Please find the attached "h8300-func-vect.patch" that adds
'function_vector' attribute for H8300 target.
I have taken the reference from previously posted patch for GCC-3.4.2:
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02529.html
I have updated functionality of the attribute to GCC-4.7.0
> +
> + /* if the latch contains more than the one statemnt of control
variable
> + increment then it contains the body. */
> + if (exit_1->dest == loop->latch && last_and_only_stmt (loop->latch))
> new_rhs = gimple_cond_rhs (cond_stmt);
>
> please check what the comment suggests, t
On Mon, 26 Mar 2012, Razya Ladelsky wrote:
> > +
> > + /* if the latch contains more than the one statemnt of control
> variable
> > + increment then it contains the body. */
> > + if (exit_1->dest == loop->latch && last_and_only_stmt (loop->latch))
> > new_rhs = gimple_cond_rhs (co
On Mon, Mar 26, 2012 at 4:53 AM, Joseph S. Myers
wrote:
> On Sun, 25 Mar 2012, H.J. Lu wrote:
>
>> Hi Joseph,
>>
>> I need to support InverseMask(XXX) in options without the corresponding
>> Mask(XXX) since XXX is never set directly via a command line option. This
>> patch adds a MaskNeeded proper
On 03/26/2012 08:18 AM, Ajinkya Dhobale wrote:
Hi,
Please find the attached "h8300-func-vect.patch" that adds
'function_vector' attribute for H8300 target.
I have taken the reference from previously posted patch for GCC-3.4.2:
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02529.html
I have upda
On Mon, Mar 26, 2012 at 06:17:08PM +0300, Janne Blomqvist wrote:
>
> currently in libgfortran we have two malloc() wrappers, get_mem and
> internal_malloc_size, which abort the program if malloc fails.
> internal_malloc_size does
>
> if (size == 0)
> size = 1;
>
> and then calls get_mem, whi
On Mon, Mar 26, 2012 at 18:37, Steve Kargl
wrote:
> On Mon, Mar 26, 2012 at 06:17:08PM +0300, Janne Blomqvist wrote:
>>
>> currently in libgfortran we have two malloc() wrappers, get_mem and
>> internal_malloc_size, which abort the program if malloc fails.
>> internal_malloc_size does
>>
>> if (si
Mangle TRAIT_EXPR and CONST_DECLs in template parameters.
We use the mangler to generate unique strings to represent types and symbols
that need to be merged. However, the C++ mangler does not handle all
possible combinations. This patch works around this problem by using
a combination of the pr
Fix check for empty statement list.
We do some sanity checks before starting to write a PPH image. The
check was inconsistent: for the VEC scope_chain->x_stmt_tree.x_cur_stmt_list
we were asserting that it was NULL *and* empty.
We just need it to be empty. It doesn't matter if it was allocated.
This initial set of timers measures time spent in the major phases of
PPH processing. We may want to add/remove timers as we measure
performance.
2012-03-26 Diego Novillo
cp/ChangeLog.pph
* pph-core.c (pph_include_handler): Use timer TV_PPH.
(pph_init): Likewise.
(pp
On Mon, Mar 26, 2012 at 9:25 AM, Richard Guenther
wrote:
> On Sat, Mar 24, 2012 at 9:25 PM, Steven Bosscher
> wrote:
>> Hello,
>>
>> This patch tightens the conditions on when assemble_external() may be
>> called. It also removes a comment that "most platforms do not define
>> ASM_OUTPUT_EXTERNA
On Mon, Mar 26, 2012 at 9:31 AM, Richard Guenther
wrote:
> On Mon, Mar 26, 2012 at 1:27 AM, Steven Bosscher
> wrote:
>> Hello,
>>
>> This patch removes all calls to assemble_external from places other
>> than final.c and MI-thunk generators.
>>
>> This is step 2 toward addressing PR17982 on the
Ok for google branches (main and 4_7).
thanks,
David
On Wed, Mar 21, 2012 at 2:45 PM, Harshit Chopra wrote:
> 2012-03-21 Harshit Chopra
>
> Minor changes:
> i386.c: made check_should_patch_current_function C90 compatible.
> i386.md: Added '\t' to bytes generated by
> ix86
On Wed, Mar 21, 2012 at 9:35 PM, Diego Novillo wrote:
> On 3/21/12 3:30 PM, Steven Bosscher wrote:
>
>> +/* FIXME: Trunk is at GCC 4.8 now and the above problem still hasn't been
>> + addressed properly. This caused PR 52640 due to O(external_decls**2)
>> + lookups in the pending_assemble_ext
On Mon, Mar 26, 2012 at 7:47 AM, H.J. Lu wrote:
> On Mon, Mar 26, 2012 at 4:53 AM, Joseph S. Myers
> wrote:
>> On Sun, 25 Mar 2012, H.J. Lu wrote:
>>
>>> Hi Joseph,
>>>
>>> I need to support InverseMask(XXX) in options without the corresponding
>>> Mask(XXX) since XXX is never set directly via a
Hello!
In a corner case of a reload, reload pass can generate partially
reloaded address, where not all registers get allocated to a hard reg.
When this address is checked with ix86_legitimate_address, it is
rejected, since in strict mode, pseudos are not valid address
registers. So, reload tries
Adjust expected patterns in some tests.
After the mangling adjustments I made earlier, these tests are
now passing and or failing in a different way. Adjusted.
2012-03-26 Diego Novillo
* g++.dg/pph/x6dynarray4.cc: Adjust expected patterns.
* g++.dg/pph/x6dynarray5.h: Likewis
On Mon, Mar 26, 2012 at 10:25 AM, Uros Bizjak wrote:
> Hello!
>
> In a corner case of a reload, reload pass can generate partially
> reloaded address, where not all registers get allocated to a hard reg.
> When this address is checked with ix86_legitimate_address, it is
> rejected, since in strict
> Uh. When is a field a bit field though? At least stor-layout.c
> resets DECL_BIT_FIELD
> when local relative alignment is "proper" and the filed has an integer
> mode. That's
> overly optimistic if the record is placed at a bit position. Of
> course we still have
> DECL_BIT_FIELD_TYPE, but I
> The patch looks reasonable - can we compute this backward from the
> result of the outer get_inner_reference call and the outermost
> field-decl though? Or make get_inner_reference compute that while
> analyzing the full reference and return a flag? OTOH it shouldn't
> be too expensive.
There
On Mon, Mar 26, 2012 at 9:26 AM, Steven Bosscher wrote:
> On Mon, Mar 26, 2012 at 9:31 AM, Richard Guenther
> wrote:
>> On Mon, Mar 26, 2012 at 1:27 AM, Steven Bosscher
>> wrote:
>>> Hello,
>>>
>>> This patch removes all calls to assemble_external from places other
>>> than final.c and MI-thunk
On Mon, Mar 26, 2012 at 10:20 AM, H.J. Lu wrote:
> On Mon, Mar 26, 2012 at 7:47 AM, H.J. Lu wrote:
>> On Mon, Mar 26, 2012 at 4:53 AM, Joseph S. Myers
>> wrote:
>>> On Sun, 25 Mar 2012, H.J. Lu wrote:
>>>
Hi Joseph,
I need to support InverseMask(XXX) in options without the corresp
On Mon, Mar 26, 2012 at 8:22 PM, H.J. Lu wrote:
> It may have caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52730
It certainly seems so. Looking into it...
Ciao!
Steven
2012/3/26 Georg-Johann Lay :
> This implements TARGET_BUILTIN_DECL which is needed to make
> LTO work with target-specific built-ins.
>
> struct avr_builtin_description gets a new field .fndecl which is
> initialized during avr_init_builtins and looked up in new hook
> avr_builtin_decl.
>
> The bui
Steven Bosscher writes:
> On Wed, Mar 21, 2012 at 1:13 AM, Ian Lance Taylor wrote:
>> On Tue, Mar 20, 2012 at 2:06 PM, Steven Bosscher wrote:
>>>
>>> This patch splits a couple of pieces of cse_insn out to new functions.
>>> There are no functional changes, and no code generation differences as
>>
On Mon, Mar 26, 2012 at 10:41 AM, H.J. Lu wrote:
> On Mon, Mar 26, 2012 at 10:25 AM, Uros Bizjak wrote:
>> Hello!
>>
>> In a corner case of a reload, reload pass can generate partially
>> reloaded address, where not all registers get allocated to a hard reg.
>> When this address is checked with i
On Mon, Mar 26, 2012 at 9:02 PM, Richard Sandiford
wrote:
>> * cse.c (cse_canonicalized_basic_blocks): New simple bitmap to
>> tag basic blocks that have already been traversed at least once,
>> so that all insns have been canonicalized.
>> (cse_insn): Call canonicalize_ins
On Mar 23, 2012, at 3:01 AM, Richard Sandiford wrote:
> ...it doesn't mean that we interpret the value as a negative _rtx_.
> As with all rtx calculations, things like signedness and saturation are
> decided by the operation rather than the "type" ("type" == rtx mode).
Ah... [ light goes on ] Le
On 03/26/2012 07:22 AM, Paolo Carlini wrote:
My basic idea so far is very simple:
--- class.c (revision 185792)
+++ class.c (working copy)
@@ -1001,6 +1001,10 @@ add_method (tree type, tree method, tree using_dec
"destructor",
type);
}
+ else if (cxx_dialect >= cxx0x
+ && !TYPE_RAISES_EXCEPTIONS
Mike Stump writes:
> On Mar 23, 2012, at 3:01 AM, Richard Sandiford wrote:
>> ...it doesn't mean that we interpret the value as a negative _rtx_.
>> As with all rtx calculations, things like signedness and saturation are
>> decided by the operation rather than the "type" ("type" == rtx mode).
>
>
On Mon, Mar 26, 2012 at 8:51 PM, Steven Bosscher wrote:
> On Mon, Mar 26, 2012 at 8:22 PM, H.J. Lu wrote:
>> It may have caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52730
>
> It certainly seems so. Looking into it...
Java is the culprit. I'm going to commit the following patch to p
> Index: varasm.c
> ===
> --- varasm.c (revision 185823)
> +++ varasm.c (working copy)
> @@ -2170,6 +2170,10 @@
>If it's not, we should not be calling this function. */
>gcc_assert (asm_out_file);
>
> + /* In a perfect
Hello,
This patch is one way to address PR44982. I see no good reason to
cgraph_finalize_compilation_unit if there were parse errors. As Richi
already pointed out, GCC traditionally has proceeded after parse
errors to preserve warnings and errors we generate from the middle-end
and during semantic
On Mon, Mar 26, 2012 at 10:51 PM, Eric Botcazou wrote:
>> Index: varasm.c
>> ===
>> --- varasm.c (revision 185823)
>> +++ varasm.c (working copy)
>> @@ -2170,6 +2170,10 @@
>> If it's not, we should not be calling this functio
On Mon, Mar 26, 2012 at 11:44, Tristan Gingold wrote:
>
> On Mar 22, 2012, at 11:06 AM, Paolo Bonzini wrote:
>
>> Il 22/03/2012 09:30, Tristan Gingold ha scritto:
>>> Hi,
>>>
>>> this is version 2 of the patch.
>>>
>>> The initial problem is that libgfortran configure.ac used
>>> AC_CHECK_LIB([m]
Hi,
The attached patch generalizes the move insn displacement calculations a
little bit. Before, the same address rebasing code was present in
sh_legitimize_address as well as sh_legitimize_reload_address. I've
pulled those out into a separate function as a preparation step for
adding HImode dis
On 03/26/2012 09:31 PM, Jason Merrill wrote:
On 03/26/2012 07:22 AM, Paolo Carlini wrote:
My basic idea so far is very simple:
--- class.c (revision 185792)
+++ class.c (working copy)
@@ -1001,6 +1001,10 @@ add_method (tree type, tree method, tree
using_dec
"destructor",
type);
}
+ else if (c
On Mar 26, 2012, at 1:03 PM, Richard Sandiford wrote:
> I think:
>
> ...copies of the top bit. Note however that values are neither inherently
> signed nor inherently unsigned; where necessary, signedness is determined
> by the rtl operation instead.
Sounds good to me, changed.
> Same idea here
Hi,
An assembler directive with an operand is filtered through
output_asm_insn (or asm_fprintf for gcc internal asm() directives) to
expand the operand values in the assembler as well as to choose
dialects if present. This patch is concerned primarily with the
dialects, since their syntax prevent
Hi Kaz,
This patch fixes a case in sh.c:find_barrier(), triggered by a testcase
in glibc. The scanning starts from a GOT move instruction, records
itself in 'last_got', but does not find a second GOT move (to reset
last_got to NULL).
It finishes by trying to insert a new barrier in the insn strea
On Mon, 26 Mar 2012, Eric Botcazou wrote:
> > Uh. When is a field a bit field though? At least stor-layout.c
> > resets DECL_BIT_FIELD
> > when local relative alignment is "proper" and the filed has an integer
> > mode. That's
> > overly optimistic if the record is placed at a bit position. Of
On Mon, 26 Mar 2012, Eric Botcazou wrote:
> > The patch looks reasonable - can we compute this backward from the
> > result of the outer get_inner_reference call and the outermost
> > field-decl though? Or make get_inner_reference compute that while
> > analyzing the full reference and return a f
73 matches
Mail list logo
