[Bug c++/80886] New: __builtin_constant_p magic has broken at some point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80886
Bug ID: 80886
Summary: __builtin_constant_p magic has broken at some point
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: q@rsn-tech.co.uk
Target Milestone: ---
I'm using g++ for an embedded system, and as is common with such things,
hardware addresses are provided as hex constants. I want to create pointers
from them, using constexpr because they are known at compile time.
Now the C++ Standard forbids reinterpret_cast<> or the equivalent in a
constexpr so it can't be done directly, which is annoying but that's the
Standard.
However, with older versions of g++, one could solve this with the magic use of
__builtin_constant_p() in a ternary expression. Thus:
test.cpp:
#define CONST(x) (__builtin_constant_p(x) ? x : x)
constexpr void *phardware {CONST ((void *) 0x1000)};
(This is sufficient for a complete test program, BTW)
This use appears to be documented, although it's not 100% clear. It's certainly
very desirable.
My cross-development system recently upgraded from 4.9.2 to 6.2.1 and the magic
has stopped working. The loss of magic holds in other 6.x versions I've tried,
but still works in clang 3.8.1 which is the latest version in my distro (Fedora
24)
Compilation results:
$ <4.9.2>-g++ -c -std=c++14 test.cpp
$
$ <6.2.1>-g++ -c -std=c++14 test.cpp
test.cpp:4:28: error: reinterpret_cast from integer to pointer
constexpr void *phardware {CONST ((void *) 0x1000)};
^~
test.cpp:2:45: note: in definition of macro 'CONST'
#define CONST(x) (__builtin_constant_p(x) ? x : x)
$
Has this behaviour changed deliberately? As I say, it is contrary to the
Standard, but it would be disappointing to lose such a useful extension.
[Bug c/63612] New: #pragma breaks if...else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
Bug ID: 63612
Summary: #pragma breaks if...else
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: q@rsn-tech.co.uk
The following program fails to compile, giving the error "else without a
previous if". Removing (or commenting out) the #pragma restores correct
behaviour.
int main (int argc, char *argv[])
{
if (argc == 1)
return 1;
#pragma message ("This is a message")
else
return 0;
}
Other valid pragmas (such as #pragma pack) also exhibit this bug, but invalid
ones (like #pragma asasdadf) don't, nor do other preprocessor directives (such
as #define FOO).
It exists in at least two builds of gcc 4.8.3, in ARM cross-compilation and
native x64:
$ /opt/Xilinx/SDK/current/gnu/arm/lin/arm-xilinx-eabi/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/Xilinx/SDK/current/gnu/arm/lin/arm-xilinx-eabi/bin/gcc
Target: arm-xilinx-eabi
Configured with:
/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/src/gcc-4.8-2014.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-xilinx-eabi
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--with-arch=armv7-a --with-cpu=cortex-a9 --with-float=softfp
--with-fpu=neon-fp16 --disable-multilib --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps: -fverbose-asm} -D__CS_SOURCERYGXX_MAJ__=2014
-D__CS_SOURCERYGXX_MIN__=5 -D__CS_SOURCERYGXX_REV__=22'
--enable-languages=c,c++ --disable-shared --enable-lto --with-newlib
--with-pkgversion='Sourcery CodeBench Lite 2014.05-22'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery --with-headers=yes
--with-sysroot=/opt/codesourcery/arm-xilinx-eabi
--with-build-sysroot=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/install/opt/codesourcery/arm-xilinx-eabi
--with-gmp=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/obj/pkg-2014.05-22-arm-xilinx-eabi/xilinx-2014.05-22-arm-xilinx-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/obj/pkg-2014.05-22-arm-xilinx-eabi/xilinx-2014.05-22-arm-xilinx-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/obj/pkg-2014.05-22-arm-xilinx-eabi/xilinx-2014.05-22-arm-xilinx-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-isl=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/obj/pkg-2014.05-22-arm-xilinx-eabi/xilinx-2014.05-22-arm-xilinx-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-cloog=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/obj/pkg-2014.05-22-arm-xilinx-eabi/xilinx-2014.05-22-arm-xilinx-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --disable-libatomic --disable-libssp
--enable-poison-system-directories
--with-build-time-tools=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/install/opt/codesourcery/arm-xilinx-eabi/bin
--with-build-time-tools=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/install/opt/codesourcery/arm-xilinx-eabi/bin
SED=sed
Thread model: single
gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-22)
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC)
[Bug c/63612] #pragma breaks if...else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612 --- Comment #3 from steveren --- That seems strange and counterintuitive to say the least. FWIW, three other compilers I've got to hand - clang on Linux, Visual C++ and an old Borland compiler on Windows - all do exactly as I'd expect, printing a compile-time message without it affecting the code semantics. Open64 silently ignores the pragma but the code still compiles and runs corectly. Is there any public discussion of the rationale behind this design decision? I've not been able to find anything. Thanks.
[Bug c/63612] #pragma breaks if...else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
--- Comment #6 from steveren ---
(In reply to Dietmar Schindler from comment #5)
> In news:comp.std.c there is a thread "#pragma are considered statements" -
> https://groups.google.com/forum/#!topic/comp.std.c/A1rhyQ5zB7g/discussion -
Thanks Dietmar.
Seems the consensus is that it's not contrary to Standard, but it's agreed to
be confusing and undesirable by everyone except the gcc maintainers :-)
FWIW, the actual context in which I found the behaviour was this:
if (whatever...)
{
stuff...
}
#ifdef FOO
#pragma message ("QUICK AND DIRTY HACK!!!")
else if (special case...)
{
other stuff...
}
#endif // FOO
I'll take a lot of persuading that this isn't a reasonable thing to want to do.
(Flagging the nasty, that is; purists who say you should never /do/ anything
you need to warn people about need not apply :-) )
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #11 from steveren --- (In reply to Manuel López-Ibáñez from comment #10) > (In reply to steveren from comment #6) > > Seems the consensus is that it's not contrary to Standard, but it's agreed > > to be confusing and undesirable by everyone except the gcc maintainers :-) > > Not sure how you reached such conclusion, but it clearly misinterprets > reality, otherwise this PR would be closed as INVALID already. Ok, my apologies. However, this bug /was/ closed as invalid before being reopened, and my own report was closed as invalid before being marked as a dupe of this one, so it's not entirely clear that there's a general feeling of a real problem that needs to be addressed. > I'm pretty sure if you submitted a patch making the behavior of all pragmas > consistent with comment #9, But I don't /want/ behaviour consistent with #9 (ie, warning that the usage is invalid), I want the usage to be valid /and/ sensible - ie, the same as other compilers. I suspect that's more difficult... Don't get me wrong - I'm not whingeing that other people should solve my problems for me without being prepared to get involved myself, but if this is WAD in the eyes of the majority, then I'll live with it sooner than create my own fork! So assuming it's not actually beyond somebody completely unfamiliar with the innards of gcc, what would be the response to a patch which changed #pragma message from 'statement' to 'not-a-statement'?
[Bug c++/61993] New: constexpr static member function "is not constant"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61993
Bug ID: 61993
Summary: constexpr static member function "is not constant"
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: q@rsn-tech.co.uk
This works:
static constexpr int idem (int x){ return x; }
struct test
{
static constexpr int a = idem (0);
};
This doesn't:
struct test
{
static constexpr int idem (int x){ return x; }
static constexpr int a = idem (0);
};
The error in the latter case is,
test.cpp:5:39: error: field initializer is not constant
static constexpr int a = idem (0);
^
I don't think this is a duplicate of any of the similar bugs posted; it seems
simpler and not dependent on any context that might not be fully available at
point of compilation.
[Bug c++/61993] constexpr static member function "is not constant"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61993 --- Comment #2 from steveren --- Ah, it is a dupe; sorry, I missed that one.
