gcc-12-20250320 is now available
Snapshot gcc-12-20250320 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20250320/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 2f7620748f0f8da4cd4017d4507063f7065f2f25 You'll find: gcc-12-20250320.tar.xz Complete GCC SHA256=5f708b1553094cd600e40b6648f48f519c95feedb89e118e696af58a945fb947 SHA1=7c57cbdfa77b10bd84d4e46ecaf57d1513d10817 Diffs from 12-20250313 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 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.
Re: Pointer semantics in GIMPLE
On Thu, Mar 20, 2025 at 2:05 AM Krister Walfridsson via Gcc
wrote:
>
> I'm working on ensuring that the GIMPLE semantics used by smtgcc are
> correct, and I have a lot of questions about the details. I'll be sending
> a series of emails with these questions. This first one is about pointers
> in general.
>
> Each section starts with a description of the semantics I've implemented
> (or plan to implement), followed by concrete questions if relevant. Let me
> know if the described semantics are incorrect or incomplete.
>
>
> Pointers values
> ---
> C imposes restrictions on pointer values (alignment, must point to valid
> memory, etc.), but GIMPLE seems more permissive. For example, when
> vectorizing a loop:
>
>void foo(int *p, int n)
>{
> for (int i = 0; i < n; i++)
>p[i] = 1;
>}
>
> the vectorized loop updates the pointer vectp_p.8 for the next iteration
> at the end of the loop, causing it to point up to a vector-length out of
> range after the last iteration:
>
> :
># vectp_p.8_34 = PHI
># ivtmp_37 = PHI
>MEM [(int *)vectp_p.8_34] = { 1, 1, 1, 1 };
>vectp_p.8_35 = vectp_p.8_34 + 16;
yeah, this should be semantically in the latch block (bb6) but causes
worse code generation if placed there
>ivtmp_38 = ivtmp_37 + 1;
>if (ivtmp_38 < bnd.5_31)
> goto ;
>else
> goto ;
>
> :
>goto ;
>
> Because of this, I allow all values -- essentially treating pointers as
> unsigned integers. Things like ensuring pointers point to valid memory or
> have correct alignment are only checked when dereferencing the pointer
> (I'll discuss pointer dereferencing semantics in the next email).
That's a reasonable thing.
>
> Pointer arithmetic -- POINTER_PLUS_EXPR
> ---
> POINTER_PLUS_EXPR calculates p + x:
> * It is UB if the calculation overflows when
> TYPE_OVERFLOW_WRAPS(ptr_type) is false.
> * It is UB if p + x == 0, unless p == 0 and x == 0, unless
> flag_delete_null_pointer_checks is false.
>
> Since the pointer type is unsigned, it's not entirely clear what overflow
> means. For example, p - 1 is represented as p + 0x, which
> overflows when treated as an unsigned addition. I check for overflow in
> p + x as follows:
>is_overflow = ((intptr_t)x < 0) ? (p + x) > p : (p + x) < p;
That looks correct. For historical reasons the offset operand is an unsigned
sizetype but when interpreting the offset you have to interpret it as signed.
>
> Pointer arithmetic -- MEM_REF and TARGET_MEM_REF
>
> A calculation p + x can also be done using MEM_REF as &MEM[p + x].
>
> Question: smtgcc does not check for overflow in address calculations for
> MEM_REF and TARGET_MEM_REF. Should it treat overflow as UB in the same way
> as POINTER_PLUS_EXPR?
I think so.
>
> Pointer arithmetic -- COMPONENT_REF
> ---
> COMPONENT_REF adds the offset of a structure element to the pointer to the
> structure.
>
> Question: smtgcc does not check for overflow in address calculation for
> COMPONENT_REF. Should it treat overflow as UB in the same way as
> POINTER_PLUS_EXPR?
Yes.
>
> Pointer arithmetic -- ARRAY_REF
> ---
> ARRAY_REF adds the offset of the indexed element to the pointer to the
> array.
>
> * It is UB if the index is negative.
> * If the TYPE_DOMAIN for the array type has a TYPE_MAX_VALUE and the
> array is not a flexible array, it is UB if the index exceeds "one
> after" this maximum value.
> * If it is a flexible array or does not have a maximum value, it is
> considered an unsized array, so all non-negative indices are valid.
> But it is UB if the calculation of
>offset = index * element_size
> overflows.
Looks good.
>
> Question: smtgcc does not check for overflow in the calculation of p +
> offset. Should it treat overflow as UB in the same way as
> POINTER_PLUS_EXPR?
I think for the index part of the ARRAY_REF we can be stricter and not
only validate this at pointer dereference.
>
> Question: What is the correct way to check for flexible arrays? I am
> currently using array_ref_flexible_size_p and flag_strict_flex_arrays, but
> I noticed that middle-end passes do not seem to use
> flag_strict_flex_arrays. Is there a more canonical way to determine how to
> interpret flexible arrays?
array_ref_flexible_size_p is the correct middle-end thing. I think
-fstrict-flex-arrays is only used for diagnostic purposes at the moment.
>
>
> Pointer arithmetic -- POINTER_DIFF_EXPR
> ---
> Subtracting a pointer q from a pointer p is done using POINTER_DIFF_EXPR.
> * It is UB if the difference does not fit in a signed integer with the
> same precision as the pointers.
Yep.
> This implies that an object's size must be less than half the address
> space; otherwise, POINTER_DIFF_EXPR cannot be used to compute si
Announce: GNU MPFR 4.2.2 is released
GNU MPFR 4.2.2 ("fondue savoyarde", patch level 2), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:
https://www.mpfr.org/mpfr-4.2.2/
and from the GNU FTP site:
https://ftp.gnu.org/gnu/mpfr/
Thanks very much to those who sent us bug reports and/or tested the
release candidate.
The SHA1 digests:
7e21e5bcfa67db572e5f2f38029fc731a19aecce mpfr-4.2.2.tar.bz2
03aa176cf35d1477e2b6725cde74a728b4ef1a9a mpfr-4.2.2.tar.gz
a63a264b273a652e27518443640e69567da498ce mpfr-4.2.2.tar.xz
2291ef02a41a8cbf27382a77a4ac7ec672f72d57 mpfr-4.2.2.zip
The SHA256 digests:
9ad62c7dc910303cd384ff8f1f4767a655124980bb6d8650fe62c815a231bb7b
mpfr-4.2.2.tar.bz2
826cbb24610bd193f36fde172233fb8c009f3f5c2ad99f644d0dea2e16a20e42
mpfr-4.2.2.tar.gz
b67ba0383ef7e8a8563734e2e889ef5ec3c3b898a01d00fa0a6869ad81c6ce01
mpfr-4.2.2.tar.xz
8c47f73c17df30bfc975079ebe4ea3cbb11e0a70d70b48768eec41e760f508af mpfr-4.2.2.zip
The signatures:
https://www.mpfr.org/mpfr-4.2.2/mpfr-4.2.2.tar.xz.asc
https://www.mpfr.org/mpfr-4.2.2/mpfr-4.2.2.tar.bz2.asc
https://www.mpfr.org/mpfr-4.2.2/mpfr-4.2.2.tar.gz.asc
https://www.mpfr.org/mpfr-4.2.2/mpfr-4.2.2.zip.asc
Each tarball is signed by Vincent Lefèvre. This can be verified using
the GPG key ID 5831D11A0D4DB02A; this key can be retrieved with:
gpg --recv-keys 5831D11A0D4DB02A
or by downloading it from .
The key fingerprint is:
A534 BE3F 83E2 41D9 1828 0AEB 5831 D11A 0D4D B02A
The signatures can be verified with: gpg --verify
You should check that the key fingerprint matches.
Changes from version 4.2.1 to version 4.2.2:
- In order to resolve a portability issue with the _Float128 fallback to
__float128 for binary128 support (e.g. with Clang and glibc 2.41), the
prototypes of the corresponding conversion functions had to be changed,
with _Float128 replaced by mpfr_float128, where mpfr_float128 is a macro
defined as _Float128 by default. This changes neither the ABI nor the API
(except that the end user of MPFR would need to define mpfr_float128 as
the actual type for the binary128 format if this is not the standard
_Float128 type).
- Other bug fixes (see and/or the
ChangeLog file). In particular, the formatted output functions behaved
incorrectly with %c on the value 0; such a use is uncommon, but this bug
may have security implications.
- Improved MPFR manual.
- Detect the use of GMP's buggy vsnprintf replacement at configure time.
With it, the tests of "%a" will be disabled to avoid an assertion failure
in the MPFR testsuite. A warning will be displayed in the configure output
in such a case.
Also, note that due to new tests related to the fix of the formatted
output functions with %c on the value 0, failures in the tfprintf and
tsprintf tests may be observed if GMP has been built with its vsnprintf
replacement (i.e. if GMP detected at configure time that the vsnprintf
function from the C library is buggy/non-conforming). This is due to a
bug in the vsnprintf replacement from GMP 6.3.0 (official tarball) and
below. This could be observed on MS Windows and OpenBSD. To get rid of
these failures, either use a fixed version (recommended!) or build the
MPFR tests with the MPFR_TESTS_SKIP_CHECK_NULL macro defined.
See the INSTALL file for other details.
You can send success and failure reports to (please
remove the other mailing-list addresses if they appear in the reply
to this message), and give us the canonical system name (by running
the "./config.guess" script), the processor and the compiler version,
in order to complete the "Platforms Known to Support MPFR" section of
the MPFR 4.2.2 web page.
Regards,
--
Vincent Lefèvre - Web:
FSF Live Memorabilia Auction - item of interest for Gcc members
Hi there, Our first-ever [Live Memorabilia Auction][1] features many enticing pieces of free software history. We think that members of the Gcc mailing list might be especially interested in the original [GCC GNU letter drawings by Etienne Suvasa][2]. [1]: https://www.fsf.org/news/fsf-40-auction [2]: https://static.fsf.org/nosvn/fsf40/auction/FSF-live-auction-booklet.pdf To participate in the [Live Memorabilia Auction][1], you must [register][3] and agree to the [terms and conditions][4]. [1]: https://www.fsf.org/news/fsf-40-auction [3]: https://my.fsf.org/civicrm/event/info?reset=1&id=132 [4]: https://www.fsf.org/blogs/community/terms-and-conditions-live-auction-2025 There's just a few days before the [live auction][1] begins on March 23, 2025 on Galène at 14:00 EDT (18:00 UTC). [Register][3] now so that you'll be ready to bid on the pair of [GCC GNU letter drawings][2] this Sunday. [1]: https://www.fsf.org/news/fsf-40-auction [3]: https://my.fsf.org/civicrm/event/info?reset=1&id=132 [2]: https://static.fsf.org/nosvn/fsf40/auction/FSF-live-auction-booklet.pdf Wishing you lots of luck and hope to see you on Sunday! The Free Software Foundation team OpenPGP_0x5E85814E300A1177.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
