[Bug c/93112] New: Incorrect rounding for float to uint64 on x86 (32bit) with -fexcess-precision=standard

[stefan.bru...@rwth-aachen.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93112

Bug ID: 93112
   Summary: Incorrect rounding for float to uint64 on x86 (32bit)
with -fexcess-precision=standard
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefan.bru...@rwth-aachen.de
  Target Milestone: ---

The following program yields 1034567 for all 4 cases on x86_64, arm64, armv7,
... and x86 with -fexcess-precision=fast, but yields 1034566 for the 1st case
on x86 with -fexcess-precision=standard:

---
#include 
#include 
#include 

#define MHZ(x) ((x) * UINT64_C(100))

uint64_t t1(uint64_t x)
{
printf("r: %" PRIu64 "\n", x);
}

void t2(float x)
{
printf("r: %f\n", x);
}

int main(int argc, char** argv)
{
if (argc < 2) {
t1(MHZ(1.034567)); // 1034567 or 1034566
t1(1034567.0); // always 1034567
t2(MHZ(1.034567)); // always 1034567.0
t2(1034567.0); // always 1034567.0
}
return 0;
}
---

1'034'567 can be represented exactly as float value. 1.034567 can't be
represented exactly, but rounding towards nearest should yield the correct
result (the error is about 2^-20, float precision is about 2^-23).

The error only happens if the multiplication result is cast to int.

Error happens with both GCC 9.2.1 and 7.5.0
- gcc-7 (SUSE Linux) 7.5.0
- gcc-9 (SUSE Linux) 9.2.1 20191209 [gcc-9-branch revision 279114]

[Bug preprocessor/93109] #undefine suggests #define but not #undef

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93109

--- Comment #2 from Andrew Pinski  ---
(In reply to Eric Gallager from comment #1)
> I understand why it happens though; to get from #undefine to #define only
> requires 2 letters to be removed, but to get from #undefine to #undef, 3
> letters have to be removed.

I think weight should given to prefix rather than suffix differences.
That is if the difference between two words should be weighted differently
based on if it removing letters at the begining or the end.  the end should be
cheaper than removing letters at the begining.  Subsitution should be similar
to weighting as removing at the end.

[Bug tree-optimization/93098] [10 Regression] ICE with negative shifter

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93098

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan  1 00:20:39 2020
New Revision: 279809

URL: https://gcc.gnu.org/viewcvs?rev=279809&root=gcc&view=rev
Log:
PR tree-optimization/93098
* match.pd (popcount): For shift amounts, use integer_onep
or wi::to_widest () == cst instead of tree_to_uhwi () == cst
tests.  Make sure that precision is power of two larger than or equal
to 16.  Ensure shift is never negative.  Use HOST_WIDE_INT_UC macro
instead of ULL suffixed constants.  Formatting fixes.

* gcc.c-torture/compile/pr93098.c: New test.

Added:
trunk/gcc/ChangeLog-2019
  - copied unchanged from r279808, trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog-2019
  - copied unchanged from r279808, trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/compile/pr93098.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541

--- Comment #17 from Jonathan Wakely  ---
Done:

https://gitlab.com/esr/gcc-conversion/merge_requests/47

[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541

--- Comment #16 from Jonathan Wakely  ---
It had nothing to do with Git. It's just a python script that says commit
r279763 is related to PR x not PR y.

[Bug target/93111] New: FAIL: gfortran.fortran-torture/compile/pr32663.f, -O3 -g (internal compiler error)

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93111

Bug ID: 93111
   Summary: FAIL: gfortran.fortran-torture/compile/pr32663.f,  -O3
-g   (internal compiler error)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-*
Target: hppa*-*-*
 Build: hppa*-*-*

spawn -ignore SIGHUP
/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran1/../../gfo
rtran -B/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran1/../../
-B/home/dave/gn
u/gcc/objdir/hppa-linux-gnu/./libgfortran/ -fno-diagnostics-show-caret
-fno-diag
nostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -w
-O3 -g -c -o /home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran1/pr32663.o
/home/d
ave/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-torture/compile/pr32663.f
during RTL pass: final
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-torture/compile/pr32663.f:
147:0: internal compiler error: in pa_print_operand, at config/pa/pa.c:5316
0xaee103 pa_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc/gcc/config/pa/pa.c:5316
0x7d9537 default_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc/gcc/targhooks.c:345
0x47e313 output_operand(rtx_def*, int)
../../gcc/gcc/final.c:4051
0x47f123 output_asm_insn(char const*, rtx_def**)
../../gcc/gcc/final.c:3944
0x48380b final_scan_insn_1
../../gcc/gcc/final.c:3106
0x483d9b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/gcc/final.c:3152
0x4840ab final_1
../../gcc/gcc/final.c:2020
0x484b53 rest_of_handle_final
../../gcc/gcc/final.c:4658
0x484b53 execute
../../gcc/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gfortran.fortran-torture/compile/pr32663.f,  -O3 -g   (internal compiler
e
rror)

Code is 66 'B', comparison is LTGT.

Rev. 277745 was okay.

[Bug preprocessor/93109] #undefine suggests #define but not #undef

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93109

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
I understand why it happens though; to get from #undefine to #define only
requires 2 letters to be removed, but to get from #undefine to #undef, 3
letters have to be removed.

[Bug tree-optimization/93110] New: grub-2.04/grub-core/lib/division.c:28:1: internal compiler error: in extract_insn, at recog.c:2294

[raj.khem at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93110

Bug ID: 93110
   Summary: grub-2.04/grub-core/lib/division.c:28:1: internal
compiler error: in extract_insn, at recog.c:2294
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raj.khem at gmail dot com
  Target Milestone: ---

Created attachment 47576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47576&action=edit
testcase

following source from grub crashed gcc master

x86_64-yoe-linux-gcc -mtune=core2 -march=i386 -m32 a.c

../../grub-2.04/grub-core/lib/division.c: In function 'abs64':
../../grub-2.04/grub-core/lib/division.c:28:1: error: unrecognizable insn:
   28 | }
  | ^
(insn 11 10 12 2 (parallel [
(set (reg:DI 83 [ _1 ])
(xor:DI (reg:DI 89)
(reg:DI 88)))
(clobber (reg:CC 17 flags))
]) "../../grub-2.04/grub-core/lib/division.c":27:20 -1
 (nil))
during RTL pass: vregs
../../grub-2.04/grub-core/lib/division.c:28:1: internal compiler error: in
extract_insn, at recog.c:2294

here is my gcc build details

x86_64-yoe-linux-gcc -v
Using built-in specs.
COLLECT_GCC=../../recipe-sysroot-native/usr/bin/x86_64-yoe-linux/x86_64-yoe-linux-gcc
COLLECT_LTO_WRAPPER=/mnt/b/yoe/build/tmp/work/core2-64-yoe-linux/grub/2.04-r0/recipe-sysroot-native/usr/bin/x86_64-yoe-linux/../../libexec/x86_64-yoe-linux/gcc/x86_64-yoe-linux/10.0.0/lto-wrapper
Target: x86_64-yoe-linux
Configured with:
../../../../../../work-shared/gcc-10.0.0-r0/official-gcc-47c4fc0/configure
--build=x86_64-linux --host=x86_64-linux --target=x86_64-yoe-linux
--prefix=/host-native/usr --exec_prefix=/host-native/usr
--bindir=/host-native/usr/bin/x86_64-yoe-linux
--sbindir=/host-native/usr/bin/x86_64-yoe-linux
--libexecdir=/host-native/usr/libexec/x86_64-yoe-linux
--datadir=/host-native/usr/share --sysconfdir=/host-native/etc
--sharedstatedir=/host-native/com --localstatedir=/host-native/var
--libdir=/host-native/usr/lib/x86_64-yoe-linux
--includedir=/host-native/usr/include --oldincludedir=/host-native/usr/include
--infodir=/host-native/usr/share/info --mandir=/host-native/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/host-native --enable-clocale=generic --with-gnu-ld
--enable-shared --enable-languages=c,c++ --enable-threads=posix
--disable-multilib --enable-default-pie --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=x86_64-yoe-linux-
--without-local-prefix --with-specs='%{!fno-common:%{!fcommon:-fcommon}}'
--enable-lto --disable-libssp --enable-libitm --disable-bootstrap
--disable-libmudflap --with-system-zlib --with-linker-hash-style=sysv
--enable-linker-build-id --with-ppl=no --with-cloog=no
--enable-checking=release --enable-cheaders=c_global --without-isl
--with-gxx-include-dir=/not/exist/usr/include/c++/10.0.0
--with-sysroot=/not/exist --with-build-sysroot=/host
--enable-poison-system-directories --with-system-zlib --disable-static
--disable-nls --with-glibc-version=2.28 --enable-initfini-array
--enable-__cxa_atexit
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191231 (experimental) (GCC)

[Bug demangler/93035] Found 91 mangled names which do not demangle using c++filt

[simonhf at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93035

--- Comment #1 from Simon Hardy-Francis  ---
Also, for names which do demangle then there are wide spread differences [1] if
the same name is demangled using llvm-cxxfilt. I tried out demangling over 100k
mangled names with both tools here [1].

[1] https://gist.github.com/simonhf/0d60bb94f2d90c1b32e4786b2d1062ad

[Bug c/92292] duplicate -Wformat warnings about incorrect printf format specifiers

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292

--- Comment #5 from joseph at codesourcery dot com  ---
On Tue, 31 Dec 2019, ssbssa at yahoo dot de wrote:

> Is there also a scenario where it would make sense to have multiple format
> attributes for the same format string?

That seems less likely to be useful in practice, but I can't rule it out 
completely.

[Bug c++/93093] __builtin_source_location reports values for default arguments not aligned with the Standard

[phdofthehouse at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093

--- Comment #3 from JeanHeyd Meneide  ---
I guess we just throw out a handful of those test cases, then. It's not like
the Standard is really impactful here, since most of Source Location's
specification is "should...", which is encouragement and not requirement.

Maybe this can be revisited later.

[Bug ipa/93087] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93087

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-31
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 47575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47575&action=edit
gcc10-pr93087.patch

Untested fix.

[Bug c++/93093] __builtin_source_location reports values for default arguments not aligned with the Standard

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093

--- Comment #2 from Jakub Jelinek  ---
What this boils down to is e.g. whether
consteval int foo (int i) { if (i) throw 1; return 0; }
void bar (int x = foo (0));
void baz (int x = foo (1));
void qux () { bar (0); bar (); baz (0); }
needs to be rejected (it is rejected by g++) or not, if it is invalid, no
diagnostics required, or if it would be invalid only if there would be a baz
(); call somewhere.
If the above testcase is invalid, and default arguments to non-immediate
functions need to be evaluated if they contain calls to immediate functions,
then I don't see how your #c0 testcase can expect what it expects, because
source_location::current() will be evaluated not when you expect it to and by
the time something else invokes the constructor or function, the default
argument will already have a constant value.

[Bug c/92292] duplicate -Wformat warnings about incorrect printf format specifiers

[ssbssa at yahoo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292

--- Comment #4 from Domani Hannes  ---
(In reply to jos...@codesourcery.com from comment #3)
> On Tue, 31 Dec 2019, ssbssa at yahoo dot de wrote:
> 
> > But does it make sense to do a format check multiple times for one function?
> 
> Yes.  You could have a function with one format string for the message 
> printed to the terminal and another for the message printed (with the same 
> arguments) to a logfile, for example.  Or multiple format strings from 
> which the function chooses one to use based on some condition.

Interesting, I would never have thought of this possibility.

Is there also a scenario where it would make sense to have multiple format
attributes for the same format string?

[Bug c/92292] duplicate -Wformat warnings about incorrect printf format specifiers

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292

--- Comment #3 from joseph at codesourcery dot com  ---
On Tue, 31 Dec 2019, ssbssa at yahoo dot de wrote:

> But does it make sense to do a format check multiple times for one function?

Yes.  You could have a function with one format string for the message 
printed to the terminal and another for the message printed (with the same 
arguments) to a logfile, for example.  Or multiple format strings from 
which the function chooses one to use based on some condition.

[Bug c++/93093] __builtin_source_location reports values for default arguments not aligned with the Standard

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think this boils down when should calls to immediate functions be evaluated
in default arguments.
What GCC implements right now is that calls to consteval functions in default
arguments are deferred until later if the default argument is for an immediate
function (and is then evaluated later when call to such consteval function is
seen outside of immediate context), but otherwise is evaluated immediately
while parsing the default argument.
In the testcase, as s::s(source_location) or void f(source_location) aren't
immediate, the constexpr evaluation is performed on the default argument right
away.
Now, if that is not how it should be treated, please point me at where the C++
standard says so.

[Bug c/92292] duplicate -Wformat warnings about incorrect printf format specifiers

[ssbssa at yahoo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292

Domani Hannes  changed:

   What|Removed |Added

 CC||ssbssa at yahoo dot de

--- Comment #2 from Domani Hannes  ---
(In reply to jos...@codesourcery.com from comment #1)
> This would be an interaction between the built-in function having a printf 
> format attribute and the header having either a gnu_printf or an ms_printf 
> format attribute (depending on feature test macros); as those attributes 
> aren't exact duplicates, both are applied (it's perfectly valid for a 
> function to have multiple format attributes, but I suppose we should 
> special-case this for format attributes for built-in functions with a more 
> specific format attribute in the header declaration).

But does it make sense to do a format check multiple times for one function?
If it's the same format attribute twice, you get duplicate warnings.
And if the format attributes are different, then I suspect that one of them has
to be wrong.

[Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #23 from Alexander Monakov  ---
In libcpp, search_line_fast implementations suffer from this, and what is
worse, attempts to workaround it by explicitly requesting zero extension don't
work:

char *foo(char *p, int x)
{
  return p + (unsigned)__builtin_ctz(x);
}

The above code is deliberately asking for zero extension, and yet various
optimizations in GCC transform it back to costlier form with sign extension.

(FWIW, LLVM gets this right)

[Bug libgomp/93065] libgomp: destructor missing to delete goacc_cleanup_key

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93065

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 31 10:34:34 2019
New Revision: 279803

URL: https://gcc.gnu.org/viewcvs?rev=279803&root=gcc&view=rev
Log:
PR libgomp/93065
* oacc-init.c (goacc_runtime_deinitialize): New function.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-init.c

[PATCH 1/1] [v3] libgomp: Add destructor to delete runtime env keys

[Ayush Mittal]

[BUG: 93065] libgomp: destructor missing to delete goacc_cleanup_key
libgomp constructor creates goacc_cleanup_key on dlopen but doesn't
delete key on dlclose.
dlopen and dlclose of libgomp.so exhausts pthread keys, which results in
pthread_key_create failure.

pthread_key_delete needs to be called by libgomp destructor.

Signed-off-by: Vaneet Narang 
Signed-off-by: Ayush Mittal 
---
[v2 patch] https://gcc.gnu.org/ml/gcc-bugs/2019-12/msg02326.html
[v2] -> [v3]
* Adding entry in libgomp/ChangeLog instead of toplevel Changelog.
 libgomp/ChangeLog   | 4 
 libgomp/oacc-init.c | 9 +
 2 files changed, 13 insertions(+)

diff --git a/libgomp/ChangeLog b/libgomp/ChangeLog
index 9eb3e2c25a0..a661685a5c2 100644
--- a/libgomp/ChangeLog
+++ b/libgomp/ChangeLog
@@ -1,3 +1,7 @@
+2019-12-31  Ayush Mittal  
+
+   * oacc-init.c (goacc_runtime_deinitialize): New function.
+
 2019-12-28  Jakub Jelinek  
 
PR bootstrap/93074
diff --git a/libgomp/oacc-init.c b/libgomp/oacc-init.c
index 487a2cca61f..6aa5fd297d6 100644
--- a/libgomp/oacc-init.c
+++ b/libgomp/oacc-init.c
@@ -858,6 +858,15 @@ goacc_runtime_initialize (void)
   goacc_host_init ();
 }
 
+static void __attribute__((destructor))
+goacc_runtime_deinitialize (void)
+{
+#if !(defined HAVE_TLS || defined USE_EMUTLS)
+  pthread_key_delete (goacc_tls_key);
+#endif
+  pthread_key_delete (goacc_cleanup_key);
+}
+
 /* Compiler helper functions */
 
 attribute_hidden void
-- 
2.17.1

Re: [v2] libgomp: Add destructor to delete runtime env keys

[Jakub Jelinek]

On Mon, Dec 30, 2019 at 07:24:08PM +0530, Ayush Mittal wrote:
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2019-12-30  Ayush Mittal  
> +
> + * libgomp: Add destructor to delete runtime env keys

This line should have been instead something like:
* oacc-init.c (goacc_runtime_deinitialize): New function.
and it should go into libgomp/ChangeLog rather than toplevel ChangeLog.

Otherwise, LGTM.
Do you have anybody that can commit it for you, or do you want me to commit
it for you?

>  2019-12-20  Jerome Lambourg  
>  
>   * MAINTAINERS (write_after_approval): Add myself.
> diff --git a/libgomp/oacc-init.c b/libgomp/oacc-init.c
> index 487a2cca61f..6aa5fd297d6 100644
> --- a/libgomp/oacc-init.c
> +++ b/libgomp/oacc-init.c
> @@ -858,6 +858,15 @@ goacc_runtime_initialize (void)
>goacc_host_init ();
>  }
>  
> +static void __attribute__((destructor))
> +goacc_runtime_deinitialize (void)
> +{
> +#if !(defined HAVE_TLS || defined USE_EMUTLS)
> +  pthread_key_delete (goacc_tls_key);
> +#endif
> +  pthread_key_delete (goacc_cleanup_key);
> +}
> +
>  /* Compiler helper functions */
>  
>  attribute_hidden void

Jakub

[Bug preprocessor/93109] New: #undefine suggests #define but not #undef

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93109

Bug ID: 93109
   Summary: #undefine suggests #define but not #undef
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

t.c:24:2: error: invalid preprocessing directive #undefine; did you mean
#define?
   24 | #undefine shift
  |  ^~~~
  |  define


I was not thinking when I was writing code for a second but the preprocessor
definitely could do better at the suggestion.