This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Optimization bug?
- From: SÃren Brinkmann <soren dot brinkmann at xilinx dot com>
- To: <pinskia at gmail dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Sat, 19 Sep 2015 14:32:47 -0700
- Subject: Re: Optimization bug?
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=pass (sender IP is 149.199.60.83) smtp.mailfrom=xilinx.com; gcc.gnu.org; dkim=none (message not signed) header.d=none;gcc.gnu.org; dmarc=bestguesspass action=none header.from=xilinx.com;
- References: <20150919180019 dot GC2722 at xsjsorenbubuntu> <A4D9A9EC-DD45-4395-BB31-974C4C4536BF at gmail dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
Hi Andrew,
On Sat, 2015-09-19 at 11:34AM -0700, pinskia@gmail.com wrote:
>
>
> > On Sep 19, 2015, at 11:00 AM, SÃren Brinkmann <soren.brinkmann@xilinx.com> wrote:
> >
> > Hi,
> >
> > I recently came across some bug in my program that I could narrow down
> > to the snipped below (also attached with a Makefile).
> >
> > extern unsigned int _vector_table;
>
> You need the attribute weak here if the location of _vector_table can be a null pointer.
Indeed, that fixes the problem. Would you have any additional background
why the 'weak' is required in this case? To me it sounded like the
'-fno-delete-null-pointer-checks' should be sufficient.
Thanks,
SÃren
>
> Thanks,
> Andrew
>
>
> >
> > int main(void)
> > {
> > unsigned int *vector_base = &_vector_table;
> >
> > if (vector_base == 0) {
> > return 1;
> > } else {
> > return 2;
> > }
> > }
> >
> > The code generated for this function is (I tested a couple of different
> > compilers and architectures (4.7, 4.9 and 5.2)):
> > 0000000000000000 <main>:
> > 0: b8 02 00 00 00 mov $0x2,%eax
> > 5: c3 retq
> >
> > If my understanding is correct, this is a legal optimization under the
> > assumption that no object may reside at address 0, resulting in the
> > optimized out if branch.
> > Though, my understanding is that the switch
> > '-fno-delete-null-pointer-checks' would remove that assumption allowing
> > such code to be compiled "correctly" (I'm on an embedded system and code
> > at 0 is actually important).
> >
> > Could somebody tell me what the correct way for implementing something
> > like that would be? Or whether this is actually a gcc issue?
> >
> > Thanks,
> > SÃren
> > <main.c>
> > <Makefile>