libiberty - Segmentation fault when attempting to delete a non-existent element in a hash table
Hello people, the attached C-program can be used to reproduce a segmentation fault found in libliberty/hashtab.c I am using a libiberty tar-gzipped source version found in a recent Debian Archive File (libiberty_20160215.tar.xz) where the first entry in ChangeLog is: * 2016-01-27 Iain Buclaw This is the output of the execution of my program before patching the library: ro...@nuc.carbo.net 1221> ./bug-remove Hello world! This program creates a hash table with htab_create(). Then: * inserts 2 objects with htab_find_slot(INSERT). * delete 1 existent with htab_remove_elt(). * attempt to delete 1 non existent with htab_remove_elt(). Boom !!! Inserting [Hello - 1] ... Ok Inserting [World! - 2] ... Ok Searching for [Hello] ... Ok Searching for [World!] ... Ok Deleting [Hello] ... Ok Segmentation fault And this was the patch I applied in libiberty/libiberty: ro...@nuc.carbo.net 1222> diff hashtab.c hashtab.c.ORG 729c729 < if (!slot || *slot == HTAB_EMPTY_ENTRY) --- > if (*slot == HTAB_EMPTY_ENTRY) Maybe the same error could be also in other different points for different API functions but I did not check. /rocco bug-remove.c Description: Binary data
[Bug other/71760] New: libiberty - Segmentation fault when attempting to delete a non-existent element in a hash table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71760 Bug ID: 71760 Summary: libiberty - Segmentation fault when attempting to delete a non-existent element in a hash table Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: rocco at tecsiel dot it Target Milestone: --- Created attachment 38831 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38831&action=edit C source file to reproduce the bug Hello people, the attached C-program can be used to reproduce a segmentation fault found in libliberty/hashtab.c I am using a libiberty tar-gzipped source version found in a recent Debian Archive File (libiberty_20160215.tar.xz) where the first entry in ChangeLog is: * 2016-01-27 Iain Buclaw This is the output of the execution of my program before patching the library: ro...@nuc.carbo.net 1221> ./bug-remove Hello world! This program creates a hash table with htab_create(). Then: * inserts 2 objects with htab_find_slot(INSERT). * delete 1 existent with htab_remove_elt(). * attempt to delete 1 non existent with htab_remove_elt(). Boom !!! Inserting [Hello - 1] ... Ok Inserting [World! - 2] ... Ok Searching for [Hello] ... Ok Searching for [World!] ... Ok Deleting [Hello] ... Ok Segmentation fault And this was the patch I applied in libiberty/libiberty: ro...@nuc.carbo.net 1222> diff hashtab.c hashtab.c.ORG 729c729 < if (!slot || *slot == HTAB_EMPTY_ENTRY) --- > if (*slot == HTAB_EMPTY_ENTRY) the same error could be also in other different points for different API functions but I did not check. /rocco
[Bug target/106902] [12/13/14/15 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
Rocco Tormenta changed:
What|Removed |Added
CC||rocco at tormenta dot eu
--- Comment #31 from Rocco Tormenta ---
Hello, I have another basic example. I encountered this issue today while
trying to calculate the squared n-dimensional Euclidean distance between two
points. I apologize if this is not the same issue, though I think it is at
least related given that it broke on the same version.
https://gcc.godbolt.org/z/1cTcazh3Y
That workspace includes proof of concept code, as well as examples of known
workarounds.
The relevant function is:
float nd_sq_euclid(float *a, float *b, int n) {
float dist = 0.0;
for (int i = 0; i < n; i++) {
float d1 = a[i] - b[i];
dist += d1 * d1;
}
return dist;
}
>From the generated assembly alone, you can see that some of the code paths
(namely, for n >= 3) do not use FMA.
I included some values (a, b, c) that have different results for FMA and
non-FMA operations, so it is easier to see the difference. As you can see, by
padding the input with zeroes and increasing n, it works fine for n=1 and n=2,
but breaks starting from n=3.
[Bug target/106902] [12/13/14/15 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #33 from Rocco Tormenta --- (In reply to Andrew Pinski from comment #32) > Note this has always worked to avoid FMA formation since > __builtin_assoc_barrier was added but is only been documented recently. > See > https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index- > _005f_005fbuiltin_005fassoc_005fbarrier . Happy new year! Right, that works if you want to disable FMA and make the results consistent. Though what I was hoping to do was the same but the other way around, have both results use FMA. If anyone is looking to do that for the time being you can use __builtin_fmaf or fmaf from math.h, both seem to disable vectorization of the loop (I guess the latter is using the former), which is the real culprit here from what I've gathered.
