> I tried to figure out why things had been done in this
> slightly convoluted manner and failed. It seems to me that
> this is easily represented with the individual instructions.
> A comment indicated that there had been problems with the
> copy to %o7 being deleted. Elsewhere we have successfu
The setup:
Configuring a toolchain targeting x86-64 GNU Linux (Ubuntu Lucid), as a
cross-compiler. Using a sysroot to provide the Lucid headers+libraries,
with the sysroot path being within the GCC install tree. Want to use the
Lucid system libstdc++ and headers, which means that I'm not
buildin
This is basically the same patch as posted before in
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02772.html and updated in
http://gcc.gnu.org/viewcvs?view=revision&revision=168273, but with a
few merge conflicts in current mainline resolved.
Re-tested natively with a bootstrap & regtest on gcc
The constant expression evaluation code was happily replacing an
expression involving a temporary with its constant value even if the
temporary had a destructor that needed to be run.
After fixing that, I needed to adjust expand_default_init to avoid
adding a TARGET_EXPR when we aren't really
On 06/26/2011 10:00 AM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, applying to trunk. Jakub, should this go
into 4.6.1 or .2?
I think it's fine to wait for .2, since a class with a non-trivial
destructor is likely to also have a non-trivial, non-constexpr
constructor, which would preven
On Sat, 25 Jun 2011, Chris Demetriou wrote:
> For the C headers, add_standard_paths prepends the sysroot location to
> the /usr/include path (since that's what's specified in cppdefault.c for
> that path). It doesn't do the same for the C++ include path, though
> (again, as specified in cppdefaul
The cppbuiltin.c and c-common.c changes are OK. I'm not sure what the
best approach is for a proper hook conversion of POINTER_SIZE, but I don't
think this patch makes things any worse. (The things that need
considering together in a hook conversion are how the modes for both Pmode
and ptr_mo
On Sun, Jun 26, 2011 at 9:00 AM, Jason Merrill wrote:
> The constant expression evaluation code was happily replacing an expression
> involving a temporary with its constant value even if the temporary had a
> destructor that needed to be run.
I thought we wanted literal types to have trivial des
I applied the following patch (approved in the PR thread) to fix this
in trunk.
It should also be applied to 4.6.x at some stage.
cheers
Iain
gcc/
PR target/47997
* config/darwin.c (darwin_mergeable_string_section): Place string
constants in '.cstring' rather than '.con
No, that's still the case, just getting confused by the need to also support
constant initialization of non-literal types.
Gabriel Dos Reis wrote:
On Sun, Jun 26, 2011 at 9:00 AM, Jason Merrill wrote:
> The constant expression evaluation code was happily replacing an expression
> involving a t
On Sun, Jun 26, 2011 at 07:28, Joseph S. Myers wrote:
> It seems to me that what's really wanted here is to change the add_sysroot
> flag for the C++ path (all of the C++ paths?), rather than adding special
> code to detect paths starting with the sysroot and reinterpret them.
I considered doing
On Sun, Jun 26, 2011 at 10:13:23AM -0400, Jason Merrill wrote:
> On 06/26/2011 10:00 AM, Jason Merrill wrote:
> >Tested x86_64-pc-linux-gnu, applying to trunk. Jakub, should this go
> >into 4.6.1 or .2?
>
> I think it's fine to wait for .2, since a class with a non-trivial
> destructor is likely t
Hi,
under some circumstances involving user specified alignment and/or
packed attributes, SRA can create a misaligned MEM_REF. As the
testcase demonstrates, it is not enough to not consider variables with
these type attributes, mainly because we might attempt to load/store
the scalar replacements
2011/6/24 Richard Henderson :
> On 06/23/2011 01:15 PM, Denis Chertykov wrote:
>>> text data bss dec hex filename
>>> 10032 25 0 10057 2749 bld-avr-orig/gcc/z.o
>>> 5816 25 0 5841 16d1 bld-avr-new/gcc/z.o
>>
>> Richard, can you send me this z.c f
On 06/25/2011 12:13 PM, H.J. Lu wrote:
This patch introduces UNIQUE_UNWIND_CONTEXT
Where is this documented? The ABI document doesn't seem to say anything
about it.
Jason
Denis Chertykov schrieb:
2011/6/24 Richard Henderson :
On 06/23/2011 01:15 PM, Denis Chertykov wrote:
textdata bss dec hex filename
10032 25 0 100572749 bld-avr-orig/gcc/z.o
5816 25 0584116d1 bld-avr-new/gcc/z.o
Richard, can you send me
On Sun, Jun 26, 2011 at 12:54 PM, Jason Merrill wrote:
> On 06/25/2011 12:13 PM, H.J. Lu wrote:
>>
>> This patch introduces UNIQUE_UNWIND_CONTEXT
>
> Where is this documented? The ABI document doesn't seem to say anything
> about it.
>
I added a short paragraph in the updated patch:
http://gcc.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-4.6.0.de.po', has just
On Sun, Jun 26, 2011 at 12:09 PM, Jason Merrill wrote:
> No, that's still the case, just getting confused by the need to also support
> constant initialization of non-literal types.
Ah, thanks!
-- Gaby
On 06/26/2011 04:06 PM, H.J. Lu wrote:
I added a short paragraph in the updated patch:
+@defmac UNIQUE_UNWIND_CONTEXT
+
+Define this macro if the target only supports single unqiue unwind
+context. The default is to support multiple unwind contexts.
I saw that. I don't know what it means.
J
On Sun, Jun 26, 2011 at 2:45 PM, Jason Merrill wrote:
> On 06/26/2011 04:06 PM, H.J. Lu wrote:
>>
>> I added a short paragraph in the updated patch:
>>
>> +@defmac UNIQUE_UNWIND_CONTEXT
>> +
>> +Define this macro if the target only supports single unqiue unwind
>> +context. The default is to supp
But yes, I think checking for literal type is a better idea.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 81e093c1d6f2657c8c3c2abc2af559111ca82da4
Author: Jason Merrill
Date: Sun Jun 26 15:23:00 2011 -0400
PR c++/49528
* semantics.c (potential_constant_expression_1): Check
On 06/25/2011 04:56 PM, Mike Stump wrote:
> On Jun 15, 2011, at 5:57 PM, Janis Johnson wrote:
>> The bug was in my attempt to run the tests with other -mfpu values, so
>> I'm very glad you caught that. I tried again, getting rid of the neon
>> requirement along the way, and found a way to run the
Yet another case where we can't use common. Tested on hppa2.0w-hp-hpux11.11
and hppa64-hp-hpux11.11. Committed to trunk.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
2011-06-2
Test uses alias attribute, so it needs dg-require-alias. Tested on
hppa64-hp-hpux11.11. Committed to trunk as obvious.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
2011-06-26
2011/6/26 Georg-Johann Lay :
> Denis Chertykov schrieb:
>>
>> 2011/6/24 Richard Henderson :
>>
>>> On 06/23/2011 01:15 PM, Denis Chertykov wrote:
>>>
> text data bss dec hex filename
> 10032 25 0 10057 2749 bld-avr-orig/gcc/z.o
> 5816 25 0
Hello All,
I am pinging http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01524.html :
On Mon, 20 Jun 2011 21:34:44 +0200
Basile Starynkevitch wrote:
>
> The attached patch to trunk 175201 makes cc1, cc1plus, ... lto1 also
> search a language specific subdirectory.
>
> # gcc/ChangeLog entry ###
27 matches
Mail list logo
