On Wed, 9 May 2012, Eric Botcazou wrote:
> > This optimizes byte_from_pos and pos_from_bit by noting that we operate
> > on sizes whose computations have no intermediate (or final) overflow.
> > This is the single patch necessary to get Ada to bootstrap and test
> > with TYPE_IS_SIZETYPE removed.
On Wed, May 9, 2012 at 10:38 PM, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on mainline and 4.7 branch. On the attached
> testcase, the compiler aborts in LTO mode with:
>
> eric@atlantis:~/build/gcc/native32> gcc/xgcc -Bgcc -S lto11.adb -O -flto
> +===GNA
On Wed, 9 May 2012, Eric Botcazou wrote:
> > This removes the TYPE_IS_SIZETYPE macro and all its uses (by
> > assuming it returns zero and applying trivial folding). Sizes
> > and bitsizes can still be treat specially by means of knowing
> > what the values represent and by means of using helper
On 10 May 2012 07:55, Miles Bader wrote:
> Paolo Carlini writes:
>> in case my message ends up garbled, the carets do not point to &&
>> (column 13), two times point to b (column 20), which is obviously
>> wrong. In other terms, all the columns are 20, all wrong.
>
> The new caret support does se
On May 8, 2012, at 5:39 PM, Tom Tromey wrote:
>> "Tristan" == Tristan Gingold writes:
>
> Tristan> 2012-05-04 Tristan Gingold
> Tristan> * expr.c (interpret_float_suffix): Add a guard.
>
> Ok.
Thanks, now committed.
On Wed, May 9, 2012 at 11:02 PM, Manuel López-Ibáñez
wrote:
> Simple enough. Bootstrapped and regression tested.
>
> The output for the example in the PR is now:
>
> /home/manuel/caret-overload.C:6:6: error: no matching function for
> call to ‘g(int)’
> g(1);
> ^
> /home/manuel/caret-overlo
Alexandre Oliva a écrit:
[...]
> Anyway, the problem is that, for some unsuitable candidate template
> specializations, tsubst returns error_mark_node, which tsubst_decl
> stores in argvec, and later on register_specialization gets this
> error_mark_node and tries to access it as a tree_vec.
>
>
On Thu, May 10, 2012 at 2:31 AM, Xinliang David Li wrote:
> Bummer. I was thinking to reserve '=' for selective dumping:
>
> -fdump-tree-pre=
>
> I guess this can be achieved via @
>
> -fdump-tree-pre@
>
> -fdump-tree-pre=@
>
>
> Another issue -- I don't think the current precedence rule is corr
Okay, I have restored the original behavior where standard streams
were considered weak. Thus in case of a conflict, the
standard streams have lower precedence. For example,
gcc -O2 -fdump-tree-pre=stdout -fdump-tree-pre ...
does the PRE dump in auto numbered file since stdout has
Hello,
This patch fix the misspelled macro in t-vxworks. Is it OK?
2012-05-10 Mingjie Xing
* config/mips/t-vxworks: Change MUTLILIB_EXTRA_OPTS to
MULTILIB_EXTRA_OPTS.
Index: config/mips/t-vxworks
===
--- config/
Paolo Bonzini writes:
>> 2012-04-26 Rainer Orth
>>
>> libgcc:
>> * config.host (i[34567]86-*-linux*, x86_64-*-linux*)
>> (i[34567]86-*-kfreebsd*-gnu, x86_64-*-kfreebsd*-gnu)
>> (i[34567]86-*-knetbsd*-gnu, i[34567]86-*-gnu*): Move
>> i386/t-cpuinfo ...
>> (i[34567
As described in the PR, several 32-bit libatomic tests FAIL on
Solaris/x86 with infinite recursion e.g. in
__atomic_compare_exchange_8. It turns out that this happens because,
unlike on glibc targets, the atomic builtin configure tests are run as
compile tests, but are currently not compiled with
On Thu, 10 May 2012, Richard Guenther wrote:
> On Wed, 9 May 2012, Eric Botcazou wrote:
>
> > > This removes the TYPE_IS_SIZETYPE macro and all its uses (by
> > > assuming it returns zero and applying trivial folding). Sizes
> > > and bitsizes can still be treat specially by means of knowing
> >
> Like this?
Let's be a bit more factual. :-)
/* Return the combined truncated byte position for the byte offset OFFSET and
the bit position BITPOS.
These functions operate on byte and bit positions present in FIELD_DECLs
and assume that these expressions result in no (intermediate)
> Hmm, but we will not possibly refer to the sizes therein, so emitting
> stmts for them
> looks pointless ... (and in fact the debug information would be odd,
> too ... what
> does dwarf2out.c do with these CALL_EXPRs when generating debug information
> without LTO?)
All variable-sized types curr
On Thu, 10 May 2012, Eric Botcazou wrote:
> > Like this?
>
> Let's be a bit more factual. :-)
>
> /* Return the combined truncated byte position for the byte offset OFFSET and
> the bit position BITPOS.
>
> These functions operate on byte and bit positions present in FIELD_DECLs
>
> As far as I can see this happens when we fold
>
> (bitsizetype) (#1 + 7) * 8 + 7 PLUS_EXPR 1
>
> which we fold to
>
> ((bitsizetype) (#1 + 7) + 1) * 8
>
> The #1 + 7 expression is computed in sizetype (which is now unsigned
> and thus has defined overflow - thus we cannot optimize the widenin
On Thu, May 10, 2012 at 12:12 PM, Eric Botcazou wrote:
>> Hmm, but we will not possibly refer to the sizes therein, so emitting
>> stmts for them
>> looks pointless ... (and in fact the debug information would be odd,
>> too ... what
>> does dwarf2out.c do with these CALL_EXPRs when generating deb
On 9 May 2012 11:18, Christophe Lyon wrote:
> Hello,
>
> On ARM+Neon, the expansion of vld1q_dup_s64() and vld1q_dup_u64() builtins
> currently fails to load the second vector element.
Thanks for the patch but this is not acceptable as it stands today.
You need to set the length attributes in thi
On Thu, May 10, 2012 at 12:26 PM, Eric Botcazou wrote:
>> As far as I can see this happens when we fold
>>
>> (bitsizetype) (#1 + 7) * 8 + 7 PLUS_EXPR 1
>>
>> which we fold to
>>
>> ((bitsizetype) (#1 + 7) + 1) * 8
>>
>> The #1 + 7 expression is computed in sizetype (which is now unsigned
>> a
Hi,
I am getting a segfault in ira-color.c:2945 on the trunk:
Program received signal SIGSEGV, Segmentation fault.
0x00a79f37 in move_spill_restore () at ../../src/gcc/ira-color.c:2945
2945 || ira_reg_equiv_const[regno] != NULL_RTX
(gdb) l
2940 /* don't d
OK.
Jason
On Wed, 9 May 2012, Manuel L?pez-Ib??ez wrote:
> 2012-05-09 Manuel L?pez-Ib??ez
>
> PR 53063
> gcc/
> * doc/options.texi (EnabledBy): Document
> * opts.c: Include opts.h and options.h before tm.h.
> (finish_options): Do not handle some sub-options here...
> (commo
Looks good.
Jason
On 05/09/2012 07:12 PM, Paolo Carlini wrote:
shame on me. I think the patch almost qualifies as obvious.
I think it does. OK.
Jason
On 05/09/2012 02:47 PM, Paolo Carlini wrote:
+ error_at(loc, "cannot bind bitfield %qE to %qT",
Missing a space.
OK with that change.
Jason
Hi,
> On 05/09/2012 07:12 PM, Paolo Carlini wrote:
>> shame on me. I think the patch almost qualifies as obvious.
>
> I think it does. OK.
Good, later today I'll commit it (branch too).
Was thinking: would it make sense to have a predicate for 'any' pointer type? I
see tens of such || around
On 05/10/2012 10:52 AM, Paolo Carlini wrote:
Was thinking: would it make sense to have a predicate for 'any' pointer type?
Something like TYPE_PTR_OR_PTRMEM_P would be fine.
Hmm, I see that TYPE_PTRMEM_P only means pointer to data member, that's
unfortunate; the name doesn't make that clear.
Hi,
> On 05/10/2012 10:52 AM, Paolo Carlini wrote:
>> Was thinking: would it make sense to have a predicate for 'any' pointer type?
>
> Something like TYPE_PTR_OR_PTRMEM_P would be fine.
Good.
> Hmm, I see that TYPE_PTRMEM_P only means pointer to data member, that's
> unfortunate; the name doe
On 05/09/2012 06:27 PM, DJ Delorie wrote:
H8/300 cpus have a larger-than-64k address space, despite 16-bit
pointers. OK to apply? Ok for 4.7 branch?
See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231
* config/h8300/h8300.h (DWARF2_ADDR_SIZE): Define as 4 bytes.
My recollection
On 10.05.2012 13:41, Ramana Radhakrishnan wrote:
On 9 May 2012 11:18, Christophe Lyon wrote:
Hello,
On ARM+Neon, the expansion of vld1q_dup_s64() and vld1q_dup_u64() builtins
currently fails to load the second vector element.
Thanks for the patch but this is not acceptable as it stands today.
On 10 May 2012 17:02, Paolo Carlini wrote:
> Hi,
>
>> On 05/10/2012 10:52 AM, Paolo Carlini wrote:
>>> Was thinking: would it make sense to have a predicate for 'any' pointer
>>> type?
>>
>> Something like TYPE_PTR_OR_PTRMEM_P would be fine.
>
> Good.
>
>> Hmm, I see that TYPE_PTRMEM_P only means
On Thu, 10 May 2012 17:31:43 +0200
Christophe Lyon wrote:
> On 10.05.2012 13:41, Ramana Radhakrishnan wrote:
> > On 9 May 2012 11:18, Christophe Lyon wrote:
> >> Hello,
> >>
> >> On ARM+Neon, the expansion of vld1q_dup_s64() and vld1q_dup_u64()
> >> builtins currently fails to load the second ve
The enclosed patch fixes many issues with pubnames and pubtypes. It generates
them for many more variables and with mostly correct and canonical dwarf names.
This patch should not affect any target that does not use pubnames.
The exceptions to the canonical names are addressed in a separate patch
> For example
>
> Index: stor-layout.c
> ===
> --- stor-layout.c (revision 187364)
> +++ stor-layout.c (working copy)
> @@ -791,6 +791,10 @@ start_record_layout (tree t)
> tree
> bit_from_pos (tree offset, tree bitpos)
> {
>
I like your suggestion and support the end goal you have. I don't
like the -fopt-info behavior to interfere with regular -fdump-xxx
options either.
I think we should stage the changes in multiple steps as originally
planned. Is Sharad's change good to be checked in for the first stage?
After thi
Backporting this patch to 4.7 fixes a problem building Fedora 17.
Bootstrapped and regression tested on powerpc64-unknown-linux-gnu. Is
the backport OK?
Thanks,
Bill
2012-05-10 Bill Schmidt
Backport from trunk:
2012-03-12 Richard Guenther
* tree.c (signed_or_unsi
On Thu, May 10, 2012 at 11:44:27AM -0500, William J. Schmidt wrote:
> Backporting this patch to 4.7 fixes a problem building Fedora 17.
> Bootstrapped and regression tested on powerpc64-unknown-linux-gnu. Is
> the backport OK?
For 4.7 I'd very much prefer a less intrusive change (i.e. change
the
On Thu, 2012-05-10 at 18:49 +0200, Jakub Jelinek wrote:
> On Thu, May 10, 2012 at 11:44:27AM -0500, William J. Schmidt wrote:
> > Backporting this patch to 4.7 fixes a problem building Fedora 17.
> > Bootstrapped and regression tested on powerpc64-unknown-linux-gnu. Is
> > the backport OK?
>
> Fo
> Regardless, shouldn't DWARF2_ADDR_SIZE be POINTER_SIZE / BITS_PER_UNIT?
That's the default. It doesn't work because pointers are still 16 bits.
Sorry for my late reply.
Manuel López-Ibáñez writes:
> This patch fixes almost all false positives in PR43772. The case not fixed is:
>
> intmax_t i = (whatever);
> if (INT_MAX < i && i <= LONG_MAX)
> print ("i is in 'long' but not 'int' ran")
>
> where we warn if INT_MAX = LONG_MAX < I
On Wed, May 9, 2012 at 12:01 PM, Sriraman Tallam wrote:
> Hi,
>
> Attached new patch with more bug fixes. I will fix the dispatching
> method to use prioirty of attributes in the next iteration.
>
> Patch also available for review here: http://codereview.appspot.com/5752064
>
The patch looks OK
Mingjie Xing writes:
> This patch fix the misspelled macro in t-vxworks. Is it OK?
>
> 2012-05-10 Mingjie Xing
>
> * config/mips/t-vxworks: Change MUTLILIB_EXTRA_OPTS to
> MULTILIB_EXTRA_OPTS.
OK, thanks.
Richard
Hello!
Introduce handling of TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL and
TARGET_SSE_TYPELESS_STORES flags to movoi, movti and movtf move
patterns. Also introduce ssePSmode attribute to determine PSmode at
compile time.
2012-05-10 Uros Bizjak
* config/i386/i386.md (*movoi_internal_avx):
The following patch is for PR53125. The PR is described on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125.
The patch improves the compilation speed by 35% for the case.
The patch was successfully bootstrapped on x86-64.
Committed as rev. 187373.
2012-05-10 Vladimir Makarov
PR rt
Hello,
could an i386 maintainer take a look at the following testcase?
gcc/testsuite/ChangeLog
2012-05-08 Marc Glisse
* gcc.target/i386/shuf-concat.c: New test.
--- gcc.target/i386/shuf-concat.c (revision 0)
+++ gcc.target/i386/shuf-concat.c (revision 0)
@@ -0,0 +1,13 @
Hi,
after some thought, the changes into omp-low are not as obviously harmless as I
originally tought. So i decided to handle this by separate patch. This patch
simply makes cgraph to not release bodies of artificial functions that papers
around the problem in easier way.
Bootstrapped/regtested
Any comment?
On Mon, 30 Apr 2012, Marc Glisse wrote:
Ping?
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01034.html
Since then, I've run a c,c++ bootstrap and:
make -k check RUNTESTFLAGS="--target_board=my-sde-sim"
where my-sde-sim is the dejagnu board posted by H.J. Lu to run tests inside
In
On 05/10/2012 09:10 AM, Tristan Gingold wrote:
Hi,
I am getting a segfault in ira-color.c:2945 on the trunk:
Program received signal SIGSEGV, Segmentation fault.
0x00a79f37 in move_spill_restore () at ../../src/gcc/ira-color.c:2945
2945 || ira_reg_equiv_const[regno] !=
On 05/08/2012 01:29 AM, Eric Botcazou wrote:
Fix debug info of nested inline functions:
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00161.html
I'll leave this one for Jason.
Emit variable as size attribute in debug info:
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00422.html
Implemen
Hi,
Yes, please. It feels as if the names are based more on the underlying
implementation of the macro than on anything else. Also, short names
are nice, but using MEM instead of MEMBER is a bit too short. The same
for OB for object and others.
PTR_OR_PTRMEM sounds to me like "pointer or pointer
Hi,
Mozilla LTO build broke due because symtab_remove_unreachable_nodes incorrectly
removes origins of clones
in some special cases.
Bootstrapped/regtested x97_64-linux and comitted.
Index: ipa.c
===
--- ipa.c (revision 187375)
Hi,
this patch cuts 10 minutes of Mozilla compilation time that is spent by
updating keys.
After Richi's removal of overall growth from the cost functions, we no longer
need to
update that much.
Bootstrapped/regtested x86_64-linux and tested on Mozilla build. Comitted.
Honza
* ipa-inli
Hello!
There is no point to emit vmovaps instead of vmovapd or vmovdqa, these
instructions have same sizes. Attached patch fixes this oversight for
TARGET_AVX.
2012-05-11 Uros Bizjak
* config/i386/i386.md (*movti_internal_rex64): Avoid MOVAPS size
optimization for TARGET_AVX.
Hello!
2012-05-11 Uros Bizjak
PR target/53291
* config/i386/i386.md (xtest): Use NE condition in ix86_expand_setcc.
Tested on x86_64-pc-linux-gnu {,-m32}, and by Andi.
Committed to mainline SVN.
Uros.
Index: config/i386/i386.md
==
Hi,
an ICE on invalid (per Daniel's analysis): when r is NULL_TREE the next
DECL_CONTEXT (r) can only crash. Plus a garbled error message because
pp_cxx_simple_type_specifier doesn't handle BOUND_TEMPLATE_TEMPLATE_PARM.
Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
201
Hello!
Recently testsuite/gcc.c-torture/execute/ieee/pr50310.c started to ICE
when compiled with -O3 -mieee on alphaev68-pc-linux-gnu:
$ ~/gcc-build-alpha/gcc/cc1 -O3 -mieee -quiet pr50310.c
pr50310.c: In function ‘foo’:
pr50310.c:31:20: internal compiler error: in
alpha_emit_conditional_move, at
2012/5/11 Richard Sandiford :
> Mingjie Xing writes:
>> This patch fix the misspelled macro in t-vxworks. Is it OK?
>>
>> 2012-05-10 Mingjie Xing
>>
>> * config/mips/t-vxworks: Change MUTLILIB_EXTRA_OPTS to
>> MULTILIB_EXTRA_OPTS.
>
> OK, thanks.
>
> Richard
Committed revision
On Thu, May 10, 2012 at 6:40 PM, Paolo Carlini wrote:
> Hi,
>
> an ICE on invalid (per Daniel's analysis): when r is NULL_TREE the next
> DECL_CONTEXT (r) can only crash. Plus a garbled error message because
> pp_cxx_simple_type_specifier doesn't handle BOUND_TEMPLATE_TEMPLATE_PARM.
>
> Tested x86
Hi,
This patch adds RTM support to -march=native. Tested on Linux/x86-64.
OK for trunk?
Thanks.
H.J.
---
2012-05-10 H.J. Lu
* config/i386/driver-i386.c (host_detect_local_cpu): Support
RTM.
diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
index 8fe
On 05/10/2012 11:21 AM, DJ Delorie wrote:
Regardless, shouldn't DWARF2_ADDR_SIZE be POINTER_SIZE / BITS_PER_UNIT?
That's the default. It doesn't work because pointers are still 16 bits.
Something's still not right then. The H8/300 has 16 bit pointers and a
64k address space and all the proce
> > That's the default. It doesn't work because pointers are still 16 bits.
>
> Something's still not right then. The H8/300 has 16 bit pointers and a
> 64k address space and all the processors in the family still support
> that mode.
The problem is when a single object is more than 64k for t
On 05/10/2012 09:55 PM, DJ Delorie wrote:
That's the default. It doesn't work because pointers are still 16 bits.
Something's still not right then. The H8/300 has 16 bit pointers and a
64k address space and all the processors in the family still support
that mode.
The problem is when a sing
Whereas making dwarf addresses always 32 bits only affects debugging
info size (not rom image size) on the oldest and smallest H8/300
variant, where real-world code would have a limited amount of debug
information anyway.
On 05/10/2012 05:31 PM, Paolo Carlini wrote:
Let's see if we can do something *now* ;) My concrete proposal would be:
TYPE_PTRMEM_P rename to TYPE_PTRDATAMEM_P (consistent with
TYPE_PTRMEMFUNC_P)
TYPE_PTR_TO_MEMBER_P rename to TYPE_PTRMEM_P
and then finally
#define TYPE_PTR_OR_PTRMEM_P(NODE) \
On 10.05.2012 08:42, Paolo Bonzini wrote:
> Il 09/05/2012 19:19, Matthias Klose ha scritto:
>> these are referenced from the http://wiki.debian.org/Multiarch/Tuples
>> https://wiki.ubuntu.com/MultiarchSpec#Filesystem_layout
>> http://err.no/debian/amd64-multiarch-3
>>
>> http://wiki.debian.org/Mult
As described in gcc/go/README.gcc, the files in gcc/go/gofrontend are
copied from http://code.google.com/p/gofrontend . Changes should be
committed there first, and mirrored to the GCC repository. Also,
changes committed to that repository are not listed in
gcc/go/ChangeLog. A recent patch updat
67 matches
Mail list logo
