INTVAL type
I was reviewing some back end code that handles integer values of various sizes, and got confused reading about CONST_INT and CONST_DOUBLE. It's pretty clear that CONST_DOUBLE is used for values bigger than HOST_WIDE_INT. But the description of INTVAL is contradictory. In some places, it states that its type is HOST_WIDE_INT; in others it says that it it "int". For example, in section 17.6 of the internals manual: Be careful when doing this, because the result of INTVAL is an integer on the host machine. If the host machine has more bits in an int than the target machine has in the mode in which the constant will be used, then some of the bits you get from INTVAL will be superfluous. A related problem is that it isn't clearly stated what the properties of HOST_WIDE_INT are. Judging by hwint.h, it is always specifically a 64 bit integer. If that is intended to be the case, it would be good for that to be documented. Alternatively, if the intent is that it is at least 64 bits but might be bigger, that should be stated. As it stands, I have some code I need to repair because it picks apart integer constants from INTVAL in a way that's incorrect if a 64-bit value is passed. paul
Re: INTVAL type
On Sun, Oct 28, 2018 at 01:39:16PM -0400, Paul Koning wrote: > I was reviewing some back end code that handles integer values of various > sizes, and got confused reading about CONST_INT and CONST_DOUBLE. > > It's pretty clear that CONST_DOUBLE is used for values bigger than > HOST_WIDE_INT. But the description of INTVAL is contradictory. In some > places, it states that its type is HOST_WIDE_INT; in others it says that it > it "int". For example, in section 17.6 of the internals manual: > > Be careful when doing this, because the result of INTVAL is an integer on the > host machine. If the host machine has more bits in an int than the target > machine has in the mode in which the constant will be used, then some of the > bits you get from INTVAL will be superfluous. It is a HOST_WIDE_INT. The section (please mention the title btw., the section numbers change over time: this is "C Statements for Assembler Output") isn't very clear, and it was written when HOST_WIDE_INT could still be 32 bit (nowadays it is always 64 bits). > A related problem is that it isn't clearly stated what the properties of > HOST_WIDE_INT are. Judging by hwint.h, it is always specifically a 64 bit > integer. If that is intended to be the case, it would be good for that to be > documented. Alternatively, if the intent is that it is at least 64 bits but > might be bigger, that should be stated. As it stands, I have some code I > need to repair because it picks apart integer constants from INTVAL in a way > that's incorrect if a 64-bit value is passed. It is always exactly 64 bits. HOST_WIDE_INT values are always sign-extended to the type it is meant as (so 0x80 is expressed as 0xff80 for a QImode value, i.e. -0x80, but it is just 0x80 for a larger mode value). Segher
gcc-9-20181028 is now available
Snapshot gcc-9-20181028 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/9-20181028/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 265575 You'll find: gcc-9-20181028.tar.xzComplete GCC SHA256=ecca0418f3336488f8fbdc8a81aa72c8c5f7773ecd24581be570035caab566a5 SHA1=3f072e409582de6a9d862baceb86703589aa1cf9 Diffs from 9-20181021 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Tests Failing On x86_64
Greetings all, I am getting failing tests when running with: make bootstrap make -k check The only code I am running is the below patch: >From 8c26b03c27912a367af52fd1e48eafb9b934fdf5 Mon Sep 17 00:00:00 2001 From: Nicholas Krause Date: Sun, 28 Oct 2018 22:23:35 -0400 Subject: [PATCH] Fix bug 86293 This fixes the bug on the gcc bugzilla with id, 86293. Basically a variable is undefined in certain build configuration scentarios and therefore must be enabled with the attribute marco and the flag, unused for it to avoid this build error. Signed-off-by: Nicholas Krause --- libitm/method-serial.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libitm/method-serial.cc b/libitm/method-serial.cc index e4804946a34..ab23d0b5660 100644 --- a/libitm/method-serial.cc +++ b/libitm/method-serial.cc @@ -306,7 +306,7 @@ GTM::gtm_thread::serialirr_mode () // We're already serial, so we don't need to ensure privatization safety // for other transactions here. gtm_word priv_time = 0; - bool ok = disp->trycommit (priv_time); + bool ok __attribute__((unused)) = disp->trycommit (priv_time); // Given that we're already serial, the trycommit better work. assert (ok); } -- 2.17.1 It seems to be failing in Running /home/nick/obdjir/../gcc/libatomic/testsuite/libatomic.c/c.exp ... as this is the last thing I see but it could be a mistake in my code or something else. It does build gcc find through so it seems to be tests failing that are not expected. Thoughts? Cheers, Nick
