[Bug c++/94454] ICE 'canonical types differ for identical types'

[nathan at acm dot org]

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

--- Comment #6 from Nathan Sidwell  ---
On 4/2/20 12:37 PM, iains at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454
> 
> --- Comment #5 from Iain Sandoe  ---
> (In reply to Nathan Sidwell from comment #4)
>> Oh, it is from the template specialization hash table.  I suggest making
>> that very poor to increase collisions:
>>
>> pt.c:
>> static hashval_t
>> hash_tmpl_and_args (tree tmpl, tree args)
>> {
>>hashval_t val = iterative_hash_object (DECL_UID (tmpl), 0);
>> return val; // INSERT THIS LINE
>>return iterative_hash_template_arg (args, val);
>> }
>>
>> sorry for not realizing this earlier
> 
> [not wishing to disturb the c-reduce sessions already started]
> 
> On Darwin17 @r10-7488, which was always succeeding
> 
> I bootstrapped with this patch, and then built a --disable-bootstrap with the
> "spec_hasher::hash always returns 0" applied too.

Ok, BTW spec_hasher::hash forwards to hash_tmpl_and_args.  They must 
agree, so ...

> Neither made any difference, the entire ranges-v3 suite built without issue.

surprises me.

> 
> Maybe that's informative in its own right.
> 
> Will hopefully have some kind of reduced test-case for x86-64-linux tomorrow.
>

[Bug c/53890] New: bogus array bounds warning

[nathan at acm dot org]

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

 Bug #: 53890
   Summary: bogus array bounds warning
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nat...@acm.org


Created attachment 27761
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27761
test case

compile the attached with:
./cc1 ary.cc -O2 -Wall -quiet

(don't worry that it's a .cc file, I found the bug in c++ code, but it
manifests in both C and C++ compilers)

see following warning:

ary.cc: In function 'Foo':
ary.cc:12:6: warning: array subscript is above array bounds [-Warray-bounds]
   tmp[jx] = 4;
  ^

This is incorrect, the compiler cannot deduce that jx is out of range at this
point -- indeed in correct calls of Foo it won't be.

[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure

[nathan at acm dot org]

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

--- Comment #8 from Nathan Sidwell  2011-11-15 20:12:33 
UTC ---
On 11/15/11 10:03, markus at trippelsdorf dot de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113
>

> With your patch:
>   % c++ -shared -w -o /dev/null -fPIC -fno-rtti -pthread -pipe
> -fprofile-generate -O0 test.ii
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> error: /tmp/cciGbsuB.o: requires dynamic R_X86_64_PC32 reloc against
> '__gcov0__ZnwmPv' which may overflow at runtime; recompile with -fPIC

Ok, I think I understand what's going on here.  Here's a piece of code to
explain:

inline int *Foo ()
{
   static int x = 2;

   return &x;
}

int *(*Bar ()) ()
{
   return Foo;
}

although Foo::x is in the same comdat group as Foo, it is separately
overridable 
at load time by another shared object.  (of course such overriding completely 
breaks language semantics, but not ELF semantics).  The linker's adhering to
ELF 
semantics, and in this example the compiler emits:
movq_ZZ3FoovE1x@GOTPCREL(%rip), %rax
to get Foo::x's address.  In the gcov case, it's emitting:
movq__gcov0_js_malloc(%rip), %rax
to access the first counter value.  Although I think that's ok in a well-formed 
program, it's confusing the linker.  that's unfortunate. (If you compile the 
above example with -fprofile-generate you'll see different access sequences for 
_ZZ3FoovE1x and __gcov0__Z3Foov.)

I'm going to have to figure out why the right PIC sequence isn't being emitted.

[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9

[nathan at acm dot org]

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

--- Comment #6 from Nathan Sidwell  2011-11-24 21:36:20 
UTC ---
On 11/24/11 19:46, ebotcazou at gcc dot gnu.org wrote:

> In fact the array is empty:
>
> (gdb) p n_names
> $1 = 0
> (gdb) p names
> $2 = (name_map_t *) 0x0

d'oh!  A fix will be right up.

[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9

[nathan at acm dot org]

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

--- Comment #8 from Nathan Sidwell  2011-11-24 22:12:11 
UTC ---
On 11/24/11 21:54, ebotcazou at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
>
> --- Comment #7 from Eric Botcazou  2011-11-24 
> 21:54:15 UTC ---
>> d'oh!  A fix will be right up.
>
> Thanks.  I confirm that adding if (n_names>  0) in the right places works 
> fine.

Hm, can you try the attached patch?  It avoids passing a null pointer, which is 
not permitted.  Passing zero as nmemb is permitted (7.20.5 para 1 of c99).  So 
I'm a little puzzled as to why bsearch managed to call the comparison function 
at all.  I'd like to understand if we're dealing with a weird, but legal, 
implementation, or one that's got a bug.

[Bug tree-optimization/91898] New: [optimization] switch statements for state machines could be better

[nathan at acm dot org]

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

Bug ID: 91898
   Summary: [optimization] switch statements for state machines
could be better
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at acm dot org
  Target Milestone: ---

Interesting talk at cppcon'19 by Miro Knejp 'Non-conforming C++: the Secrets
the Committee Is Hiding From You'  It'll be on youtube at some point.


This PR concerns his observations about a common VM implementation technique.

We have an array of instructions, and we execute these one after eachother. 
The natural way to write this would be:

for (int index = 0; ; index++)
  switch (insns[index]) {
case ADD: ... break;
case SUB: ... break;
...
case END: goto end;
 } end:;

this leads to code gen that looks like:

loop:
  r = insn[index];
  index = index + 1;
  [range check on r]
  addr = jmptable[r];
  jmp [addr];
ADD: ...
  jmp loop

etc.  This performs poorly because all the dispatches go through the single
jmp[addr] instruction, and the CPU's indirect branch predictor has no idea
where it'll go.  But there are patterns in the sequence of virtual
instructions, just as there are in real code!

Hence, people use the GCC label-address extension and write:
static void *const dispatch[] = {&&ADD, &&SUB, ... };

index = 0; goto *dispatch[insn[index++]];

ADD: ... goto *dispatch[insn[index++]];
SUB: ... goto *dispatch[insn[index++]];

code generation looks like:

ADD: ...
   r = insn[index];
   index++;
   addr = dispatch[r];
   jmp [addr];

This is faster because there are per-virtual-insn indirect jumps, and the
branch predictor does much better.

(We're also eliding the range check, I do not know how much that would cost if
it was added).

Hence, it might be worthwhile duplicating the switch's dispatch logic at the
end of every case block.

[Bug rtl-optimization/91898] [optimization] switch statements for state machines could be better

[nathan at acm dot org]

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

--- Comment #4 from Nathan Sidwell  ---
Created attachment 46941
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46941&action=edit
another example

thanks, yup.

I had a slightly different example ready to go (attached)
Rather than a single switch dispatcher:

.L12:
movl%edx, %eax
movl(%rdi,%rax,4), %eax
andl$7, %eax ; <- masked in source to provide range information
jmp *.L4(,%rax,8)

to which each case block jumps to.  Duplicate that code at the end of each case
block.

[Bug c++/70909] Libiberty Demangler segfaults (4)

[nathan at acm dot org]

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

--- Comment #29 from Nathan Sidwell  ---
On 12/02/2016 12:58 PM, trippels at gcc dot gnu.org wrote:

> Please also note that Nathan's lambda demangling patch needs adjustments,
> because with level 1 of recursion it prints everything twice.

sorry, please clarify.  With what symbol(s)?

nathan

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[nathan at acm dot org]

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

--- Comment #10 from Nathan Sidwell  ---
On 12/05/2016 03:44 PM, jakub at gcc dot gnu.org wrote:

> I thought that such constructs are widely used though, I believe e.g. glibc
> used arrays of structs with flexible array members in several places.  Maybe 
> it
> has changed, I've lost track.  So, before changing anything like that we'd 
> need
> to make sure e.g. glibc still builds.

Remarkable.  I wonder what meaning such code is expected to have. 
Anyway, I've noted on bug 68489.  I guess we want both C & C++ modes to 
agree whether such array types are meaningful.

nathan

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at acm dot org

--- Comment #10 from Nathan Sidwell  ---
What's the visibility on __gcov_merge_add?  All those functions should have
hidden visibility. I see:
extern void __gcov_merge_add (gcov_type *, unsigned) ATTRIBUTE_HIDDEN;

Could you give me the recipe for getting and building firefox in this manner?

To answer the 'how's it supposed to work' question.  Each DSO with coverage
needs contains its own set of gcov routines -- all hidden.  The linkage between
each dso is in the data -- each (compatible) dso chains onto the gcov_master
variable.  That is not hidden, and one will win in the resultant process.  Does
that make sense?

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

--- Comment #13 from Nathan Sidwell  ---
No.  Each dso's gcov machinery is individually invoked.  There should be no
cross-dso accessing of data (beyond the global chain of dso)

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

--- Comment #14 from Nathan Sidwell  ---
Jan, I'm fairly sure that even though your fix makes things work, it is wrong. 
You're  at the very least exposing an internal API across the DSO boundary,
which should not be exposed.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

--- Comment #17 from Nathan Sidwell  ---
I'm having difficulty constructing a testcase that fails.  2 DSOs are isolated
as I expect.  (rong, your description is essentially correct).

A recipe would be good.  Also, is this on gcc trunk or gcc 5.0 branch (or
both?)

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

--- Comment #20 from Nathan Sidwell  ---
Adding a call to __gcov_fork doesn't cause breakage.  I'd much rather start
from a failing testcase than stab in the dark at various hypotheses.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

--- Comment #22 from Nathan Sidwell  ---
thanks Honza, that was helpful. I'm an idiot.  Your workaround unhiding
gcov_var is fine for now, while I figure out if there's a better way.  I am
puzzled as to why I can't observe this failure in the testcase I've
constructed.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

--- Comment #24 from Nathan Sidwell  ---
xur, can you provide your testcase?  with a regular use of multiple DSOs, I
can't get a failure. (no dlopen used).

[Bug c++/97905] [11 Regression] ice in duplicate_decls, at cp/decl.c:2754

[nathan at acm dot org via Gcc-bugs]

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

--- Comment #7 from Nathan Sidwell  ---
On 11/19/20 10:18 AM, dcb314 at hotmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97905
> 
> --- Comment #6 from David Binderman  ---
> (In reply to Nathan Sidwell from comment #5)
>> David, to build just cc1plus: 'make -C gcc cc1plus
>> -j$how_many_cpus_available'
>>
>> pass 'CXXFLAGS=$whatever' to override the default (usually -O2 -g)
> 
> $ cd /home/dcb/gcc/
> $ mkdir working
> $ cd working
> $ ../trunk.git/configure --whatever
> $ ls -l gcc
> ls: cannot access 'gcc': No such file or directory
> 
> Thanks for the tip, but after a configure, there is no gcc directory
> available.
> 
> Does your tip only apply if there is a previous build available
> or have I misunderstood ?

sorry, yes, to just 'rebuild' cc1plus.  You can't just build cc1plus in 
a clean build

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

[nathan at acm dot org via Gcc-bugs]

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

--- Comment #3 from Nathan Sidwell  ---
On 12/16/20 12:26 PM, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98315
> 
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
>> --- Comment #1 from Nathan Sidwell  ---
>> I think this is fixed by
>> 6ff747f023c 2020-12-16 | c++: Fix (some) solaris breakage
>>
>> please let me know
> 
> Unfortunately not: there are still two instances of the problem:


There is another path to get to a poisoned bcopy.  Fixed thusly.

gcc/cp/
 * mapper-resolver.cc: #include sys/socket before system.h
 due to poisoned bcopy use.

pushed to trunk

[Bug bootstrap/98323] current trunk won't build with clang

[nathan at acm dot org via Gcc-bugs]

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

--- Comment #5 from Nathan Sidwell  ---
On 12/16/20 12:45 PM, dcb314 at hotmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98323
> 
> --- Comment #3 from David Binderman  ---
> (In reply to Nathan Sidwell from comment #2)
>> stupid underspecified offsetof
> 
> I did try commenting out the offending block of code and a re-build
> and got further errors ;-<
> 
> I don't know if you have access to clang, but if you don't,
> may I be so bold as to suggest you install a copy and, if
> you have the time, attempt a full build with clang ?

but, but, that'd require me to do actual work !

> 
> That should flush out all the gcc specific code in your recent changes.
> 
> Excellent compiler, BTW.

which, clang or GCC?  (why not both ¯\_(ツ)_/¯)

nathan

[Bug c++/98531] [11 Regression] g++.dg/modules/xtreme-header-2_a.H etc. FAIL

[nathan at acm dot org via Gcc-bugs]

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

--- Comment #8 from Nathan Sidwell  ---
On 1/27/21 8:30 AM, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531
> 
> --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
> Nathan,
> 
> last night I've tried the patch you posted on both i386-pc-solaris2.11
> and sparc-sun-solaris2.11, with mixed results:
> 
> * The new g++.dg/modules/pr98531_* testcases PASS.
> 
> * However, there's a libstdc++ regression:
> 
> +FAIL: 17_intro/headers/c++1998/all_attributes.cc (test for excess errors)
> +FAIL: 17_intro/headers/c++2011/all_attributes.cc (test for excess errors)
> +FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)
> +FAIL: 17_intro/headers/c++2017/all_attributes.cc (test for excess errors)
> 
> Excess errors:
> /vol/gcc/src/hg/master/local/libstdc++-v3/libsupc++/cxxabi.h:129: error:
> declaration of 'int __cxxabiv1::__cxa_atexit(void (*)(void*), void*, void*)
> throw ()' has a different exception specifier

thanks, I'm finding this too -- thankful I didn;t push the patch!  this 
is indicative there is a mismatch between the runtime library and the 
compiler's idea of it.
> 
>i.e.
> 
> In file included from
> /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:40:
> /vol/gcc/src/hg/master/local/libstdc++-v3/libsupc++/cxxabi.h:129: error:
> declaration of 'int __cxxabiv1::__cxa_atexit(void (*)(void*), void*, void*)
> throw ()' has a different exception specifier
> In file included from
> /var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11/bits/extc++.h:68,
>   from
> /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:39:
> /var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/ext/throw_allocator.h:371:
> note: from previous declaration 'int __cxxabiv1::__cxa_atexit(void (*)(void*),
> void*, void*)'
> 
>where cxxabi.h has
> 
> #ifdef _GLIBCXX_CDTOR_CALLABI
>__cxa_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, void*)
> _GLIBCXX_NOTHROW;
> #else
>__cxa_atexit(void (*)(void*), void*, void*) _GLIBCXX_NOTHROW;
> #endif
> 
> * Besides, the ICE in the original testcases remains:
> 
> /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H:
> internal compiler error: in tree_node, at cp/module.cc:9137
> 
> 
>I'm uncertain if the patch was just meant as a preparatory step to fix
>those or something else is amiss.

thanks, I was going to revisit the original report to see if there were 
further issues.

nathan