[Bug c++/93399] New: Annotate assembler option failure

[jamesgua at ca dot ibm.com]

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

Bug ID: 93399
   Summary: Annotate assembler option failure
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamesgua at ca dot ibm.com
  Target Milestone: ---

With g++ 8.3.1 version 
GNU C++14 (GCC) version 8.3.1 20190507 (Red Hat 8.3.1-4) (x86_64-redhat-linux)
compiled by GNU C version 8.3.1 20190507 (Red Hat 8.3.1-4), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP
test case to reproduce:

#include 
#include 
#include 

int main(int argc, char** argv) {
char* substr = strstr(argv[0], "\n");
char* another = strstr(argv[0], "\r\n");
//printf("found sub string len %d\n", strlen(substr));
//std::cout << "found sub string len " << strlen(substr) << "\n" <<
std::endl; 
return 0;
}

failing cmd: 
g++ -fverbose-asm -dA -g -O3 -c test.cpp
it's working with older version, g++ 4.8.5, or we can bypass failure with cmd: 
g++ -fverbose-asm -g -O3 -c test.cpp

[Bug c++/61574] New: Confusing .debug_line generation by -g option

[jamesgua at ca dot ibm.com]

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

Bug ID: 61574
   Summary: Confusing .debug_line generation by -g option
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamesgua at ca dot ibm.com

#include 
#include 

using namespace std;

int main(int argc, char** argv)
{
  string str1 = "Hello";
  string str2;

  str2 = str1;
  cout << "str2: " << str2 << ", and same as str1: " << str1 << endl;

  str2 += "World!";
  cout << "Now str2: " << str2 << endl;

  return 0;
}

g++ -g -osample sample.cpp
gdb ./sample
...
Breakpoint 1, main (argc=1, argv=0x34f8) at sample.cpp:17
17return 0;
(gdb) n
9 string str2;
(gdb)
17return 0;
(gdb)
18  }
...
This is really confusing and out of sequential execution expectation. It
happens on x86_64/ppcl4le platform using g++ 4.8.2. 
Output from cmd: readelf --debug-dump=decodedline sample
...
sample.cpp17  0x1e90
sample.cpp 9  0x1e94
sample.cpp17  0x1ea4
sample.cpp 9  0x1ee4
sample.cpp17  0x1efc
...

[Bug c++/61574] Confusing .debug_line generation by -g option

[jamesgua at ca dot ibm.com]

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

--- Comment #2 from jamesgua at ca dot ibm.com ---
(In reply to Andrew Pinski from comment #1)
> This is deconstructors.

I mean why we have those line numbers "17 9 17 9 17", debugger follow the line
number information and user may think the program running backward instead the
incremental way. This is not intuitive.

[Bug c++/61574] Confusing .debug_line generation by -g option

[jamesgua at ca dot ibm.com]

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

--- Comment #4 from jamesgua at ca dot ibm.com ---
Found the same issue with G++ 4.6.1 on zLinux.

[Bug debug/65934] New: objdump can't print correct DW_AT_encoding name

[jamesgua at ca dot ibm.com]

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

Bug ID: 65934
   Summary: objdump can't print correct DW_AT_encoding name
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamesgua at ca dot ibm.com
  Target Milestone: ---

In DWARF 4 spec DW_ATE_UTF is value 0x10 or 16, but objdump can't map that
value to UTF, instead, print "unknown type":

e.g.
char16_t utf16 = u'a';
...
<3><148>: Abbrev Number: 7 (DW_TAG_variable)
<149>   DW_AT_name: (indirect string, offset: 0x139): utf16
<14d>   DW_AT_decl_file   : 1
<14e>   DW_AT_decl_line   : 9
<14f>   DW_AT_type: <0x178>
<153>   DW_AT_location: 3 byte block: 91 de 7e  (DW_OP_fbreg: -162)
...
<1><178>: Abbrev Number: 2 (DW_TAG_base_type)
<179>   DW_AT_byte_size   : 2
<17a>   DW_AT_encoding: 16  (unknown type)
<17b>   DW_AT_name: (indirect string, offset: 0x13f): char16_t

It should be displayed UTF like similar to other values 
...
<1c8>   DW_AT_encoding: 7   (unsigned)

[Bug c/98209] New: printf failed with O1 or above

[jamesgua at ca dot ibm.com via Gcc-bugs]

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

Bug ID: 98209
   Summary: printf failed with O1 or above
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamesgua at ca dot ibm.com
  Target Milestone: ---

Testing file:

#include 

int main(int argc, char** argv) __attribute__ ((__target__ ("no-sse,no-mmx"))); 
int main(int argc, char** argv)
{
printf("hello!\n");
return 0;
} 

cmd to compile: gcc -O3 -c test.c
On Ubuntu 20.04 (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) it failed
with "inlining failed in call to always_inline printf’: target specific option
mismatch" but it works on Ubuntu 16.04 (gcc version 5.4.0 20160609 (Ubuntu
5.4.0-6ubuntu1~16.04.12))

If not supported pls let me know.

[Bug c/98209] printf failed with O1 or above

[jamesgua at ca dot ibm.com via Gcc-bugs]

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

--- Comment #2 from jamesgua at ca dot ibm.com ---
Created attachment 49709
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49709&action=edit
preprocessed src file gcc -E

[Bug middle-end/98209] [8/9/10/11 Regression] printf failed with O1 or above

[jamesgua at ca dot ibm.com via Gcc-bugs]

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

--- Comment #8 from jamesgua at ca dot ibm.com ---
one more function found the same issue:
memcpy
I guess more functions in libc might have same issue.