[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'

2015-07-24 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896

--- Comment #8 from Vittorio Zecca zeccav at gmail dot com ---
Created attachment 36052
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36052action=edit
To be compiled with -O2


[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'

2015-07-24 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896

--- Comment #9 from Vittorio Zecca zeccav at gmail dot com ---
At line 2473 of ipa-prop.c I have

if (!ctx.useless_p ())
I changed it into 

if (!ctx.useless_p () || !dst_ctx)

Now the sanitizer runtime error message disappears.
I am attaching another source, gccerr20-bis.C, that used to force
update_jump_functions_after_inlining to reference a NULL pointer dst_ctx


[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'

2015-07-23 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896

--- Comment #6 from Vittorio Zecca zeccav at gmail dot com ---
I just found the same issue at line 2479:
dst_ctx-combine_with (ctx);
dst_ctx is again NULL
Maybe the same patch should be applied here? Namely:
if (!dst_ctx)
{
  vec_safe_grow_cleared
(args-polymorphic_call_contexts,
 count);
  dst_ctx =
ipa_get_ith_polymorhic_call_context (args, i);
}
immediately before?
Do you need a reproducer?
This is compiling pythia software.


[Bug middle-end/64327] ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'

2015-07-14 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327

--- Comment #4 from Vittorio Zecca zeccav at gmail dot com ---
For your convenience I repeat here the reproducer:
/* from gcc file fixopts.c */
/* must be compiled with -O2 */
/*gcc-5.1.0/gcc/rtlanal.c:4911:48: runtime error: shift exponent
4294967295 is too large for 64-bit type 'long unsigned int'*/
/*on source line return nonzero  ((unsigned HOST_WIDE_INT) 1 
(bitwidth - 1))*/
/* because unsigned int bitwidth is zero and bitwitdth-1 is 4294967295
on my x86-64 */
/* I did double check with:
 *   bitwidth = GET_MODE_PRECISION (mode);
 *   gcc_assert(bitwidth);
*/
/* the bug appears compiling fixopts.c crc32.c md5.c and many Fedora
21 kernel files*/
/* 66853 duplicato di 64327 */
int strcmp(const char *s1, const char *s2);
int  fixinc_mode; /* must be outside main for bug to appear */
int main (void)
{
 const char *pz;
 if (strcmp (pz, true) ) fixinc_mode = 0;
}


[Bug c++/66896] New: ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'

2015-07-16 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896

Bug ID: 66896
   Summary: ipa-prop.c:2479 runtime error: member call on null
pointer of type 'struct ipa_polymorphic_call_context'
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

//must be compiled with -O2 , or -O[1] -fdevirtualize
//ipa-prop.c:2479:30: runtime error: member call on null pointer of type
'struct ipa_polymorphic_call_context'
//gcc ipa-prop.c source line dst_ctx-combine_with (ctx);
//because dst_ctx is NULL
//double checked with gcc_assert(dst_ctx);
void f2 (void *);
void f3 ();

struct A
{
  int *a;
  A ();
  ~A () { a3 (); }
  int a1 (int * p) { if (!p) f3 (); f2 (p); }
  void a3 () { if (*a) a1 (a); }
};

struct B : A {~B () { a3 ();}};

struct F {};

struct G : F {B g;};

void foo () {G g;}


[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'

2015-07-17 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896

--- Comment #5 from Vittorio Zecca zeccav at gmail dot com ---
Yes I applied the fix and it now works on all the gcc testsuite.


[Bug middle-end/64327] ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'

2015-07-19 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327

--- Comment #5 from Vittorio Zecca zeccav at gmail dot com ---
In 5.2.0 too.


[Bug fortran/66942] New: trans-expr.c:5701 runtime error: member call on null pointer of type 'struct vec'

2015-07-20 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66942

Bug ID: 66942
   Summary: trans-expr.c:5701 runtime error: member call on null
pointer of type 'struct vec'
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! gcc-5.2.0/gcc/fortran/trans-expr.c:5701:19: runtime error: member call on
null pointer of type 'struct vec'
! gfortran source line retargs-splice (arglist);
! retargs is NULL
! double check with gcc_assert(retargs); immediately before
  call sub 
  END


[Bug rtl-optimization/66940] New: ifcvt.c:1907 signed integer overflow

2015-07-19 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66940

Bug ID: 66940
   Summary: ifcvt.c:1907 signed integer overflow
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* must be compiled with -O */
/* in noce_get_alt_condition */
/*gcc-5.2.0/gcc/ifcvt.c:1907: runtime error: signed integer overflow:
9223372036854775807 + 1 cannot be represented in type 'long int'*/
/* gcc source line if (actual_val == desired_val + 1)*/
/* double check with gcc_assert(desired_val+1desired_val); immediately
before*/
long foo(void)
{
 long ival = 0;
 int cp ;
 if (cp) ival = -1;
 if (ival  0)   return -0x7fffL - 1; 
 return 0x7fffL;
}


[Bug fortran/66942] trans-expr.c:5701 runtime error: member call on null pointer of type 'struct vec'

2015-07-21 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66942

--- Comment #4 from Vittorio Zecca zeccav at gmail dot com ---
Did you put the gcc_assert line in the source?
If you have not a sanitized version you will not see the null pointer
dereferencing
Anyway this is what you asked me: (please not the runtime error:
sanitizer messages)

~/local/gcc-5.2.0-sanitized/bin/gfortran -v -S gfbug120.f
Using built-in specs.
COLLECT_GCC=/home/vitti/local/gcc-5.2.0-sanitized/bin/gfortran
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.2.0/configure
--prefix=/home/vitti/local/gcc-5.2.0-sanitized --disable-bootstrap
--enable-languages=c,c++,fortran --disable-lto
Thread model: posix
gcc version 5.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-S' '-mtune=generic' '-march=x86-64'

/home/vitti/local/gcc-5.2.0-sanitized/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/f951
gfbug120.f -ffixed-form -quiet -dumpbase gfbug120.f -mtune=generic
-march=x86-64 -auxbase gfbug120 -version -o gfbug120.s
-fintrinsic-modules-path
/home/vitti/local/gcc-5.2.0-sanitized/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/finclude
GNU Fortran (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version
3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version
3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
../../gcc-5.2.0/gcc/fortran/trans-expr.c:5701:19: runtime error:
member call on null pointer of type 'struct vec'
../../gcc-5.2.0/gcc/fortran/trans-expr.c:5704:19: runtime error:
member call on null pointer of type 'struct vec'
../../gcc-5.2.0/gcc/fortran/trans-expr.c:5707:19: runtime error:
member call on null pointer of type 'struct vec'
COMPILER_PATH=/home/vitti/local/gcc-5.2.0-sanitized/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/:/home/vitti/local/gcc-5.2.0-sanitized/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/:/home/vitti/local/gcc-5.2.0-sanitized/libexec/gcc/x86_64-unknown-linux-gnu/:/home/vitti/local/gcc-5.2.0-sanitized/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/:/home/vitti/local/gcc-5.2.0-sanitized/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/home/vitti/local/gcc-5.2.0-sanitized/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/:/home/vitti/local/gcc-5.2.0-sanitized/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/lib/../lib64/:/home/vitti/local/gcc-5.2.0-sanitized/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/ipp/../compiler/lib/intel64/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/ipp/lib/intel64/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/compiler/lib/intel64/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/tbb/lib/intel64/gcc4.4/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/mkl/lib/intel64/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/tbb/lib/intel64/gcc4.1/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/daal/lib/intel64_lin/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/daal/../tbb/lib/intel6
 
4_lin/gcc4.4/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/daal/../compiler/lib/intel64_lin/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/tbb/lib/intel64/gcc4.1/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/ipp/../compiler/lib/intel64/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/ipp/lib/intel64/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/compiler/lib/intel64/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/tbb/lib/intel64/gcc4.4/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/mkl/lib/intel64/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/tbb/lib/intel64/gcc4.1/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/daal/lib/intel64_lin/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/daal/../tbb/lib/intel64_lin/gcc4.4/:/home/vitti/intel/compilers_and_libraries_2016.0.069/linux/daal/../compiler/lib/intel64_lin/:/home/vitti/intel/compilers_and_libraries_2016.0.06
 
9/linux/tbb/lib/intel64/gcc4.1/:/home/vitti/local/gcc-5.2.0-sanitized/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/lib/:/home/vitti/local/gcc-5.2.0-sanitized/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-S' '-mtune=generic' '-march=x86-64'


[Bug fortran/66942] trans-expr.c:5701 runtime error: member call on null pointer of type 'struct vec'

2015-07-21 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66942

--- Comment #2 from Vittorio Zecca zeccav at gmail dot com ---
1) No explicit options, just the default ones, -S will suffice.
2) Sorry, I did not specify the target is x86-64, but I got the same with -m32
3) sub is not needed, the code should just be compiled to exhibit the bug

I have a sanitized (-fsanitize=address -fsanitize=undefined) version of
gfortran.
In the comments I put the output message from the sanitizer during compilation.
What happens is that the pointer retargs is NULL. I believe this is bad.
This fragment of code from gfc_conv_procedure_call is thus erroneous
because it dereferences a null pointer.
I did double check it by putting
gcc_assert(retargs);
immediately before its dereferencing. I then got an ICE at that line.


[Bug c/66853] New: sanitized gcc shows bug in rtlanal.c:4911 shift exponent too large because bitwitdth==0

2015-07-13 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66853

Bug ID: 66853
   Summary: sanitized gcc shows bug in rtlanal.c:4911 shift
exponent too large because bitwitdth==0
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

This appears to be a duplicate for 64327
Sanitized version of gcc 5.1.0 shows a bug in the following

/* from gcc file fixopts.c */
/* must be compiled with -O2 */
/*gcc-5.1.0/gcc/rtlanal.c:4911:48: runtime error: shift exponent 4294967295 is
too large for 64-bit type 'long unsigned int'*/
/*on source line return nonzero  ((unsigned HOST_WIDE_INT) 1  (bitwidth -
1))*/
/* because unsigned int bitwidth is zero and bitwitdth-1 is 4294967295 on my
x86-64 */
/* I did double check with:
 *   bitwidth = GET_MODE_PRECISION (mode);
 *   gcc_assert(bitwidth);
*/
/* the bug appears compiling fixopts.c crc32.c md5.c and many Fedora 21 kernel
files*/
int strcmp(const char *s1, const char *s2);
int  fixinc_mode; /* must be outside main for bug to appear */
int main (void)
{
 const char *pz;
 if (strcmp (pz, true) ) fixinc_mode = 0;
}


[Bug middle-end/64327] ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'

2015-07-13 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327

Vittorio Zecca zeccav at gmail dot com changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #2 from Vittorio Zecca zeccav at gmail dot com ---
Please see bug 66853, it appears to duplicate this one.
With a small reproducer included.


[Bug fortran/67498] interface.c sanitizer runtime error: load of value 1818451807, which is not a valid value for type 'expr_t'

2015-11-10 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67498

--- Comment #2 from Vittorio Zecca  ---
Sorry, I am traveling now, I'll look at it when I am back home, end of
March 2016?
Maybe you better close it, I think at that time gcc 6 will be available.

[Bug fortran/67496] trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'

2015-11-10 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496

--- Comment #2 from Vittorio Zecca  ---
I am traveling now, I cannot check the patch

[Bug fortran/67497] data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

2015-11-05 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497

--- Comment #2 from Vittorio Zecca  ---
Traveling now, I cannot check it.

[Bug libgcc/67379] New: libgcc2.c negation of -2147483648 cannot be represented in type 'int'

2015-08-28 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67379

Bug ID: 67379
   Summary: libgcc2.c negation of -2147483648 cannot be
represented in type 'int'
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

In libgcc2.c:1842

int m;
unsigned int n = m  0 ? -m : m;

when m==-2147483648

I get the following message from the sanitizer

/home/vitti/gcc-5.2.0/libgcc/libgcc2.c:1842:31: runtime error: negation of
-2147483648 cannot be represented in type 'int'; cast to an unsigned type to
negate this value to itself

I suggest changing the line to the correct version

unsigned int n = m  0 ? - (unsigned int) m : m;

to avoid undefinite behaviour

This is running the gfortran testsuite file integer_exponentiation_1.f90


[Bug testsuite/67359] New: struct-layout-1_generate.c undefined behaviour

2015-08-26 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67359

Bug ID: 67359
   Summary: struct-layout-1_generate.c undefined behaviour
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Running struct-layout-1_generate.c the sanitized version of gcc finds two
undefined statements:

At line 1081

m = (1ULL  e-len) - 1;

I get
/home/vitti/gcc-5.2.0/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c:1081:13:
runtime error: shift exponent 64 is too large for 64-bit type 'long long
unsigned int'

It seems that e-len == 64 and the shift is too large for 1ULL

At line 1901 

 e[n].type  complex_attrib_array_types[NAATYPES2])

should be

 e[n].type  complex_attrib_array_types[NCAATYPES2]) 

to avoid

/home/vitti/gcc-5.2.0/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c:1901:51:
runtime error: index 83 out of bounds for type 'types [54]'


[Bug fortran/50069] FORALL fails on a character array

2015-08-31 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069

--- Comment #5 from Vittorio Zecca  ---
Still on gfortran 5.2.0


[Bug fortran/50537] explicit interface required (r178939)

2015-08-31 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50537

Vittorio Zecca  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Vittorio Zecca  ---
I found it fixed in 5.2.0


[Bug fortran/50539] Internal error gfc_match_entry(): Bad state (r178939)

2015-08-31 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50539

Vittorio Zecca  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Vittorio Zecca  ---
I found it fixed in 5.2.0


[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)

2015-08-31 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555

Vittorio Zecca  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Vittorio Zecca  ---
I found it fixed in 5.2.0 and maybe already in 4.8.2


[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

2015-08-31 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070

--- Comment #17 from Vittorio Zecca  ---
I found it fixed in 5.2.0


[Bug c/67410] New: c/c-typeck.c references out of bounds array

2015-08-31 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67410

Bug ID: 67410
   Summary: c/c-typeck.c references out of bounds array
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/*sanitizer message*/
/*gcc-5.2.0/gcc/c/c-typeck.c:8266:42: runtime error: load of address
0x7ffc8682b570 with insufficient space for an object of type 'long int'*/
/*gcc-5.2.0/gcc/c/c-typeck.c:8266:42: runtime error: store to address
0x7ffc8682b570 with insufficient space for an object of type 'long int'*/
/*offending source line "val[bitpos % HOST_BITS_PER_WIDE_INT]"
 * val is dimensioned [2] but bitpos % HOST_BITS_PER_WIDE_INT == 8 
 * double check with "gcc_assert(bitpos % HOST_BITS_PER_WIDE_INT<2);"
 * Target: x86_64-unknown-linux-gnu */
struct {
  __CHAR16_TYPE__ S[1];
} a[] = {   u"f"  , [0].S[0] = u'x' };


[Bug c++/67409] New: tree-cfg.c dereferences a NULL pointer

2015-08-31 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67409

Bug ID: 67409
   Summary: tree-cfg.c dereferences a NULL pointer
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

//g++ 5.2.0 sanitizer detects dereferencing a NULL pointer 
//gcc-5.2.0/gcc/tree-cfg.c:1342:38: runtime error: member access within null
pointer of type 'struct basic_block_def'
//must be compiled with -fpermissive
//pointer bb is null
//source line "tree main_label = label_for_bb[bb->index].label;"
//double check with "gcc_assert(bb);" immediately before
//Target: x86_64-unknown-linux-gnu
void f()
try
  {
goto l2;
  } catch (...)
  {
  l2:;
  }


[Bug libgcc/67379] libgcc2.c negation of -2147483648 cannot be represented in type 'int'

2015-09-07 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67379

--- Comment #2 from Vittorio Zecca  ---
There is a similar bug in gcc/function.c:254

unsigned HOST_WIDE_INT size = FRAME_GROWS_DOWNWARD ? -offset : offset;

when offset == -9223372036854775808

Should I open a new bug?


[Bug ada/67473] New: init.c undefined behaviour referencing misaligned pointer

2015-09-06 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67473

Bug ID: 67473
   Summary: init.c undefined behaviour referencing misaligned
pointer
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

While running on the testsuite a sanitized version of the ada compiler
I got the following

RUN c52103x

,.,. C52103X ACATS 2.5 15-09-06 20:52:03^M
 C52103X CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS,^M
THE LENGTHS MUST MATCH; ALSO CHECK WHETHER^M
CONSTRAINT_ERROR OR STORAGE_ERROR ARE RAISED FOR LARGE^M
ARRAYS.^M
   - C52103X NO CONSTRAINT_ERROR FOR TYPE WITH 'LENGTH = INTEGER'LAST + ^M
3.^M
init.c:492:12: runtime error: load of misaligned address 0x0041871f for
type 'long long unsigned int', which requires 8 byte alignment
0x0041871f: note: pointer points here
 00 10 00 00 48  83 0c 24 00 48 39 cc 75  ef 48 29 d6 48 29 f4 48  83 0c 24 00
48 81 c4 20  10 00 00
^ ^
   - C52103X STORAGE_ERROR RAISED WHEN DECLARING TWO PACKED BOOLEAN
ARRAYS WITH INTEGER'LAST + 3 COMPONENTS.
 C52103X PASSED .
PASS:   c52103x

gcc/ada/init.c:492 is

&& ((*pc & 0xffLL) == 0x00240c8348LL

so it seems that unsigned long *pc is misaligned not being a multiple of eight

I have x86-64


[Bug tree-optimization/67486] New: ira-color.c sanitizer detects signed integer overflow

2015-09-07 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67486

Bug ID: 67486
   Summary: ira-color.c sanitizer detects signed integer overflow
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Created attachment 36302
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36302=edit
C file to compile with g++ -Os -fPIC -std=gnu++11

// g++ -Os -fPIC -std=gnu++11
// sanitizer error message 
// gcc/ira-color.c:1816:41: runtime error: signed integer overflow: 2097195682
- -131071000 cannot be represented in type 'int [33]'
// offending statement "full_costs[j] -= conflict_costs[k];"
// Target: x86_64-unknown-linux-gnu
// COLLECT_GCC_OPTIONS='-Os' '-fPIC' '-std=gnu++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'

The source is pretty large I am attaching it


[Bug c++/67484] New: options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

2015-09-07 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67484

Bug ID: 67484
   Summary: options-save.c sanitizer asan detects freed storage
referenced  heap-use-after-free
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

//g++ references freed storage
//sanitizer message: heap-use-after-free
//referenced at options-save.c:3556 "|| strcmp (ptr1->x_ix86_arch_string,
ptr2->x_ix86_arch_string)))" 
//ptr1->x_ix86_arch_string was freed at gcc/config/i386/i386.c:5020 "free
(option_strings[i]);"
//to make happy the sanitizer I commented out the for loop in i386.c lines
5019-5020
 Target: x86_64-unknown-linux-gnu
int fum () __attribute__ ((target("default")));
int fum () __attribute__ ((target("arch=core2")));
int j = fum();


[Bug c++/67483] New: combine.c sanitizer detects undefined negative left shift

2015-09-07 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67483

Bug ID: 67483
   Summary: combine.c sanitizer detects undefined negative left
shift
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

//g++ -ftracer -O2
//g++ 5.2.0 undefined left shift
//../../gcc-5.2.0/gcc/combine.c:7696:40: runtime error: shift exponent -1 is
negative
//offending line "& unsigned HOST_WIDE_INT) 1 << count)) - 1)) == 0"
//in extract_left_shift
// count == -1 thus negative shift exponent
// Target: x86_64-unknown-linux-gnu
struct double_int
{
 double_int sext (unsigned prec) const;
 static double_int mask (unsigned prec);
 unsigned low;/*unsigned long int low provokes same bug at combine.c:12078*/
};

double_int
double_int::mask (unsigned prec)
{
  double_int mask;
  if (prec <= 64) mask.low = prec ? ((unsigned long) 2 << (prec - 1)) - 1 : 0;
  return mask;
}

double_int
double_int::sext (unsigned prec) const
{
  const double_int  = *this;
  double_int mask = double_int::mask (prec);
  double_int r; 
  unsigned long snum;
  if (prec <= 64) snum = cst.low;
  if (((snum >> (prec - 1)) & 1) == 1)
{
 r.low = cst.low ;
}
  else
{
 r.low = mask.low;
}
  return r;
}


[Bug middle-end/67485] New: expmed.c sanitizer detects overflow

2015-09-07 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67485

Bug ID: 67485
   Summary: expmed.c sanitizer detects overflow
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* gcc sanitizer runtime error message*/
/* gcc/expmed.c:3026:42: runtime error: signed integer overflow:
-9223372036854775808 - 1 cannot be represented in type 'long int [3]*/
/* source line "val_so_far -= (HOST_WIDE_INT) 1 << log;" */
/* val_so_far == -9223372036854775808 */
/* log == 0 */
/* Target: x86_64-unknown-linux-gnu */
/* COLLECT_GCC_OPTIONS='-mtune=generic' '-march=x86-64' */
#define INTTYPE_SIGNED(t) (! ((t) 0 < (t) -1))
#define INTTYPE_MINIMUM(t) ((t) (INTTYPE_SIGNED (t) \
 ? ~ (t) 0 << (sizeof (t) * 8 - 1) : (t) 0))
#define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t)))
typedef long int int64_t;
int64_t
to_int ()
{
 int64_t sign;
 return sign * INTTYPE_MAXIMUM (int64_t);
}


[Bug c/67482] New: dwarf2out.c sanitizer detects undefined behaviour negation of -9223372036854775808

2015-09-07 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67482

Bug ID: 67482
   Summary: dwarf2out.c sanitizer detects undefined behaviour
negation of -9223372036854775808
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* must be compiled with -O2 -g */
/* sanitizer runtime error message
 * gcc-5.2.0/gcc/dwarf2out.c:1532:45: runtime error: negation of
-9223372036854775808 cannot be represented in type 'long int [3]'; cast to an
unsigned type to negate this value to itself */
/* offending statement "loc->dw_loc_next = int_loc_descriptor (-offset);" */
/*Target: x86_64-unknown-linux-gnu*/
/*COLLECT_GCC_OPTIONS='-O2' '-g' '-mtune=generic' '-march=x86-64'*/
int v;
__attribute__((noinline)) void
bar (void)
{
 v++;
}
__attribute__((noinline)) unsigned long long t134_2add (unsigned long long y)
{
 signed long long x = ((-0x7fffLL - 1));
 unsigned long long r;
 if (__builtin_add_overflow (x, y, )) bar ();
 return r;
}


[Bug ada/67494] New: xsinfo sanitizer detects overlapping strings in assignment statement

2015-09-08 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67494

Bug ID: 67494
   Summary: xsinfo sanitizer detects overlapping strings in
assignment statement
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

The sanitizer detects overlapping strings in the assignemnt statement 

DR.Data (1 .. Source'Length) := Source;

in a-strunb.adb:1456.

The following is the sanitizer snapshot during gcc build

(cd ada/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo sinfo.h )

Check for field name consistency
 OK

Check for function consistency
 OK

Check for missing functions
 OK

Check for set procedure consistency
 OK

Check for missing set procedures
 OK

Check pragma Inlines are all for existing subprograms
=
==7358==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges
[0x6041329c,0x604132aa) and [0x604132a0, 0x604132ae) overlap
#0 0x2adcc5f71762 in __asan_memcpy
../../../../gcc-5.2.0/libsanitizer/asan/asan_interceptors.cc:365
#1 0x42bed0 in ada__strings__unbounded__set_unbounded_string
/home/vitti/gcc-5.2.0-obj/gcc/ada/rts/a-strunb.adb:1456
#2 0x442c2a in gnat__spitbol__patterns__xmatch
/home/vitti/gcc-5.2.0-obj/gcc/ada/rts/g-spipat.adb:4066
#3 0x4435ba in gnat__spitbol__patterns__match
/home/vitti/gcc-5.2.0-obj/gcc/ada/rts/g-spipat.adb:2806
#4 0x40ae6e in _ada_csinfo
(/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/ada/bldtools/sinfo/xsinfo+0x40ae6e)
#5 0x41ba7f in _ada_xsinfo
(/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/ada/bldtools/sinfo/xsinfo+0x41ba7f)
#6 0x402b05 in main
(/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/ada/bldtools/sinfo/xsinfo+0x402b05)
#7 0x390da1ffdf in __libc_start_main (/lib64/libc.so.6+0x390da1ffdf)
#8 0x4025f3 
(/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/ada/bldtools/sinfo/xsinfo+0x4025f3)

0x6041329c is located 12 bytes inside of 48-byte region
[0x60413290,0x604132c0)
allocated by thread T0 here:
#0 0x2adcc5f7d509 in __interceptor_malloc
../../../../gcc-5.2.0/libsanitizer/asan/asan_malloc_linux.cc:38
#1 0x458a10 in __gnat_malloc
/home/vitti/gcc-5.2.0-obj/gcc/ada/rts/s-memory.adb:92
#2 0x6066157f  ()

0x604132a0 is located 16 bytes inside of 48-byte region
[0x60413290,0x604132c0)
allocated by thread T0 here:
#0 0x2adcc5f7d509 in __interceptor_malloc
../../../../gcc-5.2.0/libsanitizer/asan/asan_malloc_linux.cc:38
#1 0x458a10 in __gnat_malloc
/home/vitti/gcc-5.2.0-obj/gcc/ada/rts/s-memory.adb:92
#2 0x6066157f  ()

SUMMARY: AddressSanitizer: memcpy-param-overlap
../../../../gcc-5.2.0/libsanitizer/asan/asan_interceptors.cc:365 __asan_memcpy
==7358==ABORTING
/home/vitti/gcc-5.2.0/gcc/ada/Make-generated.in:42: recipe for target
'ada/sinfo.h' failed


[Bug fortran/67497] New: data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

2015-09-08 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497

Bug ID: 67497
   Summary: data.c sanitizer runtime error: null pointer passed as
argument 2, which is declared to never be null
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

!gcc-5.2.0/gcc/fortran/data.c:181:32: runtime error: null pointer passed as
argument 2, which is declared to never be null
! source line "memcpy ([start], rvalue->value.character.string, len *
sizeof (gfc_char_t));"
! double check with "gcc_assert(rvalue->value.character.string)" immediately
before
! esay fix "if(len) memcpy ([start], rvalue->value.character.string, len *
! sizeof (gfc_char_t));"
!Target: x86_64-unknown-linux-gnu
  CHARACTER, POINTER :: PTR
  DATA  PTR / NULL() /
  end


[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)

2015-09-01 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555

--- Comment #4 from Vittorio Zecca  ---
Sorry, you are right, the compiler should emit an error message
instead it wrongly
accepts the code. I was confused, this time the right behaviour is to
emit an error message.


[Bug fortran/50541] gfortran should not accept a pointer as a generic-name (r178939)

2015-09-02 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50541

--- Comment #5 from Vittorio Zecca  ---
Bug still there in 5.2.0


[Bug fortran/58233] null pointer cm in gfc_conv_structure at fortran/trans-expr.c:6132

2015-09-02 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58233

--- Comment #4 from Vittorio Zecca  ---
Still there on 5.2.0


[Bug fortran/50410] [4.9/5/6 Regression] ICE in record_reference

2015-09-02 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

--- Comment #19 from Vittorio Zecca  ---
ICE still there in 5.2.0


[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

2015-09-02 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402

--- Comment #2 from Vittorio Zecca  ---
! gfortran ICE in gfc_conv_expr_descriptor at fortran/trans-array.c
  interface
   function f()
   pointer f
   end
  end interface
  type t
  real,pointer ::  p(:)
  end type
  type(t) u
  u=t(f())
  end


gfortran gfbug43.f
gfbug43.f:12:0:

   u=t(f())
 1
internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:6534
0x6b5b60 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc-5.2.0/gcc/fortran/trans-array.c:6534
0x6d513b gfc_trans_subcomponent_assign
../../gcc-5.2.0/gcc/fortran/trans-expr.c:6802
0x6d4b3b gfc_trans_structure_assign
../../gcc-5.2.0/gcc/fortran/trans-expr.c:7036
0x6d6084 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-5.2.0/gcc/fortran/trans-expr.c:7065
0x6d7060 gfc_trans_assignment_1
../../gcc-5.2.0/gcc/fortran/trans-expr.c:8947
0x6a4545 trans_code
../../gcc-5.2.0/gcc/fortran/trans.c:1665
0x6c3e83 gfc_generate_function_code(gfc_namespace*)
../../gcc-5.2.0/gcc/fortran/trans-decl.c:5841
0x662270 translate_all_program_units
../../gcc-5.2.0/gcc/fortran/parse.c:5340
0x662270 gfc_parse_file()
../../gcc-5.2.0/gcc/fortran/parse.c:5537
0x6a1695 gfc_be_parse_file
../../gcc-5.2.0/gcc/fortran/f95-lang.c:229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


[Bug fortran/50406] ld undefined reference to __MOD_str

2015-09-02 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406

--- Comment #2 from Vittorio Zecca  ---
! gfortran produces weird ld message undefined reference to `___MOD_str'
  module m
  contains
   function fun(i)
character(2),  PARAMETER:: str(1) = (/'SD'/)  
character(len_trim(str(i))) :: fun 
fun = str(i)
   end function
  end
  use m
  print *,fun(1) ! should display "SD"
  end

gfortran gfbug48.f
/tmp/ccpTCSOy.o: In function `MAIN__':
gfbug48.f:(.text+0x132): undefined reference to `___MOD_str'
collect2: error: ld returned 1 exit status


[Bug other/67446] New: libiberty sha1.c:324 sanitizer runtime error: load of misaligned address 0x62f00011847e for type 'const sha1_uint32', which requires 4 byte alignment

2015-09-04 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67446

Bug ID: 67446
   Summary: libiberty sha1.c:324 sanitizer runtime error: load of
misaligned address 0x62f00011847e for type 'const
sha1_uint32', which requires 4 byte alignment
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

While building the Fedora 21 kernel 4.1.6-100 with a sanitized version of ld
I got the following sanitizer messages (sha1.c compiled with 
gcc -fsanitize=undefined)
This is sha1.c in libiberty

sha1.c:324:11: runtime error: load of misaligned address 0x62f00011847e for
type 'const sha1_uint32', which requires 4 byte alignment
0x62f00011847e: note: pointer points here
 84 00 00 00 00 00  55 be 1a 00 00 00 48 c7  c7 60 7f c1 82 48 89 e5  e8 7b 03
ed fe 5d c3 66  0f 1f
 ^ 
sha1.c:324:11: runtime error: load of misaligned address 0x62f00011847e for
type 'const sha1_uint32', which requires 4 byte alignment
0x62f00011847e: note: pointer points here
 84 00 00 00 00 00  55 be 1a 00 00 00 48 c7  c7 60 7f c1 82 48 89 e5  e8 7b 03
ed fe 5d c3 66  0f 1f
 ^ 
sha1.c:324:11: runtime error: load of misaligned address 0x62f00011847e for
type 'const sha1_uint32', which requires 4 byte alignment
0x62f00011847e: note: pointer points here
 84 00 00 00 00 00  55 be 1a 00 00 00 48 c7  c7 60 7f c1 82 48 89 e5  e8 7b 03
ed fe 5d c3 66  0f 1f
 ^ 
sha1.c:324:11: runtime error: load of misaligned address 0x62f00011847e for
type 'const sha1_uint32', which requires 4 byte alignment
0x62f00011847e: note: pointer points here
 84 00 00 00 00 00  55 be 1a 00 00 00 48 c7  c7 60 7f c1 82 48 89 e5  e8 7b 03
ed fe 5d c3 66  0f 1f

sha1.c:324 is

x[t] = SWAP (*words);

so it seems that words is not a multiple of four, but it should point to type
sha1_uint32 which is four bytes aligned.
This is on x86-64 building "LD  init/built-in.o" and the command is

ld -m elf_x86_64 --build-id -X -o .tmp_vmlinux1 -T
./arch/x86/kernel/vmlinux.lds arch/x86/kernel/head_64.o
arch/x86/kernel/head64.o arch/x86/kernel/head.o init/built-in.o --start-group
usr/built-in.o arch/x86/built-in.o kernel/built-in.o mm/built-in.o
fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o
block/built-in.o lib/lib.a arch/x86/lib/lib.a lib/built-in.o
arch/x86/lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o
arch/x86/pci/built-in.o arch/x86/power/built-in.o arch/x86/video/built-in.o
net/built-in.o --end-group


[Bug fortran/67496] New: trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'

2015-09-08 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496

Bug ID: 67496
   Summary: trans-array.c sanitizer runtime error: load of value
124, which is not a valid value for type 'bool'
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

!gcc-5.2.0/gcc/fortran/trans-array.c:2223:27: runtime error: load of value 124,
which is not a valid value for type 'bool'
! source line "typespec_chararray_ctor = (expr->ts.u.cl &&
expr->ts.u.cl->length_from_typespec);"
!Target: x86_64-unknown-linux-gnu
  type :: a
  end type a
  type :: b
  type (a) :: j(1)
  end type b
  type(a) :: x
  type(b) :: y
  y = b((/x/))
  end


[Bug fortran/67498] New: interface.c sanitizer runtime error: load of value 1818451807, which is not a valid value for type 'expr_t'

2015-09-08 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67498

Bug ID: 67498
   Summary: interface.c sanitizer runtime error: load of value
1818451807, which is not a valid value for type
'expr_t'
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

!gcc-5.2.0/gcc/fortran/interface.c:2705:33: runtime error: load of value
1818451807, which is not a valid value for type 'expr_t'
! source line "&& f->sym->ts.u.cl->length->expr_type == EXPR_CONSTANT"
! Target: x86_64-unknown-linux-gnu
  contains

  subroutine FWRite(S)
   class(*) :: S
  end subroutine

  subroutine IO_OutputMargeStats()
   character tag
   call FWrite(tag)
  end subroutine

  end


[Bug libfortran/67535] write.c sanitizer detects null pointer passed to memcpy

2015-09-10 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535

--- Comment #3 from Vittorio Zecca  ---
(In reply to kargl from comment #1)

> What happens to performance?  Simply making changes to
> make sanitizer happy seems rather questionable.  It's clear
> from context that if base_name == NULL, then base_name_len
> == 0, and the memcpy should be a NOP.

How costly is that NOP compared to if(base_name_len)?

How costly is to let go an undefined behaviour?


[Bug libfortran/67540] New: string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2015-09-10 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

Bug ID: 67540
   Summary: string_intrinsics_inc.c sanitizer detects null pointer
passed to memcpy
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

During make check-fortran in gcc build the sanitizer complains
that a null pointer is passed to memcpy in string_intrinsics_inc.c:89

res = MEMCMP (s1, s2, ((len1 < len2) ? len1 : len2));

string_intrinsics_inc.c:90:7: runtime error: null pointer passed as argument 1,
which is declared to never be null

because s1 == NULL

My fix is

int lvz=len1 < len2 ? len1 : len2;
if(lvz) res = MEMCMP (s1, s2, lvz); else res=0;


[Bug objc/67516] New: class.c left shift of 1271241028 by 4 places cannot be represented in type 'int'

2015-09-09 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67516

Bug ID: 67516
   Summary: class.c left shift of 1271241028 by 4 places cannot be
represented in type 'int'
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Running 'make check' on objc I get many sanitizer messages as in

/home/vitti/gcc-5.2.0/libobjc/class.c:186:3: runtime error: left shift of
1271241028 by 4 places cannot be represented in type 'int'

and

/home/vitti/gcc-5.2.0/libobjc/class.c:215:3: runtime error: left shift of
1271241028 by 4 places cannot be represented in type 'int'

The target instruction is 

CLASS_TABLE_HASH (length, hash, class_name);

The macro contains 

 HASH = (HASH << 4) ^ (HASH >> 28) ^ CLASS_NAME[INDEX];

which probably provokes the sanitizer massages. 

Target: x86_64-unknown-linux-gnu


[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2015-09-12 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #3 from Vittorio Zecca  ---
I believe the test case is erroneous. NULL pointers are dereferenced
in subroutines
source_check and source_check4:

if(str4 == '12a56b78') call abort()

and

if(str4 == 4_'12a56b78') call abort()

are dereferencing the null pointer str4 and this goes down to
string_intrinsics_inc.c

There are more test cases with lvz==0.
If you had a sanitized version of libgfortran you could check them by yourself.


[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2015-09-13 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #5 from Vittorio Zecca  ---
On the same line
CFLAGS="-fsanitize=undefined -Og -g -fno-omit-frame-pointer"
CXXFLAGS=$CFLAGS LDFLAGS="-lubsan -ldl -lpthread"
/home/vitti/gcc-5.2.0/configure
--prefix=/home/vitti/1tb/local/gcc-5.2.0-undefined --disable-bootstrap
--enable-languages=c,ada,c++,fortran,go,lto,objc,obj-c++ --no-create
--no-recursion : (reconfigured) /home/vitti/gcc-5.2.0/configure
--prefix=/home/vitti/1tb/local/gcc-5.2.0-undefined --disable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto

Then "make"

but it is not that easy, I had to tweak and modify some configure
files to keep going and libtool as well. But I made it. I even got a
-fsanitize=address version working.

BTW can you confirm that the test case is erroneous
because it dereferences a NULL pointer?
Is that intended?


[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2015-09-13 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #7 from Vittorio Zecca  ---
str4 used to point to str so the "logic" seems to check that str4 does
not follow any more str.
But the test is erroneous.


[Bug fortran/67567] resolve.c: gfc_error called with iface->module == NULL

2015-09-14 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67567

--- Comment #2 from Vittorio Zecca  ---
Unfortunately I do not master gdb and gcc internals enough for that.
The check costs two instructions on my x86-64.


[Bug libfortran/67535] write.c sanitizer detects null pointer passed to memcpy

2015-09-11 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535

--- Comment #6 from Vittorio Zecca  ---
The cost of adding "if(base_name_len)" is two x86-64 machine instructions

cmpl$0, -20(%rbp)
je  .L2

Six instructions follow then

call memcpy

which is not exactly a NOP even with base_name_len==0

In my opinion two machine instructions to avoid a useless and undefined memcpy
are a bargain.

It is not undefined behaviour to pass a NULL pointer to an arbitrary function,
but it is undefined to pass it to memcpy.

And it seems to me that after
memcpy(dest,src,len)

the statement "if(src)" is always TRUE because the optimizer assumes src!=NULL

The following is from https://gcc.gnu.org/gcc-4.9/porting_to.html

Null pointer checks may be optimized away more aggressively

GCC might now optimize away the null pointer check in code like:


  int copy (int* dest, int* src, size_t nbytes) {
memmove (dest, src, nbytes);
if (src != NULL)
  return *src;
return 0;
  }

The pointers passed to memmove (and similar functions in ) must be
non-null even when nbytes==0, so GCC can use that information to remove the
check after the memmove call. Calling copy(p, NULL, 0) can therefore deference
a null pointer and crash.

The example above needs to be fixed to avoid the invalid memmove call, for
example:


if (nbytes != 0)
  memmove (dest, src, nbytes);

This optimization can also affect implicit null pointer checks such as the one
done by the C++ runtime for the delete[] operator.


[Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

2015-09-14 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67484

Vittorio Zecca  changed:

   What|Removed |Added

Version|5.2.0   |6.0

--- Comment #1 from Vittorio Zecca  ---
Same bug on the trunk.
The following is the sanitizer output:

~/1tb/vitti/local/gcc-trunk-sanitized/bin/g++ -S gccerr26.C
=
==25114==ERROR: AddressSanitizer: heap-use-after-free on address 0x60205850
at pc 0x2b7d193c94a5 bp 0x7ffe44d41860 sp 0x7ffe44d41010
READ of size 1 at 0x60205850 thread T0
#0 0x2b7d193c94a4 in __interceptor_strcmp
../../../../gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:178
#1 0x170f87f in cl_target_option_eq(cl_target_option const*,
cl_target_option const*) /home/vitti/test/gcc-sanitized/gcc/options-save.c:3491
#2 0x202ee44 in cl_option_hasher::equal(tree_node*, tree_node*)
../../gcc/gcc/tree.c:11866
#3 0x204559b in hash_table::find_slot_with_hash(tree_node* const&, unsigned int,
insert_option) ../../gcc/gcc/hash-table.h:838
#4 0x2042095 in hash_table::find_slot(tree_node* const&, insert_option)
../../gcc/gcc/hash-table.h:408
#5 0x202efc4 in build_target_option_node(gcc_options*)
../../gcc/gcc/tree.c:11914
#6 0x21218b0 in ix86_valid_target_attribute_tree(tree_node*, gcc_options*,
gcc_options*) ../../gcc/gcc/config/i386/i386.c:5110
#7 0x21af79c in get_builtin_code_for_version
../../gcc/gcc/config/i386/i386.c:34678
#8 0x21b00b2 in ix86_compare_version_priority
../../gcc/gcc/config/i386/i386.c:34846
#9 0x780078 in joust ../../gcc/gcc/cp/call.c:9234
#10 0x781a8e in tourney ../../gcc/gcc/cp/call.c:9361
#11 0x7544bf in perform_overload_resolution ../../gcc/gcc/cp/call.c:4016
#12 0x754942 in build_new_function_call(tree_node*, vec**, bool, int) ../../gcc/gcc/cp/call.c:4089
#13 0xb66c40 in finish_call_expr(tree_node*, vec**, bool, bool, int) ../../gcc/gcc/cp/semantics.c:2391
#14 0xa0b32a in cp_parser_postfix_expression ../../gcc/gcc/cp/parser.c:6422
#15 0xa0fec8 in cp_parser_unary_expression ../../gcc/gcc/cp/parser.c:7486
#16 0xa11a49 in cp_parser_cast_expression ../../gcc/gcc/cp/parser.c:8122
#17 0xa11bb4 in cp_parser_binary_expression ../../gcc/gcc/cp/parser.c:8223
#18 0xa13696 in cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8481
#19 0xa14197 in cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:8727
#20 0xa42158 in cp_parser_initializer_clause
../../gcc/gcc/cp/parser.c:19925
#21 0xa41e9b in cp_parser_initializer ../../gcc/gcc/cp/parser.c:19866
#22 0xa3813e in cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:17793
#23 0xa215bc in cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11681
#24 0xa210aa in cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:11555
#25 0xa208bb in cp_parser_declaration ../../gcc/gcc/cp/parser.c:11452
#26 0xa1fe63 in cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11334
#27 0xa0181d in cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4154
#28 0xa843f8 in c_parse_file() ../../gcc/gcc/cp/parser.c:34273
#29 0xdb2e46 in c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1058
#30 0x19b8f12 in compile_file ../../gcc/gcc/toplev.c:544
#31 0x19bf8f0 in do_compile ../../gcc/gcc/toplev.c:2034
#32 0x19bff60 in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2141
#33 0x2d332c0 in main ../../gcc/gcc/main.c:39
#34 0x390da1ffdf in __libc_start_main (/lib64/libc.so.6+0x390da1ffdf)
#35 0x737768 
(/home/vitti/1tb/vitti/local/gcc-trunk-sanitized/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/cc1plus+0x737768)

0x60205850 is located 0 bytes inside of 6-byte region
[0x60205850,0x60205856)
freed by thread T0 here:
#0 0x2b7d194171dd in __interceptor_free
../../../../gcc-5.2.0/libsanitizer/asan/asan_malloc_linux.cc:28
#1 0x21219df in ix86_valid_target_attribute_tree(tree_node*, gcc_options*,
gcc_options*) ../../gcc/gcc/config/i386/i386.c:5118
#2 0x2121e77 in ix86_valid_target_attribute_p
../../gcc/gcc/config/i386/i386.c:5166
#3 0xd5e237 in handle_target_attribute
../../gcc/gcc/c-family/c-common.c:9777
#4 0xce2e48 in decl_attributes(tree_node**, tree_node*, int)
../../gcc/gcc/attribs.c:557
#5 0x9a5e3a in cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/gcc/cp/decl2.c:1493
#6 0x7d65a7 in grokfndecl ../../gcc/gcc/cp/decl.c:8100
#7 0x7ea399 in grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**) ../../gcc/gcc/cp/decl.c:11265
#8 0x7bcb26 in start_decl(cp_declarator const*, cp_decl_specifier_seq*,
int, tree_node*, tree_node*, tree_node**) ../../gcc/gcc/cp/decl.c:4740
#9 0xa37c1f in 

[Bug testsuite/67583] New: libstdc++-v3/testsuite/27_io/basic_stringbuf/seekoff/char/1.cc:92 erroneous call to sputn

2015-09-15 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67583

Bug ID: 67583
   Summary: libstdc++-v3/testsuite/27_io/basic_stringbuf/seekoff/c
har/1.cc:92 erroneous call to sputn
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

libstdc++-v3/testsuite/27_io/basic_stringbuf/seekoff/char/1.cc:92

strmsz_2 = strb_01.sputn(" ravi shankar meets carlos santana in LoHa", 90);

is erroneous, in my opinion, because it tries to transfer 90 bytes
while the string contains 43 characters, including null.


[Bug fortran/67588] module.c heap use after free

2015-09-17 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588

--- Comment #5 from Vittorio Zecca  ---
I believe that

use_list = module_list;

at line module.c:805 is useless and can be expunged.


[Bug fortran/67588] module.c heap use after free

2015-09-17 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588

--- Comment #7 from Vittorio Zecca  ---
use_list is local to the function gfc_match_submodule and it is already
reinitialized in the for statement at line 806.
So there is a duplication.
On return at line 812 it is then lost.
Maybe optimization would expunge it anyway.


[Bug middle-end/64920] bootstrap-ubsan [build/gengtype -r gtype.state]: libiberty/regex.c:6970:11: runtime error: left shift of negative value -1

2015-09-17 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64920

--- Comment #2 from Vittorio Zecca  ---
I propose the following fix at line 688 of regex.c in trunk

change

(destination) += SIGN_EXTEND_CHAR (*((source) + 1)) << 8 ; \

into

(*((source) + 1)) >= 0 ? (destination) += SIGN_EXTEND_CHAR (*((source) + 1)) <<
8 : (destination) ; \

I admit I did not tested it (yet) but the idea is to shift only if the shiftee
is not negative


[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch

2015-09-17 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827

--- Comment #3 from Vittorio Zecca  ---
(In reply to Mikhail Maltsev from comment #1)
> gcc/haifa-sched.c:1164:24
> gcc/haifa-sched.c:1442:26
> gcc/sched-deps.c:112:20
> 
> are caused by the following macro definition in gcc/sched-int.h:243:
> #define UNKNOWN_DEP_COST (-1<<19)

I fixed this one with

#define UNKNOWN_DEP_COST (-1u<<19)


[Bug libfortran/67536] New: unix.c sanitizer detects null pointer passed to memcpy

2015-09-09 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67536

Bug ID: 67536
   Summary: unix.c sanitizer detects null pointer passed to memcpy
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Running "make check" after building gcc the sanitizer complains that
at unix.c:497

memcpy (buf, s->buffer + (s->logical_offset - s->buffer_offset), nbyte);

the pointer buf == NULL

but nbyte == 0 so it should be harmless.
I believe that

if(nbyte) memcpy (buf, s->buffer + (s->logical_offset - s->buffer_offset),
nbyte);

should avoid this undefined behaviour.


[Bug libfortran/67534] New: libgfortran.h sanitizer complains on left shift of ~0 runtime error: left shift of negative value -1

2015-09-09 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67534

Bug ID: 67534
   Summary: libgfortran.h sanitizer complains on left shift of ~0
runtime error: left shift of negative value -1
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

The sanitizer complains on libgfortran.h:408

((~((index_type) 0) >> GFC_DTYPE_SIZE_SHIFT) << GFC_DTYPE_SIZE_SHIFT)

issuing

runtime error: left shift of negative value -1

because 0 is int. I believe it must be 0u to avoid undefined behaviour as in


((~((index_type) 0u) >> GFC_DTYPE_SIZE_SHIFT) << GFC_DTYPE_SIZE_SHIFT)

Target: x86_64-unknown-linux-gnu


[Bug libfortran/67535] New: write.c sanitizer detects null pointer passed to memcpy

2015-09-09 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535

Bug ID: 67535
   Summary: write.c sanitizer detects null pointer passed to
memcpy
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

During "make check" a null pointer is sometimes passed to memcpy in
write.c:1877

memcpy (ext_name, base_name, base_name_len);

because base_name == NULL

but base_name_len == 0 so it should be harmless.
To make happy the sanitizer the statement should be

if(base_name_len) memcpy (ext_name, base_name, base_name_len);


[Bug lto/67568] New: lto-streamer-in.c sanitizer runtime error: load of value 255, which is not a valid value for type 'bool'

2015-09-14 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67568

Bug ID: 67568
   Summary: lto-streamer-in.c sanitizer runtime error: load of
value 255, which is not a valid value for type 'bool'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Running make check in many test cases the sanitizer complains

../../gcc/gcc/lto-streamer-in.c:289:39: runtime error: load of value 255, which
is not a valid value for type 'bool'

The offending line is

 && current_col == stream_col && current_sysp == stream_sysp)

It seems that current_sysp has a value incompatible with its type bool


[Bug libfortran/67534] libgfortran.h sanitizer complains on left shift of ~0 runtime error: left shift of negative value -1

2015-09-13 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67534

--- Comment #3 from Vittorio Zecca  ---
I tested on trunk. The sanitizer message disappeared.


[Bug fortran/67567] New: pretty-print.h sanitizer detects NULL pointer passed to obstack_grow

2015-09-14 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67567

Bug ID: 67567
   Summary: pretty-print.h sanitizer detects NULL pointer passed
to obstack_grow
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

While running make check-fortran on submodule_4.f08 the sanitizer complains
that in pretty-print.h:142

obstack_grow (buff->obstack, start, length);

the pointer start == NULL

Most probably length == 0

but I believe it best to fix it by prefixing the statement with "if(length)"


[Bug fortran/67588] New: module.c heap use after free

2015-09-15 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588

Bug ID: 67588
   Summary: module.c heap use after free
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Let us look at module.c:800 and next:

  use_list = module_list;
  for (; module_list->next; use_list = use_list->next)
{
  module_list = use_list->next;
  free (use_list);
}

The Asan sanitizer detects that after the first iteration use_list is freed,
you can see that by inspection. But in the for statement it is dereferenced.

So this loop is wrong.

Maybe it should be

for (; module_list->next; use_list = module_list)
{
  module_list = use_list->next;
  free (use_list);
}


[Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

2015-09-15 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67484

--- Comment #5 from Vittorio Zecca  ---
Uros, I applied your patch and the sanitizer message disappeared.
Is this still an UNCONFIRMED bug?


[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2015-09-12 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #2 from Vittorio Zecca  ---
The pointer is NULL but the length is zero.
The test case is allocate_deferred_char_scalar_1.exe
on all eight combinations. As in

Executing on host:
/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/gfortran/../../gfortran
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/gfortran/../../
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/
/home/vitti/gcc-5.2.0/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
 -fno-diagnostics-show-caret -fdiagnostics-color=never-O0
-pedantic-errors
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libatomic/.libs
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
 -lm -L/home/vitti/local/gcc-5.2.0/lib64 -lasan -lubsan -ldl -lpthread
 -o ./allocate_deferred_char_scalar_1.exe(timeout = 300)
spawn -ignore SIGHUP
/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/gfortran/../../gfortran
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/gfortran/../../
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/
/home/vitti/gcc-5.2.0/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0
-pedantic-errors
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libatomic/.libs
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-lm -L/home/vitti/local/gcc-5.2.0/lib64 -lasan -lubsan -ldl -lpthread
-o ./allocate_deferred_char_scalar_1.exe^M
PASS: gfortran.dg/allocate_deferred_char_scalar_1.f03   -O0  (test for
excess errors)
Executing on unix: ./allocate_deferred_char_scalar_1.exe(timeout = 300)
spawn -ignore SIGHUP ./allocate_deferred_char_scalar_1.exe^M
lvz=0^M
lvz=0^M
Executed ./allocate_deferred_char_scalar_1.exe, status 0
lvz=0^M
lvz=0^M

PASS: gfortran.dg/allocate_deferred_char_scalar_1.f03   -O0  execution test

lvz=0 is my addition to expose the issue


[Bug libfortran/67527] io.h sanitizer complains on 1 << 31

2015-09-09 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67527

--- Comment #1 from Vittorio Zecca  ---
Same at line 383

#define IOPARM_DT_IONML_SET (1 << 31)

should be 

#define IOPARM_DT_IONML_SET (1u<< 31)


[Bug libfortran/67527] New: io.h sanitizer complains on 1 << 31

2015-09-09 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67527

Bug ID: 67527
   Summary: io.h sanitizer complains on 1 << 31
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

In io.h:314

#define IOPARM_INQUIRE_HAS_FLAGS2   (1 << 31)

should be 

#define IOPARM_INQUIRE_HAS_FLAGS2   (1u<< 31)

to make the sanitizer happy.


[Bug c++/58566] [c++11] ICE with invalid expression in lambda body

2015-09-25 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #2 from Vittorio Zecca  ---
Still fails on 6.0.0 trunk

~/gcc-trunk/bin/g++ -S p1.C -std=c++11
p1.C: In lambda function:
p1.C:5:25: error: invalid use of member function (did you forget the ‘()’ ?)
 [this]{ return foo; };
 ^
p1.C:5:25: internal compiler error: in check_return_expr, at cp/typeck.c:8609
0x729126 check_return_expr(tree_node*, bool*)
../../gcc/gcc/cp/typeck.c:8609
0x7663fe finish_return_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:873
0x70d5c4 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:9636
0x70d5c4 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:9141
0x6df257 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4510
0x6eb64b cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6201
0x6f00a9 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7486
0x6f0ce7 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8223
0x6f13ef cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8481
0x6f9b61 cp_parser_expression
../../gcc/gcc/cp/parser.c:8635
0x6fb6c6 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:10049
0x706ae5 cp_parser_statement
../../gcc/gcc/cp/parser.c:9900
0x7076a2 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:10172
0x70780b cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:10126
0x707a1b cp_parser_function_body
../../gcc/gcc/cp/parser.c:19785
0x707a1b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:19821
0x708899 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:24428
0x70c45c cp_parser_late_parsing_for_member
../../gcc/gcc/cp/parser.c:25232
0x6e7cc1 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:20645
0x6e7cc1 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:20671
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch

2015-11-18 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827

--- Comment #5 from Vittorio Zecca  ---
I am traveling now so I cannot double check your hint.
What do you suggest?

[Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

2016-04-28 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67484

--- Comment #14 from Vittorio Zecca  ---
I still get it in g++ 5.3.0

You may reproduce this one with a version of g++ compiled with
-fsanitize=address

[vitti cc]$/home/vitti/1tb/vitti/local/gcc-5.3.0-address/bin/g++ gccerr26.C -S
=
==4766==ERROR: AddressSanitizer: heap-use-after-free on address
0x602057d0 at pc 0x2b8838780025 bp 0x7fffdc0e27c0 sp
0x7fffdc0e1f70
READ of size 1 at 0x602057d0 thread T0
#0 0x2b8838780024 in __interceptor_strcmp
/home/vitti/gcc-5.3.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:178
#1 0x10bc6aa in cl_target_option_eq(cl_target_option const*,
cl_target_option const*)
/home/vitti/1tb/vitti/gcc-5.3.0-address/gcc/options-save.c:3555

options-save.c:3555 "|| strcmp (ptr1->x_ix86_arch_string,
ptr2->x_ix86_arch_string)))"

[Bug fortran/67498] interface.c sanitizer runtime error: load of value 1818451807, which is not a valid value for type 'expr_t'

2016-04-28 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67498

--- Comment #3 from Vittorio Zecca  ---
Still in gfortran 5.3.0

/home/vitti/gcc-5.3.0/gcc/fortran/interface.c:2707:33: runtime error:
load of value 1818451807, which is not a valid value for type 'expr_t'

interface.c:2707 "&& f->sym->ts.u.cl->length->expr_type == EXPR_CONSTANT"

You may reproduce this one with a version of gfortran compiled with
-fsanitize=undefined

[Bug fortran/67497] data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

2016-04-28 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497

--- Comment #3 from Vittorio Zecca  ---
Still in gfortran 5.3.0

/home/vitti/gcc-5.3.0/gcc/fortran/data.c:191:32: runtime error: null
pointer passed as argument 2, which is declared to never be null

data.c:191 "memcpy ([start], rvalue->value.character.string,
len * sizeof (gfc_char_t));"

Maybe len==0

[Bug fortran/70870] New: Segmentation violation in gfc_assign_data_value

2016-04-29 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70870

Bug ID: 70870
   Summary: Segmentation violation in gfc_assign_data_value
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! gfortran 6.1.0 Segmentation fault in gfc_assign_data_value
  type t
   integer :: g=0   ! default initialization
  end type
  type(t) :: v2
  data v2/t(2)/ ! this is wrong
  end
!f951: internal compiler error: Segmentation fault
!0xa6532f crash_signal
!../../gcc-6.1.0/gcc/toplev.c:333
!0x5de1fc gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*,
!__mpz_struct (*) [1])
!../../gcc-6.1.0/gcc/fortran/data.c:500
!0x651762 check_data_variable
!../../gcc-6.1.0/gcc/fortran/resolve.c:14564
!0x651762 traverse_data_var
!../../gcc-6.1.0/gcc/fortran/resolve.c:14693
!0x65be91 resolve_data
!../../gcc-6.1.0/gcc/fortran/resolve.c:14748
!0x65be91 resolve_types
!../../gcc-6.1.0/gcc/fortran/resolve.c:15501
!0x6576bf gfc_resolve(gfc_namespace*)
!../../gcc-6.1.0/gcc/fortran/resolve.c:15586
!0x642eda resolve_all_program_units
!../../gcc-6.1.0/gcc/fortran/parse.c:5552
!0x642eda gfc_parse_file()
!../../gcc-6.1.0/gcc/fortran/parse.c:5804
!0x684135 gfc_be_parse_file
!../../gcc-6.1.0/gcc/fortran/f95-lang.c:201
!Please submit a full bug report,
!with preprocessed source if appropriate.
!Please include the complete backtrace with any bug report.
!See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug c++/70872] New: c++ regression malloc not found c++ 5.3.0 compiles fine

2016-04-29 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70872

Bug ID: 70872
   Summary: c++ regression malloc not found c++ 5.3.0 compiles
fine
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

c++ fails to compile some mozilla firefox version 42 cc files

c++ 5.3.0 compiles fine

firefox configured with
../configure --disable-gconf
then run
make

As in:

c++ -o Unified_cpp_src_common_linux0.o -c -I../../../../../../dist/stl_wrappers
-I../../../../../../dist/system_wrappers -include
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-42.0/config/gcc_hidden.h
-DNO_STABS_SUPPORT -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API
-DIMPL_LIBXUL -DAB_CD=en-US -DNO_NSPR_10_SUPPORT
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-42.0/toolkit/crashreporter/google-breakpad/src/common/linux
-I.
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-42.0/toolkit/crashreporter/google-breakpad/src
-I../../../../../../dist/include  
-I/home/vitti/rpmbuild/SOURCES/firefox-42.0/firefox-obj/dist/include/nspr
-I/home/vitti/rpmbuild/SOURCES/firefox-42.0/firefox-obj/dist/include/nss  
-fPIC   -DMOZILLA_CLIENT -include ../../../../../../mozilla-config.h -MD -MP
-MF .deps/Unified_cpp_src_common_linux0.o.pp  -Wall -Wempty-body
-Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof
-Wcast-align -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions
-fno-math-errno -std=gnu++0x -pthread -pipe  -DNDEBUG -DTRIMMED -g
-freorder-blocks -Os -fomit-frame-pointer   
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-42.0/firefox-obj/toolkit/crashreporter/google-breakpad/src/common/linux/Unified_cpp_src_common_linux0.cpp
In file included from ../../../../../../dist/stl_wrappers/cstdlib:34:0,
 from
/home/vitti/1tb/vitti/local/gcc-6.1.0/include/c++/6.1.0/stdlib.h:36,
 from ../../../../../../dist/system_wrappers/stdlib.h:3,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-42.0/toolkit/crashreporter/google-breakpad/src/common/linux/guid_creator.cc:35,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-42.0/firefox-obj/toolkit/crashreporter/google-breakpad/src/common/linux/Unified_cpp_src_common_linux0.cpp:11:
../../../../../../dist/include/mozilla/mozalloc.h: In function ‘void* operator
new(size_t, const std::nothrow_t&)’:
../../../../../../dist/include/mozilla/mozalloc.h:192:28: error: ‘malloc’ was
not declared in this scope
 return malloc_impl(size);
^
../../../../../../dist/include/mozilla/mozalloc.h: In function ‘void* operator
new [](size_t, const std::nothrow_t&)’:
../../../../../../dist/include/mozilla/mozalloc.h:204:28: error: ‘malloc’ was
not declared in this scope
 return malloc_impl(size);
^
../../../../../../dist/include/mozilla/mozalloc.h: In function ‘void operator
delete(void*)’:
../../../../../../dist/include/mozilla/mozalloc.h:210:25: error: ‘free’ was not
declared in this scope
 return free_impl(ptr);
 ^
../../../../../../dist/include/mozilla/mozalloc.h:210:25: error:
return-statement with a value, in function returning 'void' [-fpermissive]
../../../../../../dist/include/mozilla/mozalloc.h: In function ‘void operator
delete(void*, const std::nothrow_t&)’:
../../../../../../dist/include/mozilla/mozalloc.h:216:25: error: ‘free’ was not
declared in this scope
 return free_impl(ptr);
 ^
../../../../../../dist/include/mozilla/mozalloc.h:216:25: error:
return-statement with a value, in function returning 'void' [-fpermissive]
../../../../../../dist/include/mozilla/mozalloc.h: In function ‘void operator
delete [](void*)’:
../../../../../../dist/include/mozilla/mozalloc.h:222:25: error: ‘free’ was not
declared in this scope
 return free_impl(ptr);
 ^
../../../../../../dist/include/mozilla/mozalloc.h:222:25: error:
return-statement with a value, in function returning 'void' [-fpermissive]
../../../../../../dist/include/mozilla/mozalloc.h: In function ‘void operator
delete [](void*, const std::nothrow_t&)’:
../../../../../../dist/include/mozilla/mozalloc.h:228:25: error: ‘free’ was not
declared in this scope
 return free_impl(ptr);
 ^
../../../../../../dist/include/mozilla/mozalloc.h:228:25: error:
return-statement with a value, in function returning 'void' [-fpermissive]
../../../../../../dist/include/mozilla/mozalloc.h: In function ‘void* operator
new(size_t, const mozilla::fallible_t&)’:
../../../../../../dist/include/mozilla/mozalloc.h:254:28: error: ‘malloc’ was
not declared in this scope
 return malloc_impl(size);
^
../../../../../../dist/include/mozilla/mozalloc.

[Bug c/70875] New: ICE in get_ubsan_type_info_for_type with -fsanitize=undefined

2016-04-29 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70875

Bug ID: 70875
   Summary: ICE in get_ubsan_type_info_for_type with
-fsanitize=undefined
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* gcc -fsanitize=undefined */
int foo (int n, int k)
{
  struct S
  {
int i[n];
int value;
  } s[2];
  return s[k].value = 0;
}

int main ()
{
 return foo (2, 0);
}
/* p.c: In function ‘foo’:
 * p.c:2:5: internal compiler error: in get_ubsan_type_info_for_type, at
ubsan.c:305
 *  int foo (int n, int k)
 *   ^~~
 * 0x9e54e4 get_ubsan_type_info_for_type
 * ../../gcc-6.1.0/gcc/ubsan.c:305
 * 0x9e54e4 ubsan_type_descriptor(tree_node*, ubsan_print_style)
 * ../../gcc-6.1.0/gcc/ubsan.c:454
 * 0x9e5709 ubsan_expand_bounds_ifn(gimple_stmt_iterator*)
 * ../../gcc-6.1.0/gcc/ubsan.c:692
 * 0x9ea7e9 execute
 * ../../gcc-6.1.0/gcc/sanopt.c:696
 * Please submit a full bug report,
 * with preprocessed source if appropriate.
 * Please include the complete backtrace with any bug report.
 * See <http://gcc.gnu.org/bugs.html> for instructions.
 */

[Bug c/70874] New: Segmentation violation in tree-chkp.c chkp_walk_pointer_assignments

2016-04-29 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70874

Bug ID: 70874
   Summary: Segmentation violation in tree-chkp.c
chkp_walk_pointer_assignments
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* gcc -fsanitize=undefined -fcheck-pointer-bounds -mmpx */
void f(char *a, int *b)
{
 *b = *a;
}
/*
 * p.c:5:1: internal compiler error: Segmentation fault
 *  }
 *  ^
 * 0x9caebf crash_signal
 *../../gcc-6.1.0/gcc/toplev.c:333
 *0xa4ad08 chkp_walk_pointer_assignments
 *../../gcc-6.1.0/gcc/tree-chkp.c:3725
 *0xa4c85f chkp_finish_file()
 *../../gcc-6.1.0/gcc/tree-chkp.c:3835
 *Please submit a full bug report,
 *with preprocessed source if appropriate.
 *Please include the complete backtrace with any bug report.
 *See <http://gcc.gnu.org/bugs.html> for instructions.
 */

[Bug c/70876] New: ICE in chkp_find_bounds: Unexpected tree code with_size_expr

2016-04-29 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70876

Bug ID: 70876
   Summary: ICE in chkp_find_bounds: Unexpected tree code
with_size_expr
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* gcc -fcheck-pointer-bounds  -mmpx */
void f (char *s1, char *s2)
{
  int z = 5;

  struct { char a[z]; } x;

s1[0] = s2[0];

  foo (x, x);
}
/*p.c: In function ‘f’:
 * p.c:10:3: warning: implicit declaration of function ‘foo’
[-Wimplicit-function-declaration]
 *foo (x, x);
 *^~~
 * p.c: In function ‘f.chkp’:
 * p.c:11:1: internal compiler error: chkp_find_bounds: Unexpected tree code
with_size_expr
 *  }
 *  ^
 * 0xa4de44 chkp_find_bounds_1
 *../../gcc-6.1.0/gcc/tree-chkp.c:3667
 * 0xa51f78 chkp_find_bounds
 * ../../gcc-6.1.0/gcc/tree-chkp.c:3687
 * 0xa51f78 chkp_add_bounds_to_call_stmt
 * ../../gcc-6.1.0/gcc/tree-chkp.c:1896
 * 0xa51f78 chkp_instrument_function
 * ../../gcc-6.1.0/gcc/tree-chkp.c:4271
 * 0xa51f78 chkp_execute
 * ../../gcc-6.1.0/gcc/tree-chkp.c:4455
 * 0xa51f78 execute
 * ../../gcc-6.1.0/gcc/tree-chkp.c:4514
 * Please submit a full bug report,
 * with preprocessed source if appropriate.
 * Please include the complete backtrace with any bug report.
 * See <http://gcc.gnu.org/bugs.html> for instructions.
 */

[Bug c/70877] New: ICE in in convert_move

2016-04-29 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70877

Bug ID: 70877
   Summary: ICE in in convert_move
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  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 foo(int);

typedef struct {
  double d;
  int a;
} str_t;

void bar(double d, int i, str_t s)
{
  d = ((double (*) (int)) foo) (i);
}
/*p.c: In function ‘bar’:
 * p.c:11:8: warning: function called through a non-compatible type
 * d = ((double (*) (int)) foo) (i);
 * ~^~~
 * p.c: In function ‘bar.chkp’:
 * p.c:11:5: internal compiler error: in convert_move, at expr.c:268
 * d = ((double (*) (int)) foo) (i);
 * ~~^~
 * 0x768d18 convert_move(rtx_def*, rtx_def*, int)
 * ../../gcc-6.1.0/gcc/expr.c:268
 * 0x76e515 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
 * ../../gcc-6.1.0/gcc/expr.c:5483
 * 0x76e98f expand_assignment(tree_node*, tree_node*, bool)
 * ../../gcc-6.1.0/gcc/expr.c:5175
 * 0x691a9c expand_call_stmt
 * ../../gcc-6.1.0/gcc/cfgexpand.c:2658
 * 0x691a9c expand_gimple_stmt_1
 * ../../gcc-6.1.0/gcc/cfgexpand.c:3548
 * 0x691a9c expand_gimple_stmt
 * ../../gcc-6.1.0/gcc/cfgexpand.c:3714
 * 0x693435 expand_gimple_basic_block
 * ../../gcc-6.1.0/gcc/cfgexpand.c:5720
 * 0x698316 execute
 * ../../gcc-6.1.0/gcc/cfgexpand.c:6335
 * Please submit a full bug report,
 * with preprocessed source if appropriate.
 * Please include the complete backtrace with any bug report.
 * See <http://gcc.gnu.org/bugs.html> for instructions.
 */

[Bug c++/67737] [C++1z] ICE in make_decl_rtl, at varasm.c:1299

2016-04-29 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67737

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #7 from Vittorio Zecca  ---
With gcc 6.1.0, maybe a shorter reproducer
/* gcc -fcheck-pointer-bounds -mmpx p.c */
int main ()
{
  int size = 10;
  typedef struct
{
  char val[size];
} block;
  block b;
  block retframe_block () {}
  retframe_block ();
}
/*
 * p.c: In function ‘main.chkp’:
 * p.c:11:3: internal compiler error: in make_decl_rtl, at varasm.c:1299
 *retframe_block ();
 *   ^~
 * 0xbf101d make_decl_rtl(tree_node*)
 * ../../gcc-6.1.0/gcc/varasm.c:1295
 * 0x7658b6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
 * ../../gcc-6.1.0/gcc/expr.c:9612
 * 0xc4cddf expand_normal
 * ../../gcc-6.1.0/gcc/expr.h:262
 * 0xc4cddf ix86_expand_builtin
 * ../../gcc-6.1.0/gcc/config/i386/i386.c:40323
 * 0x67643c expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
 * ../../gcc-6.1.0/gcc/builtins.c:5624
 * 0x765171 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
 * ../../gcc-6.1.0/gcc/expr.c:10591
 * 0x682662 initialize_argument_information
 * ../../gcc-6.1.0/gcc/calls.c:1186
 * 0x682662 expand_call(tree_node*, rtx_def*, int)
 * ../../gcc-6.1.0/gcc/calls.c:2699
 * 0x764c06 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
 * ../../gcc-6.1.0/gcc/expr.c:10594
 * 0x76dc39 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
 * ../../gcc-6.1.0/gcc/expr.c:5406
 * 0x76e98f expand_assignment(tree_node*, tree_node*, bool)
 * ../../gcc-6.1.0/gcc/expr.c:5175
 * 0x691a9c expand_call_stmt
 * ../../gcc-6.1.0/gcc/cfgexpand.c:2658
 * 0x691a9c expand_gimple_stmt_1
 * ../../gcc-6.1.0/gcc/cfgexpand.c:3548
 * 0x691a9c expand_gimple_stmt
 * ../../gcc-6.1.0/gcc/cfgexpand.c:3714
 * 0x693435 expand_gimple_basic_block
 * ../../gcc-6.1.0/gcc/cfgexpand.c:5720
 * 0x698316 execute
 * ../../gcc-6.1.0/gcc/cfgexpand.c:6335
 * Please submit a full bug report,
 * with preprocessed source if appropriate.
 * Please include the complete backtrace with any bug report.
 * See <http://gcc.gnu.org/bugs.html> for instructions.
 */

[Bug c/70878] New: ICE in expand_expr_addr_expr_1, at expr.c:7680

2016-04-29 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70878

Bug ID: 70878
   Summary: ICE in expand_expr_addr_expr_1, at expr.c:7680
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* gcc -fsanitize=undefined */
void * sbrk ()
{
 volatile register __attribute__ ((__spu_vector__)) unsigned int sp_r1 __asm__
("1");

 __builtin_spu_extract (sp_r1, 0);
}
/*
 /home/vitti/f95/cc/gccerr38.c: In function ‘sbrk’:
/home/vitti/f95/cc/gccerr38.c:3:2: warning: ‘__spu_vector__’ attribute
directive ignored [-Wattributes]
  volatile register __attribute__ ((__spu_vector__)) unsigned int sp_r1 __asm__
("1");
  ^~~~
/home/vitti/f95/cc/gccerr38.c:5:2: warning: implicit declaration of function
‘__builtin_spu_extract’ [-Wimplicit-function-declaration]
  __builtin_spu_extract (sp_r1, 0);
  ^
/home/vitti/f95/cc/gccerr38.c:1:8: internal compiler error: in
expand_expr_addr_expr_1, at expr.c:7680
 void * sbrk ()
^~~~
0x77627d expand_expr_addr_expr_1
../../gcc-6.1.0/gcc/expr.c:7680
0x7645b3 expand_expr_addr_expr
../../gcc-6.1.0/gcc/expr.c:7793
0x7645b3 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-6.1.0/gcc/expr.c:10825
0x774ddc expand_expr
../../gcc-6.1.0/gcc/expr.h:256
0x774ddc expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-6.1.0/gcc/expr.c:8180
0x69201e expand_gimple_stmt_1
../../gcc-6.1.0/gcc/cfgexpand.c:3653
0x69201e expand_gimple_stmt
../../gcc-6.1.0/gcc/cfgexpand.c:3714
0x693435 expand_gimple_basic_block
../../gcc-6.1.0/gcc/cfgexpand.c:5720
0x698316 execute
../../gcc-6.1.0/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
*/

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

2016-04-28 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

--- Comment #11 from Vittorio Zecca  ---
I am still having an ICE with gfortran 5.3.0 on the following

  module abc
  implicit none
  type,abstract::abc_abstract
  contains
  procedure(abc_interface),deferred::abc_function
  end type abc_abstract
  type,extends(abc_abstract)::abc_type
  contains
  procedure::abc_function
  end type abc_type
  abstract interface
  function abc_interface(this)
   import abc_abstract
   class(abc_abstract),intent(in)::this
   character(len=*)::abc_interface
  end function abc_interface
  end interface
  contains
  function abc_function(this)
  class(abc_type),intent(in)::this
  character(len=5)::abc_function
  abc_function="hello"
  end function abc_function
  subroutine do_something(this)
  class(abc_abstract),intent(in)::this
  print *,this%abc_function()
  end subroutine do_something
  end module abc

gfbug111.f:30:0:

   print *,this%abc_function()
 1
internal compiler error: in wide_int_to_tree, at tree.c:1465
0xc3eae3 wide_int_to_tree(tree_node*,
generic_wide_int const&)
/home/vitti/gcc-5.3.0/gcc/tree.c:1465
0xc3ebb9 build_int_cst(tree_node*, long)
/home/vitti/gcc-5.3.0/gcc/tree.c:1273
0x83a9aa round_up_loc(unsigned int, tree_node*, unsigned int)
/home/vitti/gcc-5.3.0/gcc/fold-const.c:16043
0xa555bb finalize_type_size
/home/vitti/gcc-5.3.0/gcc/stor-layout.c:1802
0xa56766 layout_type(tree_node*)
/home/vitti/gcc-5.3.0/gcc/stor-layout.c:2442
0xc3cb73 build_array_type_1
/home/vitti/gcc-5.3.0/gcc/tree.c:7968
0x709a64 gfc_get_character_type_len_for_eltype(tree_node*, tree_node*)
/home/vitti/gcc-5.3.0/gcc/fortran/trans-types.c:1048
0x6d16d7 gfc_conv_procedure_call(gfc_se*, gfc_symbol*,
gfc_actual_arglist*, gfc_expr*, vec*)
/home/vitti/gcc-5.3.0/gcc/fortran/trans-expr.c:5644
0x6d1d6f gfc_conv_function_expr
/home/vitti/gcc-5.3.0/gcc/fortran/trans-expr.c:6293
0x6d789a gfc_conv_expr_reference(gfc_se*, gfc_expr*)
/home/vitti/gcc-5.3.0/gcc/fortran/trans-expr.c:7349
0x6f277f gfc_trans_transfer(gfc_code*)
/home/vitti/gcc-5.3.0/gcc/fortran/trans-io.c:2394
0x6a4e47 trans_code
/home/vitti/gcc-5.3.0/gcc/fortran/trans.c:1868
0x6f03a7 build_dt
/home/vitti/gcc-5.3.0/gcc/fortran/trans-io.c:1921
0x6a4e67 trans_code
/home/vitti/gcc-5.3.0/gcc/fortran/trans.c:1840
0x6c4ce3 gfc_generate_function_code(gfc_namespace*)
/home/vitti/gcc-5.3.0/gcc/fortran/trans-decl.c:5851
0x6a8421 gfc_generate_module_code(gfc_namespace*)
/home/vitti/gcc-5.3.0/gcc/fortran/trans.c:2036
0x662d4d translate_all_program_units
/home/vitti/gcc-5.3.0/gcc/fortran/parse.c:5330
0x662d4d gfc_parse_file()
/home/vitti/gcc-5.3.0/gcc/fortran/parse.c:5540
0x6a22b5 gfc_be_parse_file
/home/vitti/gcc-5.3.0/gcc/fortran/f95-lang.c:229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Maybe it is related to this issue?

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

2016-04-28 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402

--- Comment #4 from Vittorio Zecca  ---
ICE on gfortran 5.3.0

gfortran should never have an ICE, even on invalid code.

[Bug ada/67494] xsinfo sanitizer detects overlapping strings in assignment statement

2016-04-28 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67494

--- Comment #2 from Vittorio Zecca  ---
Any update on this issue?

[Bug fortran/44265] Link error with reference to parameter array in specification expression

2016-04-28 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265

--- Comment #7 from Vittorio Zecca  ---
Still in 5.3.0

[Bug fortran/50410] [4.9/5/6/7 Regression] ICE in record_reference

2016-04-28 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

--- Comment #21 from Vittorio Zecca  ---
ICE still in 5.3.0

[Bug fortran/50536] an input item shall not appear as the do-variable of any io-implied-do

2016-04-28 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50536

--- Comment #8 from Vittorio Zecca  ---
Still in 5.3.0

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

2016-04-28 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392

--- Comment #8 from Vittorio Zecca  ---
ICE still in 5.3.0

[Bug fortran/50069] FORALL fails on a character array

2016-04-28 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069

--- Comment #7 from Vittorio Zecca  ---
Still in 5.3.0

[Bug fortran/67496] trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'

2016-04-29 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496

--- Comment #5 from Vittorio Zecca  ---
Yes, I did test your patch, but nothing changed.

I understand you tried to generate a sanitized version of f951 but the
process failed.
I did the following (approximately):

CFLAGS="-fsanitize=undefined -Og -ggdb -fno-omit-frame-pointer
-L/home/vitti/local/gcc-6.1.0/lib64" CXXFLAGS="-fsanitize=undefined
-Og -ggdb -fno-omit-frame-pointer"
LDFLAGS="-L/home/vitti/local/gcc-6.1.0/lib64 -lubsan -ldl -lpthread"
../gcc-6.1.0/configure --prefix=/home/vitti/local/gcc-6.1.0-undefined
--disable-multilib --enable-languages=c,c++,fortran
--disable-libstdcxx --disable-bootstrap
make

and cross fingers

With an analogous approach I got a -fsanitize=address version of
gcc/g++/gfortran

[Bug fortran/67498] interface.c sanitizer runtime error: load of value 1818451807, which is not a valid value for type 'expr_t'

2016-04-29 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67498

--- Comment #4 from Vittorio Zecca  ---
Still in gfortran 6.1.0

../../gcc-6.1.0/gcc/fortran/interface.c:2738:33: runtime error: load of value
1818451807, which is not a valid value for type 'expr_t'

[Bug fortran/67496] trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'

2016-04-29 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496

--- Comment #3 from Vittorio Zecca  ---
Just back from my travels.

Sorry, I get the same warning on 6.1.0:

/home/vitti/1tb/vitti/gcc-6.1.0-undefined/gcc/f951 -quiet gfbug121.f
../../gcc-6.1.0/gcc/fortran/trans-array.c:2234:27: runtime error: load of value
112, which is not a valid value for type 'bool'

If you had a sanitized version of f951 maybe you could see it by yourself.

[Bug middle-end/64327] ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'

2016-04-29 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327

--- Comment #7 from Vittorio Zecca  ---
On 6.1.0 I applied the same patch I suggested on comment 6,
this time at line 5187,
and the runtime error disappeared.

[Bug other/69412] bootstrap-ubsan profiledbootstrap issues

2016-04-30 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69412

--- Comment #4 from Vittorio Zecca  ---
A reproducer for the parser.c runtime error

/* gcc-6.1.0-undefined/bin/g++  -I../../gcc-6.1.0/gcc/.
-I../../gcc-6.1.0/gcc/../include -I../../gcc-6.1.0/gcc/../libcpp/include  p.c
-S -I. */
/* ../../gcc-6.1.0/gcc/cp/parser.c:765:7: runtime error: member call on null
pointer of type 'struct vec' */
/* must be compiled in gcc-6.1.0/gcc directory */

#include "config.h"
#include "system.h"
#include "coretypes.h"

template 
class function_summary {};

template 
class function_summary 
{

  template
  void traverse (Arg a) const
  {
   m_map.traverse  (a);/* HERE */
  }

  typedef int_hash  map_hash;

  hash_map  m_map;

};

[Bug middle-end/67485] expmed.c sanitizer detects overflow

2016-04-30 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67485

--- Comment #1 from Vittorio Zecca  ---
Still in 6.1.0 at line 3162 of expmed.c

"val_so_far -= (HOST_WIDE_INT) 1 << log;"

../../gcc-6.1.0/gcc/expmed.c:3162:42: runtime error: signed integer overflow:
-9223372036854775808 - 1 cannot be represented in type 'long int'

[Bug other/69412] bootstrap-ubsan profiledbootstrap issues

2016-04-30 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69412

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #3 from Vittorio Zecca  ---
On 6.1.0 I am having the same runtime error at parser.c:765

"gcc_assert (tp != lexer->buffer->address ());"

[Bug fortran/67496] trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'

2016-04-30 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496

--- Comment #7 from Vittorio Zecca  ---
I understand that you are still seeing a message like this

../../gcc-6.1.0/gcc/fortran/trans-array.c:2233:27: runtime error: load
of value 176, which is not a valid value for type 'bool'

right?

If yes, the problem might well be in ubsan, unless it has been fixed in 7.0.0.
I'll look into this.

[Bug fortran/67496] trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'

2016-04-30 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496

--- Comment #9 from Vittorio Zecca  ---
My C is not better than yours, but length_from_typespec might have
been incorrectly
initialized elsewhere, otherwise it is a false positive.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

2016-04-30 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278

--- Comment #13 from Vittorio Zecca  ---
I think that 1 << 31 is undefined because "1" is assumed (signed) int.
Maybe it should be 1u << 31 ?

Anyway on 6.1.0 I have no runtime error message.

[Bug middle-end/70526] [5/6 Regression] GCC 6 miscompiles Firefox JIT compiler

2016-05-17 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526

--- Comment #34 from Vittorio Zecca  ---
The Intel icpc compiler complains that in the reduced testcase
ansi-alias rules are violated.

icpc gccerr45.C -Wstrict-aliasing
gccerr45.C(77) (col. 32): warning #2102: violation of ansi-alias rules

This is line 77: "const LAllocation* value = lir->getOperand(n);"

<    1   2   3   4   5   6   >