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
+
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
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 fo
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 seem to have revealed a bunch of places
where the co
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 bar
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 correct.
Consider that -fopt-info=2 will be mapped to
-fdump-tree-all-transform-
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
==
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 du
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
Hi,
shame on me. I think the patch almost qualifies as obvious. Tested
x86_64-linux.
Thanks,
Paolo.
//
/cp
2012-05-10 Paolo Carlini
PR c++/53301
* decl.c (check_default_argument): Fix typo (POINTER_TYPE_P
instead of TYPE_PTR_P) in zero-as-null-poin
On Wed, May 9, 2012 at 11:21 AM, Richard Guenther
wrote:
> On Wed, May 9, 2012 at 6:32 PM, Xinliang David Li wrote:
>> On Wed, May 9, 2012 at 1:12 AM, Richard Guenther
>> wrote:
>>> On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li
>>> wrote:
To be clear, this flag is for malloc implement
On Wed, May 9, 2012 at 4: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-overloa
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-overload.C:6:6: note: candidate is:
/home/manuel/caret-overload.C:2:18: note: tem
On 9 May 2012 00:38, Joseph S. Myers 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. options.h is include
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 (ex
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
PR targe
> 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 "size
> 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 pl
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:
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
Hello!
Practically no functional change.
2012-05-09 Uros Bizjak
* config/i386/i386.c (*movdf_internal_rex64): Remove
TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL handling from asm output code.
Calculate "mode" attribute according to
TARGET_SSE_PACKED_SINGLE_INSN_OPTIM
On Wed, May 9, 2012 at 6:32 PM, Xinliang David Li wrote:
> On Wed, May 9, 2012 at 1:12 AM, Richard Guenther
> wrote:
>> On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li wrote:
>>> To be clear, this flag is for malloc implementation (such as tcmalloc)
>>> with side effect unknown to the compiler
On Wed, May 9, 2012 at 12:50 PM, Manuel López-Ibáñez
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
> #pragmas?
yes. patch
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
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
* doc/extend.texi (Function Attr
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-g
>OK to apply ?
Ok. Thanks!
> From: Richard Sandiford
> Date: Wed, 9 May 2012 11:14:49 +0200
> Hans-Peter Nilsson writes:
> >> From: Richard Sandiford
> >> 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 blami
On Wed, May 9, 2012 at 9:32 AM, Xinliang David Li wrote:
> On Wed, May 9, 2012 at 1:12 AM, Richard Guenther
> wrote:
>> On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li wrote:
>>> To be clear, this flag is for malloc implementation (such as tcmalloc)
>>> with side effect unknown to the compiler
On Wed, May 9, 2012 at 1:12 AM, Richard Guenther
wrote:
> On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li 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.
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 differen
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
On Wed, May 9, 2012 at 6:08 PM, Duncan Sands 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 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 ever
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
memcpy/m
2012/5/7 Georg-Johann Lay :
> 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 documentat
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)
>> @@ -61
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 revisi
On Wed, May 9, 2012 at 8:19 AM, Simon Baldwin 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 for full b
On 12-05-09 08:19 , Simon Baldwin wrote:
2012-05-09 Simon Baldwin
* libstdc++-v3/acinclude.m4: Bracket _GLIBCXX_USE_FLOAT128
definition with ifndef __clang__.
* libstdc++-v3/config.h.in: Rebuild.
OK.
Diego.
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 goo
Hi,
this patch reworks cgraph_remove_unreachable_nodes that has grown from somewhat
hackish but simple mark&sweep 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
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
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 ran
On Wed, May 9, 2012 at 3:40 PM, Paolo Bonzini 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 library,
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
Ye
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 s
On 9 May 2012 15:21, Paolo Carlini 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 these cases are most
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 le
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 broken
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 l
On Tue, May 8, 2012 at 4:05 PM, Richard Henderson 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 definition to
On Wed, May 9, 2012 at 3:20 PM, H.J. Lu wrote:
> On Tue, May 8, 2012 at 4:05 AM, Andreas Jaeger 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, 20
On Wed, May 9, 2012 at 3:26 PM, Richard Guenther
wrote:
> On Wed, May 9, 2012 at 2:52 PM, 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 i
Hmm, sorry, it seems I forgot to look at MAINTAINERS and CC him...
On Tue, 8 May 2012 09:53:43 -0400
Alexis Ballier wrote:
> gcc/config/i386/freebsd.h: Likewise.
> ---
> gcc/config/freebsd-spec.h |9 +++--
> gcc/config/i386/freebsd.h |9 +++--
> 2 files changed, 6 insertions(+)
On Wed, May 9, 2012 at 2:52 PM, 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 l
On Wed, May 9, 2012 at 2:38 PM, Michael Matz 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 is a si
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 detail
Hi,
On 05/09/2012 02:54 PM, Manuel López-Ibáñez wrote:
On 7 May 2012 16:52, Paolo Carlini wrote:
Hi,
On 06/11/2010 10:23 PM, Manuel López-Ibáñez wrote:
On 11 August 2009 02:01, Joseph S. Myerswrote:
On Tue, 11 Aug 2009, Manuel López-Ibáñez wrote:
Modified the patch to make use of the
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
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 locatio
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 Tue, May 8, 2012 at 4:05 AM, Andreas Jaeger 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 wrote:
>> >>> Hi,
>> >>>
>> >
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 (location_o
On 9 May 2012 15:04, Jason Merrill 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.
>
>
On 9 May 2012 14:59, 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 (locati
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 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 th
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.
Committed as obvious (passes on x86_64).
Richard.
2012-05-09 Richard Guenther
PR tree-optimization/18437
* gfortran.dg/vect/rnflow-trs2a2.f90: Move ...
* gfortran.dg/vect/fast-math-rnflow-trs2a2.f90: ... here.
> 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
On 7 May 2012 16:52, Paolo Carlini wrote:
> Hi,
>
>
> On 06/11/2010 10:23 PM, Manuel López-Ibáñez wrote:
>>
>> On 11 August 2009 02:01, Joseph S. Myers wrote:
>>>
>>> On Tue, 11 Aug 2009, Manuel López-Ibáñez wrote:
>>>
Modified the patch to make use of the new c-c++-common testsuite.
Bo
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 pro
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 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()::()’ 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) and we're
> -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:
>
On Wed, May 9, 2012 at 12:53 PM, 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
>
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 (host_detect_
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
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 check
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
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 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
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
Gane
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
* gcc/config/arm/neon.md (neon_vld1_dup): Fix vld1q_dup_s64.
Index: gcc/config/
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 som
On Wed, May 9, 2012 at 11:48 AM, Dehao Chen wrote:
> On Wed, May 9, 2012 at 5:22 PM, Richard Guenther
> wrote:
>> On Wed, May 9, 2012 at 10:38 AM, Dehao Chen wrote:
>>> On Wed, May 9, 2012 at 4:12 PM, Richard Guenther
>>> wrote:
On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li
wrot
On Wed, May 9, 2012 at 5:22 PM, Richard Guenther
wrote:
> On Wed, May 9, 2012 at 10:38 AM, Dehao Chen wrote:
>> On Wed, May 9, 2012 at 4:12 PM, Richard Guenther
>> wrote:
>>> On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li
>>> wrote:
To be clear, this flag is for malloc implementation (
On 08/05/12 22:42, Richard Sandiford wrote:
> Richard Earnshaw 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
>
>
> gcc/
>
"Maciej W. Rozycki" 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
>> > ===
>> > --- gcc-fsf-trunk-quilt.orig/gcc/config/mips/mips.c
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 +
Hi DJ,
Thanks for the test program. With that I can confirm that the
match_dup does work and that the bset instruction is still generated
even with my patch applied.
OK to apply ?
Cheers
Nick
On Wed, May 9, 2012 at 10:38 AM, Dehao Chen wrote:
> On Wed, May 9, 2012 at 4:12 PM, Richard Guenther
> wrote:
>> On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li wrote:
>>> To be clear, this flag is for malloc implementation (such as tcmalloc)
>>> with side effect unknown to the compiler. Usin
Hans-Peter Nilsson writes:
>> From: Richard Sandiford
>> 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
On Wed, May 9, 2012 at 4:12 PM, Richard Guenther
wrote:
> On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li 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.
On Tue, May 8, 2012 at 8:33 PM, Jakub Jelinek 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 seq changes t
On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li 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 also guards alloca
On Wed, May 9, 2012 at 1:46 AM, Sharad Singhai 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 -fdump-xxx=yyy.
[...]
On 9 May 2012 01:34, Cary Coutant 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 declaratio
98 matches
Mail list logo
