public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/115706] New: Compiling headers as header units fails depending on order.
@ 2024-06-29  2:20 devdude2 at hotmail dot com
  2024-07-01 10:02 ` [Bug c++/115706] " redi at gcc dot gnu.org
  2024-07-04  0:57 ` devdude2 at hotmail dot com
  0 siblings, 2 replies; 3+ messages in thread
From: devdude2 at hotmail dot com @ 2024-06-29  2:20 UTC (permalink / raw)
  To: gcc-bugs

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<typename _CharT, typename _InIter =
istreambuf_iterator<_CharT> >
      |                                                                        
 ^
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 _CharT, class _Traits> 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<typename _CharT, typename _OutIter =
ostreambuf_iterator<_CharT> >

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*)
        /home/gm/local/mygcc/gcc/cp/method.cc:1848
0x8120df mark_used(tree_node*, int)
        /home/gm/local/mygcc/gcc/cp/decl2.cc:6080
0x77ec2a build_over_call
        /home/gm/local/mygcc/gcc/cp/call.cc:10581
0x77d433 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
        /home/gm/local/mygcc/gcc/cp/call.cc:11855
0x77e1ef build_special_member_call(tree_node*, tree_node*, vec<tree_node*,
va_gc, vl_embed>**, tree_node*, int, int)
        /home/gm/local/mygcc/gcc/cp/call.cc:11340
0x826507 build_dtor_call
        /home/gm/local/mygcc/gcc/cp/init.cc:5110
0x826507 build_delete(unsigned int, tree_node*, tree_node*,
special_function_kind, int, int, int)
        /home/gm/local/mygcc/gcc/cp/init.cc:5310
0x7e438d cxx_maybe_build_cleanup(tree_node*, int)
        /home/gm/local/mygcc/gcc/cp/decl.cc:19156
0x95b58c build_target_expr
        /home/gm/local/mygcc/gcc/cp/tree.cc:537
0x985d25 build_functional_cast_1
        /home/gm/local/mygcc/gcc/cp/typeck2.cc:2540
0x985d25 build_functional_cast(unsigned int, tree_node*, tree_node*, int)
        /home/gm/local/mygcc/gcc/cp/typeck2.cc:2561
0x8aceff cp_parser_functional_cast
        /home/gm/local/mygcc/gcc/cp/parser.cc:33675
0x8ce96f cp_parser_postfix_expression
        /home/gm/local/mygcc/gcc/cp/parser.cc:7885
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.



Running the above script on just execution and random cause it to succeed. But
use of those headers gets:
[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)
[build]       |         ^~~~~~~~~~~~~~~~~~~~~


I assume two or three bugs/problems are at play here.

Unrelated, is this problem going to be fixed?
import std;
#include <vector> // or any other standard library header

I ask, because parts of my code (not related to the above errors AFAIK), hit
this problem, though it compiles with clang and MSVC now, but not GCC, but if
the other gcc issues are fixed, I may see issues caused by this last use case.

Thanks

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug c++/115706] Compiling headers as header units fails depending on order.
  2024-06-29  2:20 [Bug c++/115706] New: Compiling headers as header units fails depending on order devdude2 at hotmail dot com
@ 2024-07-01 10:02 ` redi at gcc dot gnu.org
  2024-07-04  0:57 ` devdude2 at hotmail dot com
  1 sibling, 0 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2024-07-01 10:02 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Dev Dude from comment #0)
> Unrelated, is this problem going to be fixed?
> import std;
> #include <vector> // or any other standard library header

I think that's PR 114990

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug c++/115706] Compiling headers as header units fails depending on order.
  2024-06-29  2:20 [Bug c++/115706] New: Compiling headers as header units fails depending on order devdude2 at hotmail dot com
  2024-07-01 10:02 ` [Bug c++/115706] " redi at gcc dot gnu.org
@ 2024-07-04  0:57 ` devdude2 at hotmail dot com
  1 sibling, 0 replies; 3+ messages in thread
From: devdude2 at hotmail dot com @ 2024-07-04  0:57 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Dev Dude <devdude2 at hotmail dot com> ---
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<class> constexpr std::__cxx11::basic_string<char>::basic_string(const
char*, const std::allocator<char>&) [with <template-parameter-1-1> =
std::allocator<char>]’:
[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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-07-04  0:57 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-29  2:20 [Bug c++/115706] New: Compiling headers as header units fails depending on order devdude2 at hotmail dot com
2024-07-01 10:02 ` [Bug c++/115706] " redi at gcc dot gnu.org
2024-07-04  0:57 ` devdude2 at hotmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).