: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
// ../../gcc7/gcc/cp/parser.c:766:7: runtime error: member call on null pointer
of type 'struct vec'
class A {
template void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70876
--- Comment #4 from Vittorio Zecca ---
Will you please check gcc 6.1 with your fix against bug 70877?
I get an ICE, could it be a regression?
gcc -fcheck-pointer-bounds -mmpx gccerr36.c
gccerr36.c: In function ‘bar’:
gccerr36.c:12:8: warning:
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
/* gcc -O2 sanitizer undefined runtime error */
/* In gcc trunk 7.0 */
/* ../../gcc7/gcc/combine.c:12340:18: runtime error: left
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71074
Vittorio Zecca changed:
What|Removed |Added
Severity|normal |minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497
--- Comment #5 from Vittorio Zecca ---
Still in trunk:
../../gcc7/gcc/fortran/data.c:191:32: runtime error: null pointer passed as
argument 2, which is declared to never be null
here:
memcpy ([start], rvalue->value.character.string, len *
++
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
Compiling the following with
g++ -fsanitize=address
int main()
{
int offset=1;
char buf[offset]="";
}
I get the following:
p.C:5:1: internal compiler error: in tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
This one seems to be fixed in trunk, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526
--- Comment #31 from Vittorio Zecca ---
It seems the following is related to the FF compilation issue:
The program runs differently depending on the optimization level.
With gcc 5.3.0 runs same regardless of the optimization level.
// g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70722
--- Comment #7 from Vittorio Zecca ---
Yes, this fixed my problem with mozilla firefox compilation,
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497
--- Comment #4 from Vittorio Zecca ---
And in 6.1.0
../../gcc-6.1.0/gcc/fortran/data.c:191:32: runtime error: null pointer passed
as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
--- Comment #22 from Vittorio Zecca ---
Same ICE in 6.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #11 from Vittorio Zecca ---
Same ICE in 6.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69412
--- Comment #5 from Vittorio Zecca ---
Bug in comment 4 still in gcc 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67483
--- Comment #2 from Vittorio Zecca ---
Yes I confirm it is in trunk:
../../gcc7/gcc/combine.c:7727:40: runtime error: shift exponent -1 is negative
combine.c:7727 is "& unsigned HOST_WIDE_INT) 1 << count)) - 1)) == 0"
count==-1 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70877
--- Comment #2 from Vittorio Zecca ---
I confirm fixed in 6.1.0 and trunk.
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67482
--- Comment #3 from Vittorio Zecca ---
I confirm I cannot reproduce it on 6.1.0 nor 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67482
--- Comment #5 from Vittorio Zecca ---
Running the sanitized version of gcc against the testsuite I got no
runtime error in dwarf2out.c
So I believe this issue can be closed as FIXED.
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
! -fsanitize=address -O0 catches out of bounds access on assumed size array
! any other optimization level, even -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71027
--- Comment #2 from Vittorio Zecca ---
Yes, you are right, and probably in real programs the subroutine would
not be optimized away.
Thank you for the explanation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
Vittorio Zecca changed:
What|Removed |Added
Version|4.8.0 |7.0
--- Comment #26 from Vittorio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61907
Vittorio Zecca changed:
What|Removed |Added
Version|4.9.1 |7.0
--- Comment #6 from Vittorio Zecca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61910
--- Comment #7 from Vittorio Zecca ---
Still there in gcc 7.0 trunk 239276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61908
Vittorio Zecca changed:
What|Removed |Added
Version|4.9.1 |7.0
--- Comment #6 from Vittorio Zecca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74265
--- Comment #1 from Vittorio Zecca ---
The following is a shorter reproducer:
struct B {
__CHAR32_TYPE__ S[6];
} d[] = { { { U"foo" } }, [0].S[2] = U'x' };
: normal
Priority: P3
Component: java
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
While generating 7.0 trunk with sanitized java I get the following
in mark.c:1468
"q = *p;"
libtool: link: /home
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67485
Vittorio Zecca changed:
What|Removed |Added
Version|5.2.0 |7.0
--- Comment #3 from Vittorio Zecca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=75860
--- Comment #2 from Vittorio Zecca ---
The preprocessed source is too big to be meaningful.
I did try to shorten it but still too big and using so many firefox
header files.
It will be faster if you could download the firefox-48 source and try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=75860
--- Comment #4 from Vittorio Zecca ---
Created attachment 39369
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39369=edit
xz-ipped reproducer
This is the xzipped test case that is my reproducer for this issue.
There are many compilation
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
While compiling firefox version 48 with the trunk gcc 7.0 I get the following
segmentation violation
tree.h:3022 is "if (TREE_CODE (__t) !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=75860
--- Comment #6 from Vittorio Zecca ---
Created attachment 39410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39410=edit
xz-ipped original firefox source file
Original firefox source file in xz format.
This one is error free except for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=75860
--- Comment #8 from Vittorio Zecca ---
Compiling the big test case, 231025 lines, with trunk level 239276 of August
9th
g++ -v
Using built-in specs.
COLLECT_GCC=g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=75860
--- Comment #11 from Vittorio Zecca ---
I applied the fix from bug 72849 and the ICE disappeared.
Many thanks for pointing me to the right place!
ponent: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
While compiling gcc itself, the sanitizer complains as follows:
gcc-trunk-239276/libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift
of 1 by 31 places
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67482
Vittorio Zecca changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496
Vittorio Zecca changed:
What|Removed |Added
Version|5.2.0 |7.0
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496
--- Comment #11 from Vittorio Zecca ---
Still in trunk 7.0
gcc-trunk-239276/gcc/fortran/trans-array.c:2243:27: runtime error: load of
value 48, which is not a valid value for type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497
--- Comment #7 from Vittorio Zecca ---
Traveling now, back home end of March.
Did you check the value of variable "len" maybe it's zero so it's not
really a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77327
--- Comment #5 from Vittorio Zecca ---
The test case you propose, dec_structure_13.f90, does not trigger the asan
memory checker.
As I wrote before, the test case gfortran.dg/import4.f90 does trigger
the asan memory checker.
In your test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77327
--- Comment #6 from Vittorio Zecca ---
After applying the proposed patch the asan memory checker did not report
any memory fault, in particular the heap-use-after-free in interface.c
Fritz, do you have a -fsanitize=address version of gfortran,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77327
--- Comment #4 from Vittorio Zecca ---
The reproducer I proposed comes from testcase gfortran.dg/import4.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
Compiling the following with ubsan sanitized gcc
f(void)
{
float y=0;
if(y<0.1) y=1.0;
}
I get
../../gcc-tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828
--- Comment #11 from Vittorio Zecca ---
Sorry I am traveling now I cannot help you.
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
Compiling the following:
subroutine foo(a)
type myT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67737
--- Comment #9 from Vittorio Zecca ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Vittorio Zecca from comment #7)
> > With gcc 6.1.0, maybe a shorter reproducer
> > /* gcc -fcheck-pointer-bounds -mmpx p.c */
>
> That is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77327
--- Comment #8 from Vittorio Zecca ---
Yes, it seems to me that import4.f90 is sufficient to trigger the asan
memory checker.
How strange, even without "implicit none" the loader should have complained
that "sub2" was referenced but undefined.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
/* gcc -fcheck-pointer-bounds -mmpx */
int main ()
{
int size = 10;
typedef struct
{
char val[size];
} block;
block b;
block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630
--- Comment #14 from Vittorio Zecca ---
(In reply to Dominique d'Humieres from comment #13)
> > I am still having an ICE as in comment 11.
>
> Me too even on trunk (7.0.1)!-(I also get an ICE with the original test.)
> Reopening the PR.
>
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67338
--- Comment #1 from Vittorio Zecca ---
Still in 7.0.1
../../gcc-7-246252/gcc/fold-const.c:14253:11: runtime error: negation of
-2147483648 cannot be represented in type 'int'; cast to an unsigned type to
negate this value to itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67359
Vittorio Zecca changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
Bug 33056 depends on bug 67497, which changed state.
Bug 67497 Summary: data.c sanitizer runtime error: null pointer passed as
argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497
Vittorio Zecca changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497
--- Comment #8 from Vittorio Zecca ---
Just back from my travel.
The sanitizer error message disappeared on trunk level 246252.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
//gcc 7.0.1 trunk 246252 undefined behaviour with optimization
//-O0 and -Og ok, higher levels get undefined
long int
f2 (long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67338
--- Comment #5 from Vittorio Zecca ---
I still have a similar issue in 7.0.1
../../gcc-7-246252/gcc/fold-const.c:14253:11: runtime error: negation of
-2147483648 cannot be represented in type 'int'; cast to an unsigned type to
negate this value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630
--- Comment #12 from Vittorio Zecca ---
I am still having an ICE as in comment 11.
Opening a new bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50542
--- Comment #3 from Vittorio Zecca ---
Still present in 7.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68045
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265
--- Comment #24 from Vittorio Zecca ---
It works on my x86_64-pc-linux-gnu with gfortran 7.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406
--- Comment #5 from Vittorio Zecca ---
With 7.0.1 20170318 compiles links and executes correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50538
--- Comment #3 from Vittorio Zecca ---
Still in 7.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67410
--- Comment #8 from Vittorio Zecca ---
Fixed on 7.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77383
--- Comment #3 from Vittorio Zecca ---
Still in 7.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80100
--- Comment #2 from Vittorio Zecca ---
simplify-rtx.c:2743 is "HOST_WIDE_INT mask = INTVAL (trueop1) << count;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80100
--- Comment #7 from Vittorio Zecca ---
(In reply to Jakub Jelinek from comment #5)
> Author: jakub
> Date: Tue Apr 11 17:21:51 2017
> New Revision: 246851
>
> URL: https://gcc.gnu.org/viewcvs?rev=246851=gcc=rev
> Log:
> PR
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
/* gcc -ftest-coverage */
/* gcc-trunk-246751/gcc/gcov-io.c:351:10: runtime error: null pointer passed as
argument 2, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77486
--- Comment #2 from Vittorio Zecca ---
Still in trunk
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/real.c:2889:25: runtime error:
left shift of negative value -3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77486
Vittorio Zecca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77486
--- Comment #7 from Vittorio Zecca ---
(In reply to Jakub Jelinek from comment #5)
> Even r246252 is more than 2 weeks old. Why not latest trunk?
Because I have no time to download and check every trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77486
--- Comment #4 from Vittorio Zecca ---
This is on trunk level 239276.
Going to check on newer level 246252.
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
Created attachment 41175
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41175=edit
To be compiled with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540
--- Comment #9 from Vittorio Zecca ---
This test case is wrong.
It dereferences thrice a NULL pointer str4.
Unfortunately -fcheck=pointer does not detect this one.
Just added to the CC list the test case author.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540
--- Comment #13 from Vittorio Zecca ---
In C strings are pointers, in Fortran they are not.
So ptr="string" is wrong.
As in the following:
character, pointer :: cptr
cptr="qwerty"
end
Running it I get a SIGSEGV.
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540
--- Comment #11 from Vittorio Zecca ---
Actually, the null pointer str4 is dereferenced four times:
at lines 39, 40, 68, 69.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
// REGRESSION g++ 6.3.0 compiles successfully
// g++ 7.0.1 trunk 246751 emits error message
// In static member function ‘static void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80489
--- Comment #2 from Vittorio Zecca ---
I did not know that one, my C++ knowledge is so limited.
This is a fragment I took from chromium web browser and I was fooled because
it is succesfully compiled by older g++, clang, and Intel icpc.
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
! undefined memcpy writing zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540
Vittorio Zecca changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
/* from pr72858.c */
/*../../gcc-trunk-246751/gcc/gimple-ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80100
--- Comment #1 from Vittorio Zecca ---
Still in trunk 246751.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67486
Vittorio Zecca changed:
What|Removed |Added
Version|5.2.0 |7.0.1
--- Comment #2 from Vittorio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62058
Vittorio Zecca changed:
What|Removed |Added
Version|4.9.1 |7.0.1
--- Comment #5 from Vittorio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66940
Vittorio Zecca changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71074
Vittorio Zecca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66940
--- Comment #5 from Vittorio Zecca ---
Fixed in trunk 246751.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80365
--- Comment #4 from Vittorio Zecca ---
Or you may add
assert(buf);
just before the memcpy library call.
If nbyte==0 then it should be harmless, but undefined.
assert(buf || !nbyte) should catch an error situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80751
--- Comment #3 from Vittorio Zecca ---
(In reply to Dominique d'Humieres from comment #1)
> > This issue is exposed by adding a gcc_assert at trans-stmt.c:455
>
> Could you please be more explicit about what you changed in trans-stmt.c and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80751
--- Comment #4 from Vittorio Zecca ---
I believe I answered your question.
The NULL pointer dereferencing is still in trunk 249961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80751
--- Comment #6 from Vittorio Zecca ---
I am sorry, I went by memory and I swapped two digits, I have trunk 249691,
tomorrow I am downloading the latest trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81302
--- Comment #2 from Vittorio Zecca ---
Maybe is this related?
// trunk 249883
// from pr46269.C
// Segmentation fault
// must be compiled with command g++ -fsanitize=address -fgnu-tm
template class shared_ptr
{
public:
shared_ptr( T * p )
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
/* from volatile-1.c */
/* in trunk 249883 */
/* must be compiled with command gcc -fgnu-tm -fsanitize=address */
__attribute ((transaction_safe))
int f() {
int x
: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
// in trunk 249883
// from devirt-45.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80751
--- Comment #7 from Vittorio Zecca ---
After downloading trunk 249883 I can confirm the bug disappeared.
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
/* from shrink-wrap-separate-0.c */
/* in trunk 249883 */
/* ICE in output_operand_lossage at final.c */
void f(int x)
{
register int r20 asm("20") = x;
}
/*
* In f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79636
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402
Vittorio Zecca changed:
What|Removed |Added
Version|4.8.0 |8.0
--- Comment #6 from Vittorio Zecca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402
--- Comment #8 from Vittorio Zecca ---
1) Sometimes error reports slip through the cracks, it happened to me,
and I found it's good
to remind that the bug is still around. Sometimes it happened the
contrary, the bug silently
disappears
301 - 400 of 564 matches
Mail list logo
