Last commit made on 2019-01-12
Get this branch:
git clone -b siddhesh/changelog-begone

Branch merges

Branch information


Recent commits

d3cb2e0... by Siddhesh Poyarekar <email address hidden> on 2019-01-12

Another major update

50845a0... by Siddhesh Poyarekar <email address hidden> on 2019-01-09

More fixes and also compact the tree somewhat

c716fcd... by Siddhesh Poyarekar <email address hidden> on 2019-01-09

Miscellaneous fixes. Also improve macrocall detection.

f6f5699... by Siddhesh Poyarekar <email address hidden> on 2018-12-21

Script to generate ChangeLog-like output

The utility of a ChangeLog file has been discussed in various mailing
list threads and GNU Tools Cauldrons in the past years and the general
consensus is that while the file may have been very useful in the past
when revision control did not exist or was not as powerful as it is
today, it's current utility is fast diminishing. Further, the
ChangeLog format gets in the way of modernisation of processes since
it almost always results in rewriting of a commit, thus preventing use
of any code review tools to automatically manage patches in the glibc

There is consensus in the glibc community that documentation of why a
change was done (i.e. a detailed description in a git commit) is more
useful than what changed (i.e. a ChangeLog entry) since the latter can
be deduced from the patch. The GNU community would however like to
keep the option of ascertaining what changed through a ChangeLog-like
output and as a compromise, it was proposed that a script be developed
that generates this output.

The script below is the result of these discussions. This script
takes two git revisions references as input and generates the git log
between those revisions in a form that resembles a ChangeLog. Its
capabilities and limitations are listed in a comment in the script.
On a high level it is capable of parsing C code and telling what
changed at the top level, but not within constructs such as functions.

For input other than C, the script only identifies if a file has been
added, removed, modified, permissions changed, etc. but cannot
understand the change in content. The design of the script however is
pluggable, so it should be possible to develop additional parsers to
process other types of files.

I have tested it with a number of commits in the glibc log and also
fixed a couple of errors that were reported earlier.


Once this script is in place, it should be possible for us to stop
maintaining the ChangeLog file and rely on the ChangeLog script to
give an output that serves a similar purpose. Given that the majority
of our code is in C, we have adequate coverage with just the C parser.
In any case the readability of ChangeLog entries for other formats
(makefiles for example) is just too convoluted and is perhaps not even
worth the effort.

I propose that we stop ChangeLog file maintenance once 2.30 opens for
development in February and focus on making the ChangeLog script more
accurate if we encounter bugs. I will also take another swipe at
patchwork to try and automate things in it now that the ChangeLog is

If there is agreement, then as part of 2.29 release management I will
update the wiki to reflect the change in our patch submission process
and also mention the Changelog script there for those who need it. I
believe Joseph is working with RMS to change the wording in the GNU
Coding Standards to make ChangeLog management optional.

Looking forward, once 2.30 is released in August we will be in a good
position to decide if patchwork is useful or if we want to consider
other alternative patch review processes and tools.


 * scripts/ New script.

5cbbf01... by TAMUKI Shoichi <email address hidden> on 2019-01-11

strftime: Consequently use the "L_" macro with character literals


 * time/strftime_l.c (__strftime_internal): Use "L_" macros, also add a
 missing space after the cast of "_NL_CURRENT".

0bc9bdf... by Rogerio Alves <email address hidden> on 2018-11-05

powerpc: Fix VSCR position in ucontext (bug 24088)

This patch fix VSCR position on ucontext. VSCR was read in the wrong
position on ucontext structure because it was ignoring the machine

 [BZ #24088]
 * sysdeps/unix/sysv/linux/powerpc/sys/ucontext.h (vscr_t): Added
 ifdef to fix read of VSCR.
 * sysdeps/powerpc/powerpc64/Makefile [$subdir == stdlib]: Add
 tst-ucontext-ppc64-vscr.c to test list.
 * sysdeps/powerpc/powerpc64/tst-ucontext-ppc64-vscr.c: New test file.

Reviewed-by: Tulio Magno Quites Machado Filho <email address hidden>

5494af0... by Andreas K. Hüttel on 2019-01-10

resolv: IDNA tests: AAAA (28) is valid, no fallthrough to default

e17f63f... by Jim Wilson <email address hidden> on 2019-01-07

RISC-V: Update LP64D libm-test-ulps.

With this patch applied, I get 13 glibc testsuite failures using
TIMEOUTFACTOR=4 on a HiFive Unleashed running Fedora Core 29, using top of
tree binutils and gcc. 5 of those failures are due to a kernel bug. Without
the patch, there are over a hundred failures.

This patch is incidentally similar to the powerpc-nofpu ulps update that
Joseph Myers added a few days ago.

 * sysdeps/riscv/rv64/rvd/libm-test-ulps: Update.

02f440c... by Wilco Dijkstra <email address hidden> on 2018-12-19

[AArch64] Add ifunc support for Ares

Add Ares to the midr_el0 list and support ifunc dispatch. Since Ares
supports 2 128-bit loads/stores, use Neon registers for memcpy by
selecting __memcpy_falkor by default (we should rename this to
__memcpy_simd or similar).

 * manual/tunables.texi ( Add ares tunable.
 * sysdeps/aarch64/multiarch/memcpy.c (__libc_memcpy): Use
 __memcpy_falkor for ares.
 * sysdeps/unix/sysv/linux/aarch64/cpu-features.h (IS_ARES):
 Add new define.
 * sysdeps/unix/sysv/linux/aarch64/cpu-features.c (cpu_list):
 Add ares cpu.

69da3c9... by "H.J. Lu" <email address hidden> on 2019-01-07

soft-fp: Properly check _FP_W_TYPE_SIZE [BZ #24066]

quad.h have

 #if _FP_W_TYPE_SIZE < 64

union _FP_UNION_Q
  Use 4 _FP_W_TYPEs


union _FP_UNION_Q
  Use 2 _FP_W_TYPEs





 #if _FP_W_TYPE_SIZE < 64

to check whether 4 or 2 _FP_W_TYPEs are used for IEEE quad precision.
Tested with

 [BZ #24066]
 * soft-fp/extenddftf2.c: Use "_FP_W_TYPE_SIZE < 64" to check if
 4_FP_W_TYPEs are used for IEEE quad precision.
 * soft-fp/extendhftf2.c: Likewise.
 * soft-fp/extendsftf2.c: Likewise.
 * soft-fp/extendxftf2.c: Likewise.
 * soft-fp/trunctfdf2.c: Likewise.
 * soft-fp/trunctfhf2.c: Likewise.
 * soft-fp/trunctfsf2.c: Likewise.
 * soft-fp/trunctfxf2.c: Likewise.
 * sysdeps/alpha/ots_cvttx.c: Likewise.
 * sysdeps/alpha/ots_cvtxt.c: Likewise.
 * sysdeps/ieee754/soft-fp/s_daddl.c: Likewise.
 * sysdeps/ieee754/soft-fp/s_ddivl.c: Likewise.
 * sysdeps/ieee754/soft-fp/s_dmull.c: Likewise.
 * sysdeps/ieee754/soft-fp/s_dsubl.c: Likewise.
 * sysdeps/ieee754/soft-fp/s_faddl.c: Likewise.
 * sysdeps/ieee754/soft-fp/s_fdivl.c: Likewise.
 * sysdeps/ieee754/soft-fp/s_fmull.c: Likewise.
 * sysdeps/ieee754/soft-fp/s_fsubl.c: Likewise.
 * sysdeps/sparc/sparc32/q_dtoq.c: Likewise.
 * sysdeps/sparc/sparc32/q_qtod.c: Likewise.
 * sysdeps/sparc/sparc32/q_qtos.c: Likewise.
 * sysdeps/sparc/sparc32/q_stoq.c: Likewise.
 * sysdeps/sparc/sparc64/qp_dtoq.c: Likewise.
 * sysdeps/sparc/sparc64/qp_qtod.c: Likewise.
 * sysdeps/sparc/sparc64/qp_qtos.c: Likewise.
 * sysdeps/sparc/sparc64/qp_stoq.c: Likewise.