Re: Namespace inside module partition not exported
Hi,
This list is mostly just a bugzilla feed and so isn't widely monitored.
If you're confident the behaviour is a bug then it would be better to
file a bugzilla ticket. If you're not sure and want to double-check
what the correct behaviour is then it'd be better to ask on gcc-help.
Thanks,
Richard
Alexander Christensen via Gcc-bugs writes:
> Hi,
>
> This is a rather strange thing, which suspiciously looks like bug. I have a
> file like this:
>
> ```
> export module engine.memory : align_type;
> export import engine.core;
>
> export I32 get_5()
> {
> return 5;
> }
>
> export namespace engine::memory
> {
> enum class AlignType : I32
> {
> align_1 = 1,
> align_2 = 2,
> align_4 = 4,
> align_8 = 8,
> align_16 = 16,
> align_32 = 32,
> align_64 = 64,
> align_128 = 128,
> align_256 = 256
> };
> }
> ```
>
> I have another translation unit which then imports the module engine.memory.
> That file can use the function get_5(), but whenever I try to use the
> namespace engine.memory I get an error that that namespace has not been
> defined.
>
> If I remove the `export import engine.core` then the namespace is suddenly
> exported. (!)
>
> So there is an issue with namespaces being hidden (ie. non-exported) whenever
> a module partition unit imports another module. It does not make any
> difference if the imported module is export-import'ed or just imported.
>
> Best,
> Alexander
Re: Compilation of rust-demangle.c fails on MinGW
Hi, Eli Zaretskii via Gcc-bugs writes: > The version of rust-demangle.c included with Binutils 2.37 doesn't > compile with MinGW: > > mingw32-gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -I. > -I../../binutils-2.37/libiberty/../include -W -Wall -Wwrite-strings > -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE > ../../binutils-2.37/libiberty/rust-demangle.c -o rust-demangle.o > ../../binutils-2.37/libiberty/rust-demangle.c:84:3: error: unknown type > name 'uint' > 84 | uint recursion; > | ^~~~ > ../../binutils-2.37/libiberty/rust-demangle.c: In function > 'demangle_path': > ../../binutils-2.37/libiberty/rust-demangle.c:87:37: error: 'uint' > undeclared (first use in this function); did you mean 'int'? > 87 | #define RUST_NO_RECURSION_LIMIT ((uint) -1) > | ^~~~ > ../../binutils-2.37/libiberty/rust-demangle.c:686:25: note: in expansion > of macro 'RUST_NO_RECURSION_LIMIT' >686 | if (rdm->recursion != RUST_NO_RECURSION_LIMIT) > | ^~~ > ../../binutils-2.37/libiberty/rust-demangle.c:87:37: note: each > undeclared identifier is reported only once for each function it appears in > 87 | #define RUST_NO_RECURSION_LIMIT ((uint) -1) > | ^~~~ > ../../binutils-2.37/libiberty/rust-demangle.c:686:25: note: in expansion > of macro 'RUST_NO_RECURSION_LIMIT' >686 | if (rdm->recursion != RUST_NO_RECURSION_LIMIT) > | ^~~ > ../../binutils-2.37/libiberty/rust-demangle.c: In function > 'rust_demangle_callback': > ../../binutils-2.37/libiberty/rust-demangle.c:87:37: error: 'uint' > undeclared (first use in this function); did you mean 'int'? > 87 | #define RUST_NO_RECURSION_LIMIT ((uint) -1) > | ^~~~ > ../../binutils-2.37/libiberty/rust-demangle.c:1347:55: note: in > expansion of macro 'RUST_NO_RECURSION_LIMIT' > 1347 | rdm.recursion = (options & DMGL_NO_RECURSE_LIMIT) ? > RUST_NO_RECURSION_LIMIT : 0; > | > ^~~ > > This is because the data type 'uint' is not defined in the MinGW > headers. I used uint32_t instead, and it compiled OK. This list is mostly just a bugzilla feed and so isn't widely read. Could you file a PR? Thanks, Richard
Re: How GCC treats ice-on-invalid-code?
Eric Botcazou writes: >> It's fine to file these ice-on-invalid bugs, but don't be surprised if >> nobody has time to work on bugs that are only triggered by unrealistic >> garbage input. > > Right, an ICE is a perfectly valid outcome for garbage input and there are > hundreds of assertions in the compiler precisely for this purpose. You mean, an ICE is perfectly valid as the first (and obviously then only) error diagnostic the compiler prints for “garbage input”? If so, I don't think that's true. What counts as “garbage” seems a bit too subjective for that anyway. E.g. deleting a chunk of lines from a file creates something that makes no sense and might be considered garbage, but that can easily happen with a botched resolution to a merge conflict (or being too trigger-happy with git rerere :-)). I don't think it's OK for the compiler simply to crash without first giving the user an idea of what's wrong. I agree ICEs are mostly OK as a downstream effect of an error that has already been reported, but in the context of the quote above, those cases are error-recovery rather than ice-on-invalid-code. Thanks, Richard
Re: How GCC treats ice-on-invalid-code?
Hi,
Haoxin Tu via Gcc-bugs writes:
> Hi, there,
>
> Our team just develop a c++ code generator tool to testing the compiler,
> and those days I have reported 13 ICE bugs in ice-on-invalid-bugs.
>
> Here are the bugs links:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95972
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95956
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95955
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95954
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95925
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95930
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95931
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95927
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95932
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95935
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95945
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95938
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95937
>
> Until now, only the last two cases are confirmed. So I am wondering that
> how GCC treats with those cases in ice-on-invalid-code? I mean, our team is
> focusing on improving the quality of the mature productive compilers. If
> those bugs are useless for GCC, maybe I should stop reporting similar
> issues.
>
> Waiting for your reply. Thank you very much!
Thanks for the work and for the bug reports.
There are really two categories of ICE on erroneous code: those in
which the compiler reports an ICE *after* reporting a sensible error
in the code and those in which the compiler reports an ICE *without*
first reporting a sensible error.
If the compiler encounters an ICE after reporting an error, production
builds will print:
confused by earlier errors, bailing out
instead of reporting the ICE itself. For example, for PR95937,
the production build would print something like:
bug.cc:1:6: error: variable or field ‘a’ declared void
1 | void a { [].decltype(auto)::b
| ^
bug.cc: In lambda function:
bug.cc:1:12: error: expected ‘{’ before ‘.’ token
1 | void a { [].decltype(auto)::b
|^
bug.cc: At global scope:
bug.cc:1:29: confused by earlier errors, bailing out
Although this isn't ideal, it's not too bad in practice, since the
errors before the “bailing out” message tell the user what they
need to do to fix the problem. In fact, there's a danger that if the
compiler is confused enough to hit (or almost hit) an ICE and continues
regardless, it could spew a lot of meaningless error messages and drown
out the useful information. So in some cases, this “bailing out”
message can (accidentally) be a good thing. :-)
In bugzilla, this category of error is classified as “error-recovery”
rather than “ice-on-invalid-code”; see:
https://gcc.gnu.org/bugs/management.html
for details. Because the ICE doesn't show up as an ICE in production
builds, and because bailing out can sometimes even make the user
experience better, these bugs tend to have a very low priority.
In contrast, the second category of ICE above is much more serious.
If GCC encounters an ICE without first reporting a normal error message,
it will print that ICE even in production builds. And this ICE message
will generally give the user no idea what's wrong or what they need
to do to fix the code.
These are the “true” ice-on-invalid-code bugs, i.e. those that are
meant to be classified as “ice-on-invalid-code” instead of “error-recovery”
in bugzilla. They generally get much more attention than “error-recovery”
bugs.
So if your tool is finding a lot of ICEs in GCC (and I imagine it is),
then it might be worth concentrating on filing bugs for the cases in
which GCC fails to report a normal user-level error before reporting
an ICE.
Thanks,
Richard
Re: [Bug target/92469] ICE: output_operand: invalid use of register 'frame' in 7/8/9/10
"jakub at gcc dot gnu.org" writes: > --- Comment #9 from Jakub Jelinek --- > Seems neither accessible_reg_set nor operand_reg_set can exclude frame, > because > the latter results in general_operand predicate failing for it and the former > results into the latter not being enabled either. > So, if we wanted to reject this right away, we'd have to add another hard reg > set (e.g. containing gcc internal artifical regs that shouldn't appear in asm > register specification), or a target hook that would reject such registers > that > varasm.c would call. Agree a hard reg set would be good. We should be able to fill in the easy cases automatically, e.g. FRAME_POINTER_REGNUM when it's != HARD_FRAME_POINTER_REGNUM. But some cases would still need target help.
Re: [Bug rtl-optimization/91994] [10 Regression] r276327 breaks -mvzeroupper
"ubizjak at gmail dot com" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91994 > > --- Comment #10 from Uroš Bizjak --- > Richard, since vzeroupper clobbers only xmm0-xmm15 (xmm0-xmm7 on 32it > targets), > shouldn't we use SSE_REGS instead of ALL_SSE_REGS here: > > Index: i386.c > === > --- i386.c (revision 276660) > +++ i386.c (working copy) > @@ -13530,7 +13530,7 @@ ix86_avx_u128_mode_needed (rtx_insn *insn) > modes wider than 256 bits. It's only safe to issue a > vzeroupper if all SSE registers are clobbered. */ >const function_abi = insn_callee_abi (insn); > - if (!hard_reg_set_subset_p (reg_class_contents[ALL_SSE_REGS], > + if (!hard_reg_set_subset_p (reg_class_contents[SSE_REGS], > abi.mode_clobbers (V4DImode))) > return AVX_U128_ANY; Ah, yeah. LGTM, thanks.
Re: MIPS: va_arg is unable to correct extract an empty zero-length array
Nick Clifton ni...@redhat.com writes: Hi Richard, + /* Even zero-sized arguments occupy one byte. */ + if (size == 0) +size = 1; That fixes it! Thanks. Will you apply this patch yourself, or should I submit the patch and the test case as a separate email to gcc-patches ? It turns out the patch was wrong. The testsuite has several other tests for zero-sized varargs, and we handle those correctly. The difference here seems to be that the type has doubleword alignment. The type doesn't occupy room as such. The problem is that its alignment is still honoured, so if you have something like: word double-word-aligned zero-size value word then a word of padding is inserted between the arguments. I'll need to think about this a bit more... Richard
Re: MIPS: va_arg is unable to correct extract an empty zero-length array
Nick Clifton ni...@redhat.com writes: + /* Even zero-sized arguments occupy one byte. */ + if (size == 0) +size = 1; That fixes it! Great! Thanks for confirming. Will you apply this patch yourself, or should I submit the patch and the test case as a separate email to gcc-patches ? It's OK, I'll try to do it this weekend. I'd like to add a testcase for stack arguments as well. Richard
Re: MIPS: va_arg is unable to correct extract an empty zero-length array
Nick Clifton ni...@redhat.com writes:
Hi Eric, Hi Richard,
A customer has reported the following bug with the MIPS target. Since
it is for a GNU extension to the C language (zero-length arrays) that
is being used in a non-intended fashion (the zero-length array is in a
structure with no other fields) I doubt if you will want to
investigate the problem too much, but I thought that it was worth
reporting anyway:
% mips64vr-elf-gcc -mgp32 -O2 -Tddb.ld -march=vr5500 bug.c
% mips64vr-elf-run a.out
assertion arg4 == va4 failed: file bug.c, line 40, function: foo
As an aside if the type3 structure in bug.c is given another,
non-zero-length field, then the test passes.
Interesting test case :-) Certainly looks like a genuine bug though.
I see the same thing happens for varargs that are passed on the stack
as well (not just those passed in registers).
Fortunately, it looks like the bug is on the varargs side, so no ABI
change is needed. Does the attached patch work? I'll try to do a
full test this weekend.
Richard
Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c (revision 170697)
+++ gcc/config/mips/mips.c (working copy)
@@ -5625,6 +5625,10 @@
NULL_TREE);
size = int_size_in_bytes (type);
+ /* Even zero-sized arguments occupy one byte. */
+ if (size == 0)
+ size = 1;
+
if (GET_MODE_CLASS (TYPE_MODE (type)) == MODE_FLOAT
GET_MODE_SIZE (TYPE_MODE (type)) = UNITS_PER_FPVALUE)
{
Re: GCC testsuite failures for mips64vrel-elf toolchain with -mlong64 -mgp32
Nick Clifton [EMAIL PROTECTED] writes: Hi Eric, Hi Richard, I need your brains... The mips64vrel-elf toolchain is showing a lot of unexpected failures in the gcc testsuite (and g++ testsuite) for multilibs which use -mlong64 and -mgp32 together. For example the first one I came across is this: % ... mips64vrel-elf/gcc/xgcc ... -mlong64 -mgp32 ... gcc.c-torture/compile/20010327-1.c gcc.c-torture/compile/20010327-1.c:12: error: initializer element is not constant Or how about this one: % ... mips64vrel-elf/gcc/xgcc ... gcc.c-torture/compile/mipscop-4.c ... -mlong64 -mgp32 gcc.c-torture/compile/mipscop-4.c:4: error: register specified for 'c3r1' isn't suitable for data type The problems all seem to extend from the fact that a long is forced to be 64-bits but the general purpose registers are 32-bits. What I am not sure about is whether this is a generic bug in gcc somewhere (that assumes that a long will fit into a register) or whether there is something mips specific about the problem. (One thing telling gcc that a long is 32-bits and another thing tell it that they are 64-bits). What do you think ? I don't think there's a generic answer here. I think you just have to go through each test in turn and see whether the test itself is assuming something like sizeof (void *) == sizeof (long), whether the library is, whether gcc is, etc. gcc.c-torture/compile/20010327-1.c does ring a bell as one of the tests that made the assumption, but it's been a long time... When I last worked on this target, I ended up maintaining an on-the-side list of expected fails. I'm afraid I no longer have a copy of that list; I kept it somewhere on Red Hat machines (can't remember where). Thanks to Janis, the testsuite now has proper support for xfailing particular multilibs, so ideally we'd do that. Richard
Re: Bug building target libiberty for mips64vrel-elf toolchain
Hi Eric, Hi Richard,
We recently ran across an ICE building a target libiberty for one of
the multilibs of the mips64vrel-elf toolchain:
.../libiberty/regex.c: In function 'byte_re_match_2_internal':
.../libiberty/regex.c:7481: error: insn does not satisfy its constraints:
(insn 5211 1697 1699 173 .../libiberty/regex.c:6589
(set (reg:SI 5 $5)
(lo_sum:SI (reg/f:SI 1104)
(symbol_ref:SI (byte_reg_unset_dummy) [flags 0x6]
var_decl 0x2a9860bc60 byte_reg_unset_dummy))) 204 {*lowsi_mips16} (nil)
(expr_list:REG_EQUAL (symbol_ref:SI (byte_reg_unset_dummy) [flags
0x6] var_decl 0x2a9860bc60 byte_reg_unset_dummy)
(nil)))
.../libiberty/regex.c:7481: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:393
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [regex.o] Error 1
make[3]: Leaving directory
`.../mips64vrel-elf/mips64vrel-elf/mips16/libiberty'
This problem does not appear to affect other mips toolchains, but
that may just be a multilib issue. I found a simple workaround for
the problem:
Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c(revision 123322)
+++ gcc/config/mips/mips.c(working copy)
@@ -2269,8 +2269,11 @@ mips_legitimize_const_move (enum machine
/* Split moves of symbolic constants into high/low pairs. */
if (splittable_symbolic_operand (src, mode))
{
- emit_insn (gen_rtx_SET (VOIDmode, dest, mips_split_symbol (dest,
src)));
- return;
+ if (! TARGET_MIPS16)
+ {
+ emit_insn (gen_rtx_SET (VOIDmode, dest, mips_split_symbol (dest,
src)));
+ return;
+ }
}
if (mips_tls_operand_p (src))
But I am pretty sure that this is the wrong solution. Since I am
not a MIPS expert however I am punting this problem to you guys. :-)
Yeah, I'm afraid it's the wrong solution. ;) It basically disables
small-data load-address operations on MIPS16.
I gather from the insn above that a use of the GP pseudo
register has been introduced during reload. At first blush,
I think the fix is to make mips_split_symbol move
(const (unspec [(const_int 0)] UNSPEC_GP)) into temp
when no_new_pseudos. I think the cleanest way to do that
would be to add a new define_expand to generate the move,
and adjust mips16_gp_pseudo_reg accordingly.
I might have time to try a fix this weekend. Please feel free
to file a bug report and assign it to [EMAIL PROTECTED]
Richard
Re: mips64 - clobberlist errors
Carl van_Schaik [EMAIL PROTECTED] writes: this becomes a pain since gcc somtimes knows this and uses fp as a gpr, but I cannot clobber it. Why do you want to?
