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
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..."???
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
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
>
> 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
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
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 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
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 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
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 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 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
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 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);
> *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
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
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 =
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 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
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 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
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 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
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
25 matches
Mail list logo
