<feed xmlns='http://www.w3.org/2005/Atom'>
<title>glibc/sysdeps/microblaze, branch master</title>
<subtitle>Fork of glibc for development</subtitle>
<id>https://git.zx2c4.com/glibc/atom/sysdeps/microblaze?h=master</id>
<link rel='self' href='https://git.zx2c4.com/glibc/atom/sysdeps/microblaze?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/'/>
<updated>2024-06-17T13:47:09Z</updated>
<entry>
<title>Implement C23 logp1</title>
<updated>2024-06-17T13:47:09Z</updated>
<author>
<name>Joseph Myers</name>
<email>josmyers@redhat.com</email>
</author>
<published>2024-06-17T13:47:09Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=bb014f50c4a0c8d8db1ba5af55c104e430b5533d'/>
<id>urn:sha1:bb014f50c4a0c8d8db1ba5af55c104e430b5533d</id>
<content type='text'>
C23 adds various &lt;math.h&gt; function families originally defined in TS
18661-4.  Add the logp1 functions (aliases for log1p functions - the
name is intended to be more consistent with the new log2p1 and
log10p1, where clearly it would have been very confusing to name those
functions log21p and log101p).  As aliases rather than new functions,
the content of this patch is somewhat different from those actually
adding new functions.

Tests are shared with log1p, so this patch *does* mechanically update
all affected libm-test-ulps files to expect the same errors for both
functions.

The vector versions of log1p on aarch64 and x86_64 are *not* updated
to have logp1 aliases (and thus there are no corresponding header,
tests, abilist or ulps changes for vector functions either).  It would
be reasonable for such vector aliases and corresponding changes to
other files to be made separately.  For now, the log1p tests instead
avoid testing logp1 in the vector case (a Makefile change is needed to
avoid problems with grep, used in generating the .c files for vector
function tests, matching more than one ALL_RM_TEST line in a file
testing multiple functions with the same inputs, when it assumes that
the .inc file only has a single such line).

Tested for x86_64 and x86, and with build-many-glibcs.py.
</content>
</entry>
<entry>
<title>login: structs utmp, utmpx, lastlog _TIME_BITS independence (bug 30701)</title>
<updated>2024-04-19T12:38:17Z</updated>
<author>
<name>Florian Weimer</name>
<email>fweimer@redhat.com</email>
</author>
<published>2024-04-19T12:38:17Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=9abdae94c7454c45e02e97e4ed1eb1b1915d13d8'/>
<id>urn:sha1:9abdae94c7454c45e02e97e4ed1eb1b1915d13d8</id>
<content type='text'>
These structs describe file formats under /var/log, and should not
depend on the definition of _TIME_BITS.  This is achieved by
defining __WORDSIZE_TIME64_COMPAT32 to 1 on 32-bit ports that
support 32-bit time_t values (where __time_t is 32 bits).

Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
</entry>
<entry>
<title>login: Check default sizes of structs utmp, utmpx, lastlog</title>
<updated>2024-04-19T12:38:17Z</updated>
<author>
<name>Florian Weimer</name>
<email>fweimer@redhat.com</email>
</author>
<published>2024-04-19T12:38:17Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=4d4da5aab936504b2d3eca3146e109630d9093c4'/>
<id>urn:sha1:4d4da5aab936504b2d3eca3146e109630d9093c4</id>
<content type='text'>
The default &lt;utmp-size.h&gt; is for ports with a 64-bit time_t.
Ports with a 32-bit time_t or with __WORDSIZE_TIME64_COMPAT32=1
need to override it.

Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
</entry>
<entry>
<title>Refer to C23 in place of C2X in glibc</title>
<updated>2024-02-01T11:02:01Z</updated>
<author>
<name>Joseph Myers</name>
<email>josmyers@redhat.com</email>
</author>
<published>2024-02-01T11:02:01Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=42cc619dfbc44e263239c2de870bae11ad65810a'/>
<id>urn:sha1:42cc619dfbc44e263239c2de870bae11ad65810a</id>
<content type='text'>
WG14 decided to use the name C23 as the informal name of the next
revision of the C standard (notwithstanding the publication date in
2024).  Update references to C2X in glibc to use the C23 name.

This is intended to update everything *except* where it involves
renaming files (the changes involving renaming tests are intended to
be done separately).  In the case of the _ISOC2X_SOURCE feature test
macro - the only user-visible interface involved - support for that
macro is kept for backwards compatibility, while adding
_ISOC23_SOURCE.

Tested for x86_64.
</content>
</entry>
<entry>
<title>Update copyright dates with scripts/update-copyrights</title>
<updated>2024-01-01T18:53:40Z</updated>
<author>
<name>Paul Eggert</name>
<email>eggert@cs.ucla.edu</email>
</author>
<published>2024-01-01T18:12:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=dff8da6b3e89b986bb7f6b1ec18cf65d5972e307'/>
<id>urn:sha1:dff8da6b3e89b986bb7f6b1ec18cf65d5972e307</id>
<content type='text'>
</content>
</entry>
<entry>
<title>configure: Use autoconf 2.71</title>
<updated>2023-07-17T14:08:10Z</updated>
<author>
<name>Siddhesh Poyarekar</name>
<email>siddhesh@sourceware.org</email>
</author>
<published>2023-06-29T18:34:16Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=c6cb8783b5fb5896cb63fe9008b6a33351f3c777'/>
<id>urn:sha1:c6cb8783b5fb5896cb63fe9008b6a33351f3c777</id>
<content type='text'>
Bump autoconf requirement to 2.71 to allow regenerating configure on
more recent distributions.  autoconf 2.71 has been in Fedora since F36
and is the current version in Debian stable (bookworm).  It appears to
be current in Gentoo as well.

All sysdeps configure and preconfigure scripts have also been
regenerated; all changes are trivial transformations that do not affect
functionality.

Signed-off-by: Siddhesh Poyarekar &lt;siddhesh@sourceware.org&gt;
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
<entry>
<title>Update copyright dates with scripts/update-copyrights</title>
<updated>2023-01-06T21:14:39Z</updated>
<author>
<name>Joseph Myers</name>
<email>joseph@codesourcery.com</email>
</author>
<published>2023-01-06T21:08:04Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=6d7e8eda9b85b08f207a6dc6f187e94e4817270f'/>
<id>urn:sha1:6d7e8eda9b85b08f207a6dc6f187e94e4817270f</id>
<content type='text'>
</content>
</entry>
<entry>
<title>elf: Introduce &lt;dl-call_tls_init_tp.h&gt; and call_tls_init_tp (bug 29249)</title>
<updated>2022-11-03T16:28:03Z</updated>
<author>
<name>Florian Weimer</name>
<email>fweimer@redhat.com</email>
</author>
<published>2022-11-03T16:28:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=1f34a2328890aa192141f96449d25b77f666bf47'/>
<id>urn:sha1:1f34a2328890aa192141f96449d25b77f666bf47</id>
<content type='text'>
This makes it more likely that the compiler can compute the strlen
argument in _startup_fatal at compile time, which is required to
avoid a dependency on strlen this early during process startup.

Reviewed-by: Szabolcs Nagy &lt;szabolcs.nagy@arm.com&gt;
</content>
</entry>
<entry>
<title>Use PTR_MANGLE and PTR_DEMANGLE unconditionally in C sources</title>
<updated>2022-10-18T15:04:10Z</updated>
<author>
<name>Florian Weimer</name>
<email>fweimer@redhat.com</email>
</author>
<published>2022-10-18T15:00:07Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=58548b9d689fb9bba67bdc5b59c8d2fa47f4f8ec'/>
<id>urn:sha1:58548b9d689fb9bba67bdc5b59c8d2fa47f4f8ec</id>
<content type='text'>
In the future, this will result in a compilation failure if the
macros are unexpectedly undefined (due to header inclusion ordering
or header inclusion missing altogether).

Assembler sources are more difficult to convert.  In many cases,
they are hand-optimized for the mangling and no-mangling variants,
which is why they are not converted.

sysdeps/s390/s390-32/__longjmp.c and sysdeps/s390/s390-64/__longjmp.c
are special: These are C sources, but most of the implementation is
in assembler, so the PTR_DEMANGLE macro has to be undefined in some
cases, to match the assembler style.

Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
</entry>
<entry>
<title>Introduce &lt;pointer_guard.h&gt;, extracted from &lt;sysdep.h&gt;</title>
<updated>2022-10-18T15:03:55Z</updated>
<author>
<name>Florian Weimer</name>
<email>fweimer@redhat.com</email>
</author>
<published>2022-10-18T15:00:07Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=88f4b6929c26f9240a4b0b7dcc62922f02544a09'/>
<id>urn:sha1:88f4b6929c26f9240a4b0b7dcc62922f02544a09</id>
<content type='text'>
This allows us to define a generic no-op version of PTR_MANGLE and
PTR_DEMANGLE.  In the future, we can use PTR_MANGLE and PTR_DEMANGLE
unconditionally in C sources, avoiding an unintended loss of hardening
due to missing include files or unlucky header inclusion ordering.

In i386 and x86_64, we can avoid a &lt;tls.h&gt; dependency in the C
code by using the computed constant from &lt;tcb-offsets.h&gt;.  &lt;sysdep.h&gt;
no longer includes these definitions, so there is no cyclic dependency
anymore when computing the &lt;tcb-offsets.h&gt; constants.

Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
</entry>
</feed>
