29.03.2015 23:18, Godmar Back writes:
> Thanks. I'm a bit confused then what constitutes defined & undefined behavior.
>
> The actual situation I encountered is best described by this example:
>
> --
> /* Tested with gcc 4.4.7 and 4.8.2 -m32 */
> #include
> #include
>
> bool boolFunctionThatRe
Done!
On 30 March 2015 at 23:23, Martin Uecker wrote:
>
> Hi Manuel,
>
> sorry for the late reply, I was travelling last week.
> My account name is: MartinUecker
>
> Martin
>
>
> Manuel López-Ibáñez :
>
>> Martin,
>>
>> did you manage to create a wiki account?
>>
>> I can add you to the editors g
So I have modified the patch to use hash_map instead of std::map. The patch is
attached.
However, I got one regression after that.
# Comparing directories
## Dir1=../build-pristine/: 11 sum files
## Dir2=../build-test/: 11 sum files
# Comparing 11 common sum files
## /bin/sh ../contrib/compare_
Hi Manuel,
sorry for the late reply, I was travelling last week.
My account name is: MartinUecker
Martin
Manuel López-Ibáñez :
> Martin,
>
> did you manage to create a wiki account?
>
> I can add you to the editors group then.
>
> On 27 January 2015 at 22:54, Martin Uecker wrote:
> > Am T
On 30/03/15 08:14, Bin.Cheng wrote:
On Sat, Mar 28, 2015 at 1:31 AM, Sandra Loosemore
wrote:
On 03/27/2015 03:43 AM, Kyrill Tkachov wrote:
On 27/03/15 03:29, Bin.Cheng wrote:
[much snippage]
As for tree ivopts, address cost is used in both ways. For any
address computation that's invalid
Hi All,
I'm working on selecting the right architecture tuple for the Rumprun
toolchain[1] to use as a prefix for naming the cross tools and for passing
to application build systems (autoconf, CMake, ...). Rumprun is a software
stack built with Rump Kernels[2] which enables running existing POSIX
On Mon, Mar 30, 2015 at 11:36 AM, Richard Biener
wrote:
> On Fri, Mar 27, 2015 at 4:00 PM, xue yinsong wrote:
>> Thanks for your reply to my proposal.
>> AFAIS, most of the files generated by -fdump-tree-all are presented in
>> C-like form instead
>> of in lisp-like tuple form.
>> So it’s better
On 30/03/15 08:07, Bin.Cheng wrote:
On Fri, Mar 27, 2015 at 5:43 PM, Kyrill Tkachov wrote:
On 27/03/15 03:29, Bin.Cheng wrote:
On Thu, Mar 26, 2015 at 11:40 PM, Kyrill Tkachov
wrote:
Hi all,
I'd like to attempt to make GCC's usage of costs in the backends
consistent.
We have a lot of diffe
On 27/03/15 17:31, Sandra Loosemore wrote:
On 03/27/2015 03:43 AM, Kyrill Tkachov wrote:
On 27/03/15 03:29, Bin.Cheng wrote:
[much snippage]
As for tree ivopts, address cost is used in both ways. For any
address computation that's invalid, it tries to legitimize it into two
parts, the first
On Fri, Mar 27, 2015 at 4:00 PM, xue yinsong wrote:
> Thanks for your reply to my proposal.
> AFAIS, most of the files generated by -fdump-tree-all are presented in C-like
> form instead
> of in lisp-like tuple form.
> So it’s better to implement a front end for the C-like gimple representations.
On Sat, Mar 28, 2015 at 1:31 AM, Sandra Loosemore
wrote:
> On 03/27/2015 03:43 AM, Kyrill Tkachov wrote:
>>
>>
>> On 27/03/15 03:29, Bin.Cheng wrote:
>>>
>>> [much snippage]
>>>
>>>
>>> As for tree ivopts, address cost is used in both ways. For any
>>> address computation that's invalid, it tries
On Fri, Mar 27, 2015 at 5:43 PM, Kyrill Tkachov wrote:
>
> On 27/03/15 03:29, Bin.Cheng wrote:
>>
>> On Thu, Mar 26, 2015 at 11:40 PM, Kyrill Tkachov
>> wrote:
>>>
>>> Hi all,
>>>
>>> I'd like to attempt to make GCC's usage of costs in the backends
>>> consistent.
>>> We have a lot of different t
12 matches
Mail list logo