[Bug regression/56844] New: Loop condition wrongly optimized from < to !=

[holger.hopp at sap dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56844



 Bug #: 56844

   Summary: Loop condition wrongly optimized from < to !=

Classification: Unclassified

   Product: gcc

   Version: 4.8.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: regression

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: holger.h...@sap.com





Following code is optimized  wrong with gcc-4.8 -O2.

It works correct with gcc-4.8 -O1 and gcc-4.7 -O2.

Somehow the 'i < 16' condition of the second loop is optimized to 'i != 16'

(runs second loop until segfault / stack overflow).



[gcc-4_8-branch revision 197479, x86_64]



int printf (const char *format, ...);

char* strncpy (char * dest, const char * src, unsigned long n);



int main()

{

  int i;

  char str[16];



  strncpy( str, "abcdefghijklmnop", 16 );

  for( i = 0; ( str[i] != '\0' ) && ( i < 16 ); i++ );

  for( ; i < 16; i++ ) str[i] = ' ';

  printf ("str = \"%s\"\n", str);

  return 0;

}

[Bug c++/52755] New: Error on use of implicitly deleted operator=

[holger.hopp at sap dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52755

 Bug #: 52755
   Summary: Error on use of implicitly deleted operator=
Classification: Unclassified
   Product: gcc
   Version: 4.6.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: holger.h...@sap.com


Following code compiles fine with every gcc, with every g++ -std=c++98, 
with g++-4.5 -std=c++0x, but not with g++ -std=c++0x (or -std=c++11) since 4.6.

typedef volatile struct t1s { int a; } t1;
typedef struct t2s { t1 b; } t2;
t2 x, y;

void foo(void)
{
  x = y;
}

compile with: g++ -std=c++0x vola.cpp

vola.cpp: In function 'void foo()':
vola.cpp:7:7: error: use of deleted function 't2s& t2s::operator=(const t2s&)'
vola.cpp:2:16: error: 't2s& t2s::operator=(const t2s&)' is implicitly deleted
because the default definition would be ill-formed:
vola.cpp:2:16: error: no matching function for call to 't1s::operator=(const
volatile t1&) volatile'
vola.cpp:2:16: note: candidates are:
vola.cpp:1:25: note: t1s& t1s::operator=(const t1s&)
vola.cpp:1:25: note:   no known conversion for argument 1 from 'const volatile
t1' to 'const t1s&'
vola.cpp:1:25: note: t1s& t1s::operator=(t1s&&)
vola.cpp:1:25: note:   no known conversion for argument 1 from 'const volatile
t1' to 't1s&&'

[Bug c++/52755] Error on use of implicitly deleted operator=

[holger.hopp at sap dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52755

--- Comment #3 from Holger Hopp  2012-03-29 
11:50:25 UTC ---
I agree that it is possible to define operator= for each struct that
is using t1 (in the original code (C code, but compiled as C++ code)
there is not only t2, and in all of them there are more members).

There are simpler methods to fix the code, e.g. to define  
  typedef struct t1s { volatile int a; } t1;
It should be equivalent in the volatile qualifier behavior when the
volatile qualifier is set for each member of t1. This compiles also
fine with gcc-4.6 and does not need several operator= definitions.

But that is not the question. The question is if that is a gcc bug or
not. If C++11 is really different compared to C++98 here (I'm not sure
about that), then I would prefer _one_ clear error message like
"error: C++11 does not allow ..." or "error: C++11 demands ..." or
similar, and not that weird 3 error messages plus 5 notes about
implicitly deleted simple assignments operators.

[Bug regression/52973] New: visibility attribute for class is not passed to its members

[holger.hopp at sap dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52973

 Bug #: 52973
   Summary: visibility attribute for class is not passed to its
members
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: holger.h...@sap.com


In following code, gcc-4.7 does not accept the visibility attribute
defined in the class declaration:

template  class __attribute__((visibility("default"))) a
{
public:
  /* A */ static int c;
};

class __attribute__((visibility("default"))) b : a  {};

template<> /* B */ int a::c = 0;


With g++-4.7, a::c is hidden, with g++-4.6 (and before) it is not.

$ g++-4.7 -fvisibility=hidden -c def.cpp && objdump -Ct def.o | grep "a"
 g O .bss0004 .hidden a::c

$ g++-4.6 -fvisibility=hidden -c def.cpp && objdump -Ct def.o | grep "a"
 g O .bss0004 a::c

Setting the default visibility at /* A */ or /* B */ works with
g++-4.7, but I think that it still should work also with the code above.

[Bug other/82352] [7 Regression] comdat-local function called by void h::i() outside its comdat

[holger.hopp at sap dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82352

--- Comment #6 from Holger Hopp  ---
The patch fixes my >10 original issues with gcc-7.
It also fixes similar (other, fewer) issues with gcc-6 (gcc-6.2.1 was ok,
gcc-6.3.1 not ok, with patch ok).
So please downport this patch also to gcc-6 branch.
Thanks!

[Bug debug/87215] New: Unused debug info with -std=c++17

[holger.hopp at sap dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87215

Bug ID: 87215
   Summary: Unused debug info with -std=c++17
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: holger.hopp at sap dot com
  Target Milestone: ---

gcc-7 and gcc-8 produce much more unused (?) debug info when compiling in C++17
mode (compared to C++14 or C++11 mode).
Seems that unused debug info elimination (-f[no-]eliminate-unused-debug-types )
does not work properly with C++17.

Source (not preprocessed, but simple):

#include 

Reproduce:

g++ -std=c++14 -g -o limits-14.o -c limits.cpp 
g++ -std=c++14 -g -fno-eliminate-unused-debug-types -o limits-14-ne.o -c
limits.cpp 
g++ -std=c++17 -g -o limits-17.o -c limits.cpp 
g++ -std=c++17 -g -fno-eliminate-unused-debug-types -o limits-17-ne.o -c
limits.cpp 
g++ -std=c++17 -g -feliminate-unused-debug-types -o limits-17-e.o -c limits.cpp 
wc -c limits*.o

With gcc-7 or gcc-8:
 37872 limits-14-ne.o
  3096 limits-14.o
 69720 limits-17-e.o
 69728 limits-17-ne.o
 69688 limits-17.o

Ok with gcc-6:
 36816 limits-14-ne.o
  2864 limits-14.o
  2888 limits-17-e.o
 36816 limits-17-ne.o
  2864 limits-17.o

(no difference between 'g++ -std=c++14 -E limits.cpp' and 'g++ -std=c++17 -E
limits.cpp' preprocessed outputs)

[Bug c++/80831] New: internal compiler error: Segmentation fault with -fsyntax-only

[holger.hopp at sap dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80831

Bug ID: 80831
   Summary: internal compiler error: Segmentation fault with
-fsyntax-only
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: holger.hopp at sap dot com
  Target Milestone: ---

Following code throws internal compiler error: Segmentation fault with
g++ -c t.cpp --std=c++11 -fsyntax-only

(gcc Releases 6 and 7, gcc 5 is ok)


class A
{
public:
virtual ~A() { }
};

class B { };

class C : public A { };

template
class D : public C
{
public:
D() { }
~D() { }
};

class E
{
public:
static E& p();
B q();
template
B q(void (J::*r)())
{
new D();
return q();
}
};

void t()
{
  class F
  {
  public:
virtual void s() { }
  };
  E& x = E::p();
  B y = x.q(&F::s);
}


$ g++ -c t.cpp --std=c++11 -fsyntax-only
t.cpp:41:1: internal compiler error: Segmentation fault
 }
 ^
0xb045cf crash_signal
/gcc/gnu/gcc-7-branch/gcc/gcc/toplev.c:337
0x642c4c c_parse_final_cleanups()
/gcc/gnu/gcc-7-branch/gcc/gcc/cp/decl2.c:4710
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug other/82352] New: link error 'defined in discarded section'

[holger.hopp at sap dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82352

Bug ID: 82352
   Summary: link error 'defined in discarded section'
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: holger.hopp at sap dot com
  Target Milestone: ---

I'm getting linker error
`...' referenced in section `...' of ..: defined in discarded section `...' of
...
with gcc-7 compiled code, that do not appear with gcc-5 or gcc-6.

Source:

typedef long unsigned int size_t;

class A
{
public :
  typedef enum { Zero = 0, One = 1 } tA;
  A(tA a) { m_a = a; }

private :
  tA m_a;
};

class B
{
public :
  void *operator new(size_t t) { return (void*)(42); };
};

class C
{
public:
  virtual void  () = 0;
};

class D
{
 public :
  virtual void g() = 0;
  virtual void h() = 0;
};

template class : public T, public D
{
public:
 void ()
 {
   if (!m_i2) throw A(A::One);
 };

 void h()
 {
  if (m_i2) throw A(A::Zero);
 }

protected:
 virtual void g()
 {
  if (m_i1 !=0) throw A(A::Zero);
 };

private :
 int m_i1;
 void *m_i2;
};

class E
{
private:
size_t m_e;
static const size_t Max;

public:
E& i(size_t a, size_t b, size_t c)
{
if ((a > Max) || (c > Max)) throw A(A::Zero );
if (a + b > m_e) throw A(A::One );
return (*this);
}

  inline E& j(const E &s)
{
  return i(0,0,s.m_e);
}
};

class F : public C { };
class G : public C { };
class  : public B, public F, public G { };

void k()
{
 *p = new ();
}

void l()
{
  E e1, e2;
  e1.j(e2);
}



Reproduce:

$ g++ -O2 -o t1.o -c t1.cpp && echo ok && objdump -t t1.o | grep Ev.part
ok
 ld  .text.unlikely._ZN4I4E4Ev.part.2  
 .text.unlikely._ZN4I4E4Ev.part.2
 l F .text.unlikely._ZN4I4E4Ev.part.2  
0023 _ZN4I4E4Ev.part.2

This symbol is causing the linker problem. Maybe this is already sufficient for
you.
You may get the final linker error as follows:

Slightly change source t1.cpp to t2.cpp:
- remove function g() (twice!)
- rename k() and l() by k2() and l2(2), respectively.

$ g++ -O2 -o t2.o -c t2.cpp && echo ok && objdump -t t2.o | grep Ev.part
ok
 ld  .text.unlikely._ZN4I4E4Ev.part.1  
 .text.unlikely._ZN4I4E4Ev.part.1
 l F .text.unlikely._ZN4I4E4Ev.part.1  
0023 _ZN4I4E4Ev.part.1

Symbol is named ...part.1 instead of ...part.2 in this case.

$ echo "int main() { return 0; }" | gcc -x c -c - -o main.o
$ g++ -o main main.o t1.o t2.o
`_ZN4I4E4Ev.part.1' referenced in section `.text.unlikely' of t2.o:
defined in discarded section
`.text.unlikely._ZN4I4E4Ev.part.1[_ZN4I4E4Ev]' of t2.o
collect2: error: ld returned 1 exit status



Following works:
(1) gcc-5 and gcc-6
(2) gcc-7 with -O1
(3) marking () with __attribute__((used))
(found in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65199)
(4) patch binutils in file bfd/elflink.c, function
_bfd_elf_default_action_discarded:
remove the COMPLAIN flag


Nevertheless, it is probably a bug on gcc side, as in similar old bug 49665
with same linker error.

[Bug tree-optimization/60871] New: internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1510

[holger.hopp at sap dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60871

Bug ID: 60871
   Summary: internal compiler error: in
possible_polymorphic_call_targets, at
ipa-devirt.c:1510
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: holger.hopp at sap dot com

Following code throws an internal compiler error with g++-4.9 -O2

$ g++ -O2 -c tst.c
tst.c: In static member function ‘static void C11::comp()’:
tst.c:88:1: internal compiler error: in possible_polymorphic_call_targets, at
ipa-devirt.c:1510
 }
 ^
0x9e77a8 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, int*)
../../gcc/ipa-devirt.c:1510
0x9a3b67 possible_polymorphic_call_targets(tree_node*, bool*, void**)
../../gcc/ipa-utils.h:142
0x9a0d56 gimple_fold_call
../../gcc/gimple-fold.c:1126
0x9a0d56 fold_stmt_1
../../gcc/gimple-fold.c:1239
0xbbc5b9 fold_marked_statements
../../gcc/tree-inline.c:4541
0xbc9b54 optimize_inline_calls(tree_node*)
../../gcc/tree-inline.c:4622
0x10639b9 early_inliner
../../gcc/ipa-inline.c:2303
0x10639b9 execute
../../gcc/ipa-inline.c:2366
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.

Source:

void *vptr;

class C2
{
public:
  static inline C2 * cbss()
  {
singleton = (C2 *)vptr;
return singleton;
  }

private:
  static C2 * singleton;
};

class C3
{
public:
  C3(void) {}
  virtual void sf();
protected:
  unsigned m_local:1;
};

class C4 : virtual public C3
{
public:
 C4(void) : C3() {}
protected:
  void sf() { }
  void uf() { }
};

class C5
{
private:
  C3 * m_g;
public:
  C5(C3 * g) : m_g(g)  { m_g->sf(); }
};

class C6
{
public:
  virtual ~C6() {}
};

class C7 : public C6
{
protected:
  C7(void) {}
};

class C8 : public C4, public C7
{
public:
 C8(void) : C3(), C4(), C7() { }
};

class C9 : public C8
{
public:
 C9(void) : C3(), C8() { }
};

class C10 : public C9
{
protected:
 C10(void) : C3(), C9() { }
};

class C11 : public C10
{
protected:
 C11( const C2 * s ) : C3(), C10() { }

public:
  static void comp(void)
  {
C11 a(C2::cbss());
C5 uf(&a);
  }
};

void foo (void)
{
  C11::comp();
}

[Bug regression/65054] New: internal compiler error: in maybe_constant_value, at cp/constexpr.c:3646

[holger.hopp at sap dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65054

Bug ID: 65054
   Summary: internal compiler error: in maybe_constant_value, at
cp/constexpr.c:3646
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: holger.hopp at sap dot com

following code throws an internal compiler error with g++-5.0 (gcc-5.0 works):

typedef char * CP;

const char * foo (void)
{
  return ((const CP)"abc"+1);
}

$ g++ -c tst.c 
tst.c: In function ‘const char* foo()’:
tst.c:5:28: internal compiler error: in maybe_constant_value, at
cp/constexpr.c:3646
   return ((const CP)"abc"+1);
^
0x83d85d maybe_constant_value(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.c:3642
0x78a0bc cp_convert_and_check(tree_node*, tree_node*, int)
../../gcc/gcc/cp/cvt.c:639
0x636331 convert_like_real
../../gcc/gcc/cp/call.c:6565
0x63721c perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/call.c:9405
0x7779e3 check_return_expr(tree_node*, bool*)
../../gcc/gcc/cp/typeck.c:8713
0x7b217e finish_return_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:887
0x735bc8 cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:11061
0x735bc8 cp_parser_statement
../../gcc/gcc/cp/parser.c:9711
0x736162 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:10099
0x7362bb cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:10053
0x74b03b cp_parser_function_body
../../gcc/gcc/cp/parser.c:19185
0x74b03b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:19221
0x7558ba cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:23464
0x756733 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:23376
0x756733 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:17055
0x757ccc cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11592
0x758023 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11466
0x760599 cp_parser_declaration
../../gcc/gcc/cp/parser.c:11363
0x76081a cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11249
0x760b2f cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4100
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 tree-optimization/48165] New: gcc-4.6: internal compiler error: in build2_stat

[holger.hopp at sap dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48165

   Summary: gcc-4.6: internal compiler error: in build2_stat
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: holger.h...@sap.com


gcc-4.6 and trunk (rev. 171047) throw an internal compiler error.

$ g++ -O2 -c t.cpp
t.cpp: In function ‘void bar(void*)’:
t.cpp:31:6: internal compiler error: in build2_stat, at tree.c:3799
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

-O0 runs fine,
platform: linux, x86_64, but probably platform-independent


source t.cpp:

typedef long unsigned int size_t;

extern "C" {

extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__, __artificial__)) void *
memcpy (void *__restrict __dest, __const void *__restrict __src, size_t __len)
throw ()
{
  return __builtin___memcpy_chk (__dest, __src, __len, __builtin_object_size
(__dest, 0));
}
}

typedef char TCODE[20];
typedef TCODE TCODE_ARRAY[5];
typedef struct PARAM
{
  TCODE_ARRAY tcode;
} PARAM;

static void foo (void* p)
{
  char buffer[4+sizeof(PARAM)];
  PARAM *param = (PARAM *)(buffer + 4);
  int i;

  for (i=0; i < 5; i++)
{
  memcpy( param->tcode[i], p, 20 );
}
}

void bar (void* p)
{
  foo (p);
}

[Bug regression/48249] New: gcc-4.6: __builtin___memmove_chk wrong results

[holger.hopp at sap dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48249

   Summary: gcc-4.6: __builtin___memmove_chk wrong results
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: holger.h...@sap.com


__builtin___memmove_chk produces wrong results if src and dest are
overlapping (gcc-4.6 rev. 171299 and trunk):

this is already wrong (source mm.c):

typedef long unsigned int size_t;

extern __inline __attribute__ ((__always_inline__)) __attribute__
((__artificial__)) void *
__attribute__ ((__nothrow__)) memmove (void *__restrict __dest, __const void
*__restrict __src, size_t __len)
{
  return __builtin___memmove_chk (__dest, __src, __len, __builtin_object_size
(__dest, 0));
}

void memmove2 (void *dest, const void *src, size_t n)
{
  memmove (dest, src, n);
}


correct test program that triggers wrong results (source m.c):

#include 
#include 

void memmove2 (void *dest, const void *src, size_t n);

int main()
{
  char s[50];
  strcpy (s, "abcdefghijklmnop");
  memmove2 (s+2, s, 14);
  printf ("%s\n", s);
  return 0;
}


reproduce (linux, x86_64):

$ gcc-4.6 -O2 -c mm.c -o mm46.o
$ gcc-4.5 -O2 -c mm.c -o mm45.o

gcc-4.6 is wrong:
$ gcc-4.6 m.c mm46.o && ./a.out
abababefefijklmn

gcc-4.5 produces correct result:
$ gcc-4.6 m.c mm45.o && ./a.out
ababcdefghijklmn

[Bug regression/48570] New: gcc-4.6: wrong subscription with -std=c++0x

[holger.hopp at sap dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570

   Summary: gcc-4.6: wrong subscription with -std=c++0x
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: holger.h...@sap.com


gcc-4.6 and trunk produce wrong results here.
I expect return 1 (==), but gcc-4.6 and trunk return 0 (!=).

$ g++ -std=c++0x t.c && ./a.out

gcc-4.5 and gcc-4.6 without -std=c++0x work correctly,
char type works correctly, but not wchar_t, char16_t, char32_t.


int main()
{
  wchar_t z = (L"01234")[1];
  return (z == L'1');
}