Hi Marek,
On Do, 2014-10-23 at 10:23 +0200, Marek Polacek wrote:
> On Tue, Apr 22, 2014 at 01:58:00PM +0200, Hannes Frederic Sowa wrote:
> > I'll play around and will post a new patch in the not too distant
> > future. ;)
>
> Are you still planning on posting the revis
On Thu, Apr 17, 2014 at 04:20:06PM +0200, Ondřej Bílka wrote:
> On Sat, Apr 12, 2014 at 12:53:45AM +0200, Hannes Frederic Sowa wrote:
> > Hi!
> >
> > On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
> > > For a "quick" GCC implementation of
On Tue, Apr 15, 2014 at 03:41:53PM +0200, Richard Biener wrote:
> On Sat, Apr 12, 2014 at 12:53 AM, Hannes Frederic Sowa
> wrote:
> > Hi!
> >
> > On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
> >> For a "quick" GCC implementation of t
Hi!
On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
> For a "quick" GCC implementation of the builtins you could expand
> them to a open-coded sequence during gimplification. But due to
> the issues pointed out above I'm not sure it is the best interface
> to support (though now t
On Fri, Mar 28, 2014 at 01:15:39PM +, Andrew Haley wrote:
> On 03/28/2014 10:46 AM, Hannes Frederic Sowa wrote:
> > On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
> >> On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
> >>> On Fri, Mar 28, 20
On Fri, Mar 28, 2014 at 03:03:11PM +, Andrew Haley wrote:
> On 03/28/2014 02:48 PM, Hannes Frederic Sowa wrote:
> > On Fri, Mar 28, 2014 at 01:15:39PM +, Andrew Haley wrote:
> >> On 03/28/2014 10:46 AM, Hannes Frederic Sowa wrote:
> >>> On Fri, Mar 28, 20
On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
> On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
> > On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
> >> On 03/28/2014 06:20 AM, dw wrote:
> >>> Using this clobber causes the c
On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
> On 03/28/2014 06:20 AM, dw wrote:
> > Using this clobber causes the compiler to flush all (modified) registers
> > being used to store memory-based values to memory before executing the
> > @code{asm} statement.
>
> I don't know wha
On Tue, Mar 04, 2014 at 12:08:19PM +0100, Richard Biener wrote:
> On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa
> wrote:
> > On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
> >> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
> >> >>
On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
> >> > So the bug was probably fixed more than 15 years ago.
> > Probably :)
> >
> > But the __volatile__ shoud do no harm and shouldn't influe
On Tue, Mar 04, 2014 at 09:19:40AM +, Jonathan Wakely wrote:
> On 4 March 2014 09:17, Hannes Frederic Sowa
> wrote:
> > On Tue, Mar 04, 2014 at 10:10:21AM +0100, Richard Biener wrote:
> >> On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian wrote:
> >> > Hi,
>
On Tue, Mar 04, 2014 at 10:10:21AM +0100, Richard Biener wrote:
> On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian wrote:
> > Hi,
> > in include/linux/compiler-gcc.h :
> >
> > /* Optimization barrier */
> > /* The "volatile" is due to gcc bugs */
> > #define barrier() __asm__ __volatile__("": : :"m
On Sat, Oct 26, 2013 at 09:29:12PM +0200, Ondřej Bílka wrote:
> Hi, as I brainstormed how prevent possible overflows in memory allocation I
> came with heretic idea:
>
> For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with size_t
> type by one that checks for integer overflow and aborts o
Hello!
Because the last user of walk_use_def_chains vanished in revision r171352
(removal of ipa-struct-reorg) I wondered if this function is pending
deprecation or removal in upcoming gcc versions?
Thanks,
Hannes
Hi!
On Wed, Aug 21, 2013 at 04:43:13PM +0200, Stephen Röttger wrote:
> Approach:
> The basic idea of the thesis is to record all addresses that are
> assigned to a function pointer variable at some place in the program (or
> in one of the shared libraries) and if a function pointer is called,
> ve
15 matches
Mail list logo