RMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
Target Milestone: ---
GCC 7.3.1 is available in Fedora RISC-V stage4 and is configured with multilib,
but only one ABI is sele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84856
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83662
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162
--- Comment #13 from David Abdurachmanov
---
Created attachment 41463
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41463&action=edit
This is just minimized *.ii file
I am also adding PGOInstrumentation2.cpp.xz, which is just slightly mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162
--- Comment #12 from David Abdurachmanov
---
I have attached minimized file (PGOInstrumentation.cpp) from LLVM.
Compile line: g++ -c PGOInstrumentation.cpp
Result:
PGOInstrumentation.cpp: In constructor
'{anonymous}::PGOInstrumentationUseLegac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162
--- Comment #11 from David Abdurachmanov
---
Created attachment 41461
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41461&action=edit
Minimized file from LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493
--- Comment #12 from David Abdurachmanov
---
Looks to be std::vector> (aka
ConstRecHitContainer).
Here is the class and typedef for the containers:
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/DataFormats/TrackingRecHit/interface/TrackingRe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493
--- Comment #10 from David Abdurachmanov
---
We have been bitten by DSE with TBB already on GCC 6.2.0.
I decided to try -fno-lifetime-dse on the first bad commit and got some
surprising results. Now it fails with:
pure virtual method called
te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493
--- Comment #8 from David Abdurachmanov
---
Can confirm that '-fno-delete-null-pointer-checks -fwrapv -fno-devirtualize'
don't change the outcode, fails the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493
--- Comment #7 from David Abdurachmanov
---
I did try -fno-devirtualize and -fno-delete-null-pointer-checks without
success, but will re-try again now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493
--- Comment #5 from David Abdurachmanov
---
I tried running valgrind on both x86_64 and ppc64le. It was running for 2 days
and didn't report any invalid reads / writes to the memory. My first guess was
that we are corrupting memory.
I added -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493
--- Comment #3 from David Abdurachmanov
---
Created attachment 39571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39571&action=edit
generated assembly with the first bad commit + pragma no-crossjumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493
--- Comment #2 from David Abdurachmanov
---
Created attachment 39570
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39570&action=edit
generated assembly with the first bad commit
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
Target Milestone: ---
Created attachment 39568
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39568&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493
--- Comment #1 from David Abdurachmanov
---
Created attachment 39569
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39569&action=edit
generated assembly with last good commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70822
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71388
--- Comment #7 from David Abdurachmanov
---
Just for reference (if someone reads this PR):
https://gcc.gnu.org/ml/gcc/2016-02/msg00205.html
It contains a reference to C++ standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71388
--- Comment #6 from David Abdurachmanov
---
Agreed. As usual, thanks for verifying this. Will cook and send a patch to TBB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71388
--- Comment #2 from David Abdurachmanov
---
Doesn't std::memset apply here? They allocate storage, set it to 0x0 and then
place construct the object.
At first look I wouldn't expect GCC to remove std::memset.
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
Target Milestone: ---
Created attachment 38626
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38626&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760
--- Comment #18 from David Abdurachmanov
---
For now I will pull this change into my GCC 6.1.0 build.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760
--- Comment #12 from David Abdurachmanov
---
I have re-tested #3 patch by recompiling 316 RPMs (from GCC to our software --
top package). Have not seen those strange segfaults.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760
--- Comment #10 from David Abdurachmanov
---
I did a quick test (still took several hours) with #1 and #3 patches and both
seem to solve the issue. Patches were tested on top of r235408.
Just in case I will run patch #3 (for now) again, but wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760
--- Comment #8 from David Abdurachmanov
---
Should I continue testing the 2nd patch, or dump whatever is currently built
and restart with the patch from your latest comment?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760
--- Comment #6 from David Abdurachmanov
---
Will do, results will be late today or tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760
--- Comment #4 from David Abdurachmanov
---
I will test the second patch. Will take a few hours (it's millions of lines in
C++).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331
--- Comment #13 from David Abdurachmanov
---
Done,
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
Target Milestone: ---
Created attachment 38325
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38325&action=edit
untouched prepr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331
--- Comment #11 from David Abdurachmanov
---
"Good" code, annotated by me. Now notice from my previous message that the fix
for this PR, caused
49 89 1c 24 mov%rbx,(%r12)
to be removed. We lost one instruction which stored the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70750
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
Target Milestone: ---
This is a follow up of comment:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802#c8
Caused by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802
--- Comment #9 from David Abdurachmanov
---
Created attachment 38230
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38230&action=edit
Failing file (pre-processed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
Reporter: david.abdurachmanov at gmail dot com
Target Milestone: ---
Created attachment 37878
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37878&action=edit
test case
I came across this while recompiling our repositories with GCC 6.0.0 (r233941,
a couple of days old already)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67603
--- Comment #1 from David Abdurachmanov
---
Created attachment 36345
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36345&action=edit
Annotated assembly
Shows that one value is computed at run-time, while another one is loaded from
litera
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
Target Milestone: ---
Created attachment 36344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #23 from David Abdurachmanov
---
GCC trunk
r226676
or 15af172f2a0ea281969e3105da9f9bb100097c7d from
git://gcc.gnu.org/git/gcc.git
Date: Thu Aug 6 14:26:18 2015 +)
Rebased and applied:
https://gcc.gnu.org/ml/gcc-patche
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #21 from David Abdurachmanov
---
I am on vacations now, but I already marked this on my TODO list. Once I find a
free time slot I will give it a spin. I will try to report in a few days.
BTW, I will also show up at GNU Tools Cauldro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #14 from David Abdurachmanov
---
I hit another two cases of this.
1. g2root tool, which converts GEANT geometry to ROOT geometry. It create a
single function, which contains lots of descriptions of material, shapes, etc.
all describ
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
Storing a single long double in a vector will cause GCC 4.9.2 and GCC 5.0.0 to
ICE on AArch64:
typedef long double a __attribute__((vector_size (16)));
a sum(a first, a second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65486
--- Comment #3 from David Abdurachmanov
---
Forgot this is on x86_64. Also tested with Clang 3.5, which worked fine.
It seems to that it's also ICE'ing on AArch64, but in expr.c if a single long
double is in a vector. I will file another bug re
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
Tested in F21 with gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) and in
F22 with gcc version 5.0.0 20150226 (Red Hat 5.0.0-0.17) (GCC)
Testcase:
typedef long double a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #8 from David Abdurachmanov
---
I will finish testing my patch for upstream next week. I was busy with other
tasks.
AArch64 is young, this kind of things are bound to happen :/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #13 from David Abdurachmanov
---
Created attachment 34416
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34416&action=edit
31-lines, minimal testcase
I am adding 31-lines minimal testcase. Should be good enough for GCC testsui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #3 from David Abdurachmanov
---
The patch has been submitted to LLVM/compiler-rt and approved. Not yet
committed, pending testing with Clang.
http://reviews.llvm.org/D6854
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #12 from David Abdurachmanov
---
I decided to re-enable -Os for OpenLoops. Then use powerful hardware with
32-physical-cores (x86_64) and 0.5TB of RAM to see if I could get lucky. Fired
up QEMU user mode with Fedora for AArch64 chroo
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
While doing testing, I found that I couldn't bootstrap GCC anymore during
holidays.
Using git bisect, I found first breaking c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #2 from David Abdurachmanov
---
linux/version.h does not bring any additional kernel headers, its fully
standalone and seems fine to include.
There might be a problem is someone builds a distribution with GCC 5 and kernel
<=3.15 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #1 from David Abdurachmanov
---
Created attachment 34356
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34356&action=edit
RFC patch (tested)
Bootstrapped on aarch64-linux-gnu machine with F19 + 3.12 and on QEMU with F21
+ 3.17
MED
Severity: major
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64413
David Abdurachmanov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
Created attachment 34338
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34338&action=edit
testcase (AArch64, Fortran)
OpenLoops 1.0.1 pac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60789
David Abdurachmanov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60789
--- Comment #1 from David Abdurachmanov
---
Found the culprit. I had CFLAGS/CXXFLAGS/LDFLAGS for gcc ./configure. Thus
probably setting CFLAGS causes `-lm` to vanish in libstdc++v3 math conftests.
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
Math functions tests are failing with GCC 4.9.0 (trunk, r209221), while working
fine at least up to 4.8.1.
Tested on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60675
--- Comment #5 from David Abdurachmanov
---
Created attachment 32460
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32460&action=edit
Minimized pre-processed file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60675
--- Comment #3 from David Abdurachmanov
---
With `-mno-lra` compiles fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60675
--- Comment #1 from David Abdurachmanov
---
Seems the testcase is too large. Trimming it more usually causes it not to ICE,
but will try to trim more.
: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
$ rpm --eval "%{_build}"
aarch64-redhat-linux-gnu
Compiles fine with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60112
--- Comment #2 from David Abdurachmanov
---
Tested today on r207627, still the same result.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/build1/davidlt/ngcc490/a/slc6_amd64_gcc490/external/gcc/4.9.0-cms/bin/../libexec/gcc/
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
GCC pre-4.9.0 (r206686), no issues on 4.6.2, 4.7.2, and 4.8.1. I found that if
I mark `get_size' as inline or constexpr errors are gone. If I keep `nFaces'
uninitialized it also
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56193
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #18 from David Abdurachmanov
---
Tested the patch on top of final 4.8.1 Cortex-A9 NEON FPU. GCC no more ICE'ing
while compiling scipy.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55149
--- Comment #11 from David Abdurachmanov
---
(In reply to Jason Merrill from comment #10)
Hi Jason,
Compiled fine in 4.8.0, fails in 4.9.0 (r199649). That's the smallest I could
get in this time. It produces two errors for the same line.
david
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55149
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #25 from David Abdurachmanov
---
I downloaded GCC 4.8.1 (final) and binutils 2.23.1 (default ld.gold). The
problem is that boost and a lot other C/C++ packages are not compiled w/ ASan.
One way would be to guarantee every single C/C++
||gmail dot com
--- Comment #22 from David Abdurachmanov
2013-04-07 08:44:21 UTC ---
Has this been resolved in the final 4.8.0 (r196952)? I checked some changes and
they seems to be in.
I have a number (<100) C++/C packages (incl. boost 1.51
||gmail dot com
--- Comment #16 from David Abdurachmanov
2013-01-29 08:54:14 UTC ---
Ping.
I noticed a patch ([PATCH] Put -lasan always very early on the ld command line
(PR sanitizer/55374)) posted on gcc-patches. There was not ACK yet from RM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753
--- Comment #9 from David Abdurachmanov
2013-01-04 11:32:39 UTC ---
Created attachment 29082
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29082
testcase #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753
--- Comment #8 from David Abdurachmanov
2013-01-04 11:31:21 UTC ---
I have tested the trunk, rev 194883. Seems to compile the test case #1, but it
still fails in the original program, Sherpa [1].
I am attaching pre-processed test case #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753
--- Comment #4 from David Abdurachmanov
2012-12-24 12:48:01 UTC ---
I did some more testing of the trunk. Compiles fine with r173678 [g++ (GCC)
4.7.0 20110511 (experimental)], but starts ICE'ing with r173679. gcc_assert
(TREE_CONSTANT (t))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753
--- Comment #3 from David Abdurachmanov
2012-12-23 12:31:40 UTC ---
I tried reverting (on r194703):
- r173680: Compiles. But still ICE'd as reported.
- r173680 && r173679: Does not compile, xgcc ICE'd
- r173680 && r173679 && r173678: Same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753
Bug #: 55753
Summary: [C++11][4.8 Regression] ICE constexpr ctor,
tsubst_copy_and_build, at cp/pt.c:14336
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55652
Bug #: 55652
Summary: [C++11][4.8] ICE (segfault) with templates and structs
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55413
--- Comment #1 from David Abdurachmanov
2012-11-20 14:07:57 UTC ---
Created attachment 28743
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28743
Testcase used.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55413
Bug #: 55413
Summary: [LTO] hashtable.h:1648 '__bbegin_bkt' may be used
uninitialized in this function
[-Werror=maybe-uninitialized]
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54563
Bug #: 54563
Summary: [4.7][C++11] MacOS 10.8, ICE in redirect_eh_edge_1, at
tree-eh.c:2215
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRM
||gmail dot com
--- Comment #4 from David Abdurachmanov
2012-04-06 19:39:18 UTC ---
I can confirm the issue. Run into the problem when re-compiling a project with
C++11.
Works fine in C++98/03, does not compile in C++11. Both work-arounds suggested
in the first
85 matches
Mail list logo
