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/Multiarch/TheCaseForMultiarch describes use cases for
Il 30/03/2012 12:08, Richard Sandiford ha scritto:
+ There are two useful preprocessor defines for use by maintainers:
+
+ #define LOG_COSTS
+
+ if you wish to see the actual cost estimates that are being used
+ for each mode wider than word mode and the cost estimates for
Il 10/05/2012 08:45, Paolo Bonzini ha scritto:
Il 30/03/2012 12:08, Richard Sandiford ha scritto:
+ There are two useful preprocessor defines for use by maintainers:
+
+ #define LOG_COSTS
+
+ if you wish to see the actual cost estimates that are being used
+ for each mode wider
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. Rather
On Wed, May 9, 2012 at 10:38 PM, Eric Botcazou ebotca...@adacore.com 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
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 mi...@gnu.org wrote:
Paolo Carlini paolo.carl...@oracle.com 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.
On May 8, 2012, at 5:39 PM, Tom Tromey wrote:
Tristan == Tristan Gingold ging...@adacore.com writes:
Tristan 2012-05-04 Tristan Gingold ging...@adacore.com
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
lopeziba...@gmail.com 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);
^
Alexandre Oliva aol...@redhat.com 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
On Thu, May 10, 2012 at 2:31 AM, Xinliang David Li davi...@google.com wrote:
Bummer. I was thinking to reserve '=' for selective dumping:
-fdump-tree-pre=func_list_regexp
I guess this can be achieved via @
-fdump-tree-pre@func_list
-fdump-tree-pre=file_name@func_list
Another issue --
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 mingjie.x...@gmail.com
* config/mips/t-vxworks: Change MUTLILIB_EXTRA_OPTS to
MULTILIB_EXTRA_OPTS.
Index: config/mips/t-vxworks
Paolo Bonzini bonz...@gnu.org writes:
2012-04-26 Rainer Orth r...@cebitec.uni-bielefeld.de
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
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
what the
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 currently
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
and
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 widening
to
On Thu, May 10, 2012 at 12:12 PM, Eric Botcazou ebotca...@adacore.com 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
On 9 May 2012 11:18, Christophe Lyon christophe.l...@st.com 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
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
OK.
Jason
Looks good.
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 and
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 doesn't
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
On 10.05.2012 13:41, Ramana Radhakrishnan wrote:
On 9 May 2012 11:18, Christophe Lyonchristophe.l...@st.com 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
On 10 May 2012 17:02, Paolo Carlini pcarl...@gmail.com 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 christophe.l...@st.com wrote:
On 10.05.2012 13:41, Ramana Radhakrishnan wrote:
On 9 May 2012 11:18, Christophe Lyonchristophe.l...@st.com wrote:
Hello,
On ARM+Neon, the expansion of vld1q_dup_s64() and vld1q_dup_u64()
builtins
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
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)
{
+ if
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
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 wschm...@vnet.linux.ibm.com
Backport from trunk:
2012-03-12 Richard Guenther
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?
For 4.7
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 lopeziba...@gmail.com 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 =
On Wed, May 9, 2012 at 12:01 PM, Sriraman Tallam tmsri...@google.com 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
Mingjie Xing mingjie.x...@gmail.com writes:
This patch fix the misspelled macro in t-vxworks. Is it OK?
2012-05-10 Mingjie Xing mingjie.x...@gmail.com
* 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 ubiz...@gmail.com
* config/i386/i386.md
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
Hello,
could an i386 maintainer take a look at the following testcase?
gcc/testsuite/ChangeLog
2012-05-08 Marc Glisse marc.gli...@inria.fr
* gcc.target/i386/shuf-concat.c: New test.
--- gcc.target/i386/shuf-concat.c (revision 0)
+++ gcc.target/i386/shuf-concat.c
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
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
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
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
*
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 ubiz...@gmail.com
* config/i386/i386.md (*movti_internal_rex64): Avoid MOVAPS size
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
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,
2012/5/11 Richard Sandiford rdsandif...@googlemail.com:
Mingjie Xing mingjie.x...@gmail.com writes:
This patch fix the misspelled macro in t-vxworks. Is it OK?
2012-05-10 Mingjie Xing mingjie.x...@gmail.com
* config/mips/t-vxworks: Change MUTLILIB_EXTRA_OPTS to
On Thu, May 10, 2012 at 6:40 PM, Paolo Carlini paolo.carl...@oracle.com 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
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 hongjiu...@intel.com
* config/i386/driver-i386.c (host_detect_local_cpu): Support
RTM.
diff --git a/gcc/config/i386/driver-i386.c
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
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 the
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
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
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
66 matches
Mail list logo
