[Bug c++/105645] Template specializations are not hidden with fvisibility=hidden

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #3 from Julian Waters  ---
I can confirm this on gcc 11 and higher:

#include 

template
void method(T* src, T* dst, size_t length);

template<>
void method(short* src, short* dst, size_t length) {

}

template<>
void method(int* src, int* dst, size_t length) {

}

Compiled using command line:
g++ -O3 -fvisibility=hidden -std=c++14 -pedantic -Wpedantic -Wall -Werror
templates.cpp

Linked using:
g++ -shared -o libtemplates.so templates.o

When nm is run over it using nm -gDC libtemplates.so, the following symbols are
seen:
 w _ITM_deregisterTMCloneTable
 w _ITM_registerTMCloneTable
1110 T void method(int*, int*, unsigned long)
1100 T void method(short*, short*, unsigned long)
 w __cxa_finalize
 w __gmon_start__

T void method(int*, int*, unsigned long) and T void method(short*,
short*, unsigned long) should not be in the symbol table, but they are even
with -fvisibility=hidden.

Strangely, marking both methods with [[gnu::visibility("hidden")]] works and
results in both not being exported.

This was recently observed in the JDK, inside the Java HotSpot VM (see
https://github.com/openjdk/jdk/pull/17955/files#r1498933843)

Is this enough of a reproducer to get this confirmed?

[Bug tree-optimization/106103] ICE in binds_to_current_def_p when source object files are compiled with -flto -Os

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #4 from Julian Waters  ---
The Java HotSpot VM also cannot currently be compiled for Windows with
optimization level SIZE and Link Time Optimization active due to this bug

[Bug lto/113875] g++ crash with Internal Compiler Error when compiling HotSpot for Windows with -Os and -flto

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Julian Waters  ---
Compiler configure options as requested by the gcc bug site:
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\ucrt64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/ucrt64/lib/gcc/x86_64-w64-mingw32/13.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-13.2.0/configure --prefix=/ucrt64
--with-local-prefix=/ucrt64/local --with-build-config=bootstrap-lto
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --with-native-system-header-dir=/ucrt64/include
--libexecdir=/ucrt64/lib --enable-bootstrap --enable-checking=release
--with-arch=nocona --with-tune=generic --enable-languages=c,lto,c++
--enable-shared --enable-static --enable-libatomic --enable-threads=win32
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-threads
--enable-libstdcxx-filesystem-ts --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-libssp
--disable-multilib --disable-rpath --disable-win32-registry --disable-nls
--disable-werror --disable-symvers --with-libiconv --with-system-zlib
--with-gmp=/ucrt64 --with-mpfr=/ucrt64 --with-mpc=/ucrt64 --with-isl=/ucrt64
--with-pkgversion='Rev3, Built by MSYS2 project'
--with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as
--with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++
--with-stage1-ldflags=-static-libstdc++
Thread model: win32
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Rev3, Built by MSYS2 project)

I don't know if obtaining a preprocessed .i file is possible, since this crash
happens with the linker command line and also due to the sheer volume of source
files that are involved

[Bug lto/113875] New: g++ crash with Internal Compiler Error when compiling HotSpot for Windows with -Os and -flto

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Bug ID: 113875
   Summary: g++ crash with Internal Compiler Error when compiling
HotSpot for Windows with -Os and -flto
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tanksherman27 at gmail dot com
  Target Milestone: ---

When compiling the Java HotSpot VM for Windows, g++ crashes with an Internal
Compiler Error if the optimization level is set to SIZE (Aka -Os):

during GIMPLE pass: dse
src/hotspot/share/runtime/continuationFreezeThaw.cpp: In function
'freeze_epilog.isra':
src/hotspot/share/runtime/continuationFreezeThaw.cpp:1544:12: internal compiler
error: in binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:383:
C:\msys64\tmp\cc602ZS3.ltrans127.ltrans.o] Error 1
make[4]: *** Waiting for unfinished jobs
during GIMPLE pass: dse
ad_x86_gen.cpp: In member function 'MachNodeGenerator':
ad_x86_gen.cpp:508:11: internal compiler error: in binds_to_current_def_p, at
symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:41:
C:\msys64\tmp\cc602ZS3.ltrans13.ltrans.o] Error 1
during GIMPLE pass: dse
src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp: In function 'details.isra':
src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:312:6: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:377:
C:\msys64\tmp\cc602ZS3.ltrans125.ltrans.o] Error 1
during GIMPLE pass: dse
src/hotspot/share/classfile/verifier.cpp: In member function
'get_newarray_type.isra':
src/hotspot/share/classfile/verifier.cpp:3003: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:371:
C:\msys64\tmp\cc602ZS3.ltrans123.ltrans.o] Error 1
during GIMPLE pass: dse
src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp: In function
'fill_continuation_entry.constprop':
src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp:1326: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:368:
C:\msys64\tmp\cc602ZS3.ltrans122.ltrans.o] Error 1
during GIMPLE pass: dse
src/hotspot/share/prims/jni.cpp: In function 'jni_MonitorEnter':
src/hotspot/share/prims/jni.cpp:2712: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:191:
C:\msys64\tmp\cc602ZS3.ltrans63.ltrans.o] Error 1
during GIMPLE pass: dse
src/hotspot/cpu/x86/c1_Runtime1_x86.cpp: In member function
'restore_live_registers_except_rax.constprop':
src/hotspot/cpu/x86/c1_Runtime1_x86.cpp:568:6: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
during GIMPLE pass: dse
src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp: In member function
'addm.constprop':
src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp:670: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:365:
C:\msys64\tmp\cc602ZS3.ltrans121.ltrans.o] Error 1
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:362:
C:\msys64\tmp\cc602ZS3.ltrans120.ltrans.o] Error 1
during GIMPLE pass: dse
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp: In member function
'steal_and_trim_queue':

[Bug c++/113760] New: gcc rejects valid empty-declaration in pedantic mode

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Bug ID: 113760
   Summary: gcc rejects valid empty-declaration in pedantic mode
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tanksherman27 at gmail dot com
  Target Milestone: ---

In https://github.com/openjdk/jdk/pull/17687#issuecomment-1926154325 we
discovered a possible g++ bug where g++ rejects empty semicolons in pedantic
mode, this is rather evident in code like

#define DEBUG_ONLY(code) code;

DEBUG_ONLY(foo());

which will fire a -Werror warning even in C++11 and above, where such empty
declarations are allowed

[Bug target/105576] x86: Support a machine constraint to get raw symbol name

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #7 from Julian Waters  ---
Strangely, the following works if compiled with optimizations enabled, -O1 and
above, but not with -O0, when optimizations are disabled

[[gnu::extended(; [dispatcher] "i" (static_cast([] ()
noexcept -> void {})); ; start)]]
asm (R"(
.endif
.rva %l[start], 1f, %c[dispatcher], 2f
.seh_code
)");

With -O0 the error is

exceptions.cpp: In function 'void exceptions()':
exceptions.cpp:59:5: warning: 'asm' operand 0 probably does not match
constraints
   59 | asm (R"(
  | ^~~
exceptions.cpp:59:5: error: impossible constraint in 'asm'

With -O1 and above, %c[dispatcher] yields:

.rva .L2, 1f, _ZZL10exceptionsvENUlPVK19_EXCEPTION_POINTERSPVKvE0_4_FUNES1_S3_,
2f

[Bug c++/110734] Attributes cannot be applied to asm declaration

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #20 from Julian Waters  ---
cppreference at least seems to indicate it retroactively applies to C++11
https://en.cppreference.com/w/cpp/language/asm

[Bug c++/110734] Attributes cannot be applied to asm declaration

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #18 from Julian Waters  ---
Oops, I meant warning: 'no_reorder' attribute ignored [-Wattributes] in my
above comment

[Bug c++/110734] Attributes cannot be applied to asm declaration

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Julian Waters  ---
Looking at the source of the C++ parser it doesn't seem like asm (""); is
considered a statement but rather is correctly parsed as a declaration, see
cp_parser_block_declaration and cp_parser_declaration_statement. The no_reorder
attribute is just a demonstration, I am aware it is not meant for asm
declarations, rather the error is in how the error message is formed, eg error:
expected primary-expression before 'asm' instead of error: expected
primary-expression before 'asm'

[Bug c++/110734] Attributes cannot be applied to asm declarations

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Julian Waters  ---
Will do, will save the new attribute for gcc 15 and just fix the attribute
specifier sequence here

[Bug c++/110734] Attributes cannot be applied to asm declarations

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

  Attachment #56717|0   |1
is obsolete||

--- Comment #8 from Julian Waters  ---
Created attachment 56732
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56732=edit
Attribute for asm declarations

[Bug c++/110734] Attributes cannot be applied to asm statements

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Julian Waters  ---
I have a new attribute proposed for asm declarations that fixes this issue, but
I need help from reviews to proceed with fixing up the patch properly

[Bug c++/110734] Attributes cannot be applied to asm statements

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #6 from Julian Waters  ---
Created attachment 56717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56717=edit
Attribute for asm declarations

[Bug c++/110734] Attributes cannot be applied to asm statements

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Julian Waters  ---
Note: Trying this with a top level asm gives me:

$ g++ -O3 -flto=auto -std=c++14 -pedantic -Wpedantic -fno-omit-frame-pointer
exceptions.cpp
exceptions.cpp:8:1: error: expected unqualified-id before 'asm'
8 | asm ("nop");
  | ^~~

So while it seems the errors are different, it fundamentally is the same issue

[Bug c++/86286] Could __attribute__ ((nothrow)) on a noexcept function turn off EH codegen?

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #6 from Julian Waters  ---
Just tested this on gcc 13, MinGW, a noexcept method includes the .seh_handler
instruction in the compiled assembly, signifying the creation of Windows
exception handling tables, while [[gnu::nothrow]] does not. So it seems to me
that nothrow is not exactly mapped to noexcept

[Bug c/111654] Introduce clang's invalid-noreturn warning

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Julian Waters  ---
Sorry for the late reply, I was busy with certain things

Are we going with numeric invalid-noreturn or explicit-noreturn +
implicit-noreturn? I'm not to sure how to implement the latter, if we're going
with that

[Bug c/111654] Introduce clang's invalid-noreturn warning

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Julian Waters  ---
(In reply to Manuel López-Ibáñez from comment #1)
> (In reply to Julian Waters from comment #0)
> > Created attachment 56022 [details]
> > Patch to add invalid-noreturn to gcc
> 
> Patches should be submitted to gcc-patc...@gcc.gnu.org
> 
> For more details, please read:
> https://gcc.gnu.org/wiki/GettingStarted#Basics:
> _Contributing_to_GCC_in_10_easy_steps
> 
> Except for clang compatibility, I believe the consensus is that numerical
> levels are not user-friendly. I think it would be better to have:
> 
> -Wnoreturn-implicit-return
> -Wnoreturn-explicit-return
> 
> -Winvalid-noreturn enables / disables both.

Yeah, I did try submitting it to gcc-patches, but it simply went ignored for
forever, so I decided to submit the patch through the bug system instead, like
others have done. I implemented it as numeric values to avoid inventing new
names for -Woption and because it was easier to implement for a gcc beginner
like myself, so worded warnings are likely to take me longer to implement

[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #8 from Julian Waters  ---
I have a patch ready for the noreturn warning at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654, is anyone willing to help
review and push it?

[Bug driver/111654] New: Introduce clang's invalid-noreturn warning

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Bug ID: 111654
   Summary: Introduce clang's invalid-noreturn warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tanksherman27 at gmail dot com
  Target Milestone: ---

Created attachment 56022
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56022=edit
Patch to add invalid-noreturn to gcc

clang has a toggleable warning flag named invalid-noreturn for noreturn
functions that return either implicitly or explicitly, while gcc has different
warnings for both explicit and implicit cases. We should add this warning (with
an extra level of tuneability since unlike clang gcc has different warnings for
each) for compatibility with clang, and for utility purposes since code may
desire to mark functions as noreturn even though it may (in the compiler's
point of view) return

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #19 from Julian Waters  ---
(In reply to Tomas Kalibera from comment #17)
> (In reply to Tomas Kalibera from comment #16)
> > (In reply to Julian Waters from comment #15)
> > > It seems like the patch also doesn't fix the strftime case too, strangely
> > > enough. gcc with that patch applied still causes a compilation failure in
> > > the Windows JDK when encountering strftime with the %T specifier
> > 
> >
> > I don't easily see why the patch doesn't help with %T in strftime. In
> > MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so
> > the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format
> > attribute is present.
> 
> The older version of the patch I use with gcc 12 doesn't seem to be helping
> with %T, but the newer one (patch_master.diff) helps with %T on the current
> gcc master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with
> MinGW-W64 11.0.1.

If I may ask, could I have the link to patch_master.diff?

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #18 from Julian Waters  ---
That's great news! With regards to this patch, I'm fairly certain you have to
proactively send it to gcc-patches mailing list for it to be merged; No gcc
committer has the time to look for this issue and commit it. I also think it's
probably time for ms_printf to formally recognize ISO C format specifiers once
and for all, too

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #15 from Julian Waters  ---
It seems like the patch also doesn't fix the strftime case too, strangely
enough. gcc with that patch applied still causes a compilation failure in the
Windows JDK when encountering strftime with the %T specifier

[Bug c++/110734] Attributes cannot be applied to asm statements

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Julian Waters  ---
My mistake, I forgot to mention that it was indeed inside a function body. I
can't seem to figure out what in parser.cc is causing this bug, anything on
your end?

[Bug c++/110734] Attributes cannot be applied to asm statements

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Julian Waters  ---
Is this accurately described as an enhancement? This is erroneous behaviour
with something that is already meant to be a feature in gcc (applying
attributes to statements, as seen inside parser.cc), not a feature request for
new behaviour

[Bug c++/110734] Attributes cannot be applied to asm statements

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

Version|unknown |13.1.1

--- Comment #1 from Julian Waters  ---
Set version to 13.1, but this problem is very likely in every version

[Bug c++/110734] New: Attributes cannot be applied to asm statements

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Bug ID: 110734
   Summary: Attributes cannot be applied to asm statements
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tanksherman27 at gmail dot com
  Target Milestone: ---

Consider the following:

[[gnu::no_reorder]]
asm ("nop");

The correct gcc warning should be that "attributes in front of statements
are ignored", signifying that the asm was correctly processed as a
statement, and the attribute dropped during that processing, but instead:

error.cpp:51:5: error: expected primary-expression before 'asm'
   51 | asm ("nop" "\n\t"
  | ^~~
error.cpp:50:5: warning: attributes at the beginning of statement are
ignored [-Wattributes]
   50 | [[gnu::no_reorder]]
  | ^~~

The compiler errors out, with the parser strangely having expected an
expression after the attribute. Afterwards, it then confusingly parses the
asm statement and discards the attribute correctly, so I am fairly certain
this is a bug. The attribute above may not be a very good example, but
there are attributes like gnu::hot and gnu::cold which are supposed to work
with asm statements.