All of lore.kernel.org
 help / color / mirror / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue
Date: Mon, 15 Apr 2019 07:19:13 -0700	[thread overview]
Message-ID: <CAMKF1sps-k6m=ZrpuMmhj23ZkmF8C=17hGPscRH-V0cagV-2rw@mail.gmail.com> (raw)
In-Reply-To: <20190415093825.GB4317@localhost>

[-- Attachment #1: Type: text/plain, Size: 2532 bytes --]

On Mon, Apr 15, 2019 at 2:38 AM Adrian Bunk <bunk@stusta.de> wrote:

> On Mon, Apr 08, 2019 at 08:53:49PM -0700, Khem Raj wrote:
> > On Mon, Apr 8, 2019 at 7:32 PM <mingli.yu@windriver.com> wrote:
> > >
> > > From: Mingli Yu <Mingli.Yu@windriver.com>
> > >
> > > When DEBUG_BUILD = "1" added in local.conf, there
> > > comes below build error when "bitbake gcc-sanitizers":
> > > |
> ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:
> In function 'elf_is_symlink':
> > > |
> ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21:
> error: 'st.st_mode' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> > > |   return S_ISLNK (st.st_mode);
> > >
> > > Per https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html,
> > > the gcc upstream thinks the warning is a false
> > > positive and suggests to use -O2 rather than -Og
> > > or -O1 when compiling that file, so pass -Wno-error
> > > to compiler when -Og is used to silence the error.
> > >
> >
> > Not particular to this change but in general if a package says that it
> > does not support -Og
> > then we are just going to get into more and more untested grounds
> > especially during runtime
> > so I wonder how useful it will be to use -Og for such packages or any
> > other non supported
> > combination for that matter.
>
> This has nothing to do with specific packages not supporting -Og
> or any other combination, it is just about how to best workaround
> a compiler bug temporarily.
>
> gcc has bug(s) emitting bogus warnings with -Og, and these are build
> failures with some packages that build with -Werror.
>
> None of this is related to whether or not the packages will work
> at runtime with -Og.


What are you trying to convey ? That’s what I mentioned before I began my
reply however to reiterate my point was if a package is not usually built
and tested with this combination which is evident because it fails to build
then how good would it be if we fix this error especially complex packages
like compilers so is it worth to fix them or disable Og for them

>
>
> cu
> Adrian
>
> --
>
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
>
>

[-- Attachment #2: Type: text/html, Size: 3470 bytes --]

  reply	other threads:[~2019-04-15 14:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-19  8:44 [PATCH] gcc-sanitizers: fix -Werror=maybe-uninitialized issue mingli.yu
2019-03-26  1:37 ` Yu, Mingli
2019-04-04  9:36 ` Yu, Mingli
2019-04-05 22:01 ` Khem Raj
2019-04-08  6:40   ` [PATCH v2] " mingli.yu
2019-04-09  2:32   ` [PATCH v3] " mingli.yu
2019-04-09  3:53     ` Khem Raj
2019-04-15  9:27       ` Yu, Mingli
2019-04-15  9:38       ` Adrian Bunk
2019-04-15 14:19         ` Khem Raj [this message]
2019-04-15 16:21           ` Adrian Bunk
2019-04-16  8:45             ` Yu, Mingli
2019-04-16 18:00               ` Khem Raj
2019-04-17  7:49                 ` Yu, Mingli
2019-04-17 17:14                   ` Khem Raj
2019-04-22  5:45                     ` Yu, Mingli
2019-04-22  8:41                     ` [PATCH v4] " mingli.yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMKF1sps-k6m=ZrpuMmhj23ZkmF8C=17hGPscRH-V0cagV-2rw@mail.gmail.com' \
    --to=raj.khem@gmail.com \
    --cc=bunk@stusta.de \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.