https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65656 Bug ID: 65656 Summary: __builtin_constant_p should be constexpr Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: scovich at gmail dot com Consider the following program compiled with `gcc -std=c++11' ===== bug.cpp ===== #include int main(int argc, char *argv[]) { constexpr bool x = __builtin_constant_p(argc); std::printf("x=%d\n", x); } =================== With optimizations disabled, it correctly treats __builtin_constant_p() as constexpr and prints "0" as expected (because the value of argc is not a compile-time constant). With optimizations enabled (-O1 or higher), compilation fails: bug.cpp: In function ‘int main(int, char**)’: bug.cpp:3:48: error: ‘argc’ is not a constant expression constexpr bool x = __builtin_constant_p(argc); ^ Clang 3.4 handles the case just fine. While I can 100% understand that the return value of __builtin_constant_p() might change depending on what information the optimizer has available, I'm pretty sure __builtin_constant_p() should always return a value computable at compile time. NOTE: this issue is *NOT* the same as Bug #54021, in spite of the two sharing the same title. The latter is mis-named: It actually requests support for constant folding for ternary expressions involving __builtin_constant_p, even when optimizations are disabled and such folding would not normally occur. >From gcc-bugs-return-482529-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 01 19:41:27 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 96559 invoked by alias); 1 Apr 2015 19:41:26 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 96528 invoked by uid 48); 1 Apr 2015 19:41:22 -0000 From: "jonathan.creekmore@synapse-wireless.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/65657] New: [avr] read from __memx address space tramples argument to following function Date: Wed, 01 Apr 2015 19:41:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jonathan.creekmore@synapse-wireless.com X-Bugzilla-Status: UNCONFIRMED 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: 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-04/txt/msg00081.txt.bz2 Content-length: 2481 https://gcc.gnu.org/bugzilla/show_bug.cgi?ide657 Bug ID: 65657 Summary: [avr] read from __memx address space tramples argument to following function Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jonathan.creekmore@synapse-wireless.com Created attachment 35207 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5207&actioníit Test snippet that exhibits the problem. For an AVR target, the following code that reads from the __memx address space results in the wrong code and tramples the handle variable: extern void writeFlashByte(uint8_t byte, uint16_t handle); void writeBuf(const uint8_t __memx *from, const uint8_t __memx *to) { uint16_t handle = ((uint16_t)(((__uint24)to) & 0xFFFFUL)); writeFlashByte(*from++, handle++); } The relevant assembly code is as follows: mov r27,r22 # Move 'from' out of the way mov r26,r23 # Move 'from' out of the way mov r21,r24 # Move 'from' out of the way mov r24,r20 # Move 'to' into 'handle' for calling writeFlashByte movw r22,r18 # Move 'to' into 'handle' for calling writeFlashByte mov r30,r27 # Put the relevant bits of 'from' into place to call __xload_1 mov r31,r26 # Put the relevant bits of 'from' into place to call __xload_1 call __xload_1 # <-- Returns into r22, corrupting the lower byte of 'handle' mov r24,r22 # Move the result of __xload_1 for calling writeFlashByte jmp writeFlashByte The line marked <-- is where the badness occurs. Since __xload_1 returns into r22, the 'handle' argument to writeFlashByte (which should be in r22 and r23), gets its r22 portion corrupted by the value __xload_1. PR target/52484 mentioned adding R22 to the register footprint for xload, but that was targeted to 4.7.1, so I am not sure why this is failing in 4.8.1. == compile = avr-gcc -save-temps -mmcu=atmega128rfa1 -Os -v -Wall -Wextra -c test.c == configure = ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr Thread model: single gcc version 4.8.1 (GCC)