[Bug c++/115705] New: dubious macro definition ‘__attr_dealloc_fclose’ [-Winvalid-imported-macros]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115705 Bug ID: 115705 Summary: dubious macro definition ‘__attr_dealloc_fclose’ [-Winvalid-imported-macros] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: devdude2 at hotmail dot com Target Milestone: --- When I compile my code with c++ modules, I get this error, using gcc module compiled headers, i.e. headers compiled like: g++ -std=c++20 -fconcepts -fcoroutines -fmodules-ts -fmodule-header=system -x c++-system-header random I think cwchar and stdio define __attr_dealloc_fclose differently. Is this an error and if so, can this be fixed, by making the definitions the same or whatever? Thanks [build] /home/gm/projects/chess/src/libchess/libchess.cppm: warning: inconsistent imported macro definition ‘__attr_dealloc_fclose’ [-Winvalid-imported-macros] [build] In file included from /home/gm/local/install-mygcc/include/c++/15.0.0/cwchar:44, [build] of module /home/gm/local/install-mygcc/include/c++/15.0.0/cwchar, imported at /home/gm/local/install-mygcc/include/c++/15.0.0/bits/postypes.h:40, [build] included from /home/gm/local/install-mygcc/include/c++/15.0.0/bits/char_traits.h:42, [build] from /home/gm/local/install-mygcc/include/c++/15.0.0/string:42, [build] of module /home/gm/local/install-mygcc/include/c++/15.0.0/string, imported at /home/gm/projects/chess/src/libchess/libchess.cppm:3: [build] /usr/include/wchar.h:713:11: note: ‘#define __attr_dealloc_fclose ’ [build] 713 | # define __attr_dealloc_fclose /* empty */ [build] | ^ [build] In file included from /home/gm/local/install-mygcc/include/c++/15.0.0/cstdio:42, [build] of module /home/gm/local/install-mygcc/include/c++/15.0.0/cstdio, imported at /home/gm/local/install-mygcc/include/c++/15.0.0/ext/string_conversions.h:45, [build] included from /home/gm/local/install-mygcc/include/c++/15.0.0/bits/basic_string.h:4154, [build] from /home/gm/local/install-mygcc/include/c++/15.0.0/string:54, [build] of module /home/gm/local/install-mygcc/include/c++/15.0.0/string, imported at /home/gm/projects/chess/src/libchess/libchess.cppm:3: [build] /usr/include/stdio.h:187:9: note: ‘#define __attr_dealloc_fclose __attr_dealloc (fclose, 1)’ [build] 187 | #define __attr_dealloc_fclose __attr_dealloc (fclose, 1) [bu
[Bug c++/115706] New: Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706
Bug ID: 115706
Summary: Compiling headers as header units fails depending on
order.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: devdude2 at hotmail dot com
Target Milestone: ---
It's unclear how to compile C++ standard headers. It seems order dependent.
i.e. If I use a script like the one below to try to build all the headers in
folder order, see the results that follow. random and execution seem to fail on
first pass (and crash the compiler), but if I re-run the script, random and
execution fail do compile. In any case my code that uses them fails to compile
in other ways.
std="c++20"
cflags="-std=${std} -fconcepts -fcoroutines -fmodules-ts"
hflags="$cflags -fmodule-header=system -x c++-system-header"
ccpath="$(dirname $(which g++))"
ccroot="$(dirname "$ccpath")"
ccver="$(g++ -dumpversion)"
ipath="$ccroot/include/c++/${ccver}"
all_hdrs=()
if [[ "$1" == "" ]]; then
std_hdrs=$(ls -p "$ipath" | grep -E -v /$)
for hdr in ${std_hdrs[@]}; do
all_hdrs+=("$hdr")
done
else
declare -a all_hdrs="($@)"
fi
if [[ "$1" == "" ]]; then
rm -rf gcm.cache
fi
for hdr in ${all_hdrs[@]}; do
echo "Compiling header \"${hdr}\""
hdr_ext="${hdr##*.}"
echo "$hdr_ext"
if [[ $hdr == $hdr_ext ]] # Not sure this condition is correct.
then
echo "Doing: g++ $hflags $hdr"
g++ $hflags $hdr
else
echo "NOT compiling $hdr because of file type assumed to be C or not
standard C++ header."
fi
# -o ${hdr}
done
e.g.
Doing: g++ -std=c++20 -fconcepts -fcoroutines -fmodules-ts
-fmodule-header=system -x c++-system-header random
In file included from
/home/gm/local/install-mygcc/include/c++/15.0.0/string:45,
from
/home/gm/local/install-mygcc/include/c++/15.0.0/random:43:
/home/gm/local/install-mygcc/include/c++/15.0.0/bits/localefwd.h:156:74: error:
wrong number of template arguments (1, should be 2)
156 | template >
|
^
In file included from
/home/gm/local/install-mygcc/include/c++/15.0.0/bits/specfun.h:43,
from
/home/gm/local/install-mygcc/include/c++/15.0.0/cmath:3898,
of module /home/gm/local/install-mygcc/include/c++/15.0.0/cmath, imported at
/home/gm/local/install-mygcc/include/c++/15.0.0/random:40:
/home/gm/local/install-mygcc/include/c++/15.0.0/bits/stl_algobase.h:476:11:
note: provided for ‘template class
std::istreambuf_iterator’
476 | class istreambuf_iterator;
| ^~~
/home/gm/local/install-mygcc/include/c++/15.0.0/bits/localefwd.h:158:75: error:
wrong number of template arguments (1, should be 2)
158 | template >
Also:
Doing: g++ -std=c++20 -fconcepts -fcoroutines -fmodules-ts
-fmodule-header=system -x c++-system-header execution
In file included from
/home/gm/local/install-mygcc/include/c++/15.0.0/bits/shared_ptr_base.h:62,
from
/home/gm/local/install-mygcc/include/c++/15.0.0/bits/shared_ptr.h:53,
from
/home/gm/local/install-mygcc/include/c++/15.0.0/memory:80,
from
/home/gm/local/install-mygcc/include/c++/15.0.0/pstl/parallel_backend_serial.h:15,
from
/home/gm/local/install-mygcc/include/c++/15.0.0/pstl/parallel_backend.h:14,
from
/home/gm/local/install-mygcc/include/c++/15.0.0/pstl/algorithm_impl.h:22,
from
/home/gm/local/install-mygcc/include/c++/15.0.0/pstl/glue_execution_defs.h:50,
from
/home/gm/local/install-mygcc/include/c++/15.0.0/execution:39:
/home/gm/local/install-mygcc/include/c++/15.0.0/ext/concurrence.h: In
destructor ‘virtual
__gnu_cxx::__concurrence_lock_error::~__concurrence_lock_error()’:
/home/gm/local/install-mygcc/include/c++/15.0.0/ext/concurrence.h:64:9:
internal compiler error: in build_op_delete_call, at cp/call.cc:8038
64 | class __concurrence_lock_error : public std::exception
| ^~~~
0x20316ed internal_error(char const*, ...)
/home/gm/local/mygcc/gcc/diagnostic-global-context.cc:491
0x7652f1 fancy_abort(char const*, int, char const*)
/home/gm/local/mygcc/gcc/diagnostic.cc:1725
0x71bed2 build_op_delete_call(tree_code, tree_node*, tree_node*, bool,
tree_node*, tree_node*, int)
/home/gm/local/mygcc/gcc/cp/call.cc:8038
0x8914b2 build_delete_destructor_body
/home/gm/local/mygcc/gcc/cp/optimize.cc:140
0x8927c8 maybe_clone_body(tree_node*)
/home/gm/local/mygcc/gcc/cp/optimize.cc:608
0x944e58 expand_or_defer_fn_1(tree_node*)
/home/gm/local/mygcc/gcc/cp/semantics.cc:5100
0x945078 expand_or_defer_fn(tree_node*)
/home/gm/local/mygcc/gcc/cp/semantics.cc:5135
0x84a207 synthesize_method(tree_node*)
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 --- Comment #2 from Dev Dude --- Just to clarify the initial comment if it is unclear: It's unclear how to compile C++ standard headers. If I use the script below to try to build all the standard c++ headers, I see the "random" header errors and the "execution" header crashes compiler (see output in original post). But if I re-run the script, random and execution compile successfully. The crash in "execution" is a compiler bug or an incorrect assertion. But that the process fails then works on re-run, seems to be a bug to in that the header build is order dependent or sometning when it probably shouldn't be To see this, save the script in the original comment as make_gcc_headers.sh then do . make_gcc_headers.sh then . make_gcc_headers execution random I hope this clarifies things and how to reproduce this problem if it was unclear before. Thanks Oh one other thing, I think I accidentally cut the related errors from using the collective headers after they successfully compile on second pass. I don't think this adds much, as it may go away once you fix the other problems, but in case it helps here those errors are too: [build] In module imported at /home/gm/projects/chess/src/libutil/util.cpp:49:1: [build] /home/gm/projects/chess/src/libutil/util.cpp: In substitution of ‘template constexpr std::__cxx11::basic_string::basic_string(const char*, const std::allocator&) [with = std::allocator]’: [build] /home/gm/projects/chess/src/libutil/util.cpp:88:18: required from here [build]88 | mypath = pathbuf; [build] | ^~~ [build] /home/gm/local/install-mygcc/include/c++/15.0.0/filesystem: error: failed to read compiled module cluster 1499: Bad file data [build] /home/gm/local/install-mygcc/include/c++/15.0.0/filesystem: note: compiled module file is ‘gcm.cache/./home/gm/local/install-mygcc/include/c++/15.0.0/filesystem.gcm’ [build] /home/gm/projects/chess/src/libutil/util.cpp:88:18: fatal error: failed to load pendings for ‘std::__cxx11::basic_string’ [build]88 | mypath = pathbuf; [build] | ^~~ But the stack dump showing and compiler crash related to __concurrence_lock_error in the original post is the main thing in this post relating to gcc. But to see it, you'll have to run the script that I gave.
[Bug other/115705] dubious macro definition ‘__attr_dealloc_fclose’ [-Winvalid-imported-macros]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115705 --- Comment #4 from Dev Dude --- (In reply to Andrew Pinski from comment #3) > Confirmed; suspended. > > We should do a fix includes once this has been fixed in glibc. Any follow up / update on this. The related glibc bug says that should be an easy fix but it doesn't seem to have progressed. Thanks!
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 --- Comment #3 from Dev Dude --- Hello, any update on this bug? Has anyone run the script I provided in the prior post for building the module headers? Or can anyone comment on the correct way to build module headers? I can't progress on modules builds. Running the script with no parameters causes stack dump shown on compiling headers execution and random, but re-running the script with parameters 'random' and 'execution' causes them to build without compiler crash. But in any case, the resulting compilation of my project with all the headers, bug 115705, stops modules compilation in any case. So I can't progress module builds with gcc. It would seem easy to confirm at least. Thanks.
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 --- Comment #5 from Dev Dude --- I'm not sure what's difficult about me posing a question about what the correct way is to build module headers so they all build properly, and also providing my own script to show what I'm doing in absence of knowing the correct way, and pointing out that doesn't work, and why. It doesn't need my own code as it's failing on gcc's own code. It's a case of simply pasting that script in a file and running it, vs, downloading it and running it. But in any case my question wasn't answered, and remains unanswered, but apparently it's hard to paste the script into a file, and easier to write back instead and complain. Ok then. Have it your way. I'll continue to use clang where modules work for me and not help your project. I'm sick of this.
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 --- Comment #7 from Dev Dude --- Created attachment 58661 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58661&action=edit A script to try to build gcc module headers A script to try to build gcc module headers, used in absence of knowing any other way to do this, such as via cmake. But running this seems to illicit a stack dump of gcc, which is a bug I would think in the compiler in any case, even if the script is wrong or something.
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 --- Comment #8 from Dev Dude --- Hmmm it seems adding an attachment lost my comment. I'll try to remember most of it. First, thanks Nathaniel for your polite comments. Much appreciated. I'm not sure why Sam is mentioning multiple bugs because that was already addressed in creating 115705, which existed prior to his comment about multiple bugs, and he's replied to it in further do nothing fashion. So Bug 115705 is self evident and in it's own report already. Regarding this bug, which is the stack trace, if Sam spent as much time running the small script as complaining that it was pasted rather than attached, he could have confirmed the bug instead of doing nothing here too. And the time Sam spent on 115705 telling me he's doing nothing on it and it's easy, he could have fixed it. I don't need either bug fixed as I only use gcc as a test compiler, I am simply trying to help GCC for that same reason. But I'm not paid for this either, and it takes time to discover gcc's and libstdc++'s problems and write them up in any form, code, let alone write scripts to assist people to see the problems, which I did that Sam ignored only to complain about it. I don't appreciate attitude for simply having the audacity to try to help. It isn't going to be perfect reports every time. If life was perfect, I wouldn't be assisting to fix someone else's screw up anyway. More to the point, I'm not going to fix it, however easy it is, because I don't appreciate this attitude and lest I get further complaints for trying to help. Sam and a few others might want to consider that next time, but these types don't it seems. Somebody should really have a team get together and knock this attitude on the head. Sure I try to get clarity on bug reports myself, but I don't spew out attitude to would be helpers. I wish to clearly note that I am not referring to you Nathaniel, you're extremely polite and helpful, but if somebody reading this can sort this attitude out, it'd be great, because I'm doing nothing more with any of this because of this. So to summarize, there IS only one bug in this report from my perspective, the stack dump to which the attached script relates. Running it, should yield an assert failure of sorts, so running the script should yield a line number in your own builds - it does from trunk, and that should allow for a debug break point to be used to see the state of the compiler, which means a lot more to you lot than me, but this script does reveal some bugs I think, because it's a dump. If it doesn't for you, let me know the circumstance. To be clear, it's failing on on gcc's own headers not my own code. Regardin the line here: [build]88 | mypath = pathbuf; that is from my project, but I don't consider that a bug report, it's just output from using the headers built by the attached script, but as that crashed on headers execution and random on first attempt (with not parameters), it can't be trusted, even though it compiles on second attempt with random and execution as parameters to the script. So it's just some output that that'll likely go away when this bug is fixed and or 115705 is fixed, I just included the line as it might have revealed something for this or 115705. I hope this is helpful Nathaniel and thanks for your supportive commentary. If you wish to do nothing until your other 92277 bug is solved, that's of course fine by me. I will try to build my code again if I see that bug fixed or if you tell me to. Just FYI, I'm unlikely to publicly get involved any more, or certainly with this site and that's fault of yours Nathaniel.
