[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115453 Andrew Pinski changed: What|Removed |Added Keywords||build Component|rust|bootstrap --- Comment #8 from Andrew Pinski --- Toplevel makefile is consider bootstrap component rather than rust ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115453 --- Comment #10 from Andrew Pinski --- (In reply to Arthur Cohen from comment #9) > Ah, sorry Andrew, I thought the component was referring to the origin of the > issue. Just wanted to be able to find it in the list of Rust-related issues. > Sorry! One way to do this is to use `personal tags` though they only show up for your account and not another account. This might be one of the few cases where rust related issues are not in the rust components. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/114629] rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > While you are at it, it would be useful to add a link to the rust langauge > specification (like there is for almost all other languages [I see > objective-C is not listed]) to https://gcc.gnu.org/readings.html . Also it would be useful to update https://gcc.gnu.org/frontends.html too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/114629] rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629 --- Comment #5 from Andrew Pinski --- (In reply to Pierre-Emmanuel Patry from comment #2) > I can see the problem with the message, but I don't think we can remove the > behavior as we have to match rustc's behavior. The compiler has to ICE when > meeting this identifier. I suggest changing the message to rustc's one "It > looks like you're trying to break rust; would you like some ICE?" and > removing the "gcc" identifier check. Really this sounds like a bad idea to copy 100% of what rustc does. Instead we should follow the rust language specification (hopefully that actually exists). While you are at it, it would be useful to add a link to the rust langauge specification (like there is for almost all other languages [I see objective-C is not listed]) to https://gcc.gnu.org/readings.html . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/114629] rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-04-07
Status|UNCONFIRMED |NEW
Keywords||diagnostic
--- Comment #1 from Andrew Pinski ---
Confirmed.
else if (funny_error)
{
/* This was a "break rust" or "break gcc", and the identifier failed to
resolve. Emit a funny ICE. We set the finalizer to our custom one,
and use the lower-level emit_diagnostic () instead of the more common
internal_error_no_backtrace () in order to pass our locus. */
diagnostic_finalizer (global_dc) = funny_ice_finalizer;
emit_diagnostic (DK_ICE_NOBT, expr.get_locus (), -1,
"are you trying to break %s? how dare you?",
expr.as_string ().c_str ());
This is not even that funny.
I suggest to remove the idea of funny_error really.
if (ident == "rust" || ident == "gcc")
funny_error = true;
...
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug rust/113553] rust fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553 --- Comment #13 from Andrew Pinski --- (In reply to Bruno Haible from comment #12) > For reference: The Gnulib unit tests for posix_spawn* pass on > sparc-linux-gnu (both in 32-bit mode and in 64-bit mode). But the issue sounds very intermittent which makes it sound like memset might not always work. Even if the GNUlib unit test works, it might be different alignment of the variables on the stack or something like that is causing the failures there ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/113553] rust fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553 --- Comment #11 from Andrew Pinski --- (In reply to John Paul Adrian Glaubitz from comment #10) > (In reply to Andrew Pinski from comment #9) > > oh look at this a memset issue on sparc glibc: > > https://sourceware.org/bugzilla/show_bug.cgi?id=31068 . > > Hmm, but this would be sparc32. Are you sure that this applies here? Hmm, that is true. Still that does seem like memset is not working correctly. Someone will need to debug memset because this code looks correct otherwise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/113553] rust fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553
Andrew Pinski changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
||illa/show_bug.cgi?id=31068
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> > Some playing around showed that this fixes the problem for me:
> >
> > diff --git a/libiberty/pex-unix.c b/libiberty/pex-unix.c
> > index af98062a94c..a1d35820181 100644
> > --- a/libiberty/pex-unix.c
> > +++ b/libiberty/pex-unix.c
> > @@ -574,8 +574,8 @@ pex_unix_exec_child (struct pex_obj *obj
> > ATTRIBUTE_UNUSED,
> > {
> >int ret;
> >pid_t pid = -1;
> > - posix_spawnattr_t attr;
> > - posix_spawn_file_actions_t actions;
> > + static posix_spawnattr_t attr;
> > + static posix_spawn_file_actions_t actions;
> >int attr_initialized = 0, actions_initialized = 0;
> >
> >*err = 0;
>
> Let me look that seems like an unitialized variable. If it is obvious one, I
> will apply a patch.
So I looked into pex-unix.c and the code does the right thing:
ret = posix_spawnattr_init (&attr);
...
ret = posix_spawn_file_actions_init (&actions);
And looking into glibc we have just basically:
memset (attr, '\0', sizeof (*attr)); //__posix_spawnattr_init
memset (file_actions, '\0', sizeof (*file_actions)); //
__posix_spawn_file_actions_init
And that code has not changed in glibc for years (over 10) either.
So maybe memset is not working correctly.
oh look at this a memset issue on sparc glibc:
https://sourceware.org/bugzilla/show_bug.cgi?id=31068 .
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug rust/113553] rust fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553
--- Comment #6 from Andrew Pinski ---
(In reply to John Paul Adrian Glaubitz from comment #5)
> (In reply to Rainer Orth from comment #1)
> > The build works for me just fine on sparc-sun-solaris2.11.
> >
> > I've also fired one off on sparc64-unknown-linux-gnu which worked just as
> > well.
> > It was a rough ride, however, with the build aborting with
> >
> > xgcc: fatal error: cannot execute
> > '/var/gcc/regression/master/6.4.0-gcc-gas-gld/build/./gcc/cc1plus':
> > posix_spawn: Bad address
> >
> > several times. When I ran make under strace -f, however, the build worked
> > just
> > fine. Quite ugly, actually.
>
> It seems that this can be avoided by building with one job, i.e. with "make
> -j1".
>
> Some playing around showed that this fixes the problem for me:
>
> diff --git a/libiberty/pex-unix.c b/libiberty/pex-unix.c
> index af98062a94c..a1d35820181 100644
> --- a/libiberty/pex-unix.c
> +++ b/libiberty/pex-unix.c
> @@ -574,8 +574,8 @@ pex_unix_exec_child (struct pex_obj *obj
> ATTRIBUTE_UNUSED,
> {
>int ret;
>pid_t pid = -1;
> - posix_spawnattr_t attr;
> - posix_spawn_file_actions_t actions;
> + static posix_spawnattr_t attr;
> + static posix_spawn_file_actions_t actions;
>int attr_initialized = 0, actions_initialized = 0;
>
>*err = 0;
Let me look that seems like an unitialized variable. If it is obvious one, I
will apply a patch.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug rust/113553] rust fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553 --- Comment #2 from Andrew Pinski --- Which glibc are you using? See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82346 and maybe https://sourceware.org/bugzilla/show_bug.cgi?id=22146 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/113461] [14 Regression] rust-proc-macro.cc:174:15: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Werror=format=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113461 --- Comment #4 from Andrew Pinski --- Try after r14-8211-g2341df1cb9b3681bfefe29207887b2b3dc271a95 which was just committed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/113461] [14 Regression] rust-proc-macro.cc:174:15: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Werror=format=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113461 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-18 Keywords||build --- Comment #1 from Andrew Pinski --- Confirmed, this was also reported on IRC. I think there will be a patch pushed in the next day or so too to fix this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/113056] [14 regression] Build failure in libgrust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056 --- Comment #9 from Andrew Pinski --- I am testing out using an absolute path for configure right now. Seeing if that changes things ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/113056] [14 regression] Build failure in libgrust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-12-18 Status|UNCONFIRMED |WAITING --- Comment #7 from Andrew Pinski --- Wait are you building in the src directory? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/113056] [14 regression] Build failure in libgrust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056 --- Comment #6 from Andrew Pinski --- I just did: ``` mkdir objdir cd objdir ../configure --enable-languages=rust make -j24 ``` And it work ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/113056] [14 regression] Build failure in libgrust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056 Andrew Pinski changed: What|Removed |Added Keywords||build -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/113056] [14 regression] Build failure in libgrust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056 --- Comment #4 from Andrew Pinski --- Looks like multilib support in libgrust is just broken. I suspect it would be worse on other targets where there are many more multilibs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/113056] [14 regression] Build failure in libgrust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056 --- Comment #3 from Andrew Pinski --- Well this is not right: /var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/xgcc: not 32 should not be there ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/111899] [14 regression] GCC fails to bootstrap with 'rust-tree.cc:131:10: error: ‘NON_DEPENDENT_EXPR’ was not declared in this scope'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111899 --- Comment #2 from Andrew Pinski --- I noticed it via the build bot: https://gcc.gnu.org/pipermail/gcc-testresults/2023-October/798851.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/111899] [14 regression] GCC fails to bootstrap with 'rust-tree.cc:131:10: error: ‘NON_DEPENDENT_EXPR’ was not declared in this scope'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111899 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/111899] [14 regression] GCC fails to bootstrap with 'rust-tree.cc:131:10: error: ‘NON_DEPENDENT_EXPR’ was not declared in this scope'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111899 Andrew Pinski changed: What|Removed |Added Keywords||build -- You are receiving this mail because: You are on the CC list for the bug.
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #5 from Andrew Pinski --- (In reply to Stefan Schulze Frielinghaus from comment #4) > and the current working directory was most likely /devel/gcc/build/gcc. > Creating a symlink from $build/stage1-gcc to $build/prev-gcc and then > running the command from above doesn't do the trick. There is probably an > easier way which I miss. Any hints? See stage2-start/stage3-start I think. See https://gcc.gnu.org/onlinedocs/gccint/Makefile.html#Makefile -- You are receiving this mail because: You are on the CC list for the bug. -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED --- Comment #3 from Andrew Pinski --- Moved to middle-end since the code that is causing issues is c++ code. Can you attach the preprocessed source? I wonder if this is a -g0 vs -g issue ... -- You are receiving this mail because: You are on the CC list for the bug. -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 Andrew Pinski changed: What|Removed |Added Keywords||build Component|rust|middle-end -- You are receiving this mail because: You are on the CC list for the bug. -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108087] -Wodr warnings in rust/rust-lang.cc (lang_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108087 Andrew Pinski changed: What|Removed |Added Keywords||build --- Comment #2 from Andrew Pinski --- This does look like a real issue in the rust front-end. lang_type is defined differently in those two files. -- You are receiving this mail because: You are on the CC list for the bug. -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
