[Bug c/28581] New: Illegal loading the address of a label with -O2

[Bug c/28581] New: Illegal loading the address of a label with -O2

[inaoka dot kazuhiro at renesas dot com]

The label is placed on illegal address when only loading the address of a label
without jump into. (compile with -O2 option)


test_func()
{
        func(&&here);
        func1();
here:
        func2();
}


-- 
           Summary: Illegal loading the address of a label with -O2
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: inaoka dot kazuhiro at renesas dot com
GCC target triplet: i386


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug c/28581] Illegal loading the address of a label with -O2

[inaoka dot kazuhiro at renesas dot com]

------- Comment #1 from inaoka dot kazuhiro at renesas dot com  2006-08-03 06:07 -------
Created an attachment (id=12001)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12001&action=view)
testcase

gcc -S -O2 label_address.c

label_address.s

        .file   "label_address.c"
        .text
        .p2align 4,,15
.globl test_func
        .type   test_func, @function
test_func:
.L2:                     <====== NG
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        movl    $.L2, (%esp)
        call    func
        call    func1
        call    func2
        leave
        .p2align 4,,4
        ret
        .size   test_func, .-test_func
        .ident  "GCC: (GNU) 4.1.2 20060708 (prerelease) (Debian 4.1.1-8)"
        .section        .note.GNU-stack,"",@progbits


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-08-03 11:44 -------
This is actually invalid but I cannot find where in the docs which talk about
this issue.  What is happening is the scheduler is moving around the label as
the basic block which contains the user label is gone.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-08-08 00:33 -------
This is invalid as there are no computed gotos in your example so the compiler
does not know it is a target for a goto so it is able to move the label around.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-11-16 19:57 -------
*** Bug 34116 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sparc64 at rediffmail dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[sparc64 at rediffmail dot com]

------- Comment #5 from sparc64 at rediffmail dot com  2007-11-17 11:50 -------
(In reply to comment #3)
> This is invalid as there are no computed gotos in your example so the compiler
> does not know it is a target for a goto so it is able to move the label around.

I dont understand why this bug is invalid. When I use "&&label", I intend to
load the address where I point to in my code -- not where the compiler wants to
move it around.  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2007-11-17 20:36 -------
(In reply to comment #5)
> I dont understand why this bug is invalid. When I use "&&label", I intend to
> load the address where I point to in my code -- not where the compiler wants to
> move it around.  

No, this extension is not designed that way.  It is only designed for computed
goto's.
Please read:
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Labels-as-Values.html

Thanks,
Andrew Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[sparc64 at rediffmail dot com]

------- Comment #7 from sparc64 at rediffmail dot com  2007-11-18 06:41 -------

> No, this extension is not designed that way.  It is only designed for computed
> goto's.

So, Are programmers expected to see their code work differently with
optimization enabled ? I dont think so.

> Please read:
> http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Labels-as-Values.html

I dont find anything in this site that says that the compiler will generate
correct code only when used on a "goto" statement.

I am sure that even the "goto" statement mentioned in this site will not work
with optimization enabled. I am referring to this:
"
void *ptr;
ptr = &&foo;
....
goto *ptr;
"
I will do a quick check and get back. Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[sparc64 at rediffmail dot com]

------- Comment #8 from sparc64 at rediffmail dot com  2007-11-18 07:25 -------
Ok, Continued :

The "goto" statement works fine with optimization unless that "goto" is
needless (like "goto" to next C statement) in which case, usage of "labels" as
addresses in other places (like printf) takes a beating.

The compiler is refusing to see the usage of labels as addresses in other
places than "goto"s.  I think you call this "design". But one cant expect the
code to produce different results with "optimization" enabled. This is against
the definition of "optimization".

It would be nice if you could include a fix for this. It even helps writing
"self-modifying" code, you see. (apart from "goto"s). In fact that is when I
hit this problem.

Ofcourse, self-modifying code has other architectural limitations (like harvard
cache structure etc..). But it is upto the programmer to over-come it.

So, I would really appreciate if you can get this fixed in a future "gcc"
release.

Thank you


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[sparc64 at rediffmail dot com]

------- Comment #9 from sparc64 at rediffmail dot com  2007-11-18 07:28 -------
I must have said "architectural hurdles" not "limitations..." especially
because I have quoted "harvard cache" as an example.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[ebotcazou at gcc dot gnu dot org]

------- Comment #10 from ebotcazou at gcc dot gnu dot org  2007-11-18 08:46 -------
> The compiler is refusing to see the usage of labels as addresses in other
> places than "goto"s.  I think you call this "design". But one cant expect
> the code to produce different results with "optimization" enabled. This is
> against the definition of "optimization".

This is acceptable if the code is deemed invalid.

> It would be nice if you could include a fix for this. It even helps writing
> "self-modifying" code, you see. (apart from "goto"s). In fact that is when I
> hit this problem.

I agree that we should clarify the documentation if we definitely rule the
code as being invalid.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[sparc64 at rediffmail dot com]

------- Comment #11 from sparc64 at rediffmail dot com  2007-11-18 14:44 -------
> I agree that we should clarify the documentation if we definitely rule the
> code as being invalid.

Since "&&" is a C extension, I believe one can reserve the right to limit how
long it extends. But this limitation, which hits only when "optimization" kicks
in is very very misleading. And, I find such a limitation spoiling the whole
idea of having the extension.

For example, the original post posted by "inaoka" tries to pass a pointer
loaded with "&&" extension. And, he has run into trouble.

The point here is that the "Optimization" rule is very quick to rule out that
the usage of "&&" is only for "goto"s. This precludes a beautiful C extension
from being as beautiful as it ought to be.

It would be really nice on the part of GCC developers to fix this. I am sure
this must be a very small thing to fix (apologies if not).

Thanks


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[steven at gcc dot gnu dot org]

------- Comment #12 from steven at gcc dot gnu dot org  2007-11-18 16:05 -------
This is not a smal thing to fix at all.

"Fixing" this involves teaching the compiler that some labels cannot be moved;
that these labels are optimization barriers (i.e. no insn can be safely moved
up or down across the label); that basic blocks beginning with an addressable
label cannot be merged with other basic blocks, duplicated for e.g. unrolling
or versioning, or removed if they have become unreachable; and probably many
more things.

This is not "spoiling" the idea of the extension.  You're just using it in a
way that the extension is not intended for.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joel.porquet at gmail dot com

--- Comment #13 from Andreas Schwab <schwab@linux-m68k.org> ---
*** Bug 101559 has been marked as a duplicate of this bug. ***

[Bug middle-end/28581] Illegal loading the address of a label with -O2

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |DUPLICATE

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---


*** This bug has been marked as a duplicate of bug 44298 ***