From: Richard Sandiford rdsandif...@googlemail.com
Date: Tue, 1 May 2012 16:46:38 +0200
To repeat: as things stand, very few targets define proper rtx costs
for SET.
IMHO it's wrong to start blaming targets when rtx_cost doesn't
take the mode in account in the first place, for the default
On Tue, 8 May 2012, Richard Sandiford wrote:
Are you using a hard-float multilib for your -mabi=32/-mips16 Linux
testing?
Yeah. As an example:
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00393.html
which doesn't look to bad. Clean fortran results, which I expect
would
In response to comments, I have updated the patch to support dumps in
user provided files via the option -fdump-xxx=filename. The
filenames stdout/stderr are treated specially, and are considered
standard streams.
Also updated documentation and a testcase. Okay for trunk?
Thanks,
Sharad
On Wed, May 09, 2012 at 09:02:14AM +0800, Dehao Chen wrote:
Sorry for the error. Here is a new patch to fix them:
gcc/testsuite/ChangeLog:
2012-05-08 Dehao Chen de...@google.com
* gcc.dg/predict-1.c: Remove the replicated text in this text.
* gcc.dg/predict-2.c: Likewise.
On Tue, May 8, 2012 at 11:46 PM, Sharad Singhai sing...@google.com wrote:
In response to comments, I have updated the patch to support dumps in
user provided files via the option -fdump-xxx=filename. The
filenames stdout/stderr are treated specially, and are considered
standard streams.
I
On Wed, May 9, 2012 at 1:51 AM, Andrew Pinski pins...@gmail.com wrote:
On Tue, May 8, 2012 at 11:46 PM, Sharad Singhai sing...@google.com wrote:
In response to comments, I have updated the patch to support dumps in
user provided files via the option -fdump-xxx=filename. The
filenames
On 9 May 2012 01:34, Cary Coutant ccout...@google.com wrote:
A suggestion: Make dwarf_name call the demangler, and then a (new?) a
function that converts a mangled decl to a human-readable string. In
any case, the pretty-printer does a lot of stuff that is mostly
useless for just printing a
On Wed, May 9, 2012 at 1:46 AM, Sharad Singhai sing...@google.com wrote:
[...]
+@item -fdump-rtl-all=stderr
+@opindex fdump-rtl-all=stderr
You do not need to have a separate index entry for '=stderr' or '=stdout'.
Rather, expand the description to state this in all the documentation
for
On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li davi...@google.com wrote:
To be clear, this flag is for malloc implementation (such as tcmalloc)
with side effect unknown to the compiler. Using -fno-builtin-xxx is
too conservative for that purpose.
I don't think that flys. Btw, the patch
On Tue, May 8, 2012 at 8:33 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
The attached testcase loops endlessly, using more and more memory.
The problem is that the prev stmt iterator sometimes references stmts that
remove_prop_source_from_use decides to remove, and since Michael's
gimple
On Wed, May 9, 2012 at 4:12 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li davi...@google.com wrote:
To be clear, this flag is for malloc implementation (such as tcmalloc)
with side effect unknown to the compiler. Using -fno-builtin-xxx
Hans-Peter Nilsson hans-peter.nils...@axis.com writes:
From: Richard Sandiford rdsandif...@googlemail.com
Date: Tue, 1 May 2012 16:46:38 +0200
To repeat: as things stand, very few targets define proper rtx costs
for SET.
IMHO it's wrong to start blaming targets when rtx_cost doesn't
take
On Wed, May 9, 2012 at 10:38 AM, Dehao Chen de...@google.com wrote:
On Wed, May 9, 2012 at 4:12 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li davi...@google.com wrote:
To be clear, this flag is for malloc implementation (such as
On Tue, 8 May 2012, Richard Sandiford wrote:
gcc-mips16-gp-pseudo-loc.patch
Index: gcc-fsf-trunk-quilt/gcc/config/mips/mips.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/config/mips/mips.c 2012-05-02
23:42:46.185566469 +0100
Maciej W. Rozycki ma...@codesourcery.com writes:
On Tue, 8 May 2012, Richard Sandiford wrote:
gcc-mips16-gp-pseudo-loc.patch
Index: gcc-fsf-trunk-quilt/gcc/config/mips/mips.c
===
---
On 08/05/12 22:42, Richard Sandiford wrote:
Richard Earnshaw rearn...@arm.com writes:
FTR, this caused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278
Well, this really has been a brown-paper-bag patch. Fixed as below.
Tested on x86_64-linux-gnu and applied as obvious.
Richard
On Wed, May 9, 2012 at 5:22 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, May 9, 2012 at 10:38 AM, Dehao Chen de...@google.com wrote:
On Wed, May 9, 2012 at 4:12 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li
On Wed, May 9, 2012 at 11:48 AM, Dehao Chen de...@google.com wrote:
On Wed, May 9, 2012 at 5:22 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, May 9, 2012 at 10:38 AM, Dehao Chen de...@google.com wrote:
On Wed, May 9, 2012 at 4:12 PM, Richard Guenther
On Wed, May 09, 2012 at 05:48:25PM +0800, Dehao Chen wrote:
So why not use an alternate interface into this special allocator for this
purpose?
There can be the following scenario:
We want to add a module to an existing app. Before implementing the
module, we want to collect some
Hello,
On ARM+Neon, the expansion of vld1q_dup_s64() and vld1q_dup_u64() builtins
currently fails to load the second vector element.
Here is a small patch to address this problem:
2012-05-07 Christophe Lyon christophe.l...@st.com
* gcc/config/arm/neon.md (neon_vld1_dup): Fix
Hello,
Below is the patch that has been committed in trunk (Revision: 187075).
We like to backport it to GCC 4.7 branch as couple of AMD processors require
this change for fma3 instruction generation.
Bootstrapping and testing are successful.
Is it OK to commit in GCC 4.7 branch?
Regards
Someone opened a bug about this: http://gcc.gnu.org/PR53289
Pinging: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01836.html
On 29 April 2012 12:28, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
A new version using unsigned int for the flag type. It also adds
another use in the C FE.
I
Hi Mike,
On May 8, 2012, at 10:19 AM, Rainer Orth wrote:
Several /gcc.target/i386/hle-*.c tests are currently failing on Solaris
9/x86 with Sun as:
FAIL: gcc.target/i386/hle-add-acq-1.c scan-assembler lock[
\\n\\t]+(xacquire|.byte[ \\t]+0xf2)[ \\t\\n]+add
The .s file has
This continues the series of patches cleaning up versioning / peeling
in the vectorizer. This moves computation of whether to do a cost
model check to a central place where it is also easy to see where
it will eventually end up generated. Apart from this re-org this
recognizes that runtime
Ping.
On 02/05/12 10:49, Andrew Stubbs wrote:
On 19/04/12 13:58, Andrew Stubbs wrote:
In the meantime, Mr Maintainers, can I commit my patch while we wait for
the new world order? I'm happy to change the option name quiet to
something else if necessary.
Ping.
I think David may have a point
Hello!
Below is the patch that has been committed in trunk (Revision: 187075).
We like to backport it to GCC 4.7 branch as couple of AMD processors require
this change for fma3 instruction generation.
Is it OK to commit in GCC 4.7 branch?
* config/i386/driver-i386.c
On Wed, May 9, 2012 at 12:53 PM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Several /gcc.target/i386/hle-*.c tests are currently failing on Solaris
9/x86 with Sun as:
FAIL: gcc.target/i386/hle-add-acq-1.c scan-assembler lock[
\\n\\t]+(xacquire|.byte[ \\t]+0xf2)[ \\t\\n]+add
The .s
-Original Message-
From: Joseph Myers [mailto:jos...@codesourcery.com]
Sent: Thursday, May 03, 2012 8:49 PM
To: Terry Guo
Cc: gcc-patches@gcc.gnu.org
Subject: RE: Propose to add a new argument MULTILIB_REQUIRED in
multilib framework
On Thu, 3 May 2012, Terry Guo wrote:
Hi again,
On 05/08/2012 03:00 PM, Jason Merrill wrote:
On 05/07/2012 11:28 PM, Paolo Carlini wrote:
error: could not convert ‘b.main()::lambda()()’ from ‘void’ to ‘bool’
It wouldn't say operator()?
I think I'd leave that alone; it is somewhat more informative (about
what b() expands to)
On Wed, May 09, 2012 at 10:21:04AM +0200, Richard Guenther wrote:
Using the stmt UID looks odd as you are using it as flag - why not use
one of the two stmt flags available to passes?
Btw, the other possibility would be to simply change the various combiners
to require them to update the
Hi,
the current code for strided loads can't deal with the situation when a
prologue loop (peeling for alignment) is created after analyzing the data
refs. There are multiple issues (non-constant steps in DRs mainly), so
this is a simple stop gap.
Regtesting on x86_64-linux (all langs) in
On 7 May 2012 16:52, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
On 06/11/2010 10:23 PM, Manuel López-Ibáñez wrote:
On 11 August 2009 02:01, Joseph S. Myersjos...@codesourcery.com wrote:
On Tue, 11 Aug 2009, Manuel López-Ibáñez wrote:
Modified the patch to make use of the new
I would like another set of eyes on the backend specific changes - I
am currently regression testing this final version on FSF trunk.
After testing and benchmarking and getting some private feedback about
the patch, this is what I ended up committing. I have a follow up
patch coming to adjust
Committed as obvious (passes on x86_64).
Richard.
2012-05-09 Richard Guenther rguent...@suse.de
PR tree-optimization/18437
* gfortran.dg/vect/rnflow-trs2a2.f90: Move ...
* gfortran.dg/vect/fast-math-rnflow-trs2a2.f90: ... here.
Hi Guys,
http://www.mpfr.org/mpfr-current/#changes
The current release of the MPFR library (v3.1.0) has reorganized its
sources such the mpfr.h header file is now in a sub-directory called
'src', rather than being at the top level. This has broken GCC's use
of in-tree MPFR sources.
On 05/09/2012 08:21 AM, Paolo Carlini wrote:
Is unapplied because I was really nervous due to the wrong location
(thus caret) of the error call, at the end of the whole condition. Now,
I'm wondering, shall we consistently use error_at (location_of (expr),
... for the error messages produced by
On 04/29/2012 06:28 AM, Manuel López-Ibáñez wrote:
A new version using unsigned int for the flag type. It also adds
another use in the C FE.
I am not asking for approval, only whether this
approach/implementation is the way to go.
That looks good. I would still also adjust the caret printer
On 9 May 2012 14:59, Jason Merrill ja...@redhat.com wrote:
On 05/09/2012 08:21 AM, Paolo Carlini wrote:
Is unapplied because I was really nervous due to the wrong location
(thus caret) of the error call, at the end of the whole condition. Now,
I'm wondering, shall we consistently use error_at
On 9 May 2012 15:04, Jason Merrill ja...@redhat.com wrote:
On 04/29/2012 06:28 AM, Manuel López-Ibáńez wrote:
A new version using unsigned int for the flag type. It also adds
another use in the C FE.
I am not asking for approval, only whether this
approach/implementation is the way to go.
Hi,
On 05/09/2012 02:59 PM, Jason Merrill wrote:
On 05/09/2012 08:21 AM, Paolo Carlini wrote:
Is unapplied because I was really nervous due to the wrong location
(thus caret) of the error call, at the end of the whole condition. Now,
I'm wondering, shall we consistently use error_at
On Tue, May 8, 2012 at 4:05 AM, Andreas Jaeger a...@suse.com wrote:
On Tuesday, May 08, 2012 11:59:34 Richard Earnshaw wrote:
On 08/05/12 10:04, Andreas Jaeger wrote:
On Tuesday, May 08, 2012 10:43:14 Richard Guenther wrote:
On Mon, May 7, 2012 at 11:11 PM, H.J. Lu hongjiu...@intel.com
I think the problem is you really want to use EXPR_LOC_OR_HERE rather
than location_of; if the argument happens to be a DECL, location_of will
give you the declaration location rather than the use location.
Jason
On 05/09/2012 09:04 AM, Manuel López-Ibáñez wrote:
This far less clear than error_at(location, whatever). And it
requires the diagnostics machinery to know about input_location. I
removed %H precisely for those reasons. Please, let's stop using +
in diagnostics and always use explicit locations.
On 05/09/2012 09:07 AM, Manuel López-Ibáñez wrote:
I could implement that by storing the last location in the
diagnostic_context or using a static location_t in
diagnostic_show_locus. What is your preference?
diagnostic_context, I guess.
Jason
Hi,
On 05/09/2012 02:54 PM, Manuel López-Ibáñez wrote:
On 7 May 2012 16:52, Paolo Carlinipaolo.carl...@oracle.com wrote:
Hi,
On 06/11/2010 10:23 PM, Manuel López-Ibáñez wrote:
On 11 August 2009 02:01, Joseph S. Myersjos...@codesourcery.comwrote:
On Tue, 11 Aug 2009, Manuel
On 05/09/2012 03:20 PM, Jason Merrill wrote:
I think the problem is you really want to use EXPR_LOC_OR_HERE rather
than location_of; if the argument happens to be a DECL, location_of
will give you the declaration location rather than the use location.
Ah! Thanks a lot, now all those small
On Wed, May 9, 2012 at 2:38 PM, Michael Matz m...@suse.de wrote:
Hi,
the current code for strided loads can't deal with the situation when a
prologue loop (peeling for alignment) is created after analyzing the data
refs. There are multiple issues (non-constant steps in DRs mainly), so
this
On Wed, May 9, 2012 at 2:52 PM, Nick Clifton ni...@redhat.com wrote:
Hi Guys,
http://www.mpfr.org/mpfr-current/#changes
The current release of the MPFR library (v3.1.0) has reorganized its
sources such the mpfr.h header file is now in a sub-directory called
'src', rather than being at
Hmm, sorry, it seems I forgot to look at MAINTAINERS and CC him...
On Tue, 8 May 2012 09:53:43 -0400
Alexis Ballier aball...@gentoo.org wrote:
gcc/config/i386/freebsd.h: Likewise.
---
gcc/config/freebsd-spec.h |9 +++--
gcc/config/i386/freebsd.h |9 +++--
2 files changed,
On Wed, May 9, 2012 at 3:26 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, May 9, 2012 at 2:52 PM, Nick Clifton ni...@redhat.com wrote:
Hi Guys,
http://www.mpfr.org/mpfr-current/#changes
The current release of the MPFR library (v3.1.0) has reorganized its
sources such
On Tue, May 8, 2012 at 4:05 PM, Richard Henderson r...@redhat.com wrote:
On 05/06/2012 11:41 AM, Richard Sandiford wrote:
PR middle-end/53249
* dwarf2out.h (get_address_mode): Move declaration to...
* rtl.h: ...here.
* dwarf2out.c (get_address_mode): Move
Il 09/05/2012 02:38, Matthias Klose ha scritto:
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 187271)
+++ gcc/doc/invoke.texi (working copy)
@@ -6110,6 +6110,11 @@
@file{../lib32}, or if OS
On Wed, 9 May 2012, Nick Clifton wrote:
Hi Guys,
http://www.mpfr.org/mpfr-current/#changes
The current release of the MPFR library (v3.1.0) has reorganized its
sources such the mpfr.h header file is now in a sub-directory called
'src', rather than being at the top level. This has
Il 09/05/2012 14:52, Nick Clifton ha scritto:
Hi Guys,
http://www.mpfr.org/mpfr-current/#changes
The current release of the MPFR library (v3.1.0) has reorganized its
sources such the mpfr.h header file is now in a sub-directory called
'src', rather than being at the top level.
On 9 May 2012 15:21, Paolo Carlini paolo.carl...@oracle.com wrote:
Good, I even have a patch essentially ready for that, but can you point me
to that detailed feedback? I couldn't find it when I looked for it.
This is how I understood the following paragraph:
I still think the warnings for
Il 09/05/2012 15:31, Richard Guenther ha scritto:
Btw, it would probably be better to make the drop-in compiles doing
a staged install during build instead of using the build tree for use.
Same for GCC while building target library, but not really easy to do...
GMP/MPFR are compiled without
On Wed, 9 May 2012, Manuel López-Ibáñez wrote:
That is,
cases where you not are able to make a deduction about ranges = the
warnings are appropriate and should be disabled only under a separate
option.
cases where you are able to deduce the ranges = warning is not appropriate
Yes,
On Wed, May 9, 2012 at 3:40 PM, Paolo Bonzini bonz...@gnu.org wrote:
Il 09/05/2012 15:31, Richard Guenther ha scritto:
Btw, it would probably be better to make the drop-in compiles doing
a staged install during build instead of using the build tree for use.
Same for GCC while building target
On 05/09/2012 03:54 PM, Joseph S. Myers wrote:
On Wed, 9 May 2012, Manuel López-Ibáñez wrote:
That is,
cases where you not are able to make a deduction about ranges = the
warnings are appropriate and should be disabled only under a separate
option.
cases where you are able to deduce the
Il 09/05/2012 15:57, Richard Guenther ha scritto:
Btw, it would probably be better to make the drop-in compiles doing
a staged install during build instead of using the build tree for use.
Same for GCC while building target library, but not really easy to do...
GMP/MPFR are compiled
Hi,
this patch reworks cgraph_remove_unreachable_nodes that has grown from somewhat
hackish but simple marksweep routine into quite unmaintainable mess. It is
because it needs to handle several special cases - extern inline functions,
virtual functions, clones and inline clone tree reshaping and
Hide all uses of __float128 from Clang.
Brackets _GLIBCXX_USE_FLOAT128 with #ifndef __clang__. Clang does not
currently support the __float128 builtin, and so will fail to process
libstdc++ headers that use it.
Tested for full bootstrap and dejagnu testsuite.
Okay for google/integration and
On 12-05-09 08:19 , Simon Baldwin wrote:
2012-05-09 Simon Baldwinsim...@google.com
* libstdc++-v3/acinclude.m4: Bracket _GLIBCXX_USE_FLOAT128
definition with ifndef __clang__.
* libstdc++-v3/config.h.in: Rebuild.
OK.
Diego.
On Wed, May 9, 2012 at 8:19 AM, Simon Baldwin sim...@google.com wrote:
Hide all uses of __float128 from Clang.
Brackets _GLIBCXX_USE_FLOAT128 with #ifndef __clang__. Clang does not
currently support the __float128 builtin, and so will fail to process
libstdc++ headers that use it.
Tested
contrib/gcc_update currently uses svn explicitly to determine the
Revision and Branch instead of the $GCC_SVN shell variable used in
other instances in the script. This patch uses the shell variable in
all instances.
Thanks, David
* gcc_update: Use $GCC_SVN to retrieve branch and
On 09.05.2012 15:37, Paolo Bonzini wrote:
Il 09/05/2012 02:38, Matthias Klose ha scritto:
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 187271)
+++ gcc/doc/invoke.texi (working copy)
@@ -6110,6
2012/5/7 Georg-Johann Lay a...@gjlay.de:
AVR-LibC switched from using either signal /or/ interrupt function
attribute to using both at the same time.
This was never documented or implemented but worked accidentally for
some time, but results in wrong code for 4.7+
This patch adds better
On 04/28/2012 11:31 AM, Bernd Schmidt wrote:
This patch allows us to recognize that even if the argument to memcpy
lives across the call, we can allocate it to a call-used register by
reusing the return value of the function.
First, the patch sets the existing fn spec attribute for
Hi Simon,
Hide all uses of __float128 from Clang.
Brackets _GLIBCXX_USE_FLOAT128 with #ifndef __clang__. Clang does not
currently support the __float128 builtin, and so will fail to process
libstdc++ headers that use it.
if one day clang gets support for this type, won't this still turn
On Wed, May 9, 2012 at 6:08 PM, Duncan Sands baldr...@free.fr wrote:
Hi Simon,
Hide all uses of __float128 from Clang.
Brackets _GLIBCXX_USE_FLOAT128 with #ifndef __clang__. Clang does not
currently support the __float128 builtin, and so will fail to process
libstdc++ headers that use it.
Hi Guys,
Ok. I think it's nicer for the users if we enable both builds to work.
Thanks. I have applied the patch, along with a reference to PR 50461
and a credit to Paul Smith in the ChangeLog entry since he came up with
basically the same patch as mine.
Cheers
Nick
Il 09/05/2012 17:34, Matthias Klose ha scritto:
So -print-multiarch is like --print-multi-os-directory?
the former prints the part before the `:' in the MULTILIB_OSDIRNAMES, the
latter
the part after the `':', e.g. ../lib32 and i386-linux-gnu.
Yes, of course.
What is the difference, and
On Wed, May 9, 2012 at 1:12 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li davi...@google.com wrote:
To be clear, this flag is for malloc implementation (such as tcmalloc)
with side effect unknown to the compiler. Using -fno-builtin-xxx
On Wed, May 9, 2012 at 9:32 AM, Xinliang David Li davi...@google.com wrote:
On Wed, May 9, 2012 at 1:12 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li davi...@google.com wrote:
To be clear, this flag is for malloc implementation (such
From: Richard Sandiford rdsandif...@googlemail.com
Date: Wed, 9 May 2012 11:14:49 +0200
Hans-Peter Nilsson hans-peter.nils...@axis.com writes:
From: Richard Sandiford rdsandif...@googlemail.com
Date: Tue, 1 May 2012 16:46:38 +0200
To repeat: as things stand, very few targets define
OK to apply ?
Ok. Thanks!
On 09.05.2012 18:29, Paolo Bonzini wrote:
Il 09/05/2012 17:34, Matthias Klose ha scritto:
So -print-multiarch is like --print-multi-os-directory?
the former prints the part before the `:' in the MULTILIB_OSDIRNAMES, the
latter
the part after the `':', e.g. ../lib32 and i386-linux-gnu.
It is strange that a paragraph talking about GCC pragmas refers to the
section in CPP talking about #indent and other such directives (no
#pragma there). Wouldn't it better if it pointed to the section about
#pragmas?
OK?
2012-05-09 Manuel López-Ibáñez m...@gcc.gnu.org
*
Hello!
Attached patch avoids a deficiency in reload, where reload gives up on
handling subregs of pseudos (please see the PR [1] for explanation by
Ulrich). The patch simply avoids generating V4SF moves with V4SF
subregs of V2DF values unless really necessary (i.e. moving SSE2 modes
without SSE2
On Wed, May 9, 2012 at 12:50 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
It is strange that a paragraph talking about GCC pragmas refers to the
section in CPP talking about #indent and other such directives (no
#pragma there). Wouldn't it better if it pointed to the section about
On Wed, May 9, 2012 at 6:32 PM, Xinliang David Li davi...@google.com wrote:
On Wed, May 9, 2012 at 1:12 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li davi...@google.com wrote:
To be clear, this flag is for malloc implementation (such
Hello!
Practically no functional change.
2012-05-09 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.c (*movdf_internal_rex64): Remove
TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL handling from asm output code.
Calculate mode attribute according to
Hi again,
thus the below is what I booted and tested. As you can see I had to
tweak a bit an existing testcase, for which the location is now a bit
smaller, 3 chars, in fact is still not perfect, but arguably a tad
better. Otherwise no issues. Ah, I'm touching also a c-common.c
function, in
Jan,
This patch is causing a bootstrap failure on AIX. It generates linker
errors that TOC symbols are not emitted:
ld: 0711-317 ERROR: Undefined symbol: LC..0
ld: 0711-317 ERROR: Undefined symbol: LC..1
ld: 0711-317 ERROR: Undefined symbol: LC..2
ld: 0711-317 ERROR: Undefined symbol: LC..3
ld:
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 than amending size_binop
(my original plan)
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 functions
that assume you are dealing with sizes (in
Hello!
Attached patch fixes PR 52908. There is no need to generate fake
multiply instructions after reload, we can expand directly to MAC
instructions. This approach even produced better assembly for a couple
of testcases in gcc.target/i386 testsuite.
2012-05-09 Uros Bizjak ubiz...@gmail.com
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
+===GNAT BUG DETECTED==+
| 4.8.0 20120506
On 9 May 2012 00:38, Joseph S. Myers jos...@codesourcery.com wrote:
On Wed, 9 May 2012, Manuel López-Ibáñez wrote:
which looks correct to me. However, the build fails because now
options.h requires input.h which requires line-map.h, which is not
included when building for example libgcc.
On Wed, May 9, 2012 at 4: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);
^
On Wed, May 9, 2012 at 11:21 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, May 9, 2012 at 6:32 PM, Xinliang David Li davi...@google.com wrote:
On Wed, May 9, 2012 at 1:12 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li
Hi,
shame on me. I think the patch almost qualifies as obvious. Tested
x86_64-linux.
Thanks,
Paolo.
//
/cp
2012-05-10 Paolo Carlini paolo.carl...@oracle.com
PR c++/53301
* decl.c (check_default_argument): Fix typo (POINTER_TYPE_P
instead of
This patch to the Go frontend adds a new command line option:
-fgo-pkgpath. This permits setting the string that is returned by the
PkgPath() method of reflect.Type for types defined in the package being
compiled. It also sets the prefix used for symbol names. This largely
replaces the existing
Thanks for your suggestions/comments. I have updated the patch and
documentation. It supports the following usage:
gcc -fdump-tree-all=tree.dump -fdump-tree-pre=stdout
-fdump-rtl-ira=ira.dump
Here all tree dumps except the PRE are output into tree.dump, PRE dump
goes to stdout and the IRA
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.
Index: h8300.h
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 -- I don't think the current precedence rule is correct.
Consider that -fopt-info=2
Hi,
I'm looking into making more progress on those locations, for another
class of cases. Consider:
struct T { };
T foo();
void bar(int a, int b)
{
if (foo() a b)
;
}
thus, in this case, we have a class type T, instead of void. The error
message is:
a.cc: In function ‘void
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.
The new caret support does seem to have revealed a bunch of
98 matches
Mail list logo
