On Thu, Feb 04, 2021 at 08:06:12AM +0900, Masahiro Yamada wrote:
> GCC never outputs '.file 0', which is why
> this test is only needed for Clang, correct?
No, GCC outputs .file 0 if it during configure time detected assembler that
supports it and doesn't have any of the known bugs related to it.
On Fri, Jan 29, 2021 at 02:05:59PM -0800, Nick Desaulniers wrote:
> Ah, I see. Then I should update the script I add
> (scripts/test_dwarf5_support.sh) to feature detect that bug, since
> it's the latest of the bunch. Also, should update my comment to note
> that this requires binutils greater
On Fri, Jan 29, 2021 at 04:32:32PM -0500, Arvind Sankar wrote:
> Given what Jakub is saying, i.e. it was previously impossible to get
> dwarf2 with gcc, and you get dwarf4 whether or not DEBUG_INFO_DWARF4 was
It isn't impossible to get it, -gdwarf-2 works, it is just not a very good
choice (at
On Fri, Jan 29, 2021 at 01:05:56PM -0800, Nick Desaulniers wrote:
> > Wasn't that fixed in GAS?
> > https://sourceware.org/bugzilla/show_bug.cgi?id=27195
>
> $ make LLVM=1 -j72 defconfig
> $ ./scripts/config -e DEBUG_INFO -e DEBUG_INFO_DWARF5
> $ make LLVM=1 -j72
> ...
> /tmp/init-d50d89.s:
On Fri, Jan 29, 2021 at 12:48:11PM -0800, Nick Desaulniers wrote:
> > Should this be...?
> >
> > KBUILD_AFLAGS += -Wa,-gdwarf-5
>
> No; under the set of conditions Clang is compiling .c to .S with DWARF
> v5 assembler directives. GAS will choke unless told -gdwarf-5 via
> -Wa,-gdwarf-5 for .c
On Fri, Jan 29, 2021 at 11:43:17AM -0800, Nick Desaulniers wrote:
> Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
> explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
> way that's forward compatible with existing configs, and makes adding
> future
On Sat, Nov 21, 2020 at 09:23:10PM +0100, Luc Van Oostenryck wrote:
> On Fri, Nov 20, 2020 at 01:51:54PM +0100, Peter Zijlstra wrote:
> >
> > Other option would be to change the const_ilog2 macro, though as the
> > description says it is meant to be used also in C constant expressions,
> > and
The following commit has been merged into the core/core branch of tip:
Commit-ID: ecbd43f6728a5cf79c8b50ed326658e9181531b1
Gitweb:
https://git.kernel.org/tip/ecbd43f6728a5cf79c8b50ed326658e9181531b1
Author:Jakub Jelinek
AuthorDate:Wed, 21 Oct 2020 15:27:18 +02:00
On Tue, Nov 03, 2020 at 02:21:22PM -0800, Nick Desaulniers wrote:
> > > This script fails for GCC 10.
> >
> > One thing is GCC DWARF-5 support, that is whether the compiler
> > will support -gdwarf-5 flag, and that support should be there from
> > GCC 7 onwards.
>
> I should improve my Kconfig
On Mon, Nov 02, 2020 at 11:20:41AM +0900, Masahiro Yamada wrote:
> > --- /dev/null
> > +++ b/scripts/test_dwarf5_support.sh
> > @@ -0,0 +1,4 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0
> > +set -eu
> > +echo ".file 0 \"asdf\"" | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -
>
>
>
On Wed, Oct 21, 2020 at 10:00:31AM +0200, Peter Zijlstra wrote:
> On Tue, Oct 20, 2020 at 04:39:38PM -0700, Florian Fainelli wrote:
> > This patch causes all files under kernel/sched/* that include sched.h to
> > be rebuilt whenever the value of CONFIG_BLK_DEV_INITRD. There are at
> > least two
On Wed, Dec 20, 2017 at 09:52:05PM +0100, Arnd Bergmann wrote:
> diff --git a/crypto/aes_generic.c b/crypto/aes_generic.c
> index ca554d57d01e..35f973ba9878 100644
> --- a/crypto/aes_generic.c
> +++ b/crypto/aes_generic.c
> @@ -1331,6 +1331,20 @@ EXPORT_SYMBOL_GPL(crypto_aes_set_key);
>
On Wed, Dec 20, 2017 at 09:52:05PM +0100, Arnd Bergmann wrote:
> diff --git a/crypto/aes_generic.c b/crypto/aes_generic.c
> index ca554d57d01e..35f973ba9878 100644
> --- a/crypto/aes_generic.c
> +++ b/crypto/aes_generic.c
> @@ -1331,6 +1331,20 @@ EXPORT_SYMBOL_GPL(crypto_aes_set_key);
>
On Sat, Aug 20, 2016 at 05:45:00PM -0700, Linus Torvalds wrote:
> You have to save the stack pointer at the setjmp point too. And there
> might be other architecture-specific ABI rules for that. But you're
> right, it might be worth it.
>
> I *would* be a bit worried about code generation issues.
On Sat, Aug 20, 2016 at 05:45:00PM -0700, Linus Torvalds wrote:
> You have to save the stack pointer at the setjmp point too. And there
> might be other architecture-specific ABI rules for that. But you're
> right, it might be worth it.
>
> I *would* be a bit worried about code generation issues.
On Thu, Mar 03, 2016 at 02:47:16PM +0100, Ingo Molnar wrote:
> I tried to distill a testcase out of it, and the following silly hack seems
> to
> trigger it:
...
This is a known issue, which we don't have a solution for yet.
The thing is, GCC has 2 uninitialized warning passes, one is done
On Thu, Mar 03, 2016 at 02:47:16PM +0100, Ingo Molnar wrote:
> I tried to distill a testcase out of it, and the following silly hack seems
> to
> trigger it:
...
This is a known issue, which we don't have a solution for yet.
The thing is, GCC has 2 uninitialized warning passes, one is done
On Thu, Mar 03, 2016 at 02:24:34PM +0100, Ingo Molnar wrote:
> 6 hours of PeterZ time translates to quite a bit of code restructuring
> overhead to
> eliminate false positive warnings...
I'll file a bugzilla enhancement request for this (with new attribute),
perhaps we could do it in FRE that
On Thu, Mar 03, 2016 at 02:24:34PM +0100, Ingo Molnar wrote:
> 6 hours of PeterZ time translates to quite a bit of code restructuring
> overhead to
> eliminate false positive warnings...
I'll file a bugzilla enhancement request for this (with new attribute),
perhaps we could do it in FRE that
On Thu, Mar 03, 2016 at 01:19:44PM +0100, Ingo Molnar wrote:
> struct sigaction sa;
>
> ...
>
> sigfillset(_mask);
> sa.sa_sigaction = segfault_handler;
> sigaction(SIGSEGV, , NULL);
>
> ... which uninitialized sa.sa_flags field GCC merrily accepted as
On Thu, Mar 03, 2016 at 01:19:44PM +0100, Ingo Molnar wrote:
> struct sigaction sa;
>
> ...
>
> sigfillset(_mask);
> sa.sa_sigaction = segfault_handler;
> sigaction(SIGSEGV, , NULL);
>
> ... which uninitialized sa.sa_flags field GCC merrily accepted as
On Wed, Jul 01, 2015 at 01:35:16PM -0400, Vladimir Makarov wrote:
> Actually it raise a question for me. If we describe that a function
> clobbers more than calling convention and then use it as a value (assigning
> a variable or passing as an argument) and loosing a track of it and than
> call
On Wed, Jul 01, 2015 at 11:23:17AM -0400, Vladimir Makarov wrote:
> >>(I'm not necessarily suggesting that we do this for the syscall bodies
> >>themselves. I want to do it for the entry and exit helpers, so we'd
> >>still lose the five cycles in the full fast-path case, but we'd do
> >>better in
On Wed, Jul 01, 2015 at 01:35:16PM -0400, Vladimir Makarov wrote:
Actually it raise a question for me. If we describe that a function
clobbers more than calling convention and then use it as a value (assigning
a variable or passing as an argument) and loosing a track of it and than
call it.
On Wed, Jul 01, 2015 at 11:23:17AM -0400, Vladimir Makarov wrote:
(I'm not necessarily suggesting that we do this for the syscall bodies
themselves. I want to do it for the entry and exit helpers, so we'd
still lose the five cycles in the full fast-path case, but we'd do
better in the slower
On Tue, Jun 30, 2015 at 02:22:33PM -0700, Andy Lutomirski wrote:
> I'm working on a massive set of cleanups to Linux's syscall handling.
> We currently have a nasty optimization in which we don't save rbx,
> rbp, r12, r13, r14, and r15 on x86_64 before calling C functions.
> This works, but it
On Tue, Jun 30, 2015 at 02:22:33PM -0700, Andy Lutomirski wrote:
I'm working on a massive set of cleanups to Linux's syscall handling.
We currently have a nasty optimization in which we don't save rbx,
rbp, r12, r13, r14, and r15 on x86_64 before calling C functions.
This works, but it makes
On Fri, May 01, 2015 at 09:03:32AM -0700, Linus Torvalds wrote:
> > PPS. Jakub, I see gcc5.1 still hasn't got output operands for asm goto;
> > is this something we can get 'fixed' ?
CCing Richard as author of asm goto and Vlad as register allocator
maintainer. There are a few enhancement
On Fri, May 01, 2015 at 09:03:32AM -0700, Linus Torvalds wrote:
PPS. Jakub, I see gcc5.1 still hasn't got output operands for asm goto;
is this something we can get 'fixed' ?
CCing Richard as author of asm goto and Vlad as register allocator
maintainer. There are a few enhancement
On Thu, Sep 04, 2014 at 08:24:12AM -0400, Peter Hurley wrote:
> And I just confirmed with the Alpha cross-compiler that the fields are
> not 'padded out' if volatile either.
They can't be, struct layout is part of the ABI.
Guess you can introduce say atomic_bool and similar typedefs which would
On Thu, Sep 04, 2014 at 10:57:40AM +0200, Mikael Pettersson wrote:
> Benjamin Herrenschmidt writes:
> > On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
> >
> > > Apologies for hijacking this thread but I need to extend this discussion
> > > somewhat regarding what a compiler might do
On Thu, Sep 04, 2014 at 10:57:40AM +0200, Mikael Pettersson wrote:
Benjamin Herrenschmidt writes:
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat regarding what a compiler might do with
On Thu, Sep 04, 2014 at 08:24:12AM -0400, Peter Hurley wrote:
And I just confirmed with the Alpha cross-compiler that the fields are
not 'padded out' if volatile either.
They can't be, struct layout is part of the ABI.
Guess you can introduce say atomic_bool and similar typedefs which would be
On Fri, Aug 15, 2014 at 03:23:01PM -0400, Paul Gortmaker wrote:
> --- /dev/null
> +++ b/include/linux/compiler-gcc5.h
> @@ -0,0 +1,52 @@
> +#ifndef __LINUX_COMPILER_H
> +#error "Please don't include directly, include
> instead."
> +#endif
> +
> +#define __used
On Fri, Aug 15, 2014 at 03:23:01PM -0400, Paul Gortmaker wrote:
--- /dev/null
+++ b/include/linux/compiler-gcc5.h
@@ -0,0 +1,52 @@
+#ifndef __LINUX_COMPILER_H
+#error Please don't include linux/compiler-gcc5.h directly, include
linux/compiler.h instead.
+#endif
+
+#define __used
On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote:
> On Tue, Aug 5, 2014 at 2:07 PM, Frank Ch. Eigler wrote:
> >
> > Actually, "perf probe" does (via HAVE_DWARF_SUPPORT), to place probes
> > and to extract variables at those probes, much as systemtap does.
> > Without var-tracking,
On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote:
On Tue, Aug 5, 2014 at 2:07 PM, Frank Ch. Eigler f...@redhat.com wrote:
Actually, perf probe does (via HAVE_DWARF_SUPPORT), to place probes
and to extract variables at those probes, much as systemtap does.
Without
On Tue, Aug 05, 2014 at 01:46:49PM +0200, Markus Trippelsdorf wrote:
> On 2014.08.05 at 07:31 -0400, Josh Boyer wrote:
> > Sorry to bring this back up after the fact, but it's important for a
> > number of things in various distros. I don't disagree it should be
> > disabled by default, but
On Tue, Aug 05, 2014 at 01:46:49PM +0200, Markus Trippelsdorf wrote:
On 2014.08.05 at 07:31 -0400, Josh Boyer wrote:
Sorry to bring this back up after the fact, but it's important for a
number of things in various distros. I don't disagree it should be
disabled by default, but making it
On Wed, Jul 30, 2014 at 09:13:08AM +0200, Markus Trippelsdorf wrote:
> On 2014.07.30 at 08:53 +0200, Jakub Jelinek wrote:
> > On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
> > > 3.15-stable review patch. If anyone has any objections, please
On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
> 3.15-stable review patch. If anyone has any objections, please let me know.
IMNSHO this is a too big hammer approach. The bug happened on a single
file only (right?), so if anything, IMHO it could be disabled for that
single
On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
3.15-stable review patch. If anyone has any objections, please let me know.
IMNSHO this is a too big hammer approach. The bug happened on a single
file only (right?), so if anything, IMHO it could be disabled for that
single
On Wed, Jul 30, 2014 at 09:13:08AM +0200, Markus Trippelsdorf wrote:
On 2014.07.30 at 08:53 +0200, Jakub Jelinek wrote:
On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
3.15-stable review patch. If anyone has any objections, please let me
know.
IMNSHO
On Mon, Jul 28, 2014 at 08:09:02PM +0200, Markus Trippelsdorf wrote:
> Here's the testcase:
>
> int a, b, c;
> void fn1 ()
> {
> int d;
> if (fn2 () && !0)
> {
> b = (
>{
>int e;
>fn3 ();
>switch (0)
>default:
>
On Mon, Jul 28, 2014 at 08:09:02PM +0200, Markus Trippelsdorf wrote:
Here's the testcase:
int a, b, c;
void fn1 ()
{
int d;
if (fn2 () !0)
{
b = (
{
int e;
fn3 ();
switch (0)
default:
asm volatile( :
On Sat, Jul 26, 2014 at 10:20:55PM +0200, Markus Trippelsdorf wrote:
> On 2014.07.26 at 15:55 -0400, Theodore Ts'o wrote:
> > On Sat, Jul 26, 2014 at 09:35:57PM +0200, Markus Trippelsdorf wrote:
> > >
> > > But fortunately the workaround for the new inode.c bug is the same as
> > > for the
On Sat, Jul 26, 2014 at 10:20:55PM +0200, Markus Trippelsdorf wrote:
On 2014.07.26 at 15:55 -0400, Theodore Ts'o wrote:
On Sat, Jul 26, 2014 at 09:35:57PM +0200, Markus Trippelsdorf wrote:
But fortunately the workaround for the new inode.c bug is the same as
for the original bug:
On Fri, Jul 25, 2014 at 01:01:11PM -0700, Linus Torvalds wrote:
> For example, gcc will not create a small stack frame with "sub
> $8,%rsp". No, what gcc does is to use a random "push" instruction.
> Fair enough, but that really makes things much harder to see. Here's
> an example:
That is
On Thu, Jul 24, 2014 at 11:47:17AM -0700, Linus Torvalds wrote:
> Adding Jakub to the cc, because gcc-4.9.0 seems to be terminally broken.
...
> Jakub, any ideas?
Can I ask anyone involved in this for preprocessed source and all gcc command
line options to reproduce it, best in the form of a
On Thu, Jul 24, 2014 at 11:47:17AM -0700, Linus Torvalds wrote:
Adding Jakub to the cc, because gcc-4.9.0 seems to be terminally broken.
...
Jakub, any ideas?
Can I ask anyone involved in this for preprocessed source and all gcc command
line options to reproduce it, best in the form of a
On Fri, Jul 25, 2014 at 01:01:11PM -0700, Linus Torvalds wrote:
For example, gcc will not create a small stack frame with sub
$8,%rsp. No, what gcc does is to use a random push instruction.
Fair enough, but that really makes things much harder to see. Here's
an example:
That is because for
On Tue, Jun 10, 2014 at 05:13:29PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 10, 2014 at 05:04:55PM +0200, Marek Polacek wrote:
> > On Tue, Jun 10, 2014 at 04:53:27PM +0200, Peter Zijlstra wrote:
> > > On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
> > > > +# Tell gcc to never
On Tue, Jun 10, 2014 at 05:13:29PM +0200, Peter Zijlstra wrote:
On Tue, Jun 10, 2014 at 05:04:55PM +0200, Marek Polacek wrote:
On Tue, Jun 10, 2014 at 04:53:27PM +0200, Peter Zijlstra wrote:
On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
+# Tell gcc to never replace
On Thu, Feb 13, 2014 at 03:37:08AM -0800, tip-bot for Steven Noonan wrote:
> Commit-ID: a9f180345f5378ac87d80ed0bea55ba421d83859
> Gitweb: http://git.kernel.org/tip/a9f180345f5378ac87d80ed0bea55ba421d83859
> Author: Steven Noonan
> AuthorDate: Wed, 12 Feb 2014 23:01:07 -0800
> Committer:
On Thu, Feb 13, 2014 at 03:37:08AM -0800, tip-bot for Steven Noonan wrote:
Commit-ID: a9f180345f5378ac87d80ed0bea55ba421d83859
Gitweb: http://git.kernel.org/tip/a9f180345f5378ac87d80ed0bea55ba421d83859
Author: Steven Noonan ste...@uplinklabs.net
AuthorDate: Wed, 12 Feb 2014 23:01:07
On Wed, Feb 12, 2014 at 08:11:49PM -0800, Linus Torvalds wrote:
> Jakub, any suggestions to how Steven might be able to pinpoint where
> the code generation problem lies?
For a suspected wrong-code where you have no idea where the problem is from
debugging or oops etc., usually the best way is to
On Wed, Feb 12, 2014 at 08:11:49PM -0800, Linus Torvalds wrote:
Jakub, any suggestions to how Steven might be able to pinpoint where
the code generation problem lies?
For a suspected wrong-code where you have no idea where the problem is from
debugging or oops etc., usually the best way is to
On Tue, Nov 19, 2013 at 04:57:49PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 19, 2013 at 03:29:12PM +, Mathieu Desnoyers wrote:
> > However, looking at ARM arch/arm/include/asm/thread_info.h:
> >
> > static inline struct thread_info *current_thread_info(void) { register
> > unsigned long sp
On Tue, Nov 19, 2013 at 04:57:49PM +0100, Peter Zijlstra wrote:
On Tue, Nov 19, 2013 at 03:29:12PM +, Mathieu Desnoyers wrote:
However, looking at ARM arch/arm/include/asm/thread_info.h:
static inline struct thread_info *current_thread_info(void) { register
unsigned long sp asm (sp);
On Thu, Oct 10, 2013 at 07:04:18AM -0700, Richard Henderson wrote:
> On 10/10/2013 01:31 AM, Jakub Jelinek wrote:
> > Also, for the bitops patch, you probably want an asm_volatile_goto variant.
>
> Why? Asm without output (which asm goto must be) are automatically volatile
t; + *
> > + * Work it around via quirk suggested by Jakub Jelinek.
> > + * Fixed in GCC 4.8.2 and later versions.
> > + */
> > +#if GCC_VERSION <= 40801
>
> We didn't do version checks for CC_HAVE_ASM_GOTO because of vendor
> backports; can't we detect
> + * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
> + *
> + * Work it around via quirk suggested by Jakub Jelinek.
> + * Not yet fixed, so use the quirk on all compiler versions:
> + */
> +#if GCC_VERSION <= 9
> +# define asm_goto(x...) do { asm goto(x); asm ("
On Thu, Oct 10, 2013 at 08:51:04AM +0200, Jakub Jelinek wrote:
> @@ -8,6 +8,7 @@ foo (int a, int b)
>asm volatile goto ("bts $1, %0; jc %l[lab]" : : "m" (b) : "memory" : lab);
>return 0;
> lab:
> + asm ("");
>return 0;
>
On Thu, Oct 10, 2013 at 08:22:38AM +0200, Ingo Molnar wrote:
> > On Wed, Oct 09, 2013 at 09:02:31PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 09, 2013 at 08:16:13PM +0200, Jakub Jelinek wrote:
> > >
> > > > Confirmed as gcc bug, filed http://gcc.gnu.org/
On Thu, Oct 10, 2013 at 08:22:38AM +0200, Ingo Molnar wrote:
On Wed, Oct 09, 2013 at 09:02:31PM +0200, Peter Zijlstra wrote:
On Wed, Oct 09, 2013 at 08:16:13PM +0200, Jakub Jelinek wrote:
Confirmed as gcc bug, filed http://gcc.gnu.org/PR58670 Seems all of
4.[6-9] miscompile
On Thu, Oct 10, 2013 at 08:51:04AM +0200, Jakub Jelinek wrote:
@@ -8,6 +8,7 @@ foo (int a, int b)
asm volatile goto (bts $1, %0; jc %l[lab] : : m (b) : memory : lab);
return 0;
lab:
+ asm ();
return 0;
}
Or alternatively put the asm (); right after asm goto,
asm volatile goto
it around via quirk suggested by Jakub Jelinek.
+ * Not yet fixed, so use the quirk on all compiler versions:
+ */
+#if GCC_VERSION = 9
+# define asm_goto(x...) do { asm goto(x); asm (); } while (0)
+#else
+# define asm_goto(x...) do { asm goto(x); } while (0)
+#endif
#ifdef
suggested by Jakub Jelinek.
+ * Fixed in GCC 4.8.2 and later versions.
+ */
+#if GCC_VERSION = 40801
We didn't do version checks for CC_HAVE_ASM_GOTO because of vendor
backports; can't we detect this in the same way?
The problem is that it will be harder to check for this as compile time only
On Thu, Oct 10, 2013 at 07:04:18AM -0700, Richard Henderson wrote:
On 10/10/2013 01:31 AM, Jakub Jelinek wrote:
Also, for the bitops patch, you probably want an asm_volatile_goto variant.
Why? Asm without output (which asm goto must be) are automatically volatile.
You're right
On Wed, Oct 09, 2013 at 09:02:31PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 09, 2013 at 08:16:13PM +0200, Jakub Jelinek wrote:
> > Confirmed as gcc bug, filed http://gcc.gnu.org/PR58670
> > Seems all of 4.[6-9] miscompile it. Will have a look tomorrow
> > unl
On Wed, Oct 09, 2013 at 04:46:56PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 09, 2013 at 04:33:59PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 09, 2013 at 04:07:34PM +0200, Peter Zijlstra wrote:
> > > Once I force a x86_64 build using the 'same' config it goes away and
> > > generates
On Wed, Oct 09, 2013 at 04:46:56PM +0200, Peter Zijlstra wrote:
On Wed, Oct 09, 2013 at 04:33:59PM +0200, Peter Zijlstra wrote:
On Wed, Oct 09, 2013 at 04:07:34PM +0200, Peter Zijlstra wrote:
Once I force a x86_64 build using the 'same' config it goes away and
generates 'sensible' code
On Wed, Oct 09, 2013 at 09:02:31PM +0200, Peter Zijlstra wrote:
On Wed, Oct 09, 2013 at 08:16:13PM +0200, Jakub Jelinek wrote:
Confirmed as gcc bug, filed http://gcc.gnu.org/PR58670
Seems all of 4.[6-9] miscompile it. Will have a look tomorrow
unless somebody beats me
On Tue, Oct 08, 2013 at 08:51:54PM +0200, Oleg Nesterov wrote:
> On 10/08, Linus Torvalds wrote:
> >
> > (not yet merged), see:
> >
> >
> > http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=0c44c2d0f459cd7e275242b72f500137c4fa834d
>
> I do not really understand inline
On Tue, Oct 08, 2013 at 08:51:54PM +0200, Oleg Nesterov wrote:
On 10/08, Linus Torvalds wrote:
(not yet merged), see:
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=0c44c2d0f459cd7e275242b72f500137c4fa834d
I do not really understand inline assembly
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
> I'm suggesting that the string returned by get_extended_error_info()
> ought to be the audit record the system call would generate, regardless
> of whether the audit system would emit it or not.
What system call would that info be
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
I'm suggesting that the string returned by get_extended_error_info()
ought to be the audit record the system call would generate, regardless
of whether the audit system would emit it or not.
What system call would that info be
On Thu, Feb 14, 2008 at 09:25:35PM +0100, Ingo Molnar wrote:
> The per function call overhead from stackprotector is already pretty
> serious IMO, but at least that's something that GCC _could_ be doing
> (much) smarter (why doesnt it jne forward out to __check_stk_failure,
> instead of
On Thu, Feb 14, 2008 at 09:25:35PM +0100, Ingo Molnar wrote:
The per function call overhead from stackprotector is already pretty
serious IMO, but at least that's something that GCC _could_ be doing
(much) smarter (why doesnt it jne forward out to __check_stk_failure,
instead of generating
On Wed, Feb 13, 2008 at 08:26:50AM +0100, Ingo Molnar wrote:
>
> * Jakub Jelinek <[EMAIL PROTECTED]> wrote:
>
> > x86: use generic register names in struct sigcontext
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=742fa54a62be6
On Wed, Feb 13, 2008 at 08:26:50AM +0100, Ingo Molnar wrote:
* Jakub Jelinek [EMAIL PROTECTED] wrote:
x86: use generic register names in struct sigcontext
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=742fa54a62be6a263df14a553bf832724471dfbe
Hi!
The
x86: use generic register names in struct sigcontext
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=742fa54a62be6a263df14a553bf832724471dfbe
changeset breaks userland, e.g. it is not possible to compile gcc anymore
(both 32-bit and 64-bit libgcc), and I
Hi!
The
x86: use generic register names in struct sigcontext
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=742fa54a62be6a263df14a553bf832724471dfbe
changeset breaks userland, e.g. it is not possible to compile gcc anymore
(both 32-bit and 64-bit libgcc), and I
On Tue, Feb 05, 2008 at 01:54:26PM +0100, Ingo Molnar wrote:
> * Jiri Kosina <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 5 Feb 2008, Pavel Machek wrote:
> >
> > > > Actually, this clearly shows that either prehistoric libc.so.5 or the
> > > > program itself are broken.
> > > I believe it shows
On Tue, Feb 05, 2008 at 01:54:26PM +0100, Ingo Molnar wrote:
* Jiri Kosina [EMAIL PROTECTED] wrote:
On Tue, 5 Feb 2008, Pavel Machek wrote:
Actually, this clearly shows that either prehistoric libc.so.5 or the
program itself are broken.
I believe it shows clear regression in
On Wed, Jan 09, 2008 at 02:35:32AM -0800, [EMAIL PROTECTED] wrote:
> After I patched my 2.6.23 kernel to 2.6.24-rc7 this morning, I noticed
> some odd behavior with respect to POSIX threads in a test program I had
> written (originally to test epoll.)
>
> The behavior is as follows:
>
> 1.
On Wed, Jan 09, 2008 at 02:35:32AM -0800, [EMAIL PROTECTED] wrote:
After I patched my 2.6.23 kernel to 2.6.24-rc7 this morning, I noticed
some odd behavior with respect to POSIX threads in a test program I had
written (originally to test epoll.)
The behavior is as follows:
1. main()
On Mon, Dec 03, 2007 at 12:34:17PM +0100, Thomas Gleixner wrote:
> Of course just to annoy you :)
It doesn't matter whether I'm annoyed about this or not, but whether gcc is
able to generate decent code with it or not. And especially with union it
is not, at least through all the tree ssa
On Mon, Dec 03, 2007 at 09:17:22AM +0100, Thomas Gleixner wrote:
> I looked at the disassembly but I can not spot the problem.
>
> I think the real problem is somewhere else. Likely candidates are
> hrtimer_forward() or hrtimer_start() - in that order.
Should be hopefully fixed in latest Fedora
On Mon, Dec 03, 2007 at 09:17:22AM +0100, Thomas Gleixner wrote:
I looked at the disassembly but I can not spot the problem.
I think the real problem is somewhere else. Likely candidates are
hrtimer_forward() or hrtimer_start() - in that order.
Should be hopefully fixed in latest Fedora gcc.
On Mon, Dec 03, 2007 at 12:34:17PM +0100, Thomas Gleixner wrote:
Of course just to annoy you :)
It doesn't matter whether I'm annoyed about this or not, but whether gcc is
able to generate decent code with it or not. And especially with union it
is not, at least through all the tree ssa passes.
On Sun, Nov 11, 2007 at 07:48:29AM +0100, Adrian Bunk wrote:
> The gcc from svn that will become gcc 4.3 generates libgcc calls in
> cases like the following (on 32bit architectures):
>
> <-- snip -->
>
> static inline void timespec_add_ns(struct timespec *a, u64 ns)
> {
> ...
>
On Sun, Nov 11, 2007 at 07:48:29AM +0100, Adrian Bunk wrote:
The gcc from svn that will become gcc 4.3 generates libgcc calls in
cases like the following (on 32bit architectures):
-- snip --
static inline void timespec_add_ns(struct timespec *a, u64 ns)
{
...
while(ns =
On Fri, Sep 21, 2007 at 10:45:02PM +0200, Andi Kleen wrote:
>
> Kernel doesn't use SSE2, so it doesn't need 16 byte alignment. Also
> the stack can be already unaligned so letting the compiler align
> is useless. This may make some stack frames smaller.
Shouldn't sources that are compiled into
On Fri, Sep 21, 2007 at 10:45:02PM +0200, Andi Kleen wrote:
Kernel doesn't use SSE2, so it doesn't need 16 byte alignment. Also
the stack can be already unaligned so letting the compiler align
is useless. This may make some stack frames smaller.
Shouldn't sources that are compiled into the
On Fri, Sep 14, 2007 at 01:00:57PM +0200, Olaf Hering wrote:
> include/asm-powerpc/elf.h has 6 entries in ARCH_DLINFO.
> fs/binfmt_elf.c has 14 unconditional NEW_AUX_ENT entries and 2
> conditional NEW_AUX_ENT entries.
> So in the worst case, saved_auxv does not get an AT_NULL entry at the
> end.
On Fri, Sep 14, 2007 at 01:00:57PM +0200, Olaf Hering wrote:
include/asm-powerpc/elf.h has 6 entries in ARCH_DLINFO.
fs/binfmt_elf.c has 14 unconditional NEW_AUX_ENT entries and 2
conditional NEW_AUX_ENT entries.
So in the worst case, saved_auxv does not get an AT_NULL entry at the
end.
Is
On Wed, Aug 08, 2007 at 04:03:07PM +0200, Jiri Kosina wrote:
> @@ -870,11 +917,15 @@ static int load_elf_binary(struct linux_binprm *bprm,
> struct pt_regs *regs)
>* default mmap base, as well as whatever program they
>* might try to exec. This is
On Wed, Aug 08, 2007 at 04:03:07PM +0200, Jiri Kosina wrote:
@@ -870,11 +917,15 @@ static int load_elf_binary(struct linux_binprm *bprm,
struct pt_regs *regs)
* default mmap base, as well as whatever program they
* might try to exec. This is
On Fri, Aug 03, 2007 at 09:59:32AM +, gregfe wrote:
> I find little documentation on the actual implementation of POSIX message
> queues in Linux, and need some advise. In particular, I am wondering
> whether it supports inter-process *and* inter-thread communication, and if
Not sure what
1 - 100 of 292 matches
Mail list logo
