[Bug ada/51691] New: Cast of an array with type generates a "please file bug" message (See below)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51691 Bug #: 51691 Summary: Cast of an array with type generates a "please file bug" message (See below) Classification: Unclassified Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: minor Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: ale...@m2osw.com Created attachment 26193 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26193 Case Folding implementation for my own Ada compiler --- prompt> gnatmake case_folding gcc-4.4 -c case_folding.adb +===GNAT BUG DETECTED==+ | 4.4.5 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:880 | | Error detected at case_folding.adb:401:32| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.4 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. case_folding.adb case_folding.adb:401:53: missing ")" compilation abandoned gnatmake: "case_folding.adb" compilation error --- As I type fast, the error came from this line: output_line(1 .. indent) := string(1 .. indent => ' '); which includes an invalid cast, the proper line should be (without "string"): output_line(1 .. indent) := (1 .. indent => ' '); There are still problems on line 403 which I left in case the bug would not be reported without that other error (unlikely though.) Just in case, I'm on Ubuntu 11.04. I use the stock version of Ada. --- More info about my project can be found here: http://aada.m2osw.com/compiler
[Bug c++/86296] New: Creating a pointer class for a unique_ptr<>() deleter fails with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86296 Bug ID: 86296 Summary: Creating a pointer class for a unique_ptr<>() deleter fails with optimizations Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alexis at m2osw dot com Target Milestone: --- Created attachment 44317 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44317&action=edit Source exhibiting the template deleter with a pointer problem I created a C++ deleter template for unique_ptr<>() that includes a pointer class. It works as expected when no optimizations are applied (-O0) however, when I add any level of optimizations (-O1, -O2, -O3) the compiler doesn't work right. At that point the pointer can't be retrieved correctly. The pointer operator (T & operator * ()) function returns zero even though within that function, the pointer value is correct. main() creates a unique pointer. I immediately check for the value and it returns -1 as expected when I use -O0, but zero when I use a higher level of optimization. Then I reset the pointer to the value of a file descriptor (safe_fd.reset(fd)) and at that point the pointer operator still returns zero when the code is optimized. The following is the output when I compile with -O0 default initialization: safe_fd = -1 fd = 3 safe_fd after the reset(3) = 3 second close returned -1 (errno = 9) The wrong output when I compile with -O1, -O2, -O3 default initialization: safe_fd = 0 fd = 3 safe_fd after the reset(3) = 0 second close returned -1 (errno = 9) The output is expected to be the same as with -O0. I tested with stock g++ on Ubuntu 16.04 g++ (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 And also on Ubuntu 18.04 g++ (Ubuntu 7.3.0-16ubuntu3) 7.3.0 Both versions failed in a similar way. I'm attaching my source file. It compiles as is on those versions of Ubuntu and I would imagine any Unix system with the same or similar compiler version. The command line I use to compile. No optimization (working as expected): g++ --std=c++14 -O0 ~/tmp/b.cpp -o b Any level of optimization (1 to 3 at least) and the pointer operator breaks: g++ --std=c++14 -O3 ~/tmp/b.cpp -o b
[Bug c++/86296] Creating a pointer class for a unique_ptr<>() deleter fails with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86296 --- Comment #3 from Alexis Wilke --- Okay, I understand and fixed my pointer class and its usage (i.e. I not have an "operator T () const" instead of "T & operator * ()" and I use "safe_fd.get()" instead of "*safe_fd"). However, as an FYI, I tried the -fsanitize=address and the -D_GLIBCXX_ASSERTIONS command line options as shown in your examples and did not get any errors reported in my environment. So as much as these look like useful options, they don't seem to be activated as is. I even tried to run the code in gdb in case some debug would react there and it did not help either. It's rather annoying to see that such features can't automatically be used and work as expected. It would be very useful.
[Bug c++/86296] Creating a pointer class for a unique_ptr<>() deleter fails with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86296 --- Comment #5 from Alexis Wilke --- I tested again under Ubuntu 16.04 and 18.04. Most everything doesn't work right under 16.04. However, when I tested under 18.04, I got the same output as you. So I guess there were problems in 5.x that have been resolved since.
[Bug c++/61312] New: variable function parameters declared as const in the class may not be declared as const in the function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61312
Bug ID: 61312
Summary: variable function parameters declared as const in the
class may not be declared as const in the function
definition
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexis at m2osw dot com
In the following code, the functions test() and foo() are both declared with a
flags parameter which is marked const. The declaration of the actual functions
(blah::foo() and blah::test() below the class declaration) do not specify the
const modifier and yet the compiler does not complain.
This happens with any number of parameters in the function declarations. It
does not happen with complex types (other classes) only basic types like int.
Since I may want to overload such functions, it is a problem. ("int" and "int
const" are not supposed to be the same type.)
class blah
{
public:
blah() {}
void test(int const flags);
private:
bool foo(int const flags);
int f_test;
};
bool blah::foo(int flags)
{
if(flags & 0x10)
{
f_test = 3;
}
else
{
f_test = 1;
}
return (flags & 0x03) != 0;
}
void blah::test(int flags)
{
flags |= 0x80;
foo(flags | 0x10);
}
int main()
{
blah a;
a.test(3);
return 0;
}
[Bug c++/61312] variable function parameters declared as const in the class may not be declared as const in the function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61312 --- Comment #3 from Alexis Wilke --- Wow! I see that is now... "normal behavior". If you ask me, it sucks. But well... I suppose I don't count. Thank you for the PDF reference.
[Bug c++/113211] New: Trying to initialize the tripwire database ends up with a SEGV if a uid cannot be found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113211
Bug ID: 113211
Summary: Trying to initialize the tripwire database ends up
with a SEGV if a uid cannot be found
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexis at m2osw dot com
Target Milestone: ---
On some systems, when I install tripwire, it crashes.
Now I have had the problem many times, so I decided to look into why it
happens. In most cases, one can avoid the issue just by skipping checking
certain files and then go on with their life. I don't think that tripwire
should ever SEGV, though.
Thus, this time I compiled from source on Ubuntu 22.04 and got a stacktrace.
The SEGV actually happens in a systemd library which uses a thread safe
variable.
The systemd function looks like this:
_public_ bool _nss_systemd_is_blocked(void) {
return _blocked > 0;
}
The _blocked variable is defined like this:
static thread_local unsigned _blocked = 0;
When reading the value, the `eax` register is 0 and we get the SEGV. This seems
to be a compiler functionality that fails. There are other tools that have a
similar issue and also SEGV. Note that it only happens if the `uid` does not
exist in the `/etc/passwd` file and that function will have been called many
times before, so the variable should already have been initialized.
Here is the stack trace:
#0 0x77bf86a4 in _nss_systemd_is_blocked () from
/lib/x86_64-linux-gnu/libnss_systemd.so.2
#1 0x77bfa46d in _nss_systemd_getpwuid_r () from
/lib/x86_64-linux-gnu/libnss_systemd.so.2
#2 0x005e5bcf in getpwuid_r ()
#3 0x005e59d3 in getpwuid ()
#4 0x00481b6f in cUnixFSServices::GetUserName (this=,
user_id=501, tstrUser=...) at ../core/unixfsservices.cpp:542
#5 0x00459892 in cFSPropDisplayer::InitForProp (this=0x760be0,
pFCO=, propIdx=)
at ../fs/./../core/fsservices.h:353
#6 0x00453ab6 in cFSPropDisplayer::InitForFCO (this=0x760be0,
ifco=0x8e2550) at ../fs/fspropdisplayer.cpp:248
#7 0x00427631 in cTripwireUtil::CalcProps (pFCO=0x8e2550,
pSpec=, pCalc=, pPD=0x760be0)
at ./src/tripwire/tripwireutil.cpp:79
#8 0x00423740 in util_ProcessDir (dbIter=..., pIter=0x9a0110,
pSpec=0x770330, pPC=0x747070, pPD=0x760be0)
at ./src/tripwire/generatedb.cpp:92
#9 0x0042389f in util_ProcessDir (dbIter=..., pIter=0x99b370,
pSpec=0x770330, pPC=0x747070, pPD=0x760be0)
at ./src/tripwire/generatedb.cpp:105
#10 0x0042389f in util_ProcessDir (dbIter=..., pIter=0x949370,
pSpec=0x770330, pPC=0x747070, pPD=0x760be0)
at ./src/tripwire/generatedb.cpp:105
#11 0x0042389f in util_ProcessDir (dbIter=..., pIter=0x9482b0,
pSpec=0x770330, pPC=0x747070, pPD=0x760be0)
at ./src/tripwire/generatedb.cpp:105
and the assembly code of the very function that SEGV:
0x77bf86a4 in _nss_systemd_is_blocked () from
/lib/x86_64-linux-gnu/libnss_systemd.so.2
(gdb) disassemble
Dump of assembler code for function _nss_systemd_is_blocked:
0x77bf8690 <+0>:endbr64
0x77bf8694 <+4>:sub$0x8,%rsp
0x77bf8698 <+8>:lea0x44919(%rip),%rdi#
0x77c3cfb8
0x77bf869f <+15>:call 0x77bf7c80 <__tls_get_addr@plt>
=> 0x77bf86a4 <+20>:mov0x1c(%rax),%eax
0x77bf86aa <+26>:test %eax,%eax
0x77bf86ac <+28>:setne %al
0x77bf86af <+31>:add$0x8,%rsp
0x77bf86b3 <+35>:ret
End of assembler dump.
If I try a simple `getpwuid()` call with an unknown UID, it returns nullptr
just as expected. I'm not too sure what tripwire adds that would cause the
issue. It's rather complex and still looks like it happens because the C
compiler returns a nullptr in a location where it is never expected to happen.
To reproduce, you can create a VM, change the ownership of a file to an
undefined user on a file that tripwire will read (as under /root or /etc), then
install tripwire. At the time it tries to initializes its database, it will
SEGV instead.
Note: this has been happening for a long time. I think the first time was under
Ubuntu 16.04 so this bug has been around for a while.
[Bug c++/113211] Trying to initialize the tripwire database ends up with a SEGV if a uid cannot be found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113211 --- Comment #4 from Alexis Wilke --- Well, it could be a glibc issue, but the syntax: static thread_local unsigned _blocked = 0; is a compiler thing, right? Looking at ldd output, it is 100% static: $ ldd tripwire not a dynamic executable $
