Hi,
I sent my last “driver/options” patch to Neil Booth, listed as “option
handling” maintainer, but the email bounced back from his daikokuya.co.uk
address. Given that he did not commit to the tree since January 2005 (almost 10
years), and that his last commit was to the toplevel ChangeLog:
2
On 10/14/14 13:40, Andrew MacLeod wrote:
On 09/15/2014 02:18 PM, Andrew MacLeod wrote:
During the re-architecture session at Cauldron, I mentioned the
possibility of introducing a plugin-headers.h.
This would be a file which plugins could use which would protect them
somewhat from header file r
Another similar issue I've seen is handling DW_TAG_lexical_block
(gen_lexical_block_die). Ideally we should generate the
DW_TAG_lexical_block and the corresponding locals in early dumping, and
then fill in the high/low attributes of the lexical block the second
time around. We would need a has
On 10/14/14 06:21, Richard Biener wrote:
On Tue, Oct 14, 2014 at 2:48 AM, Aldy Hernandez wrote:
Gentlemen, your feedback would be greatly appreciated!
I was investigating why locals were not being early dumped, and realized
Michael's patch was skipping decls_for_scope() unless
DECL_STRUCT_FUNC
On 09/15/2014 02:18 PM, Andrew MacLeod wrote:
During the re-architecture session at Cauldron, I mentioned the
possibility of introducing a plugin-headers.h.
This would be a file which plugins could use which would protect them
somewhat from header file restructuring. The idea is that it inclu
Hi Umesh,
My apologies if I shouldn't have sent this answer to all on this list,
but since this is the first time I ever replied on any GCC/LLVM thread,
I'm taking a guess. I'm finishing a Ph.D. in static analysis and I have
lectured compiler courses in the last few years as well as implemente
Hi Michael,
On Tue, Oct 14, 2014 at 04:24:13PM +0200, Michael Matz wrote:
> Hi,
>
> On Tue, 14 Oct 2014, Jamie Iles wrote:
>
> > int foo(void)
> > {
> > if (getreturn() != 0)
> > return -1;
> >
> > return 0;
> > }
>
> So if getreturn(
Hi,
On Tue, 14 Oct 2014, Jamie Iles wrote:
> int foo(void)
> {
> if (getreturn() != 0)
> return -1;
>
> return 0;
> }
So if getreturn() returns zero it can simply reuse that return value ...
> but at -O1 I get
>
> 10:
On Tue, Oct 14, 2014 at 2:48 AM, Aldy Hernandez wrote:
> Gentlemen, your feedback would be greatly appreciated!
>
> I was investigating why locals were not being early dumped, and realized
> Michael's patch was skipping decls_for_scope() unless
> DECL_STRUCT_FUNCTION->gimple_df was set. I assume
On Tue, Oct 14, 2014 at 03:19:10PM +0400, Dmitry Vyukov wrote:
> > One problem is that for BUILT_IN_ASAN_REPORT_{LOAD,STORE}_N patch I need
> > libsanitizer APIs (__asan_loadN, __asan_storeN) which were introduced in a
> > giant libsanitizer merge in 5.0. In current patchset I backport the whole
>
On 10/14/2014 03:19 PM, Dmitry Vyukov wrote:
On Tue, Oct 14, 2014 at 3:07 PM, Yury Gribov wrote:
On 09/18/2014 01:57 PM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 01:46:21PM +0400, Yury Gribov wrote:
Kernel Asan patches are currently being discussed in LKML. One of the
points>> raised duri
On Tue, Oct 14, 2014 at 3:07 PM, Yury Gribov wrote:
> On 09/18/2014 01:57 PM, Jakub Jelinek wrote:
>> On Thu, Sep 18, 2014 at 01:46:21PM +0400, Yury Gribov wrote:
>>> Kernel Asan patches are currently being discussed in LKML. One of the
>>> points>> raised during review was that KAsan requires GCC
On Tue, Oct 14, 2014 at 03:07:42PM +0400, Yury Gribov wrote:
> Finally got time to look into this. I've successfully backported 22 patches
> to 4.9:
> * bugfixes (12 patches)
> * install Asan headers (1 patch)
> * libsanitizer merge (1 patch) - this is questionable, see below for
> discussion
> * B
On 09/18/2014 01:57 PM, Jakub Jelinek wrote:
> On Thu, Sep 18, 2014 at 01:46:21PM +0400, Yury Gribov wrote:
>> Kernel Asan patches are currently being discussed in LKML. One of
the points>> raised during review was that KAsan requires GCC 5.0 which
is presumably
>> unstable (e.g. compilation of
Hi folks,
I'm retargetting GCC to a custom architecture
(https://github.com/jamieiles/gcc-oldland is the retarget) and have an
odd problem with function return values near the end of a function being
eliminated. For example:
extern int getreturn(void);
int foo(void)
Hi,
in this email I'm trying to explain in detail what problem I'm running into with
reductions in oacc kernels region, and how I think it could be solved.
Any advice is welcome.
OVERALL PROBLEM
The overall problem I'm trying to solve is to implement the oacc kernels
directive in gcc, reus
On Tue, Oct 07, 2014 at 11:07:56PM +0200, Marek Polacek wrote:
> I'd like to kick off a discussion about moving the default standard
> for C from gnu89 to gnu11.
The consensus seems to be to go forward with this change. I will
commit the patch in 24 hours unless I hear objections.
Thanks,
On Sun, Oct 12, 2014 at 7:44 PM, Uros Bizjak wrote:
>>> Right. And my question is what happens if we aren't as aggressive here.
>>> What happens if before this check we return nonzero if X or Y is a VALUE?
>>> Do we then get into memrefs_conflict_p and does it do the right thing?
>>
>> Following
18 matches
Mail list logo
