https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117151
--- Comment #4 from vincenzo Innocente ---
I submitted a bug report to llvm
https://github.com/llvm/llvm-project/issues/113332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117151
--- Comment #3 from vincenzo Innocente ---
this is surely affecting
https://github.com/llvm/llvm-project/blob/4275a731249c5becec666f47d26254695fd7f468/clang/lib/Headers/cuda_wrappers/complex#L70
I get things like
lld: error: undefined hidden sy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117216
--- Comment #1 from vincenzo Innocente ---
sorry last entry in the bug report should have been
innocent@vinmacscreen binary64 % c++ -O3 -march=native sqrt.cpp
-D_GLIBCXX_USE_C99_COMPLEX=0; ./a.out
(-4,-0) (0,2)
4 -3.14159
-0 positive
-0 negativ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117216
Bug ID: 117216
Summary: wrong sign for complex sqrt(-x-i0) (for targets
without C99 math)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117151
--- Comment #2 from vincenzo Innocente ---
fine.
I was trying to understand (reverse-engineering) what cuda and hip were using
in device and host code...
In case anybody is interested I think that cuda/nvcc uses their own
implementation (in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117151
Bug ID: 117151
Summary: _GLIBCXX_USE_C99_COMPLEX_ARC and
_GLIBCXX_USE_C99_COMPLEX are not defined in a
consistent way
Product: gcc
Version: 14.0
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
--- Comment #8 from vincenzo Innocente ---
for completeness: if C syntax is used gcc generates scalar code with fma
https://godbolt.org/z/4GPrrejWd
#include
#include
float complex
__attribute__ ((noinline))
mulf(float complex a, float comple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
--- Comment #7 from vincenzo Innocente ---
hadcrafted x86 code would look like this
scalar code:
vmovss xmm0, dword ptr [rdi]
vmovss xmm1, dword ptr [rdi + 4]
vmovss xmm2, dword ptr [rsi]
vmovss xmm3, dword ptr [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
--- Comment #6 from vincenzo Innocente ---
I'm just taking the product of two complex numbers, cannot call std::fma in the
user code: reimplementing the operator* is not trivial (and is a stdlib job
anyhow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
vincenzo Innocente changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
Bug ID: 116979
Summary: [12 regression] fma not always used in complex product
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114943
Bug ID: 114943
Summary: X86 AVX2: inefficient code generated to convert SIMD
Vectors
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484
--- Comment #9 from vincenzo Innocente ---
We observe that including xmmintrin.h the behaviour of some code,
notably abs(x), when x is float or double changes.
And this depends on the platform as xmmintrin.h is x86_64 specific.
Yes, is 20 years
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484
--- Comment #4 from vincenzo Innocente ---
in C++ one is supposed to #include
not
I do not think that there is an explicit version of C++ headers for the
intrinsics that avoids the conflicts between C and C++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484
--- Comment #2 from vincenzo Innocente ---
*** Bug 114483 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114483
vincenzo Innocente changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484
--- Comment #1 from vincenzo Innocente ---
xmmintrin.h
includes mm_malloc.h
which
#include
which
using std::abs;
(among others)
see
https://godbolt.org/z/cxo65rnr9
or this excerpt from c++ -E dump
```
# 32
"/data/cmssw/el9_amd64_gcc12/exter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484
Bug ID: 114484
Summary: #include changes ::abs in std::abs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114483
Bug ID: 114483
Summary: #include changes ::abs in std::abs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114363
--- Comment #4 from vincenzo Innocente ---
Thanks Harald, I missed the point that float z = pow(double(x),2) and
float z = x*x would indeed produce exactly the same result, while in all other
cases of course not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114363
Bug ID: 114363
Summary: inconsistent optimization of pow(x,2)+pow(y,2)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112649
Bug ID: 112649
Summary: [c++23] in presence of inline functions and debug-info
stacktrace reports the deepest callee
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112348
--- Comment #1 from vincenzo Innocente ---
This patch works for me
diff --git a/libstdc++-v3/include/std/stacktrace
b/libstdc++-v3/include/std/stacktrace
index da0e48d3532..9a0d0b16068 100644
--- a/libstdc++-v3/include/std/stacktrace
+++ b/libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
--- Comment #12 from vincenzo Innocente ---
confirm that the patch solves the issue
c++ -std=c++23 testStacktrace.cpp -lstdc++exp -g -DINLIB -fpic -shared -o
liba.so -ldl;c++ -std=c++23 testStacktrace.cpp -lstdc++exp -g -DINMAIN -L. -la
-Wl,-rp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
--- Comment #8 from vincenzo Innocente ---
Thanks Ian for the patch.
For testing I will need the full git diff (including the makefile itself as my
autoconf is not compatible with gcc14).
Backports down to gcc12 will be appreciated.
Could you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112348
Bug ID: 112348
Summary: [C++23] defect in struct
hash>
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
--- Comment #6 from vincenzo Innocente ---
Sorry, made the (almost) full exercise:
read the doc in
https://en.cppreference.com/w/cpp/utility/stacktrace_entry
and the code in stacktrace header file and in
libstdc++-v3/src/c++23/stacktrace.cc
(ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
--- Comment #5 from vincenzo Innocente ---
so if I add to
std::cout << std::stacktrace::current() << '\n';
I get what needed
Dl_info dlinfo;
for (auto & entry : std::stacktrace::current() ) {
dladdr((const void*)(entry.native_hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
--- Comment #4 from vincenzo Innocente ---
intel x86_64
uname -a
Linux patatrack01 4.18.0-477.13.1.el8_8.x86_64 #1 SMP Thu May 18 10:27:05 EDT
2023 x86_64 x86_64 x86_64 GNU/Linux
boost::backtrace works
can provide example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
vincenzo Innocente changed:
What|Removed |Added
CC||ian at gcc dot gnu.org
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
Bug ID: 112263
Summary: [C++23] std::stacktrace does not identify symbols in
shared library
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111936
--- Comment #9 from vincenzo Innocente ---
Thanks for the second patch.
I was indeed struggling with autoconf versions (1.15 vd 1.16)
Any chance to backport to gcc12 (our current production version)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111936
--- Comment #7 from vincenzo Innocente ---
not explicitly in the src tree.
only run configure in the build directory.
what I need to run in the src tree?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111936
--- Comment #5 from vincenzo Innocente ---
My bad, long time I'm not using archive libraries and forgot about the order
rule.
The issue is indeed missing -fPIC.
Thanks for the fast action.
I applied the patch but it seems not sufficient.
If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934
--- Comment #3 from vincenzo Innocente ---
with
gcc version 14.0.0 20231024 (experimental) [master r14-4877-g724badcadf8] (GCC)
I get the same ICE.
Please note that one needs to include "iostream"
(in my test compile with "-DICE")
to trigger th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111936
--- Comment #1 from vincenzo Innocente ---
here is a minimal malloc hook that I would like to use
[innocent@patatrack01 ctest]$ cat getStacktrace.cc
#include
std::string get_stacktrace() {
std::string trace;
for (auto & entry : std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111936
Bug ID: 111936
Summary: std::stacktrace cannot be used in a shared library
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934
--- Comment #1 from vincenzo Innocente ---
sorry missed the version
gcc version 14.0.0 20231021 (experimental) [master r14-4817-g405a4140fc3] (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934
Bug ID: 111934
Summary: ICE internal compiler error: in
discriminator_for_local_entity, at cp/mangle.cc:2065
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109885
Bug ID: 109885
Summary: gcc does not generate movmskps and testps instructions
(clang does)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109281
Bug ID: 109281
Summary: use std::optional results in suboptimal code
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
Bug ID: 109011
Summary: missed optimization in presence of __builtin_ctz
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108804
Bug ID: 108804
Summary: missed vectorization in presence of conversion from
uint64_t to float
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108677
--- Comment #3 from vincenzo Innocente ---
sorry. the original internal bug report was for gcc 7.5
https://godbolt.org/z/9crafbqen
where I think the generated code is indeed wrong (and does not depend on the
presence of the constructor!)
SO, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108677
Bug ID: 108677
Summary: wrong vectorization (when copy constructor is
present?)
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106012
--- Comment #6 from vincenzo Innocente ---
just to confirm that
-Ofast -fno-reciprocal-math -mno-recip
seems to inhibit all reciprocals...
https://godbolt.org/z/f4bccb9GP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107933
Bug ID: 107933
Summary: std::sqrt complies in intrinsics for float even if
--no-builtin is provided
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106012
vincenzo Innocente changed:
What|Removed |Added
Summary|rsqrtss instruction |rsqrtps and rcpps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106012
Bug ID: 106012
Summary: rsqrtss instruction generated even if -mno-recip
specified
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104950
Bug ID: 104950
Summary: GCC does not emit branchless code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97707
--- Comment #3 from vincenzo Innocente ---
the main point in using -mprefer-vector-width=256 is to avoid clock throttling
in "mixed" workloads.
In small benchmarks like this one avx512 is faster (even on an old Silver) even
if trigger a slower cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97707
Bug ID: 97707
Summary: avx12 math function invoked even if
-mprefer-vector-width=256 specified
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
52 matches
Mail list logo
