On June 2, 2014 11:30:20 PM CEST, "Joseph S. Myers"
wrote:
>On Mon, 2 Jun 2014, Florian Weimer wrote:
>
>> On 05/31/2014 08:56 AM, Alan Modra wrote:
>>
>> > > It's fine to change ABI when compiling an old-style function
>> > > definition for which a prototype exists (relative to the
>> > > non-p
On 01/06/2014 01:21, Roman Gareev wrote:
Hi Tobias,
Allright. It seems you understood the tree traversel. For the actual
patch that we want to commit, let's leave it out for now. Instead,
let's try to get a minimal patch that only adds the flag and the new
file for the isl_ast stuff. In case
On 3 June 2014 01:47, Vincent Lefevre wrote:
> On 2014-06-02 10:33:37 -0400, Geert Bosch wrote:
>> It should, or it would be a bug. Please feel free to add/correct
>> anything on this page.
>
> I am not a member of EditorGroup.
That's easy to fix, email me your username.
Am 02.06.2014 22:30, schrieb Eric Botcazou:
>> I have successfully built without the switch, but I am not sure of the
>> effects at runtime.
>
> For sure libitm cannot work, there is a 'flushw' in config/sparc/sjlj.S.
>
>> If V9 is indeed required, is there a way to build without those libs? Or
>
On 3 June 2014 08:39, Yury Gribov wrote:
> Christophe,
>
>
>> Indeed, when testing on my laptop, execution tests fail because
>> libsanitizer wants to allocated 8GB of memory (I am using qemu as
>> execution engine).
>
> Is this 8G of RAM? If yes - I'd be curious to know which part of
> libsanitiz
> V9 is currently bound to 64bit, you can't build a sparc-linux-gnu compiler
> defaulting to V9 without patches.
libitm was tested on SPARC/Linux though.
--
Eric Botcazou
Is this 8G of RAM? If yes - I'd be curious to know which part of
libsanitizer needs so much memory.
Here is what I have in gcc.log:
==12356==ERROR: AddressSanitizer failed to allocate 0x21000
(8589938688) bytes at address ff000 (errno: 12)^M
==12356==ReserveShadowMemoryRange failed while
>> IMHO an efficiency enhancement should not prevent running less
>> efficiently on a supported architecture. If target triple is
>> sparcv9-*-*, the next case will match and will add the "-mcpu=v9" to
>> XCFLAGS, but adding it for non-v9 sparc-*-* targets is at least weird.
>
> Well, V9 is about 2
On 06/03/2014 12:16 PM, Yury Gribov wrote:
Is this 8G of RAM? If yes - I'd be curious to know which part of
libsanitizer needs so much memory.
Here is what I have in gcc.log:
==12356==ERROR: AddressSanitizer failed to allocate 0x21000
(8589938688) bytes at address ff000 (errno: 12)^M
==
On 3 June 2014 12:16, Yury Gribov wrote:
>>> Is this 8G of RAM? If yes - I'd be curious to know which part of
>>> libsanitizer needs so much memory.
>>
>>
>> Here is what I have in gcc.log:
>> ==12356==ERROR: AddressSanitizer failed to allocate 0x21000
>> (8589938688) bytes at address ff00
I have not found out why the assertion is violated, yet.
However I noticed that the original function disappears somehow between
the passes pass_ipa_comdats and pass_fixup_cfg.
By that I mean that the function appears from the dump files.
These passes run several passes after the outlining pass.
B
On Tue, Jun 3, 2014 at 3:03 PM, Benedikt Huber
wrote:
>
> I have not found out why the assertion is violated, yet.
> However I noticed that the original function disappears somehow between
> the passes pass_ipa_comdats and pass_fixup_cfg.
> By that I mean that the function appears from the dump fi
According to the output the ICE is in the newly generated function
(_GLOBAL__N_bar)
which is the one that remains.
Further more the compilation continues until the
expand pass (outline.c.180r.expand), where the error happens.
The original function (bar) is last seen in outline.c.056i.comdats.
I a
On Tue, Jun 3, 2014 at 3:59 PM, Benedikt Huber
wrote:
>
> According to the output the ICE is in the newly generated function
> (_GLOBAL__N_bar)
> which is the one that remains.
> Further more the compilation continues until the
> expand pass (outline.c.180r.expand), where the error happens.
> The
Ah, now I get it.
So the reason is that comdats is the last ipa pass that is run.
I continue to look for the problem in purge_dead_edges.
Thank you for the explanation.
Best regards,
Benedikt
On 03 Jun 2014, at 16:10, Richard Biener wrote:
> On Tue, Jun 3, 2014 at 3:59 PM, Benedikt Huber
> wr
I have posted the presentation abstracts at
https://gcc.gnu.org/wiki/cauldron2014
Presenters, please make sure that I have not butchered
the abstract that you sent when you registered your talk.
Thanks. Diego.
On Tue, 3 Jun 2014, Vincent Lefevre wrote:
> On 2014-06-02 21:20:57 +, Joseph S. Myers wrote:
> > ([...] Conversion from __float128 to __ibm128 would presumably be
> > done in the usual way of converting to double, and, if the result is
> > finite, subtracting the double from the __float128 va
On May 30, 2014, at 10:39 AM, Jeff Law wrote:
> On 05/25/14 18:19, Matt Thomas wrote:
>>
>> But even if movhi is a define_expand, as far as I can tell there's
>> isn't enough info to know whether that is possible. At that time,
>> how can I tell that operands[0] will be a hard reg or operands
18 matches
Mail list logo
