[Bug target/114679] New: .file directive missing on MIPS ports when debug symbols are enabled.

[jan.smets at nokia dot com via Gcc-bugs]

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

Bug ID: 114679
   Summary: .file directive missing on MIPS ports when debug
symbols are enabled.
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

I noticed that the .file directive prints differently on targets (mips vs x86)
when (dwarf) debug symbols are enabled.

output_file_directive() strips the directories and calls
output_source_filename()
For most targets (that do not define a TARGET_ASM_OUTPUT_SOURCE_FILENAME) that
is default_asm_output_source_filename(), which prints the directory stripped
filename. 
(.file X.c , without a number)

For MIPS, TARGET_ASM_OUTPUT_SOURCE_FILENAME is mips_output_filename().
mips_output_filename() defers the writing of .file to dwarf2out when debug
symbols are enabled, otherwise it prints the directory stripped file as ".file
N X.c"

Essentially we're missing the ".file" on MIPS when debug symbols are enabled.


gcc version 12.2.0 (Debian 12.2.0-14)


mkdir -p /tmp/a/b/c
echo 'void test(void){}' > /tmp/a/b/c/test.c
$GCC \
 -o /tmp/out -S \
  -g0 (or -g)  \
 -ffile-prefix-map=/tmp/a/= \
  -c /tmp/a/b/c/test.c \
head -n1 /tmp/out



X86 vs MIPS , -g0 
<   .file   "test.c"
---
>   .file   1 "test.c"

X86 vs MIPS, -g

<   .file   "test.c"
---
>   

Can we have MIPS behave similar to other targets? 

Ideally I would like .file to have "b/c/test.c" instead of just "test.c", but
that's perhaps a different discussion.

diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index ce764a5cb35..210b87a85d8 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
@@ -9756,11 +9756,7 @@ mips_output_external (FILE *file, tree decl, const char
*name)
 static void
 mips_output_filename (FILE *stream, const char *name)
 {
-  /* If we are emitting DWARF-2, let dwarf2out handle the ".file"
- directives.  */
-  if (dwarf_debuginfo_p ())
-return;
-  else if (mips_output_filename_first_time)
+  if (mips_output_filename_first_time)
 {
   mips_output_filename_first_time = 0;
   num_source_filenames += 1;

[Bug sanitizer/103730] ubsan: store with insufficient space for an object of type

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #2 from Jan Smets  ---
PEBKAC. Thanks for clarifying.

[Bug sanitizer/103730] New: ubsan: store with insufficient space for an object of type

[jan.smets at nokia dot com via Gcc-bugs]

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

Bug ID: 103730
   Summary: ubsan: store with insufficient space for an object of
type
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Following testcase produces an ubsan runtime error in GCC 10.2/11.3/trunk

gcc test.c -o /tmp/test -O2 -Wall -Wextra -fsanitize=undefined && /tmp/test


typedef int (logger_args_to_string)(void *event, void *pEntry);
typedef struct logger_msginfo
{
#if 1 // OK when excluded
void *test;
#endif
logger_args_to_string *Fn;
} logger_msginfo;

logger_msginfo x;
logger_msginfo *logger = 

void call( void )
{
logger->Fn = (logger_args_to_string*) 0x1234; // Happy
((logger_msginfo *) & logger[0])->Fn = (logger_args_to_string*) 0x1234; //
Happy
((logger_msginfo *) & logger)->Fn = (logger_args_to_string*) 0x1234; //
store with insufficient space... , trunk gives array-bounds warning here too -
but not on the line above.
}

int main(void) {
call();
return 0;
}

[Bug middle-end/70871] questionable optimisation in fold-const.c

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #6 from Jan Smets  ---
Sounds good. I appreciate the follow-up, thanks you for that.

[Bug tree-optimization/100653] usage of scalar_storage_order produces incorrect result

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #3 from Jan Smets  ---
Is there some way there can be warned against such invalid usages? Because
these things are really hard to see on a 'macro' level.

[Bug c/100671] override-init suppressed in 'two shot' compilation when initializer macro/value is defined in system header file

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #1 from Jan Smets  ---
Another one we've had problems with is quite similar. The example below is a
void function trying to return a value. 

#if 1
  /* NULL defined in a system header file
=> warning in "one shot" compilation.
=> no warning in "two shot" compilation. */
  #include 
#else
  /* always warns */
  #define NULL (0L)
#endif

void test(void)
{
return NULL;
}

[Bug c/100671] New: override-init suppressed in 'two shot' compilation when initializer macro/value is defined in system header file

[jan.smets at nokia dot com via Gcc-bugs]

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

Bug ID: 100671
   Summary: override-init suppressed in 'two shot' compilation
when initializer macro/value is defined in system
header file
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

This test case reports a override-init error when doing a "one step"
compilation.

A "two shot" (preprocesing + compilation, eg, what distcc does) reports no
error when the initializer (macro) value is defined in a system header file.

I don't know if this is related, but the diagnostics point towards the value
and not the duplicate index. 


#if 1
  /* NULL defined in a system header file
=> warning in "one shot" compilation.
=> no warning in "two shot" compilation. */
  #include 
#else
  /* always warns */
  #define NULL (0L)
#endif

void*table[] =
{
[0] NULL,
[0] NULL,
};


echo "One shot"
gcc -c test.c -Woverride-init -o /dev/null

echo "Two shot"
gcc -c test.c -Woverride-init -o test.i -E
gcc -c test.i -o /dev/null  -Woverride-init

[Bug tree-optimization/100653] New: usage of scalar_storage_order produces incorrect result

[jan.smets at nokia dot com via Gcc-bugs]

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

Bug ID: 100653
   Summary: usage of scalar_storage_order produces incorrect
result
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

Created attachment 50840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50840=edit
scalar_storage_order test case

Attached test case produces invalid results with -O2, good with -O1.

Known to fail : 11.1 10.3 9.3 8.5 7.5
Known to work: 6.5 
Target: x86_64-linux-gnu

$ gcc test.c -o /tmp/test -O2 -Wall -Wextra && /tmp/test
a0a1e01 EQ? 11e0a0a 0
$ gcc test.c -o /tmp/test -O1 -Wall -Wextra && /tmp/test
a0a1e01 EQ? a0a1e01 1

Thank you

[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #10 from Jan Smets  ---
I have a couple of changes in my own tree. I had a couple of different issues
and I don't recall exactly what change was for what specifically.

I locally have a revert of 0d48e8779c6a9ac88f5efd1b4a2d40f43ef75faf "Support
string locations for C++ in -Wformat (PR c++/56856)" , plus the ugly hack patch
from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96940

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #15 from Jan Smets  ---
Thanks. See 98018.

[Bug target/98018] New: Option to force frame pointer

[jan.smets at nokia dot com via Gcc-bugs]

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

Bug ID: 98018
   Summary: Option to force frame pointer
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

As discussed in PR 97902 we'd need an option that disables all optimizations
that may affect the generation of a frame pointer.

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #13 from Jan Smets  ---
H.J, There are still some very basic backtrace implementations that rely on
frame pointers. (No DWARF based things or any other forms of 'assistance'). A
missing stack frame means the "previous" function is not visible in the trace.
That makes it fairly useless.

We do explicitly disable a (partial)inlining, sibling calls, use
-fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer. The latter two
options makes someone (perhaps incorrectly) assume that frame pointers are not
being omitted.

I understand, technically, they're not being omitted because there is no stack
usage to begin with... If a new option -fforce-frame-pointer is what is
required, then so be it, but I personally think it just adds more confusion on
what (no-)omit-frame-(leaf-)pointer does.  All I want are stack frames :-)

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

[jan.smets at nokia dot com via Gcc-bugs]

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

Jan Smets  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #6 from Jan Smets  ---
As discussed on IRC, Martin asked to reopen:  The frame pointer is required for
backtracing on some embedded platforms.

[Bug middle-end/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #2 from Jan Smets  ---
Apologies, I omitted the -O1 / -O2 

$ docker run --privileged --rm -it -v /tmp:/tmp gcc:10.2 bash -c "gcc -c
/tmp/test4.c -S -o - -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
| grep rbp"

$ docker run --privileged --rm -it -v /tmp:/tmp gcc:7.5 bash -c "gcc -c
/tmp/test4.c -S -o - -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
| grep rbp"
pushq   %rbp
movq%rsp, %rbp
popq%rbp
popq%rbp

[Bug middle-end/97902] New: x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

[jan.smets at nokia dot com via Gcc-bugs]

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

Bug ID: 97902
   Summary: x86 frame pointer missing with -fno-omit-frame-pointer
(-mno-omit-leaf-frame-pointer)
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

int strcmpTEST(
const char * s1,
const char * s2)
{
while (*s1++ == *s2++)
if (*(s1-1) == '\0')
return (0);

return (*(s1-1) - *(s2-1));
}

Target: x86_64-linux-gnu

GCC 6.5/7.5: OK 
GCC 8.1/8.4/9.3/10.2: Missing.

[Bug middle-end/97617] missing aggressive loop optimization warning in C++

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #3 from Jan Smets  ---
Sorry, I was too quickly in my wording to "skip single_exit()", of course that
edge is still required.

[Bug middle-end/97617] missing aggressive loop optimization warning in C++

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #2 from Jan Smets  ---
Is it maybe a possibility to report the (possible) false positives with
something like -Waggressive-loop-optimizations=2 ? 

Would that only require a skip of single_exit() in
do_warn_aggressive_loop_optimizations, or is there more to it? 
Thanks

[Bug middle-end/97617] New: missing aggressive loop optimization warning in C++

[jan.smets at nokia dot com via Gcc-bugs]

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

Bug ID: 97617
   Summary: missing aggressive loop optimization warning in C++
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

Created attachment 49458
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49458=edit
testcase

Following testcase produces a compile warning in C, but not C++.

 error: iteration 16 invokes undefined behavior
[-Werror=aggressive-loop-optimizations]

The warning *is* shown when the printf call is removed. (C++)
When compiled as C the warning is always shown.

GCC 10.2, x86_64-linux-gnu

[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute

[jan.smets at nokia dot com]

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

--- Comment #9 from Jan Smets  ---
Thanks for the quick resolution everyone. Our codebase apparenty has a handful
of these issues.

[Bug tree-optimization/97164] New: incorrect offset on structure member where type of that member has aligned attribute

[jan.smets at nokia dot com]

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

Bug ID: 97164
   Summary: incorrect offset on structure member where type of
that member has aligned attribute
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

Created attachment 49256
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49256=edit
testcase

Following testcase produces invalid code with GCC 10.2, 9.3, 8.4, 7.5
Works with GCC 6.5

GCC 6:
movqFPAPools+143752(%rdi), %rax

GCC 10 : 
movqFPAPools+143744(%rbx), %rax


Testcase compiled with : -fno-builtin -nostdinc -march=core2 -m64 -O2 
-mno-red-zone -fno-omit-frame-pointer -Wall -Wextra

Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go
gcc version 10.2.0 (GCC)

[Bug preprocessor/96935] [9 Regression] ICE in subspan, at input.h:69

[jan.smets at nokia dot com]

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

--- Comment #11 from Jan Smets  ---
Thanks. Fix verified.

[Bug tree-optimization/96993] [10/11 Regression] invalid code

[jan.smets at nokia dot com]

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

--- Comment #5 from Jan Smets  ---
Hi Andrew
I agree that __builtin_offsetof would of good use here. However, I believe this
code predates the availability of the builtin (was written around the time we
were using gcc3.4)

[Bug rtl-optimization/96993] [10/11 Regression] invalid code

[jan.smets at nokia dot com]

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

--- Comment #3 from Jan Smets  ---
The testcase has a sign-compare warning that we've traditionally been ignoring
given the ancient codebase. 

warning: operand of ‘?:’ changes signedness from ‘int’ to ‘long unsigned int’
due to unsignedness of other operand [-Wsign-compare]

Changing the testcase From:

 ((address_ != (0L)) ? (tUint8 *)(address_) - (tUint8 *)(&((struct
tmm_blk_free_head_t *)0)->ql.column_list) : (uintptr_t)(0L));

To:

 ((address_ != (0L)) ? (uintptr_t)(tUint8 *)(address_) - (uintptr_t)(tUint8
*)(&((struct tmm_blk_free_head_t *)0)->ql.column_list) : (uintptr_t)(0L));

will generate different code in GCC 10, whereas it generates the same code in
GCC 9 for both forms.
 (with the added casts the generated GCC 10 code is good), 


commit 810c42c38d37317c80b57db0a8b6d8991e78ef50
Author: Richard Biener 
Date:   Mon May 20 12:02:35 2019 +

tree-ssa-structalias.c (find_func_aliases): POINTER_DIFF_EXPR doesn't
produce pointers.

2019-05-20  Richard Biener  

* tree-ssa-structalias.c (find_func_aliases): POINTER_DIFF_EXPR
doesn't produce pointers.
{TRUNC,CEIL,FLOOR,ROUND,EXACT}_{DIV,MOD}_EXPR points to what
the first operand points to.

From-SVN: r271414


I've been trying to get a working/crashing testcase for you, but finding the
right 'input data' to trigger the behavior for my testcase seems a bit
problematic.

[Bug rtl-optimization/96993] New: invalid code

[jan.smets at nokia dot com]

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

Bug ID: 96993
   Summary: invalid code
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

Created attachment 49203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49203=edit
testcase

Following testcase produces invalid code in 10.1, 10.2. Works with 9.3. 

%rdi is sometimes invalid in call to listReplaceEntry()   (is 0x8)
(or if listReplaceEntry() would always return, it would crash on mov   
0x18(%rbx),%rbx right before constructing %rdi for the call (%rbx is zero on
second loop iteration)

Adding simple code changes, like a asm("nop") before if (b_rep), makes it
produce working code.

Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go

Compile testcase with -O2 [-fno-omit-frame-pointer]

[Bug preprocessor/96940] ICE in linemap_compare_locations, at libcpp/line-map.c:1359

[jan.smets at nokia dot com]

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

--- Comment #2 from Jan Smets  ---
This is the workaround I currently have. It avoids calling min_location().

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 90111e4c786..f49019e81d0 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -11005,8 +11005,11 @@ grokdeclarator (const cp_declarator *declarator,
   if (initialized > 1)
 funcdef_flag = true;

-  location_t typespec_loc = smallest_type_location (type_quals,
+  location_t typespec_loc = smallest_type_quals_location (type_quals,
declspecs->locations);
+  // using smallest_type_quals_location() iso. smallest_type_quals_location()
+  //  basically removes the usage of min_location on the result of
smallest_type_quals_location().
+  // typespec_loc = min_location (typespec_loc,
declspecs->locations[ds_type_spec]);
   if (typespec_loc == UNKNOWN_LOCATION)
 typespec_loc = input_location;

[Bug preprocessor/96940] ICE in linemap_compare_locations, at libcpp/line-map.c:1359

[jan.smets at nokia dot com]

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

--- Comment #1 from Jan Smets  ---
Likely duplicate of Bug 96391
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391)
That one has a testcase for i686-w64-mingw32

[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359

[jan.smets at nokia dot com]

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

Jan Smets  changed:

   What|Removed |Added

 CC||jan.smets at nokia dot com

--- Comment #5 from Jan Smets  ---
Similar issue @ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935
(with bisect to the 'last known good' version)

[Bug preprocessor/96940] New: ICE in linemap_compare_locations, at libcpp/line-map.c:1359

[jan.smets at nokia dot com]

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

Bug ID: 96940
   Summary: ICE in linemap_compare_locations, at
libcpp/line-map.c:1359
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go

Reproduces with:
 10.2, 10.1

Works with:
 9.3, 9.1

Bisect traced it to

commit 4593483f15ca2a82049500b9434e736996bb0891
Author: Paolo Carlini 
Date:   Tue May 14 11:43:55 2019 +

Reapply r270597.

2019-05-14  Paolo Carlini  

PR preprocessor/90382
* decl.c (grokdeclarator): Fix value assigned to typespec_loc, use
min_location.
2019-05-14  Paolo Carlini  

PR preprocessor/90382
* g++.dg/diagnostic/trailing1.C: New test.

From-SVN: r271164




/x/bcm_sdk/sdk/include/shared/bitop.h:73: internal compiler error: in
linemap_compare_locations, at libcpp/line-map.c:1359
   73 |  CONST SHR_BITDCL *c,
  |
0x2233e01 linemap_compare_locations(line_maps*, unsigned int, unsigned int)
/jasmets/git/tools/gcc/libcpp/line-map.c:1359
0x9b9bbb linemap_location_before_p(line_maps*, unsigned int, unsigned int)
/jasmets/git/tools/gcc/gcc/../libcpp/include/line-map.h:1247
0x9a6998 min_location
/jasmets/git/tools/gcc/gcc/cp/decl.c:10641
0x9a6a67 smallest_type_location
/jasmets/git/tools/gcc/gcc/cp/decl.c:10673
0x9a759e grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/jasmets/git/tools/gcc/gcc/cp/decl.c:11009
0xa6115d cp_parser_parameter_declaration_list
/jasmets/git/tools/gcc/gcc/cp/parser.c:22618
0xa60fd2 cp_parser_parameter_declaration_clause
/jasmets/git/tools/gcc/gcc/cp/parser.c:22531
0xa5ea98 cp_parser_direct_declarator
/jasmets/git/tools/gcc/gcc/cp/parser.c:21203
0xa5e8a5 cp_parser_declarator
/jasmets/git/tools/gcc/gcc/cp/parser.c:21069
0xa5da7b cp_parser_init_declarator
/jasmets/git/tools/gcc/gcc/cp/parser.c:20570
0xa5281d cp_parser_simple_declaration
/jasmets/git/tools/gcc/gcc/cp/parser.c:13749
0xa5240a cp_parser_block_declaration
/jasmets/git/tools/gcc/gcc/cp/parser.c:13566
0xa52105 cp_parser_declaration
/jasmets/git/tools/gcc/gcc/cp/parser.c:13438
0xa521ea cp_parser_toplevel_declaration
/jasmets/git/tools/gcc/gcc/cp/parser.c:13466
0xa40e07 cp_parser_translation_unit
/jasmets/git/tools/gcc/gcc/cp/parser.c:4734
0xa926f8 c_parse_file()
/jasmets/git/tools/gcc/gcc/cp/parser.c:44001
0xbc9712 c_common_parse_file()
/jasmets/git/tools/gcc/gcc/c-family/c-opts.c:1190

[Bug preprocessor/96935] ICE in subspan, at input.h:69

[jan.smets at nokia dot com]

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

--- Comment #3 from Jan Smets  ---
A bisect resulted in this commit :

commit 0d48e8779c6a9ac88f5efd1b4a2d40f43ef75faf
Author: David Malcolm 
Date:   Fri Oct 5 19:02:17 2018 +

Support string locations for C++ in -Wformat (PR c++/56856)

-Wformat in the C++ FE doesn't work as well as it could:
(a) it doesn't report precise locations within the string literal, and
(b) it doesn't underline arguments for those arguments
!CAN_HAVE_LOCATION_P,
despite having location wrapper nodes.



Your suggestion doesn't trigger it for me.
I'v  built GCC with -g -O0 , but the standard provided backtrace didn't include
function call arguments.

A printf confirms your suspicion about start.column == 0 
 => start.column=0 literal_length=1

[Bug preprocessor/96935] ICE in subspan, at input.h:69

[jan.smets at nokia dot com]

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

--- Comment #1 from Jan Smets  ---
Proper backtrace (10.2)

x.cpp: In function ‘void a()’:
x.cpp:3: internal compiler error: in subspan, at input.h:69
3 | #define DB_PRINTF(str, fmt, args...) db_printf(indent_len, 50, fmt,
str, ##args)
  |
x.cpp:7: note: in expansion of macro ‘DB_PRINTF’
7 |   DB_PRINTF("", "%llu", 0);
  |
0x168ee7b char_span::subspan(int, int) const
/jasmets/git/tools/gcc/gcc/input.h:69
0x168ee7b get_substring_ranges_for_loc
/jasmets/git/tools/gcc/gcc/input.c:1467
0x168ee7b get_location_within_string(cpp_reader*, string_concat_db*, unsigned
int, cpp_ttype, int, int, int, unsigned int*)
/jasmets/git/tools/gcc/gcc/input.c:1553
0x8fad84 c_get_substring_location(substring_loc const&, unsigned int*)
/jasmets/git/tools/gcc/gcc/c-family/c-common.c:903
0x92e3ad get_corrected_substring
/jasmets/git/tools/gcc/gcc/c-family/c-format.c:4505
0x92e3ad format_type_warning
/jasmets/git/tools/gcc/gcc/c-family/c-format.c:4721
0x93142b check_format_types
/jasmets/git/tools/gcc/gcc/c-family/c-format.c:4266
0x93142b argument_parser::check_argument_type(format_char_info const*,
length_modifier const&, tree_node*&, char const*&, bool, unsigned long&,
tree_node*&, int, char const*, char const*, unsigned int, char)
/jasmets/git/tools/gcc/gcc/c-family/c-format.c:2859
0x9332e0 check_format_info_main
/jasmets/git/tools/gcc/gcc/c-family/c-format.c:3998
0x9332e0 check_format_arg
/jasmets/git/tools/gcc/gcc/c-family/c-format.c:1821
0x92f3a2 check_format_info
/jasmets/git/tools/gcc/gcc/c-family/c-format.c:1543
0x92f3a2 check_function_format(tree_node const*, tree_node*, int, tree_node**,
vec*)
/jasmets/git/tools/gcc/gcc/c-family/c-format.c:1197
0x922f09 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
/jasmets/git/tools/gcc/gcc/c-family/c-common.c:5730
0x77d86f build_over_call
/jasmets/git/tools/gcc/gcc/cp/call.c:8901
0x77f2ea build_new_function_call(tree_node*, vec**, int)
/jasmets/git/tools/gcc/gcc/cp/call.c:4613
0x8baac6 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/jasmets/git/tools/gcc/gcc/cp/semantics.c:2672
0x864abf cp_parser_postfix_expression
/jasmets/git/tools/gcc/gcc/cp/parser.c:7468
0x84d261 cp_parser_unary_expression
/jasmets/git/tools/gcc/gcc/cp/parser.c:8563
0x846d11 cp_parser_cast_expression
/jasmets/git/tools/gcc/gcc/cp/parser.c:9459
0x8473e1 cp_parser_binary_expression
/jasmets/git/tools/gcc/gcc/cp/parser.c:9562

[Bug preprocessor/96935] New: ICE in subspan, at input.h:69

[jan.smets at nokia dot com]

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

Bug ID: 96935
   Summary: ICE in subspan, at input.h:69
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

Following ICE is seen :

x.cpp: In function 'void a()':
x.cpp:3: internal compiler error: in subspan, at input.h:69
3 | #define DB_PRINTF(str, fmt, args...) db_printf(indent_len, 50, fmt,
str, ##args)
  |
x.cpp:7: note: in expansion of macro 'DB_PRINTF'
7 |   DB_PRINTF("", "%llu", 0);
  |


Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go

Compiled with:  -O2 -Wformat 

Reproduces with 
 10.2, 10.1
 9.3, 9.1
Works with
 8.4
 7.5


The reduced testcase is :

#include "x.h"
#define DB_PRINTF(str, fmt, args...) db_printf(indent_len, 50, fmt, str,
##args)
extern "C" void db_printf(unsigned indent_len, unsigned column_split, const
char * fmt, const char * str, ...) __attribute__ ((format (printf, 3, 5)));
void a() {
  unsigned int indent_len = 0;
  DB_PRINTF("", "%llu", 0);
  // preprocesses to: db_printf(indent_len, 50, "%llu", "");
}

But I suspect the testcase is just garbage.

I tried various ways trying to reduce x.h, but even the slightest change makes
the problem go away. "x.h" recursively includes about 200 other header files.
A "flat" x.h (700k lines) (-fdirectives-only) does not reproduce the issue.

This ICE occurs on couple of dozen files in my project. Some print
 "during GIMPLE pass: strlen".

Goes away with --enable-checking=no, but then other problems show up (ICE in
linemap_compare_locations, at libcpp/line-map.c:1359 - which may or may not be
related)

I suppose my next best option is start a bisect between 8.x and 9.x ?

Thanks

[Bug other/81712] gcc does not compile when using glib 2.26 (everything works fine with 2.25)

[jan.smets at nokia dot com]

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

Jan Smets  changed:

   What|Removed |Added

 CC||jan.smets at nokia dot com

--- Comment #7 from Jan Smets  ---
Any chance of the fix being backported to the 6 branch, for the 6.5 release?

[Bug middle-end/82810] New: missed uninitialized variable warning in for/while loop

[jan.smets at nokia dot com]

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

Bug ID: 82810
   Summary: missed uninitialized variable warning in for/while
loop
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

In the following code x clearly is used uninitialized

#include 
int main(void)
{
while (1) 
{   
int x;  
printf("x=%d\n", x); 
x = 0;
}   
return 0;
}

Possibly dup of 82101 ?

[Bug rtl-optimization/80474] [6 regression] ipa-cp wrongly adding LO(symbol) twice

[jan.smets at nokia dot com]

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

--- Comment #17 from Jan Smets  ---
Patch confirmed to work on the original code. Thanks.

[Bug rtl-optimization/80474] [6 regression] ipa-cp wrongly adding LO(symbol) twice

[jan.smets at nokia dot com]

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

--- Comment #11 from Jan Smets  ---
Thanks Eric

[Bug rtl-optimization/80474] ipa-cp wrongly adding LO(symbol) twice

[jan.smets at nokia dot com]

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

--- Comment #7 from Jan Smets  ---
My apologies, somehow I dropped the -mno-abicalls along the road.

$ git status
HEAD detached at gcc-6_3_0-release

configure --target=mips64-linux-gnuabi64 --enable-languages=c (with
binutils/gmp/etc all alread present)

make all-gcc -jN

 ./gcc/xgcc --version
xgcc (GCC) 6.3.0

./gcc/xgcc -B ./gcc  -O2 -fno-reorder-blocks -march=mips2 
-fno-inline-small-functions -mabi=32 -c /tmp/test.c -S -dA -dP  -o -
-mno-abicalls

The output still matches the above output.

Thanks

[Bug rtl-optimization/80474] ipa-cp wrongly adding LO(symbol) twice

[jan.smets at nokia dot com]

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

--- Comment #5 from Jan Smets  ---
We get 'good' code on 7.1/trunk since 

2016-04-29  Patrick Palka    
tree-ssa-threadedge.c (simplify_control_stmt_condition): Split out into ...
simplify_control_stmt_condition_1): ... here.  Recurse into
BIT_AND_EXPRs and BIT_IOR_EXPRs.

but that just makes it latent.

[Bug rtl-optimization/80474] ipa-cp wrongly adding LO(symbol) twice

[jan.smets at nokia dot com]

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

--- Comment #4 from Jan Smets  ---
For the reduced testcase : 

$ mips64-linux-gnuabi64-gcc --version
mips64-linux-gnuabi64-gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406

mips64-linux-gnuabi64-gcc -O2 -fno-reorder-blocks -march=mips2 
-fno-inline-small-functions -mabi=32 -c /tmp/test.c -S -dA -dP  -o - 


 # BLOCK 30 freq:1892 seq:27
 # PRED: 36 [100.0%]
$L34:
 #(jump_insn 153 152 198 (set (pc)
 #(if_then_else (eq (reg:SI 11 $11 [orig:202 prephitmp_65 ] [202])
 #(const_int 0 [0]))
 #(label_ref 187)
 #(pc))) /tmp/test.c:58 472 {*branch_equalitysi}
 # (int_list:REG_BR_PROB 5000 (nil))
 # -> 187)
beq $11,$0,$L29  # 153  *branch_equalitysi  [length = 4]
 #(insn 198 153 712 (set (reg/f:SI 16 $16 [282])
 #(lo_sum:SI (reg/f:SI 16 $16 [283])
 #(symbol_ref:SI ("badFn") [flags 0x41] ))) 300 {*lowsi}
 # (expr_list:REG_EQUAL (symbol_ref:SI ("badFn") [flags 0x41]
)
 #(nil)))
addiu   $16,$16,%lo(badFn)   # 198  *lowsi  [length = 4]


 # BLOCK 38 freq:945 seq:35
 # PRED: 30 [50.0%]
$L29:
 #(jump_insn 189 188 376 (set (pc)
 #(if_then_else (ne (reg:SI 9 $9 [orig:203 _67 ] [203])
 #(const_int 0 [0]))
 #(label_ref 373)
 #(pc))) /tmp/test.c:58 472 {*branch_equalitysi}
 # (int_list:REG_BR_PROB 6446 (nil))
 # -> 373)
bne $9,$0,$L36   # 189  *branch_equalitysi  [length = 4]
 #(insn/s 376 189 515 (set (reg/f:SI 16 $16 [282])
 #(lo_sum:SI (reg/f:SI 16 $16 [283])
 #(symbol_ref:SI ("badFn") [flags 0x41] ))) 300 {*lowsi}
 # (expr_list:REG_EQUAL (symbol_ref:SI ("badFn") [flags 0x41]
)
 #(nil)))
addiu   $16,$16,%lo(badFn)   # 376  *lowsi  [length = 4]


 # BLOCK 71 freq:609 seq:68
 # PRED: 38 [64.5%]
$L36:
$L36:
 #(insn 661 776 377 (set (reg/f:SI 7 $7 [270])
 #(high:SI (symbol_ref/f:SI ("*$LC0") [flags 0x2] ))) /tmp/test.c:58 310 {*movsi_internal}
 # (expr_list:REG_EQUIV (high:SI (symbol_ref/f:SI ("*$LC0") [flags 0x2]
))
 #(nil)))
lui $7,%hi($LC0) # 661  *movsi_internal/4   [length = 4]
 #(insn 377 661 379 (set (mem:SI (plus:SI (reg/f:SI 29 $sp)
 #(const_int 16 [0x10])) [0  S4 A32])
 #(reg/f:SI 16 $16 [282])) /tmp/test.c:58 310 {*movsi_internal}
 # (nil))
sw  $16,16($sp)  # 377  *movsi_internal/11  [length = 4]
...

[Bug rtl-optimization/80474] ipa-cp wrongly adding LO(symbol) twice

[jan.smets at nokia dot com]

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

--- Comment #2 from Jan Smets  ---
Created attachment 41245
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41245=edit
testcase pr80474

-O2 -fno-reorder-blocks -march=mips2  -fno-inline-small-functions
MIPS O32

[Bug rtl-optimization/80474] New: ipa-cp wrongly adding LO(symbol) twice

[jan.smets at nokia dot com]

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

Bug ID: 80474
   Summary: ipa-cp wrongly adding LO(symbol) twice
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

On MIPS, O32
GCC 6.3.1 (does not happen on GCC5, but there it's not similarly optimized by
ipa-cp)

I wasn't yet successful at producing a minimized testcase.

A function is called and one of the arguments is a function pointer.
On mips the symbol is loaded in two steps, the HI and the LO part.
The LO part is an increment and is happening twice, resulting in a bogus
pointer being passed.


409 INITEVENT (PP_MASK_QX,   T01, OUTRESEG_DRAM_DATA_ECC_UNCORRECTABLE_0,
0,1,
"OUTRESEG_DRAM_DATA_ECC_UNCORRE  CTABLE_0", ERROR_EVENT,   
_ext_dram_unc_err, myFunce);
0x04431644 <+11384>: beqzt4,0x4431730 <InitEventNameTables+11620>
0x04431648 <+11388>: addiu   s1,s1,-9260

t4 is zero, so branches to 0x4431730 


 # BLOCK 530 freq:156 seq:526
 # PRED: 543 [69.5%]
$L599:
 #(jump_insn 4608 4607 4691 (set (pc)
 #(if_then_else (eq (reg:SI 12 $12 [orig:1564 _4488 ] [1564])
 #(const_int 0 [0]))
 #(label_ref 4678)
 #(pc))) myfile.c:409 472 {*branch_equalitysi}
 # (int_list:REG_BR_PROB 5000 (nil))
 # -> 4678)
beq $12,$0,$L592 # 4608 *branch_equalitysi  [length = 4]
 #(insn 4691 4608 27788 (set (reg/f:SI 17 $17 [6100])
 #(lo_sum:SI (reg/f:SI 17 $17 [6102])
 #(symbol_ref:SI ("myFunce") [flags 0x3] ))) 300 {*lowsi}
 # (expr_list:REG_EQUAL (symbol_ref:SI ("myFunce") [flags 0x3]
)
 #(nil)))
addiu   $17,$17,%lo(myFunce)# 4691 *lowsi  [length = 4]


s1 is now 0x442dbd4 , which is myFunce()

 77370x04431730 <+11620>: bnezt2,0x4439a0c <InitEventNameTables+45120>
 77380x04431734 <+11624>: addiu   s1,s1,-9260

t2 is 0x2000, so branches to 0x4439a0c and changes s1 from 0x442dbd4 (correct)
to 0x442b7a8 (incorrect)


 # BLOCK 545 freq:78 seq:541
 # PRED: 530 [50.0%] 
$L592:
 #(jump_insn 4680 4679 15195 (set (pc)
 #(if_then_else (ne (reg:SI 10 $10 [orig:456 prephitmp_915 ] [456]) 
 #(const_int 0 [0]))
 #(label_ref 15192) 
 #(pc))) myfile.c:409 472 {*branch_equalitysi}
 # (int_list:REG_BR_PROB 7002 (nil)) 
 # -> 15192) 
bne $10,$0,$L601 # 4680 *branch_equalitysi  [length = 4]
 #(insn/s 15195 4680 4681 (set (reg/f:SI 17 $17 [6100])
 #(lo_sum:SI (reg/f:SI 17 $17 [6102])
 #(symbol_ref:SI ("myFunce") [flags 0x3] ))) 300 {*lowsi}
 # (expr_list:REG_EQUAL (symbol_ref:SI ("myFunce") [flags 0x3]
)
 #(nil)))
addiu   $17,$17,%lo(myFunce)# 15195*lowsi  [length = 4]

[Bug tree-optimization/80032] [6 Regression] C++ excessive stack usage (no stack reuse)

[jan.smets at nokia dot com]

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

--- Comment #12 from Jan Smets  ---
Thanks. I've also been using the patch on the 6 branch and it seems to work
fine as well.

[Bug tree-optimization/80032] [6/7 Regression] C++ excessive stack usage (no stack reuse)

[jan.smets at nokia dot com]

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

--- Comment #9 from Jan Smets  ---
The alternative patch to gimplify.c seems to run fine.
Thanks

[Bug preprocessor/80070] New: -Wmisleading-indentation disabled on -E (or when using distcc)

[jan.smets at nokia dot com]

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

Bug ID: 80070
   Summary: -Wmisleading-indentation disabled on -E (or when using
distcc)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

-Wmisleading-indentation is basically disabled when compile jobs are
distributed using distcc

[Bug tree-optimization/80032] [6/7 Regression] C++ excessive stack usage (no stack reuse)

[jan.smets at nokia dot com]

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

--- Comment #5 from Jan Smets  ---
I think suggested patch might generate bad code. (but hard to track down on my
embedded target, it's stuck at a point where I don't have exceptions/backtraces
available yet).

[Bug c++/80032] New: C++ excessive stack usage (no stack reuse)

[jan.smets at nokia dot com]

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

Bug ID: 80032
   Summary: C++ excessive stack usage (no stack reuse)
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

Created attachment 40959
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40959=edit
testcase

I have a unlucky code pattern that resulted in 10592 bytes stack usage when
built with GCC 6.3, whereas it only used 304 bytes when compiled with GCC 5.4.

gcc-5 (Ubuntu 5.4.1-8ubuntu1) 5.4.1 20170304
gcc (Ubuntu 6.3.0-8ubuntu1) 6.3.0 20170221

Attached is a C-Reduced testcase. If the if() block is repeated multiple times
the stack increases more. Looks as if stack isn't reused.

if() block occurs 
 1x : GCC5:  96 bytes , GCC6:  96 bytes
 2x : GCC5: 112 bytes , GCC6: 176 bytes
10x : GCC5: 112 bytes , GCC6: 688 bytes

Testcase compiled with : -fstack-usage -std=c++11 -O2 -Wall

Using -fstack-reuse=none gives GCC 5 the same stack usage as GCC 6.

I think this is a regression.

[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 (could not split insn) on mips* when compiling libstdc++ with -mlong-calls -mno-abicalls

[jan.smets at nokia dot com]

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

--- Comment #4 from Jan Smets  ---
Created attachment 40910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40910=edit
testcase pr79951

mips64-linux-gnuabi64-gcc -xc++ pr79951.i -o /dev/null -S -mlong-calls
-mno-abicalls

[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 (could not split insn) on mips* when compiling libstdc++ with -mlong-calls -mno-abicalls

[jan.smets at nokia dot com]

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

Jan Smets  changed:

   What|Removed |Added

 Target|mips|mips64-linux-gnuabi64
Summary|ICE in final_scan_insn, at  |ICE in final_scan_insn, at
   |final.c:2982 on mips when   |final.c:2982 (could not
   |compiling libstdc++ with|split insn) on mips* when
   |-mlong-calls|compiling libstdc++ with
   ||-mlong-calls -mno-abicalls

--- Comment #3 from Jan Smets  ---
And that was because vxworks defaults to -mno-abicalls.

Thus, the example reproduces on mips64-linux with -mno-abicalls

[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 on mips when compiling libstdc++ with -mlong-calls

[jan.smets at nokia dot com]

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

--- Comment #2 from Jan Smets  ---
Reduced test case, only occurs on the vxworks port, not on linux.

namespace a {
template  class c;
class d {
public:
  virtual ~d();
};
template  class e : d {};
template  class c : virtual e {};
class g : c {
  ~g();
};
g::~g() {}
}

[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 on mips with -mlong-calls

[jan.smets at nokia dot com]

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

--- Comment #1 from Jan Smets  ---
Sorry, copy/pasted incorrect libtool compile, it's the one of
libstdc++-v3/src/c++98/strstream.cc
Also, occurs at any optimisation level.

libtool: compile:  /jasmets/git/tools/toolchains/gcc6/gcc-builddir/./gcc/xgcc
-shared-libgcc -B/jasmets/git/tools/toolchains/gcc6/gcc-builddir/./gcc
-nostdinc++ -L/jasm
ets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/long-calls/O0/libstdc++-v3/src
-L/jasmets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/long
-calls/O0/libstdc++-v3/src/.libs
-L/jasmets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/long-calls/O0/libstdc++-v3/libsupc++/.libs
-B/jasmets/git/tools/t
oolchains/gcc6/prefix/mips-wrs-vxworks/bin/
-B/jasmets/git/tools/toolchains/gcc6/prefix/mips-wrs-vxworks/lib/ -isystem
/jasmets/git/tools/toolchains/gcc6/prefix/mips-wr
s-vxworks/include -isystem
/jasmets/git/tools/toolchains/gcc6/prefix/mips-wrs-vxworks/sys-include -mabi=64
-mlong-calls -O0 -I/jasmets/git/tools/toolchains/gcc6/gcc-bui
lddir/gcc-6.3.1/libstdc++-v3/../libgcc
-I/jasmets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/long-calls/O0/libstdc++-v3/include/mips-wrs-vxworks
-I/jasm
ets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/long-calls/O0/libstdc++-v3/include
-I/jasmets/git/tools/toolchains/gcc6/gcc-builddir/gcc-6.3.1/libstdc++-
v3/libsupc++ -std=gnu++98 -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -
frandom-seed=strstream.lo -O2 -fno-optimize-sibling-calls -fno-partial-inlining
-fasynchronous-unwind-tables -mabi=64 -mlong-calls -O0
-I/jasmets/git/tools/toolchains/g
cc6/gcc-builddir/mips-wrs-vxworks/64/long-calls/O0/libstdc++-v3/include/backward
-Wno-deprecated -c
../../../../../../.././gcc-6.3.1/libstdc++-v3/src/c++98/strstream.cc -o
strstream.o

[Bug middle-end/79915] New: ICE in final_scan_insn, at final.c:2982 on mips with -mlong-calls

[jan.smets at nokia dot com]

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

Bug ID: 79915
   Summary: ICE in final_scan_insn, at final.c:2982 on mips with
-mlong-calls
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

During compilation of libstdc++-v3 with -mlong-calls 
Occurs on mips O32, N32, 64.
In both GCC5 and 6.
Target I used is a modified mips-wrs-vxworks target with added long-calls
multilibs.
(the prototype for write() is 


libtool: compile:  /jasmets/git/tools/toolchains/gcc6/gcc-builddir/./gcc/xgcc
-shared-libgcc -B/jasmets/git/tools/toolchains/gcc6/gcc-builddir/./gcc
-nostdinc++ -L/jasm
ets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/64-long/libstdc++-v3/src
-L/jasmets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/64-long/li
bstdc++-v3/src/.libs
-L/jasmets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/64-long/libstdc++-v3/libsupc++/.libs
-B/jasmets/git/tools/toolchains/gcc6/pre
fix/mips-wrs-vxworks/bin/
-B/jasmets/git/tools/toolchains/gcc6/prefix/mips-wrs-vxworks/lib/ -isystem
/jasmets/git/tools/toolchains/gcc6/prefix/mips-wrs-vxworks/include
-isystem /jasmets/git/tools/toolchains/gcc6/prefix/mips-wrs-vxworks/sys-include
-mabi=64 -mlong-calls
-I/jasmets/git/tools/toolchains/gcc6/gcc-builddir/gcc-6.3.1/libstd
c++-v3/../libgcc
-I/jasmets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/64-long/libstdc++-v3/include/mips-wrs-vxworks
-I/jasmets/git/tools/toolchains/gcc
6/gcc-builddir/mips-wrs-vxworks/64/64-long/libstdc++-v3/include
-I/jasmets/git/tools/toolchains/gcc6/gcc-builddir/gcc-6.3.1/libstdc++-v3/libsupc++
-std=gnu++98 -fno-imp
licit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=c++locale.lo -O2 -fno
-optimize-sibling-calls -fno-partial-inlining -fasynchronous-unwind-tables
-mabi=64 -mlong-calls -fimplicit-templates -c c++locale.cc -o c++locale.o
../../../../../.././gcc-6.3.1/libstdc++-v3/src/c++98/strstream.cc: In member
function 'virtual void std::istrstream::_ZTv0_n24_NSt10istrstreamD1Ev()':
../../../../../.././gcc-6.3.1/libstdc++-v3/src/c++98/strstream.cc:417:1: error:
could not split insn
 } // namespace
 ^
(insn 5 4 6 (set (reg:DI 2 $2)
(high:DI (symbol_ref:DI ("*$LTHUNK0") [flags 0x203] )))
/jasmets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks
/64/64-long/libstdc++-v3/include/backward/strstream:131 286 {*lea_high64}
 (nil))
../../../../../.././gcc-6.3.1/libstdc++-v3/src/c++98/strstream.cc:417:1:
internal compiler error: in final_scan_insn, at final.c:2982
0xa26ac3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
.././gcc-6.3.1/gcc/rtl-error.c:108
0x7f3b2b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.././gcc-6.3.1/gcc/final.c:2982
0x7f3d9f final(rtx_insn*, _IO_FILE*, int)
.././gcc-6.3.1/gcc/final.c:2045
0xd045ca mips_output_mi_thunk
.././gcc-6.3.1/gcc/config/mips/mips.c:17514
0x721604 cgraph_node::expand_thunk(bool, bool)
.././gcc-6.3.1/gcc/cgraphunit.c:1647
0x722072 cgraph_node::assemble_thunks_and_aliases()
.././gcc-6.3.1/gcc/cgraphunit.c:1923
0x7220d7 cgraph_node::assemble_thunks_and_aliases()
.././gcc-6.3.1/gcc/cgraphunit.c:1941
0x722630 cgraph_node::expand()
.././gcc-6.3.1/gcc/cgraphunit.c:2053
0x723bb3 expand_all_functions
.././gcc-6.3.1/gcc/cgraphunit.c:2126
0x723bb3 symbol_table::compile()
.././gcc-6.3.1/gcc/cgraphunit.c:2482
0x72532f symbol_table::finalize_compilation_unit()
.././gcc-6.3.1/gcc/cgraphunit.c:2572
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.