public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/60915] New: confusing diagnostic from attribute on function definition
@ 2014-04-21 14:40 tromey at gcc dot gnu.org
  2014-04-23 14:13 ` [Bug c/60915] " mpolacek at gcc dot gnu.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: tromey at gcc dot gnu.org @ 2014-04-21 14:40 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 60915
           Summary: confusing diagnostic from attribute on function
                    definition
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tromey at gcc dot gnu.org

Consider this program:

int something(void) __attribute__((__visibility__("default")))
{
  return 23;
}


Compiling gives:

barimba. gcc --syntax-only t.c
t.c:2:1: error: expected ‘,’ or ‘;’ before ‘{’ token
 {
 ^


A few notes here:

First, while this is not the correct syntax, it seems natural
enough that I've written it several times by mistake now.
Is there any chance it could be blessed?

Second, I think the diagnostic could be improved.  For example
it could mention that an attribute is not valid in this position
on a definition, and suggest an alternative.

Third, the manual could use an example of how to do this.
>From gcc-bugs-return-449412-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 21 14:52:45 2014
Return-Path: <gcc-bugs-return-449412-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29175 invoked by alias); 21 Apr 2014 14:52:45 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29133 invoked by uid 48); 21 Apr 2014 14:52:42 -0000
From: "ktietz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
Date: Mon, 21 Apr 2014 14:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: build
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ktietz at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60830-4-sk8UDFYb8b@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60830-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60830-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg01432.txt.bz2
Content-length: 1792

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`830

--- Comment #31 from Kai Tietz <ktietz at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #30)
> It looks like a bug in the assembler!
>
> with objdump -d -r crtbegin.o we have wrong code:
>
>   f3:   83 ec 04                sub    $0x4,%esp
>   f6:   85 c0                   test   %eax,%eax
>   f8:   ba f0 ff ff ff          mov    $0xfffffff0,%edx
>                         f9: dir32       ___deregister_frame_info
>   fd:   74 16                   je     115 <___gcc_deregister_frame+0x35>
>
>
> but the cygming-crtbegin.s looks correct:
>
> LVL17:
>         .loc 1 158 0
>         testl   %eax, %eax
>         .loc 1 162 0
>         movl    $___deregister_frame_info, %edx
>         .loc 1 158 0
>         je      L27
>
>
> whenever there is a weak definition the reference is actually minus
> the offset of the previous weak definition. Everything is OK if that was
> at offset zero.
>
> test case:
>
> $ cat test.c
> #include <stdio.h>
>
> extern void test() __attribute__((weak));
>
> int main()
> {
>   printf("hello\n");
>   test();
>   return 0;
> }
>
> __attribute__((weak))
> void test()
> {
>   printf("weak\n");
> }
>
> $ cat test1.c
> #include <stdio.h>
>
> void test()
> {
>   printf("strong\n");
> }
>
>
> $ gcc -o test test.c test1.c
> $ ./test
> hello
> Segmentation fault (core dumped)

Interesting finding.  So second issue cooks down to be an binutils bug about
weak.  I remember the cause of the change to gcc's crtbegin, and it is pretty
important one (at least for x64).  As the implicit zero-relocation doesn't work
on x64 as instructions have +/-2^31 offset in max.
So I would suggest to report this issue on binutils.  gcc's bz isn't the right
place to discuss that issue further.


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-05-01  7:41 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-21 14:40 [Bug c/60915] New: confusing diagnostic from attribute on function definition tromey at gcc dot gnu.org
2014-04-23 14:13 ` [Bug c/60915] " mpolacek at gcc dot gnu.org
2014-04-24 14:31 ` mpolacek at gcc dot gnu.org
2014-04-30  6:17 ` mpolacek at gcc dot gnu.org
2014-05-01  7:41 ` mpolacek at gcc dot gnu.org
2014-05-01  7:41 ` mpolacek at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).