https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
Hime Haieto changed:
What|Removed |Added
CC||himehaieto at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #21 from Hime Haieto ---
Sorry to leave you hanging this long, but I was actually testing this rather
extensively since your last update, both for dummy test cases and my real
(generic containers) application for it. I've thus far b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #17 from Hime Haieto ---
I'm not entirely sure what I should be doing/commenting on at the moment
considering that the current patches are clearly marked as being
temporary/partial fixes. However, I did still mess around with it a b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #14 from Hime Haieto ---
Said code *is* using -std=c23, so that's why. Don't worry - I'm not aware of
this affecting any pre-c23 code.
If you'd care for a bit more background, my code uses macros to define
so-called compound types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #12 from Hime Haieto ---
This is a good weekend indeed! While I can't say that all is well, this patch
is good progress - at least one of my non-toy sources compiles/works correctly
now with workarounds.
It seems like if you typede
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #8 from Hime Haieto ---
Alright, so apparently the union example is no longer valid (and the comments
you referenced were interesting, and I'd have never found them otherwise!), so
yes, scratch that one - the only issue here is for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #2 from Hime Haieto ---
Odd - I don't see any difference on trunk other than the addition of a helpful
note message (nice!). However, I'm testing trunk via godbolt, so I don't know
if its trunk might be slightly older.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
Bug ID: 118765
Summary: c23 tag matching broken for multiple redeclarations of
unions and typedefs
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #43 from Hime Haieto ---
1) Yes, I had been building within a git worktree,
repodir/worktrees/<14.2_worktree>/build/votocon/.
2) The bad links I got looked nuts, like so:
../../../libbacktrace/../../../libbacktrace/../../../libbackt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918
Hime Haieto changed:
What|Removed |Added
CC||himehaieto at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116729
--- Comment #1 from Hime Haieto ---
This PR is about C23, but I think it's interesting to note that -Wno-unused
does actually work to suppress this warning in g++ (at least for c++17),
although [[maybe_unused]] fails to do so. Neither option wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
--- Comment #7 from Hime Haieto ---
Your comment about typedefs is just starting to sink in...I'll have to return
to this later though, as this is a conference week for me and it's about to
start up again soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
--- Comment #6 from Hime Haieto ---
I was pretty sure the first example in the attachment to this PR was something
that should work (less so about the second), though something something
standardese something something language lawyers. Especia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #33 from Hime Haieto ---
(In reply to Jonathan Wakely from comment #31)
> (In reply to Andrew Pinski from comment #9)
> > So yes I can reproduce the failure
>
> I can't
>
>
> cd /tmp
> git clone ~/src/gcc/gcc
> cd gcc
> mkdir -p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #32 from Hime Haieto ---
(In reply to Jonathan Wakely from comment #28)
> (In reply to Hime Haieto from comment #27)
> > Also, the links don't even correctly point to the sources in the first
> > place,
>
> They do for me.
>
> > ye
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #29 from Hime Haieto ---
(In reply to Jonathan Wakely from comment #24)
> (In reply to Hime Haieto from comment #23)
> > you may not
> > have seen the rest of the Makefile.am and its history within the commit I
> > referenced.
>
> Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #27 from Hime Haieto ---
Also, the links don't even correctly point to the sources in the first place,
yet the build still completed for me with broken symlinks anyway. As for why I
tried removing the manual make rule entirely a lit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #26 from Hime Haieto ---
(In reply to Jonathan Wakely from comment #22)
> (In reply to Andreas Schwab from comment #15)
> > Does it help to change the symlink creation rules in
> > libstdc++-v3/src/libbacktrace/Makefile.am to use $(t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #23 from Hime Haieto ---
Relax, we're still working to pinpoint where the actual problem/solution is. I
only confused the src/build stuff for the raw makefile rule - you may not have
seen the rest of the Makefile.am and its history
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #18 from Hime Haieto ---
(In reply to Andreas Schwab from comment #17)
> No, top_builddir is wrong. The rule wants to link to a file in the _source_
> directory.
I think you may be right...I was thinking about what's to the left of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #16 from Hime Haieto ---
(In reply to Andreas Schwab from comment #15)
> Does it help to change the symlink creation rules in
> libstdc++-v3/src/libbacktrace/Makefile.am to use $(top_srcdir)/.. instead of
> ../../..? I think that sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #14 from Hime Haieto ---
It could still be worth doing a couple other "easy" tests first before going
more fully into the Makefile.am - skipping a separate make step (i.e. configure
then straight to make install), and if there's mayb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #13 from Hime Haieto ---
(In reply to Andrew Pinski from comment #12)
> (In reply to Andrew Pinski from comment #11)
> > I am testing a full non relative path configure now; that is:
> > ```
> > mkdir -p t1/t1
> > cd t1/t1
> > /home/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
--- Comment #2 from Hime Haieto ---
This may not actually be about pointer issues specifically - I came across
another failing test case that I think is most likely caused by the same
underlying issue:
typedef void f(struct s1);
struct s1 {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #10 from Hime Haieto ---
(In reply to Andrew Pinski from comment #9)
> So yes I can reproduce the failure but I think relative pathes other than
> `../` are not supported when it comes to configuring.
>
> As I mentioned invoking con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #8 from Hime Haieto ---
I am aware of how checking generated files, particularly from autotools, is a
common practice employed for convenience. I am also aware of how easily it can
mask bugs that could otherwise go unnoticed. Thoug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #6 from Hime Haieto ---
(In reply to Andrew Pinski from comment #4)
> > autoreconf2.69 -vfi
>
>
> Don't do this.
Where do you think babies...I mean configure comes from?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #5 from Hime Haieto ---
This is the same process I've used for every past version of gcc, every
autotools project that isn't completely broken by abusing the autotools
environment/standards, as well as most projects that don't use au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #3 from Hime Haieto ---
git clone 'git://gcc.gnu.org/git/gcc.git'
cd gcc
git worktree add worktrees/14.2.0 releases/gcc-14.2.0
cd worktrees/14.2.0
autoreconf2.69 -vfi
mkdir -p build/votocon
cd build/votocon
../../configure --prefix=/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
Bug ID: 116730
Summary: `make install` fails when processing libbacktrace
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
--- Comment #1 from Hime Haieto ---
This may possibly have some connections to the behaviour seen in PR116726.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116729
Bug ID: 116729
Summary: [[maybe_unused]] doesn't prevent warning for unused
function declarations
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
Bug ID: 116728
Summary: c23 tag compatibility broken with pointers to
incomplete types
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
--- Comment #2 from Hime Haieto ---
Actually, I had also tried using the -freport-bug option like the ICE had
advised, but it failed with the message:
"The bug is not reproducible, so it is likely a hardware or OS problem."
It seems to fail fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
Bug ID: 116726
Summary: compiler segfault when using certain struct
redefinitions
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
P
35 matches
Mail list logo
