public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/64509] New: _Generic throws error in unselected generic association
@ 2015-01-06 10:25 maurits.de.jong at ericsson dot com
  2015-01-06 15:17 ` [Bug c/64509] " mpolacek at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: maurits.de.jong at ericsson dot com @ 2015-01-06 10:25 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 64509
           Summary: _Generic throws error in unselected generic
                    association
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: maurits.de.jong at ericsson dot com

Created attachment 34387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34387&action=edit
The offending source separately

I would have expected this to work (basically insert a conversion function
call if the type doesn't match):


-----
typedef struct {
        int x;
} mystruct;

extern int __f(int);
extern int __stoi(mystruct);

void call(void)
{
        mystruct S = {1};

        double z = _Generic((S), mystruct: __f(__stoi(S)), default: __f(S));
}
-----

but the typechecker is not happy about __f(S), which is in an association 
not relevant for the controlling expression:

The standard says:

  None of the expressions from any other generic association of the generic
  selection is evaluated.

Of course, evaluation is different from typechecking, but since the construct
is intended to conditionalise based on types, wouldn't it make sense to only
typecheck the selected association?




bash$ ./bin/gcc -std=c11 -v generic.c
Using built-in specs.
COLLECT_GCC=./bin/gcc
COLLECT_LTO_WRAPPER=/space/radmmj/gcc492/gcc-4.9.2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/space/radmmj/gcc492/gcc-4.9.2 :
(reconfigured) ../configure --prefix=/space/radmmj/gcc492/gcc-4.9.2
--enable-languages=c
Thread model: posix
gcc version 4.9.2 (GCC) 
COLLECT_GCC_OPTIONS='-std=c11' '-v' '-mtune=generic' '-march=x86-64'
 /space/radmmj/gcc492/gcc-4.9.2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1
-quiet -v -imultiarch x86_64-linux-gnu generic.c -quiet -dumpbase generic.c
-mtune=generic -march=x86-64 -auxbase generic -std=c11 -version -o
/tmp/ccEshK6s.s
GNU C (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.9.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/space/radmmj/gcc492/gcc-4.9.2/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /space/radmmj/gcc492/gcc-4.9.2/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include
 /usr/local/include
 /space/radmmj/gcc492/gcc-4.9.2/include

/space/radmmj/gcc492/gcc-4.9.2/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.9.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1bfa4fb39c457521c17e15d89fa44581
generic.c: In function ‘call’:
generic.c:12:69: error: incompatible type for argument 1 of ‘__f’
         double z = _Generic((S), mystruct: __f(__stoi(S)), default: __f(S));
                                                                     ^
generic.c:5:12: note: expected ‘int’ but argument is of type ‘mystruct’
 extern int __f(int);
            ^
>From gcc-bugs-return-472295-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 06 10:43:30 2015
Return-Path: <gcc-bugs-return-472295-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7614 invoked by alias); 6 Jan 2015 10:43:30 -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 7570 invoked by uid 48); 6 Jan 2015 10:43:26 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/64479] [4.8 Regression][SH] wrong optimization delayed-branch
Date: Tue, 06 Jan 2015 10:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.4
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_gcctarget bug_status cf_reconfirmed_on cc short_desc everconfirmed
Message-ID: <bug-64479-4-kL5txm4e15@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64479-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64479-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: 2015-01/txt/msg00289.txt.bz2
Content-length: 1197

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd479

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|sh3                         |sh*-*-*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-06
                 CC|                            |kkojima at gcc dot gnu.org,
                   |                            |olegendo at gcc dot gnu.org
            Summary|wrong optimization          |[4.8 Regression][SH] wrong
                   |delayed-branch  for SH      |optimization delayed-branch
     Ever confirmed|0                           |1

--- Comment #1 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Thanks for pinpointing and reporting this.

trunk (GCC 5): OK
4.9 branch: OK
4.8 branch: NG

This is a problem of the flaky cbranch optimization in 4.8 in the *cbranch_t
splitter code.

For some reason, modified_between_p seems to ignore the fact that the T_REG is
clobbered in call insns.  Thus it thinks that it's OK to extend the T_REG
lifetime across a call insn.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-01-14 14:59 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-06 10:25 [Bug c/64509] New: _Generic throws error in unselected generic association maurits.de.jong at ericsson dot com
2015-01-06 15:17 ` [Bug c/64509] " mpolacek at gcc dot gnu.org
2015-01-06 18:16 ` joseph at codesourcery dot com
2015-01-14 14:59 ` 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).