On 3/29/20 4:30 PM, Jeffrey Walton wrote:
Would you be willing to hide a macro like CLANG_NO_DIV_BY_ZERO in a
header somewhere so it can be used in tests like test-math.h?
It'd be better to have the test fail with Clang, since Clang does have a bug
here.
There should be some way you can
On Sun, Mar 29, 2020 at 7:21 PM Jeffrey Walton wrote:
>
> On Sun, Mar 29, 2020 at 5:59 PM Bruno Haible wrote:
> >
> > Jeffrey Walton wrote:
> > > Let's see what the GCC folks recommend: "GCC and division by 0 under
> > > sanitizers",
> > >
On Sun, Mar 29, 2020 at 5:59 PM Bruno Haible wrote:
>
> Jeffrey Walton wrote:
> > Let's see what the GCC folks recommend: "GCC and division by 0 under
> > sanitizers", https://gcc.gnu.org/pipermail/gcc-help/2020-March/138746.html.
>
> The way I interpret their answer
>
Jeffrey Walton wrote:
> Let's see what the GCC folks recommend: "GCC and division by 0 under
> sanitizers", https://gcc.gnu.org/pipermail/gcc-help/2020-March/138746.html.
The way I interpret their answer
https://gcc.gnu.org/pipermail/gcc-help/2020-March/138747.html
is:
1) You need to distinguish
On Sun, Mar 29, 2020 at 12:24 PM Bruno Haible wrote:
>
> Jeffrey Walton wrote:
> > This showed up during acosf testing with UBsan:
> >
> > test-math.c:89:3: runtime error: division by zero
>
> The code performs a division 1.0 / 0.0. This is a valid operation in
> IEEE 854. It must produce a
Hi Bruno,
> Do you have time to look into this?
Sure. I'll take a look.
Regards,
Sergey
Jeffrey Walton wrote:
> This showed up during acosf testing with UBsan:
>
> test-math.c:89:3: runtime error: division by zero
The code performs a division 1.0 / 0.0. This is a valid operation in
IEEE 854. It must produce a HUGE_VAL.
Surely you can tell the sanitizer to ignore this?
Bruno
Jeffrey,
> Forgive my ignorance... No'oping 0 leaks timing information
There are only few algorithms where leaking timing information is an
issue. For most of the code we deal with, the developer wants to get
optimal performance.
> I also don't think developers are going to write a rotate like:
This showed up during acosf testing with UBsan:
test-math.c:89:3: runtime error: division by zero
On Sun, Mar 29, 2020 at 8:53 AM Bruno Haible wrote:
>
> Hi Jeffrey,
>
> > It looks like test-bitrotate.c is missing test cases. It is missing
> > the 32-bit rotl and rotr of 0-bits.
> >
> > The 0-bit rotate should tickle undefined behavior.
> >
> > If you want to clear the undefined behavior,
Hi Jeffrey,
> It looks like test-bitrotate.c is missing test cases. It is missing
> the 32-bit rotl and rotr of 0-bits.
>
> The 0-bit rotate should tickle undefined behavior.
>
> If you want to clear the undefined behavior, then use this code. ...
The functions are specified in bitrotate.h,
Hi Sergey,
Do you have time to look into this?
> > OS X 10.10 is reporting a failure in the argp test
> > (https://travis-ci.org/github/noloader/gnulib/jobs/668196414). It is
> > not present in OS X 10.14 testing. Search for 'error:' in the wall of
> > text:
> >
> > PASS: test-accept
> > PASS:
Hi Jeffrey,
> I noticed arpa_inet-c++ tested OK
There's no module named 'arpa_inet-c++':
- There's no file modules/arpa_inet-c++ ,
- './gnulib-tool --list' does not mention it.
> The script is picking up arpa_inet-c++ because it does a find looking
> for a filename -tests.
It should also
On Sun, Mar 29, 2020 at 5:00 AM Jeffrey Walton wrote:
>
> It looks like test-bitrotate.c is missing test cases. It is missing
> the 32-bit rotl and rotr of 0-bits.
>
> The 0-bit rotate should tickle undefined behavior.
>
> If you want to clear the undefined behavior, then use this code. It is
>
Hi Everyone,
It looks like test-bitrotate.c is missing test cases. It is missing
the 32-bit rotl and rotr of 0-bits.
The 0-bit rotate should tickle undefined behavior.
If you want to clear the undefined behavior, then use this code. It is
recognized by Clang, GCC, ICC. It will be compiled down
15 matches
Mail list logo
