https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99662
Bug ID: 99662
Summary: GNAT compiled with the address sanitizer fails at
build time
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 99624, which changed state.
Bug 99624 Summary: Address sanitizer detects heap-buffer-overflow in namet.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
Vittorio Zecca changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
--- Comment #8 from Vittorio Zecca ---
Address sanitizer of Version 11.0.1 current trunk miscompiles the Ada
compiler, maybe a previous version would work.
Undefined behavior sanitizer works.
I am now trying to build the Ada compiler with gcc 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
--- Comment #6 from Vittorio Zecca ---
It is not that easy, unfortunately.
If I compile the build with -gnata, thereby arming the pragma assert,
the build fails.
So I had to build without -gnata.
Now trying to build Ada with gcc 9.1.0
Earlier v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
--- Comment #4 from Vittorio Zecca ---
I added
pragma Assert (Id in Name_Entries.Table'Range);
at namet.adb:156, but then I get at compile time
namet.adb:156:25: warning: condition can only be False if invalid values
present
and the build sto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
--- Comment #2 from Vittorio Zecca ---
Yes, probably gcc -fsanitize=address is miscompiling the Ada compiler.
I had to take out the -gnata option to disable pragma assert that was failing.
So I do not know if this is a genuine compiler bug or it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
Bug ID: 99624
Summary: Address sanitizer detects heap-buffer-overflow in
namet.adb
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #30 from Vittorio Zecca ---
On the following source code I still have the ICE:
type t
integer g
end type
type(t) :: u=t(1)
data u%g /2/ ! should emit diagnostic here
end
gfortran -S gfbug63.f
gfb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99382
Bug ID: 99382
Summary: Address sanitizer detects stack-buffer-overflow in
stl_construct.h
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99376
Bug ID: 99376
Summary: Sanitizer detects undefined behaviour in rtlanal.c
compiling ada
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82721
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79524
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99337
--- Comment #4 from Vittorio Zecca ---
(In reply to Iain Buclaw from comment #3)
> Fix is trivial
>
> --- a/gcc/d/dmd/dmodule.c
> +++ b/gcc/d/dmd/dmodule.c
> @@ -195,7 +195,7 @@ static void checkModFileAlias(OutBuffer *buf, OutBuffer
> *dotmods,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52622
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99337
--- Comment #1 from Vittorio Zecca ---
This issue was found with the address sanitizer, while issues in bug
63426 were found with the undefined behavior sanitizer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99337
Bug ID: 99337
Summary: Sanitizer detect heap-buffer-overflow in
checkModFileAlias
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50551
--- Comment #3 from Vittorio Zecca ---
Still in trunk.
The NAG nagfor and Intel ifort compilers detect the issue.
gfortran -S gfbug89.f
[vitti f95]$nagfor -S -w gfbug89.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug89.f,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81319
Vittorio Zecca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80774
--- Comment #6 from Vittorio Zecca ---
Still in current trunk.
gfortran -S gfbug132.f -fcoarray=single
gfbug132.f:18:72:
18 | deallocate(obj%link)
|
1
interna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85789
--- Comment #2 from Vittorio Zecca ---
Still in trunk:
~/local/gcc-150221-undefined/bin/gcc -S gccerr67.c -O
../../gcc-150221/gcc/cse.c:2204:34: runtime error: signed integer overflow: 1 -
-9223372036854775807 cannot be represented in type 'long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50541
--- Comment #7 from Vittorio Zecca ---
The NAG nagfor and Intel ifort detect the issue.
gfortran -S gfbug81.f
[vitti f95]$nagfor -S gfbug81.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug81.f, line 4: Multiply defined symb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58224
--- Comment #3 from Vittorio Zecca ---
Still in trunk.
The NAG nagfor compiler detects the issue at compile time.
nagfor gfbug103.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Warning: gfbug103.f, line 8: Pointer Q never dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82083
Vittorio Zecca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525
--- Comment #6 from Vittorio Zecca ---
Still in trunk.
The NAG nagfor and Intel ifort compilers detect the issue.
ifort -S -w gfbug72.f
gfbug72.f(4): error #6482: An ENTRY dummy argument is referenced in an
executable statement before it appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67486
Vittorio Zecca changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 62058, which changed state.
Bug 62058 Summary: Undefined behaviour in tree-data-ref.c with options -O1
-ftree-loop-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62058
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62058
Vittorio Zecca changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81986
Vittorio Zecca changed:
What|Removed |Added
Component|sanitizer |libfortran
--- Comment #4 from Vittorio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402
--- Comment #9 from Vittorio Zecca ---
Still in current trunk.
The compilers NAG nagfor and Intel ifort correctly detect a syntax error.
nagfor -S -w gfbug43.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug43.f, line 12: Sc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50538
--- Comment #4 from Vittorio Zecca ---
Still present in current trunk.
The compilers NAG nagfor and Intel ifort detect the issue.
nagfor -S -w gfbug78.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug78.f, line 4: Dummy argu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50542
--- Comment #4 from Vittorio Zecca ---
Still present in version 11.
The compilers NAG nagfor and Intel ifort detect the issue.
ifort -S -w gfbug82.f -warn stderrors
gfbug82.f(9): error #8252: A DATA implied-DO variable must be an array element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50536
--- Comment #9 from Vittorio Zecca ---
Still present in version 11.
Detected by NAG nagfor and Intel ifort.
[vitti f95]$nagfor -S -w gfbug74.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug74.f, line 4: Input item L cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67379
Vittorio Zecca changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50377
--- Comment #4 from Vittorio Zecca ---
Still present at version 11.
The Intel ifort and NAG nagfor compilers decet the issue.
nagfor -S gfbug158.f -w
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug158.f, line 3: External proc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50535
--- Comment #2 from Vittorio Zecca ---
Still in version 11.
Both Intel ifort and NAG nagfor detect the issue.
ifort -S gfbug73.f -w
gfbug73.f(5): error #6736: This transformational intrinsic function is invalid
in this context; statement functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44798
Vittorio Zecca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50549
--- Comment #2 from Vittorio Zecca ---
Still present on version 11.
NAG nagfor compiler detecs it.
nagfor -S gfbug87.f -w
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug87.f, line 13: Wrong character length (1 instead of 2) fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44922
Vittorio Zecca changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99255
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99236
--- Comment #2 from Vittorio Zecca ---
After patching libgcc2.c the test case runs fine without sanitizer messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99236
Bug ID: 99236
Summary: Undefined behaviour in libgcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190
--- Comment #8 from Vittorio Zecca ---
I can confirm the new libubsan works on my test case.
Keep up the good work!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99202
--- Comment #2 from Vittorio Zecca ---
I believe you need LD_PRELOAD if the object program uses the address sanitizer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44792
--- Comment #3 from Vittorio Zecca ---
Still unmodified, I cannot see the modification of Tobias Burnus.
NAG nagfor compiler stll produces run time error message.
Runtime Error: gcc/testsuite/gfortran.fortran-torture/execute/data.f90, line
28: R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190
--- Comment #5 from Vittorio Zecca ---
Sorry I meant libubsan, but I am building the whole gcc, g++, and gfortran
sanitized version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99203
Bug ID: 99203
Summary: Undefined behaviour in libquadmath file print_fp.c
function __quadmath_printf_fp
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99202
Bug ID: 99202
Summary: Undefined behaviour in libquadmath file rem_pio2q.c
function __quadmath_rem_pio2q
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190
--- Comment #4 from Vittorio Zecca ---
To generate a sanitized version of libgfortran I built whole sanitized
gcc with the following command:
CFLAGS="-g -O0 -fsanitize=undefined -lubsan" LIBS="-lubsan"
CXXFLAGS=$CFLAGS ../gcc-150221/configure
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99191
Bug ID: 99191
Summary: sanitizer detects undefined behaviour in libgfortran
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190
Bug ID: 99190
Summary: Undefined behaviour in libubsan
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67516
Vittorio Zecca changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67485
Vittorio Zecca changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158
Vittorio Zecca changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065
--- Comment #10 from Vittorio Zecca ---
This issue seems to have been resolved in the trunk gfortran 11.0.0
gfortran gfbug109.f -fcheck=pointer -g
[vitti f95]$./a.out
At line 9 of file gfbug109.f
Fortran runtime error: Allocatable argument 'a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99148
--- Comment #1 from Vittorio Zecca ---
Reproduction of this issue requires an address sanitized version of
libgfortran.
I narrowed the issue to unpack0_char changing
{
gfc_array_char tmp;
if (unlikely(compile_options.bounds_check))
unpa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145
--- Comment #4 from Vittorio Zecca ---
(In reply to Jerry DeLisle from comment #3)
> Initially it is creating the very large string in the frontend passes and
> then via resolution and translation phases, and finally into the middle-end
> and bac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99147
--- Comment #5 from Vittorio Zecca ---
I ran the testsuite against the proposed fix and it was successful, no
sanitizer errors in symbol.c.
Only remaining error as in bug 99148.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99147
--- Comment #3 from Vittorio Zecca ---
I changed symbol.c as per your suggestion and now the address
sanitized gfortran compiles fine.
Now I am going to check it against the testsuite.
Results tomorow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145
--- Comment #2 from Vittorio Zecca ---
I am sorry I should have taken more time analyzing this issue.
Actually it is not and infinite loop, I clocked the compilation first
with the -S option,
then with the -c option.
The compiler takes 4'52" of r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99148
Bug ID: 99148
Summary: sanitizer detects stack-buffer-overflow in
unpack_generic.c
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99147
Bug ID: 99147
Summary: Sanitizer detects heap-use-after-free in
gfc_add_flavor
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99146
Bug ID: 99146
Summary: ICE in gfc_find_specific_dtio_proc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145
Bug ID: 99145
Summary: gfortran LOOP
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85851
--- Comment #7 from Vittorio Zecca ---
Fixed in trung February 15th, 2021.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550
--- Comment #9 from Vittorio Zecca ---
Intel ifort and ifx accept the test case without errors.
They both accept
pointer pi
integer :: pi=>null()
and
integer :: pi=>null()
pointer pi
Anyway, it's easy to transfom it into
integer, pointer ::
67 matches
Mail list logo
