Dear gcc contributors,
The removing of CLooG library installation dependency is almost
finished. The code review of these patches
(https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01564.html) is the only
thing, which prevents it. Could you please review them? My mentor’s
already accepted them, but w
On 14/08/14 09:45, Kyrill Tkachov wrote:
>
> On 13/08/14 18:32, Segher Boessenkool wrote:
>> On Wed, Aug 13, 2014 at 03:57:31PM +0100, Richard Earnshaw wrote:
>>> The problem with the frankenmonster patterns is that they tend to
>>> proliferate into the machine description, and before you know whe
On Fri, Aug 15, 2014 at 6:33 PM, Richard Biener
wrote:
> On Fri, Aug 15, 2014 at 10:45 AM, Joey Ye wrote:
>> Running into an unexpected result with GCC with following case, but
>> not sure if it is a valid C++ case.
>>
>> #define nullptr 0
>> enum nonetype { none };
>>
>> template
>> class class_
On 18/08/14 10:19, Richard Earnshaw wrote:
On 14/08/14 09:45, Kyrill Tkachov wrote:
On 13/08/14 18:32, Segher Boessenkool wrote:
On Wed, Aug 13, 2014 at 03:57:31PM +0100, Richard Earnshaw wrote:
The problem with the frankenmonster patterns is that they tend to
proliferate into the machine des
Joern, there is https://sourceware.org/ml/newlib/2014/msg00166.html,
which is already in newlib mainline. I think it solves the same issue
in a slight different approach.
Does it work for you?
Thanks,
Joey
On Thu, Aug 14, 2014 at 4:52 PM, Joern Rennecke
wrote:
> For embedded targets with small
On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
> So... I've been getting my feet wet with LTO and debugging and I noticed a
> seemingly unrelated yet annoying problem. On x86-64,
> gcc.dg/guality/pr48437.c fails when run in LTO mode.
>
> I've compared the dwarf output with and without LTO
On Mon, Aug 18, 2014 at 11:39 AM, Joey Ye wrote:
> On Fri, Aug 15, 2014 at 6:33 PM, Richard Biener
> wrote:
>> On Fri, Aug 15, 2014 at 10:45 AM, Joey Ye wrote:
>>> Running into an unexpected result with GCC with following case, but
>>> not sure if it is a valid C++ case.
>>>
>>> #define nullptr
On Sun, Aug 17, 2014 at 9:50 PM, Prathamesh Kulkarni
wrote:
> Hi,
>Apparently this pattern is not getting fired (even in isolation).
>
> /* x % 1 -> 0 */
> (simplify
> (trunc_mod @0 integer_onep)
> { build_zero_cst (type); })
>
> I tried with this test-case:
> int f(int x)
> {
> int t1 =
Dear Evgeniya,
Maybe missed optimizations in vectorizer will be interesting to you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
It has a lot of open tasks that can highly influence the performance,
but many of them have not been solved for long years.
For now gcc vectorizer works in some
> *From:* Evgeniya Maenkova
> *Sent:* Friday, August 15, 2014 4:45PM
> *To:* gcc@gcc.gnu.org
> *Subject:* What are open tasks about GIMPLE loop optimizations?
>
> Dear GCC Developers,
>
> Nobody answers my question below, so perhaps something wrong with my email
> :)
>
Starting as a newbie in GCC
On Mon, Aug 18, 2014 at 4:37 PM, Richard Biener
wrote:
> On Sun, Aug 17, 2014 at 9:50 PM, Prathamesh Kulkarni
> wrote:
>> Hi,
>>Apparently this pattern is not getting fired (even in isolation).
>>
>> /* x % 1 -> 0 */
>> (simplify
>> (trunc_mod @0 integer_onep)
>> { build_zero_cst (type);
The wiki also contains the following: https://gcc.gnu.org/wiki/LoopOptTasks
Probably very outdated, but updating it might be a helpful learning
experience. Don't be afraid to edit the wiki, we can always revert
your changes ;-)
Cheers,
Manuel.
On 18 August 2014 13:43, Manuel López-Ibáñez wrot
On 06-08-14 17:10, Tom de Vries wrote:
The place after build_ealias is early enough to be before the lto-stream
write/read. I don't see how we can do this earlier. Before ealias, there's no
alias info, and one of the loops fails to be recognized as parallel.
Furthermore, pass_ch, pass_ccp, pass_l
On Sat, Aug 16, 2014 at 3:46 PM, Prathamesh Kulkarni
wrote:
> On Mon, Aug 11, 2014 at 4:58 PM, Richard Biener
> wrote:
>> On Sun, Aug 10, 2014 at 11:17 PM, Prathamesh Kulkarni
>> wrote:
>>> On Mon, Aug 4, 2014 at 2:13 PM, Richard Biener
>>> wrote:
On Sun, Aug 3, 2014 at 6:58 PM, Prathamesh
On Mon, Aug 18, 2014 at 1:45 PM, Prathamesh Kulkarni
wrote:
> On Mon, Aug 18, 2014 at 4:37 PM, Richard Biener
> wrote:
>> On Sun, Aug 17, 2014 at 9:50 PM, Prathamesh Kulkarni
>> wrote:
>>> Hi,
>>>Apparently this pattern is not getting fired (even in isolation).
>>>
>>> /* x % 1 -> 0 */
>>> (
On Mon, Aug 18, 2014 at 12:46 PM, Richard Biener
wrote:
> On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
>> So... I've been getting my feet wet with LTO and debugging and I noticed a
>> seemingly unrelated yet annoying problem. On x86-64,
>> gcc.dg/guality/pr48437.c fails when run in LTO
Not sure I understand what the problem is. Responded inline.
On Mon, Aug 18, 2014 at 9:43 AM, Yury Gribov wrote:
> On 08/18/2014 09:42 AM, Yury Gribov wrote:
>>
>> On 08/16/2014 04:37 AM, Manuel López-Ibáñez wrote:
>>>
>>> On the compile farm, ASAN tests seem to fail a lot like:
>>>
>>> FAIL: c-c
On Mon, Aug 18, 2014 at 9:42 AM, Yury Gribov wrote:
> On 08/16/2014 04:37 AM, Manuel López-Ibáñez wrote:
>>
>> On the compile farm, ASAN tests seem to fail a lot like:
>>
>> FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern
>> test, is ==31166==ERROR: AddressSanitizer failed to all
On 08/18/2014 06:36 PM, Alexander Potapenko wrote:
Added Sanitizer folks. Frankly it'd be cool if dumping PIDs and addresses
could be turned off.
Could you please name a reason for that?
Reproducibility?
-Y
On 18 August 2014 16:34, Alexander Potapenko wrote:
> Not sure I understand what the problem is. Responded inline.
>
> On Mon, Aug 18, 2014 at 9:43 AM, Yury Gribov wrote:
>> On 08/18/2014 09:42 AM, Yury Gribov wrote:
>>>
>>> On 08/16/2014 04:37 AM, Manuel López-Ibáñez wrote:
On the comp
>
> The following seems to fix it. In testing now.
Will streaming as non-reference prevent DECL from being merged and tails of
BLOCK_VAR chains
to be corrupted?
Honza
>
> Richard.
>
> > Richard.
> >
> >> Thanks.
> >> Aldy
Its been quite a while, hope you are doing well. I have been writing with no
response. Please respond to me, i was browsing looking for honest partner, It
hurts me so bad. No one to talk to, i want to know you and tell you more about
me, share my experience with you, with my pictures and phone
On August 18, 2014 8:46:00 PM CEST, Jan Hubicka wrote:
>>
>> The following seems to fix it. In testing now.
>
>Will streaming as non-reference prevent DECL from being merged and
>tails of BLOCK_VAR chains
>to be corrupted?
Yes, the decl ends up in the function section then, not the global types
On 08/18/14 07:31, Richard Biener wrote:
On Mon, Aug 18, 2014 at 12:46 PM, Richard Biener
wrote:
On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
For the rest them on the floor instead of ICEing in dwarf2out.c. */
Should that read "For the rest, drop them on the floor..."???
Hi
-mkernel is documented as:
Enable kernel development mode. The '-mkernel' option sets
'-static', '-fno-common', '-fno-cxa-atexit', '-fno-exceptions',
'-fno-non-call-exceptions', '-fapple-kext', '-fno-weak' and
'-fno-rtti' where applicable. This mode also sets '-mno-altive
25 matches
Mail list logo
