subject:"\[Bug libfortran\/123366\] \[16 regression\] Segmentation fault on FreeBSD when compiling libgfortran\/generated"

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #44 from Andrew Pinski  ---
Fixed.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-10 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #43 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:1ce1870fbe0b141d38e02b7ac6a41d8d36b73b30

commit r16-7441-g1ce1870fbe0b141d38e02b7ac6a41d8d36b73b30
Author: Dimitry Andric 
Date:   Tue Feb 10 19:51:58 2026 +0100

build: Correctly restore CXXFLAGS/LDFLAGS for zstd test

Commit r16-5592-g56889bfec25 added saving and restoring of CXXFLAGS and
LDFLAGS in the gcc configure script, to avoid including the wrong zstd
headers.

However, due to misleading indentation in the configure script, the
restoration of CXXFLAGS and LDFLAGS was put after the if block where the
values were saved. This could cause various interesting effects, among
others segfaults while building gcc in the FreeBSD ports system.

Move the restoration of CXXFLAGS and LDFLAGS to just before the end of
the same if block to fix this.

Thanks to Mark Millard for spotting the actual mistake.

2026-02-10  Dimitry Andric  

gcc:
PR libfortran/123366
* configure.ac: Move restoring of CXXFLAGS/LDFLAGS for zstd test to
the correct place.
* configure: Regenerate.

Signed-off-by: Dimitry Andric

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-10 Thread dimitry at andric dot com via Gcc-bugs

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

--- Comment #42 from Dimitry Andric  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2026-February/708133.html

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-09 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #41 from Sam James  ---
(In reply to Dimitry Andric from comment #38)
> Created attachment 63606 [details]
> Fix misplaced block due to indent
> 
> I can confirm that lang/gcc16-devel, updated to the 20251130 snapshot,
> builds with the attached patch. It just moves the setting of CXXFLAGS and
> LDFLAGS into the preceding if block.

Please write it up with a commit message + ChangeLog, send to the ML, then we
can review it (you deserve the credit for debugging it)? I think it's obviously
correct though and I'll say such when posted.

The worst thing is, I think I even tried to check that when the patch was
posted, but I obviously missed this :(

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-09 Thread dimitry at andric dot com via Gcc-bugs

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

--- Comment #40 from Dimitry Andric  ---
(In reply to Lorenzo Salvadore from comment #39)
> Thanks Dimitry for creating the patch for the GCC code too.
> 
> Meanwhile, I have tested successfully the patch with latest GCC 16 snapshot
> (20260201).

Is there anybody on the gcc side willing to commit that patch, please? :)

Would be even nicer if it was backported to a few release branches. If needed I
can supply patches for those too.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-06 Thread developer at lorenzosalvadore dot it via Gcc-bugs

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

--- Comment #39 from Lorenzo Salvadore  
---
Thanks Dimitry for creating the patch for the GCC code too.

Meanwhile, I have tested successfully the patch with latest GCC 16 snapshot
(20260201).

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-06 Thread dimitry at andric dot com via Gcc-bugs

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

--- Comment #38 from Dimitry Andric  ---
Created attachment 63606
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63606&action=edit
Fix misplaced block due to indent

I can confirm that lang/gcc16-devel, updated to the 20251130 snapshot, builds
with the attached patch. It just moves the setting of CXXFLAGS and LDFLAGS into
the preceding if block.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-06 Thread developer at lorenzosalvadore dot it via Gcc-bugs

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

--- Comment #37 from Lorenzo Salvadore  
---
Thanks a lot Mark for your help with this issue! It was indeed quite difficult
to spot the problem with the nested if.

I am going to test the patch for the FreeBSD GCC 16 port and let you know if
everything is fine. If it is, then I will prepare the patch for the upstream
GCC code and attach it here.

(And once this bug will be fixed, I will do some work to upstream the patches
we already have in the FreeBSD ports tree, which will surely simplify our lives
in the future.)

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-06 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #36 from Mark Millard  ---
Created attachment 63605
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63605&action=edit
Temporary FreeBSD lang/gcc16-devel patch for one of the 2 problems

For now, for FreeBSD port lang/gcc16-devel . . .

This update to files/patch-gcc_configure should fix the
incorrect placement of a flags restore line pair in
gcc/configure for 20251130, from being like:

if . . .
. . .
saved_CXXFLAGS="$CXXFLAGS"
saved_LDFLAGS="$LDFLAGS"
. . .
fi

CXXFLAGS="$saved_CXXFLAGS"
LDFLAGS="$saved_LDFLAGS"


To being like:

if . . .
. . .
saved_CXXFLAGS="$CXXFLAGS"
saved_LDFLAGS="$LDFLAGS"
. . .
CXXFLAGS="$saved_CXXFLAGS"
LDFLAGS="$saved_LDFLAGS"
fi

In other words ( see comment #12 ):

https://gcc.gnu.org/cgit/gcc/commit/?id=56889bfec25e467deedb2750bdae7ec456a8f92c

is wrong. (gcc/configure.ac should get such a change upstream
as well. But I've not supplied such in the patch for
lang/gcc16-devel .)


The other of the 2 problems identified (no handling of a null
pointer return where such returns are allowed) is not fixed
but is hidden because the build happens to no longer return
the null pointer value during the build.


In other words, this should be enough to be a work around for
the FreeBSD OS lang/gcc16-devel context until upstream fixes
things.

But it is only build tested in my context.

Also, the patch makes no attempt to support prior to
20251130 and is only build tested for 20251130 .

Unpatched 20251130 code could be used for investigating
whatever the fix is for the null pointer handling problem.
I do not plan on investigating such.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-05 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #35 from Mark Millard  ---
(In reply to Dimitry Andric from comment #12)
> Bisecting seems to point at commit
> r16-5592-g56889bfec25e467deedb2750bdae7ec456a8f92c ("build: Save/restore
> CXXFLAGS for zstd tests") by Rainer Orth.
> 
> I don't completely understand the mechanism though, so I hope somebody else
> has a good insight. :)

The insight is that the code structure has part of the
code out of place. It has:

if . . .
. . .
saved_CXXFLAGS="$CXXFLAGS"
saved_LDFLAGS="$LDFLAGS"
. . .
fi 

CXXFLAGS="$saved_CXXFLAGS"
LDFLAGS="$saved_LDFLAGS"


It should be:

if . . .
. . .
saved_CXXFLAGS="$CXXFLAGS"
saved_LDFLAGS="$LDFLAGS"
. . .
CXXFLAGS="$saved_CXXFLAGS"
LDFLAGS="$saved_LDFLAGS"
fi


(There are nested if's involved that make it hard to track
by reading as the text is organized.)

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-05 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #34 from Mark Millard  ---
(In reply to Mark Millard from comment #33)
> In build/gcc/config.log . . .
> 
> The 3 ./conftest that prev-gcc/xg++ produced where the ./conftest
> fails with:
> 
> ld-elf.so.1: Shared object "libstdc++.so.6" not found, required by "conftest"
> 
> are the only ones where the prev-gcc/xg++ command involved
> did not contain:
> 
> -static-libstdc++ -static-libgcc
> 
> All the ./conftest produced using -static-libstdc++ -static-libgcc
> did not have the problem when that ./conftest was executed.
> 
> So a 1-1 correspondance and it appears that the 3 should have
> -static-libstdc++ -static-libgcc (or something specifying
> an rpath for finding a libstdc++.so.6 ?).

That is, for work/gcc-16-20251130, the failure example that has
been in use . . .

By contrast for work/gcc-16-20251123 that builds just fine
without any lang/gcc* installed in the context:

All the executed ./conftest were built using -static-libstdc++
-static-libgcc on the prev-gcc/xg++ command line and they all
work, including the 3 where work/gcc-16-20251130 did not use:

-static-libstdc++ -static-libgcc

This matches up with Dimitry Andric's comment 14 that
noted the gcc/Makefile difference

-CXXFLAGS = -g -O2 -fchecking=1
-LDFLAGS = -static-libstdc++ -static-libgcc
+CXXFLAGS =
+LDFLAGS =

and his comment 12 about the saved_CXXFLAGS and saved_LDFLAGS.

In 20251130 has the gcc/config.log 'configure:10612: checking for times'
as the first to not match 20251123 . The prior ones match between the
two. The last two that have matching prev-gcc/xg++ commands are:

configure:10341: checking for library containing dlopen
configure:10404: checking for inttypes.h

After that they mismatch.

For reference:

configure:10341: checking for library containing dlopen
configure:10372: 
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./prev-gcc/xg++
-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./prev-gcc/
-B/usr/local/x86_64-portbld-freebsd16.0/bin/ -nostdinc++

-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3
/libsupc++/.libs  -isystem
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include/x86_64-portbld-freebsd16.0
 -isystem /wrkdirs/usr/ports/lang/gcc16-devel
/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include  -isystem
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251123/libstdc++-v3/libsupc++
-L/wrkdirs/usr/ports/lang/gcc16-devel/work/.
build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-L/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/libsupc++/.libs
-o conftest -g -O2 -fcheckin
g=1 -DLIBICONV_PLUG -static-libstdc++ -static-libgcc  conftest.cpp  >&5
configure:10372: $? = 0
configure:10389: result: none required
configure:10404: checking for inttypes.h
configure:10425: 
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./prev-gcc/xg++
-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./prev-gcc/
-B/usr/local/x86_64-portbld-freebsd16.0/bin/ -nostdinc++

-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3
/libsupc++/.libs  -isystem
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include/x86_64-portbld-freebsd16.0
 -isystem /wrkdirs/usr/ports/lang/gcc16-devel
/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include  -isystem
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251123/libstdc++-v3/libsupc++
-L/wrkdirs/usr/ports/lang/gcc16-devel/work/.
build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-L/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/libsupc++/.libs
-c -g -O2 -fchecking=1 -DLIB
ICONV_PLUG conftest.cpp >&5
configure:10425: $? = 0
configure:10433: result: yes
configure:10612: checking for times
configure:10612: 
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./prev-gcc/xg++
-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./prev-gcc/
-B/usr/local/x86_64-portbld-freebsd16.0/bin/ -nostdinc++

-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3
/libsupc++/.libs  -isystem
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include/x86_64-portbld-freebsd16.0
 -isystem /wrkdirs/usr/ports/lang/gcc16-devel
/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include  -isystem
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251123/libstdc++-v3/libsupc++
-L/wrkdirs/usr/ports/lang/gcc16-devel/work/.
build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.l

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-05 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #33 from Mark Millard  ---
In build/gcc/config.log . . .

The 3 ./conftest that prev-gcc/xg++ produced where the ./conftest
fails with:

ld-elf.so.1: Shared object "libstdc++.so.6" not found, required by "conftest"

are the only ones where the prev-gcc/xg++ command involved
did not contain:

-static-libstdc++ -static-libgcc

All the ./conftest produced using -static-libstdc++ -static-libgcc
did not have the problem when that ./conftest was executed.

So a 1-1 correspondance and it appears that the 3 should have
-static-libstdc++ -static-libgcc (or something specifying
an rpath for finding a libstdc++.so.6 ?).

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-05 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #32 from Mark Millard  ---
(In reply to Mark Millard from comment #31)
> In case it is unclear:
> 
> My gcc/auto-host.h comparisons were of the same stage of two
> different runs where the environment varied by if there was
> a libstdc++.so.6 found vs. not by the ELF configuration
> search path. bootstrap-lean (via STANDARD_BOOTSTRAP) was
> in use for both, as was the initial toolchain (the world
> toolchain).
> 
> I was not comparing across different lang/gcc16-devel
> stages.

RETRACKED.

Rainer Orth was correct that I did not manage to
get the intended stage's gcc/auto-host.h from the
GOOD case so I was comparing across stages for
that file.

Not one of my better days. Sorry for wasting Rainer's
time on this point (mostly in an Email exchange).

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-05 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #31 from Mark Millard  ---
In case it is unclear:

My gcc/auto-host.h comparisons were of the same stage of two
different runs where the environment varied by if there was
a libstdc++.so.6 found vs. not by the ELF configuration
search path. bootstrap-lean (via STANDARD_BOOTSTRAP) was
in use for both, as was the initial toolchain (the world
toolchain).

I was not comparing across different lang/gcc16-devel
stages.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-04 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #30 from Mark Millard  ---
The problem for the:

ld-elf.so.1: Shared object "libstdc++.so.6" not found, required by "conftest"

appears to be the AC_LANG(C++) use for contexts in which
C would be sufficient. For FreeBSD , AC_LANG(C++) should
never be used for C code because libstdc++.so.6 need not
exist.

Both BAD and GOOD have the issue, the distinction for GOOD
is the context happening to have a libstdc++.so.6 that is
found and used because some other lang/gcc* had been
installed in the context.

Using the specific mbstowcs example: it is incorrect to
treat a libstdc++.so.6 failure as indicating anything
about the mbstowcs status that the test is attempting
to do. The resulting mbstowcs status ends up wrong for
FreeBSD. Similarly for at least 2 other status checks.

One way to view this: the gcc/configure.ac currently
presumes that libstdc++.so.6 is a non-optional system
library that can be used before a lang/gcc16-devel
libstdc++.so.6 has been built and put in place for
later stages of the build to use. That assumption
is false for FreeBSD.


Note the lack of any AC_LANG(C) in the below. :1566:
is part of the specific mbstowcs example.

# grep -n AC_LANG
/wrkdirs/usr/ports/lang/gcc16-devel/work.*/gcc-16-20251130/gcc/configure.ac
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:464:AC_LANG(C++)
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:535:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:547:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:558:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:1442:[AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:1522:[AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:1566:[
   AC_RUN_IFELSE([AC_LANG_SOURCE([[#include 
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:1662:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:1701:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:1716:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:1727:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:1743:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:1764:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:1784:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:1803:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:1833:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:2040:
 AC_COMPILE_IFELSE([AC_LANG_SOURCE([
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:6676:
 AC_LINK_IFELSE([AC_LANG_SOURCE([int main(void) {return 0;}])],
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:7775:
  AC_COMPILE_IFELSE([AC_LANG_SOURCE([int main(void) {return 0;}])],
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:7785:
  AC_LINK_IFELSE([AC_LANG_SOURCE([int main(void) {return 0;}])],
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:7899:
 AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/gcc-16-20251130/gcc/configure.ac:7913:
   AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/gcc-16-20251130/gcc/configure.ac:464:AC_LANG(C++)
/wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/gcc-16-20251130/gcc/configure.ac:535:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/gcc-16-20251130/gcc/configure.ac:547:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/gcc-16-20251130/gcc/configure.ac:558:AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
/wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/gcc-16-20251130/gcc/configure.ac:1442:[AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
/wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/gcc-16-20251130/gcc/configure.ac:1522:[AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
/wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/gcc-16-20251130/gcc/configure.ac:1566:[
   AC_RUN_IFELSE([AC_LANG_SOURCE([[#include 
/wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/gcc-16-20251130/gcc/configure.ac:1662:AC_COMPILE_IFELSE([AC_LA

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-04 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #29 from Mark Millard  ---
Note to Lorenzo Salvadore :

Only the SIGSEGV issue is specific to libfortran in the
lang/gcc16-devel build.

The 3 misconfigurations for FreeBSD when there is no
prior lang/gcc* installation in the relevant environment
is just pain wrong for the whole, overall build.

There may need to be a separate submittal for the:

-/* #undef HAVE_ICONV */
+#define HAVE_ICONV 1

-/* #undef HAVE_WORKING_FORK */
+#define HAVE_WORKING_FORK 1

-/* #undef HAVE_WORKING_MBSTOWCS */
+#define HAVE_WORKING_MBSTOWCS 1

and the 3 related instances of:

ld-elf.so.1: Shared object "libstdc++.so.6" not found, required by "conftest"

that cause those incorrect ("-") cases.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-04 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #28 from Mark Millard  ---
(In reply to Rainer Orth from comment #27)
> I'm seeing those SEGVs myself, but only since I upgraded from FreeBSD 14.3 to
> 15.0, and even then only for 11000+ g++ tests where cc1plus SEGVs.  The build
> itself works without issues.
> 
> . . .


See comment 19 where it is not cc1plus and not posix_fallocate
that was involved but .build/gcc/f951 in linemap_check_ordinary
that SIGSEGV's when linemap_lookup returned a null pointer for
use as an argument, something it is designed to be able to do,
but the code using that linemap_lookup call does not try to
handle. So: Not the same SIGSEGV's.


But there is a lang/gcc16-devel internal configuration problem
as well where it matters if there is a prior installation of a
lang/gcc* vs. not --when there should be no requirement on
FreeBSD to have already installed a lang/gcc* in order to build
lang/gcc16-devel . This happens rather early in the overall
build, long before the gfortran related build activity. It
leads to variations like:

 /* Define this macro if mbstowcs does not crash when its first argument is
NULL. */
 #ifndef USED_FOR_TARGET
-/* #undef HAVE_WORKING_MBSTOWCS */
+#define HAVE_WORKING_MBSTOWCS 1
 #endif

that just should not be occurring: both types of contexts should
have the "+" case. The "-" case is just wrong for the FreeBSD OS
involved in my testing.


Your cc1plus SIGSEGV problem is distinct from both the problems
that I identified for lang/gcc16-devel builds. No cc1plus
SIGSEGV has been observed for the lang/gcc16-devel builds.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-04 Thread ro at gcc dot gnu.org via Gcc-bugs

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

--- Comment #27 from Rainer Orth  ---
I'm seeing those SEGVs myself, but only since I upgraded from FreeBSD 14.3 to
15.0, and even then only for 11000+ g++ tests where cc1plus SEGVs.  The build
itself works without issues.

Looking at the failing invocation with truss, I see right before the end

69427:
openat(AT_FDCWD,"gcm.cache/has_internal_linkage-counter.gcm~",O_RDWR|O_CR
EAT|O_TRUNC|O_CLOEXEC,0666) = 4 (0x4)
69427: posix_fallocate(0x4,0x0,0x2000)   ERR#45 'Operation not
supported
'
69427: posix_fallocate(0x4,0x0,0x1000)   ERR#45 'Operation not
supported
'
69427: posix_fallocate(0x4,0x0,0x2000)   ERR#45 'Operation not
supported
'
69427: posix_fallocate(0x4,0x0,0x1000)   ERR#45 'Operation not
supported
'
69427: posix_fallocate(0x4,0x0,0x2000)   ERR#45 'Operation not
supported
'
69427: posix_fallocate(0x4,0x0,0x1000)   ERR#45 'Operation not
supported
'
69427: SIGNAL 11 (SIGSEGV) code=SEGV_MAPERR trapno=12 addr=0x10
69427: sigprocmask(SIG_SETMASK,{ SIGSEGV },0x0)  = 0 (0x0)

ERR#45 isn't even documented as a possible error code for posix_fallocate ;-(

I wonder what filesystem type you are running your builds on?

In my case, it's zfs.  I'm starting my bootstrap with a self-compiled
gcc 11.4.0 (which includes gdc).

Rather than comparing build logs and auto-host.h files, I think it would be way
more effective to investigate the SEGVs themselves to get a direct
understanding
of the failure.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-04 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #26 from Mark Millard  ---
(In reply to Mark Millard from comment #19)
(In reply to Mark Millard from comment #25)

I think I've identified 2 problems:

comment #19 reports, in part:

QUOTE
Looks like linemap_lookup (in line 843) is returning the null
pointer value and the calling/using code does not check for
or handle that. I've currently no clue why the null pointer
is returned.
END QUOTE

comment #25 reports, in part:

QUOTE
I'm not sure why .build/./prev-gcc/xg++ is in use
for this check, leading to the need for
libstdc++.so.6 being available.
END QUOTE

I'll add here to that last: when it need not be available
at that point. Having a lang/gcc* already installed can
lead to one being available via the ELF config search
path. (Not true of the poudriere jail for a normal
poudriere bulk build.)

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-04 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #25 from Mark Millard  ---
(In reply to Mark Millard from comment #24)
> (In reply to Mark Millard from comment #23)
> > . . .
> > 
> > # grep -n ld-elf.so.1:
> > /wrkdirs/usr/ports/lang/gcc16-devel/work.*/.build/gcc/config.log | less
> > /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.log:4920:ld-
> > elf.so.1: Shared object "libstdc++.so.6" not found, required by "conftest"
> > /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.log:5919:ld-
> > elf.so.1: Shared object "libstdc++.so.6" not found, required by "conftest"
> > /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.log:6117:ld-
> > elf.so.1: Shared object "libstdc++.so.6" not found, required by "conftest"
> 
> Going through the config.log files in time sequence order,
> looking for the first signficant differences between BAD 
> and GOOD, the above for :4920: looks to be the first such.

And, since it involves:

. . .
-| #include 
-| int main()
-| {
-|   mbstowcs(0, "", 0);
-|   return 0;
-| }

It likely explains the .build/gcc/auto-host.h :

-/* #undef HAVE_WORKING_MBSTOWCS */
+#define HAVE_WORKING_MBSTOWCS 1

The other 2 likely have a similar status for
the other 2 .build/gcc/auto-host.h differences.

I'm not sure why .build/./prev-gcc/xg++ is in use
for this check, leading to the need for
libstdc++.so.6 being available.


As for why it is found in the GOOD case when gcc15 had
been previously installed, the poudriere jail context
reports:

# ldconfig -r | grep gcc15
search directories:
/lib:/usr/lib:/usr/local/lib:/usr/local/lib/compat/pkg:/usr/local/lib/gcc15:/usr/local/lib/perl5/5.42/mach/CORE
239:-lstdc++.6 => /usr/local/lib/gcc15/libstdc++.so.6
240:-lubsan.1 => /usr/local/lib/gcc15/libubsan.so.1
241:-lasan.8 => /usr/local/lib/gcc15/libasan.so.8
242:-lcc1.0 => /usr/local/lib/gcc15/libcc1.so.0
243:-lgcc_s.1 => /usr/local/lib/gcc15/libgcc_s.so.1
244:-latomic.1 => /usr/local/lib/gcc15/libatomic.so.1
245:-lquadmath.0 => /usr/local/lib/gcc15/libquadmath.so.0
246:-lgccjit.0 => /usr/local/lib/gcc15/libgccjit.so.0
247:-lgfortran.5 => /usr/local/lib/gcc15/libgfortran.so.5
248:-lgomp.1 => /usr/local/lib/gcc15/libgomp.so.1
249:-litm.1 => /usr/local/lib/gcc15/libitm.so.1

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-04 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #24 from Mark Millard  ---
(In reply to Mark Millard from comment #23)
> . . .
> 
> # grep -n ld-elf.so.1:
> /wrkdirs/usr/ports/lang/gcc16-devel/work.*/.build/gcc/config.log | less
> /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.log:4920:ld-
> elf.so.1: Shared object "libstdc++.so.6" not found, required by "conftest"
> /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.log:5919:ld-
> elf.so.1: Shared object "libstdc++.so.6" not found, required by "conftest"
> /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.log:6117:ld-
> elf.so.1: Shared object "libstdc++.so.6" not found, required by "conftest"

Going through the config.log files in time sequence order,
looking for the first signficant differences between BAD 
and GOOD, the above for :4920: looks to be the first such.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-04 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #23 from Mark Millard  ---
(In reply to Mark Millard from comment #22)
> Odd differences in BAD vs. GOOD ?
> 
> diff -ru /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/auto-host.h
> /wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/.build/gcc/auto-host.h
> --- /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/auto-host.h
> 2026-02-04 05:56:02.544124000 +
> +++ /wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/.build/gcc/auto-host.h
> 2026-02-03 21:29:09.873515000 +
> @@ -1676,7 +1676,7 @@
>  
>  /* Define if you have the iconv() function and it works. */
>  #ifndef USED_FOR_TARGET
> -/* #undef HAVE_ICONV */
> +#define HAVE_ICONV 1
>  #endif
>  
>  
> @@ -2267,14 +2267,14 @@
>  
>  /* Define to 1 if `fork' works. */
>  #ifndef USED_FOR_TARGET
> -/* #undef HAVE_WORKING_FORK */
> +#define HAVE_WORKING_FORK 1
>  #endif
>  
>  
>  /* Define this macro if mbstowcs does not crash when its first argument is
> NULL. */
>  #ifndef USED_FOR_TARGET
> -/* #undef HAVE_WORKING_MBSTOWCS */
> +#define HAVE_WORKING_MBSTOWCS 1
>  #endif
>  
>  
> 
> And:
> 
> diff -ru
> /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.cache
> /wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/.build/gcc/config.cache
> --- /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.cache
> 2026-02-04 05:56:02.273738000 +
> +++ /wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/.build/gcc/config.cache   
> 2026-02-03 21:29:09.60554 +
> @@ -73,7 +73,7 @@
>  ac_cv_func_fgets_unlocked=${ac_cv_func_fgets_unlocked=no}
>  ac_cv_func_fileno_unlocked=${ac_cv_func_fileno_unlocked=yes}
>  ac_cv_func_fork=${ac_cv_func_fork=yes}
> -ac_cv_func_fork_works=${ac_cv_func_fork_works=no}
> +ac_cv_func_fork_works=${ac_cv_func_fork_works=yes}
>  ac_cv_func_fprintf_unlocked=${ac_cv_func_fprintf_unlocked=no}
>  ac_cv_func_fputc_unlocked=${ac_cv_func_fputc_unlocked=yes}
>  ac_cv_func_fputs_unlocked=${ac_cv_func_fputs_unlocked=yes}
> @@ -250,8 +250,8 @@
>  acx_cv_prog_cc_warning__fno_rtti=${acx_cv_prog_cc_warning__fno_rtti=yes}
>  am_cv_CXX_dependencies_compiler_type=${am_cv_CXX_dependencies_compiler_type=
> gcc3}
>  am_cv_func_iconv=${am_cv_func_iconv=yes}
> -am_cv_func_iconv_summary=${am_cv_func_iconv_summary='not working, consider
> installing GNU libiconv'}
> -am_cv_func_iconv_works=${am_cv_func_iconv_works=no}
> +am_cv_func_iconv_summary=${am_cv_func_iconv_summary='yes, in libc'}
> +am_cv_func_iconv_works=${am_cv_func_iconv_works=yes}
>  am_cv_langinfo_codeset=${am_cv_langinfo_codeset=yes}
>  am_cv_lib_iconv=${am_cv_lib_iconv=no}
>  am_cv_val_LC_MESSAGES=${am_cv_val_LC_MESSAGES=yes}
> @@ -327,7 +327,7 @@
>  gcc_cv_decl_char_bit=${gcc_cv_decl_char_bit=yes}
>  gcc_cv_decl_map_anon=${gcc_cv_decl_map_anon=yes}
>  gcc_cv_dsymutil=${gcc_cv_dsymutil=''}
> -gcc_cv_func_mbstowcs_works=${gcc_cv_func_mbstowcs_works=no}
> +gcc_cv_func_mbstowcs_works=${gcc_cv_func_mbstowcs_works=yes}
>  gcc_cv_func_mmap_anon=${gcc_cv_func_mmap_anon=yes}
>  gcc_cv_func_mmap_dev_zero=${gcc_cv_func_mmap_dev_zero=yes}
>  gcc_cv_func_mmap_file=${gcc_cv_func_mmap_file=yes}
> 
> 
> And:
> 
>  configure:10693: 
> /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./prev-gcc/xg++
> -B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./prev-gcc/
> -B/usr/local/x86_64-portbld-freebsd16.0/bin/ -nostdinc++
> -B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-
> freebsd16.0/libstdc++-v3/src/.libs
> -B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-
> freebsd16.0/libstdc++-v3/libsupc++/.libs  -isystem
> /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-
> freebsd16.0/libstdc++-v3/include/x86_64-portbld-freebsd16.0  -isystem
> /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-
> freebsd16.0/libstdc++-v3/include  -isystem
> /wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libstdc++-v3/
> libsupc++
> -L/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-
> freebsd16.0/libstdc++-v3/src/.libs
> -L/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-
> freebsd16.0/libstdc++-v3/libsupc++/.libs -o conftest  -DLIBICONV_PLUG 
> conftest.cpp  >&5
>  configure:10693: $? = 0
>  configure:10693: ./conftest
> -ld-elf.so.1: Shared object "libstdc++.so.6" not found, required by
. . .

For reference, such happens 3 times, and only for BAD, not GOOD:

# grep -n ld-elf.so.1:
/wrkdirs/usr/ports/lang/gcc16-devel/work.*/.build/gcc/config.log | less
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.log:4920:ld-elf.so.1:
Shared object "libstdc++.so.6" not found, required by "conftest"
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.log:5919:ld-elf.so.1:
Shared object "libstdc++.so.6" not found, required by "conftest"
/wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.log:6117:ld-elf.so.1:
Shared object "libstdc++.so.6" not found, required by "conftest"

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-03 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #22 from Mark Millard  ---
Odd differences in BAD vs. GOOD ?

diff -ru /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/auto-host.h
/wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/.build/gcc/auto-host.h
--- /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/auto-host.h
2026-02-04 05:56:02.544124000 +
+++ /wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/.build/gcc/auto-host.h   
2026-02-03 21:29:09.873515000 +
@@ -1676,7 +1676,7 @@

 /* Define if you have the iconv() function and it works. */
 #ifndef USED_FOR_TARGET
-/* #undef HAVE_ICONV */
+#define HAVE_ICONV 1
 #endif


@@ -2267,14 +2267,14 @@

 /* Define to 1 if `fork' works. */
 #ifndef USED_FOR_TARGET
-/* #undef HAVE_WORKING_FORK */
+#define HAVE_WORKING_FORK 1
 #endif


 /* Define this macro if mbstowcs does not crash when its first argument is
NULL. */
 #ifndef USED_FOR_TARGET
-/* #undef HAVE_WORKING_MBSTOWCS */
+#define HAVE_WORKING_MBSTOWCS 1
 #endif



And:

diff -ru /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.cache
/wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/.build/gcc/config.cache
--- /wrkdirs/usr/ports/lang/gcc16-devel/work.BAD/.build/gcc/config.cache   
2026-02-04 05:56:02.273738000 +
+++ /wrkdirs/usr/ports/lang/gcc16-devel/work.GOOD/.build/gcc/config.cache  
2026-02-03 21:29:09.60554 +
@@ -73,7 +73,7 @@
 ac_cv_func_fgets_unlocked=${ac_cv_func_fgets_unlocked=no}
 ac_cv_func_fileno_unlocked=${ac_cv_func_fileno_unlocked=yes}
 ac_cv_func_fork=${ac_cv_func_fork=yes}
-ac_cv_func_fork_works=${ac_cv_func_fork_works=no}
+ac_cv_func_fork_works=${ac_cv_func_fork_works=yes}
 ac_cv_func_fprintf_unlocked=${ac_cv_func_fprintf_unlocked=no}
 ac_cv_func_fputc_unlocked=${ac_cv_func_fputc_unlocked=yes}
 ac_cv_func_fputs_unlocked=${ac_cv_func_fputs_unlocked=yes}
@@ -250,8 +250,8 @@
 acx_cv_prog_cc_warning__fno_rtti=${acx_cv_prog_cc_warning__fno_rtti=yes}

am_cv_CXX_dependencies_compiler_type=${am_cv_CXX_dependencies_compiler_type=gcc3}
 am_cv_func_iconv=${am_cv_func_iconv=yes}
-am_cv_func_iconv_summary=${am_cv_func_iconv_summary='not working, consider
installing GNU libiconv'}
-am_cv_func_iconv_works=${am_cv_func_iconv_works=no}
+am_cv_func_iconv_summary=${am_cv_func_iconv_summary='yes, in libc'}
+am_cv_func_iconv_works=${am_cv_func_iconv_works=yes}
 am_cv_langinfo_codeset=${am_cv_langinfo_codeset=yes}
 am_cv_lib_iconv=${am_cv_lib_iconv=no}
 am_cv_val_LC_MESSAGES=${am_cv_val_LC_MESSAGES=yes}
@@ -327,7 +327,7 @@
 gcc_cv_decl_char_bit=${gcc_cv_decl_char_bit=yes}
 gcc_cv_decl_map_anon=${gcc_cv_decl_map_anon=yes}
 gcc_cv_dsymutil=${gcc_cv_dsymutil=''}
-gcc_cv_func_mbstowcs_works=${gcc_cv_func_mbstowcs_works=no}
+gcc_cv_func_mbstowcs_works=${gcc_cv_func_mbstowcs_works=yes}
 gcc_cv_func_mmap_anon=${gcc_cv_func_mmap_anon=yes}
 gcc_cv_func_mmap_dev_zero=${gcc_cv_func_mmap_dev_zero=yes}
 gcc_cv_func_mmap_file=${gcc_cv_func_mmap_file=yes}


And:

 configure:10693: 
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./prev-gcc/xg++
-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./prev-gcc/
-B/usr/local/x86_64-portbld-freebsd16.0/bin/ -nostdinc++
-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/libsupc++/.libs
 -isystem
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include/x86_64-portbld-freebsd16.0
 -isystem
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include
 -isystem
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libstdc++-v3/libsupc++
-L/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-L/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/libsupc++/.libs
-o conftest  -DLIBICONV_PLUG  conftest.cpp  >&5
 configure:10693: $? = 0
 configure:10693: ./conftest
-ld-elf.so.1: Shared object "libstdc++.so.6" not found, required by "conftest"
-configure:10693: $? = 1
-configure: program exited with status 1
-configure: failed program was:
-| /* confdefs.h */
-| #define PACKAGE_NAME ""
-| #define PACKAGE_TARNAME ""
-| #define PACKAGE_VERSION ""
-| #define PACKAGE_STRING ""
-| #define PACKAGE_BUGREPORT ""
-| #define PACKAGE_URL ""
-| #define ENABLE_STDLIB_OPTION 1
-| #define DEFAULT_LINKER "/usr/local/bin/ld"
-| #define DEFAULT_ASSEMBLER "/usr/local/bin/as"
-| #define STDC_HEADERS 1
-| #define HAVE_SYS_TYPES_H 1
-| #define HAVE_SYS_STAT_H 1
-| #define HAVE_STDLIB_H 1
-| #define HAVE_STRING_H 1
-| #define HAVE_MEMORY_H 1
-| #define HAVE_STRINGS_H 1
-| #define HAVE_INTTYPES_H 1
-| #define HAVE_STDINT_H 1
-| #define HAVE_UNISTD_H 1
-| #define __EXTENSIONS__ 1
-| #define _ALL_SOURCE 1
-| #define _GNU_SOURCE 1
-| #define _POSIX_PTHREAD_SEMANTICS 1
-| #define _TANDEM_SOURCE 1
-| #define SIZEOF_INO_T 8
-| #define SIZEO

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-03 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #21 from Mark Millard  ---
(In reply to Mark Millard from comment #20)
> (In reply to Mark Millard from comment #18)
> 
> > Since there appear to be good vs. bad instances of the likes of:
> > 
> > /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/f951
> > 
> >. . .
> > 
> > might someone be able to report the ldd -a output for an
> > instance of each status for one of those (or other such example)?
> 

This time for a working build (lang/gcc15 had been installed
before the build):

# ldd -a /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/f951 
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/f951:
libz.so.6 => /lib/libz.so.6 (0x22a1521cc000)
libmpc.so.3 => /usr/local/lib/libmpc.so.3 (0x22a153e17000)
libmpfr.so.6 => /usr/local/lib/libmpfr.so.6 (0x22a154a01000)
libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x22a1558f2000)
libm.so.5 => /lib/libm.so.5 (0x22a152de8000)
libc.so.7 => /lib/libc.so.7 (0x22a15648f000)
/lib/libz.so.6:
libc.so.7 => /lib/libc.so.7 (0x22a15648f000)
/usr/local/lib/libmpc.so.3:
libmpfr.so.6 => /usr/local/lib/libmpfr.so.6 (0x22a154a01000)
libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x22a1558f2000)
libm.so.5 => /lib/libm.so.5 (0x22a152de8000)
libc.so.7 => /lib/libc.so.7 (0x22a15648f000)
/usr/local/lib/libmpfr.so.6:
libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x22a1558f2000)
libc.so.7 => /lib/libc.so.7 (0x22a15648f000)
/usr/local/lib/libgmp.so.10:
libc.so.7 => /lib/libc.so.7 (0x22a15648f000)
/lib/libm.so.5:
libc.so.7 => /lib/libc.so.7 (0x22a15648f000)
/lib/libc.so.7:
libsys.so.7 => /lib/libsys.so.7 (0x22a15872f000)
[preloaded]
[vdso] (0x22a15124b000)

Looks like the same lists of files are used to me. The
difference is apparently inside f951, not what f951
binds to.

It would seem some part of the example build is finding
something involving some path from:

# find /usr/local/ -name '*gcc15*' -print | less
/usr/local/include/gcc15
/usr/local/bin/x86_64-portbld-freebsd16.0-gcc15
/usr/local/bin/gcc15
/usr/local/lib/gcc15
/usr/local/share/licenses/gcc15-15.2.0_1
/usr/local/share/info/gcc15
/usr/local/share/man/man1/gcc15.1.gz
/usr/local/libdata/ldconfig/gcc15
/usr/local/libdata/ldconfig32/gcc15
/usr/local/lib32/gcc15
/usr/local/libexec/gcc15

when such exists (but not when no such exists) and
the build then works differently as a consequence.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-03 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #20 from Mark Millard  ---
(In reply to Mark Millard from comment #18)

> Since there appear to be good vs. bad instances of the likes of:
> 
> /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/f951
> 
>. . .
> 
> might someone be able to report the ldd -a output for an
> instance of each status for one of those (or other such example)?

At least for a failing case for f951:

# ldd -a /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/f951
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/f951:
libz.so.6 => /lib/libz.so.6 (0x19b044602000)
libmpc.so.3 => /usr/local/lib/libmpc.so.3 (0x19b045434000)
libmpfr.so.6 => /usr/local/lib/libmpfr.so.6 (0x19b046744000)
libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x19b047767000)
libm.so.5 => /lib/libm.so.5 (0x19b0484e3000)
libc.so.7 => /lib/libc.so.7 (0x19b048b36000)
/lib/libz.so.6:
libc.so.7 => /lib/libc.so.7 (0x19b048b36000)
/usr/local/lib/libmpc.so.3:
libmpfr.so.6 => /usr/local/lib/libmpfr.so.6 (0x19b046744000)
libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x19b047767000)
libm.so.5 => /lib/libm.so.5 (0x19b0484e3000)
libc.so.7 => /lib/libc.so.7 (0x19b048b36000)
/usr/local/lib/libmpfr.so.6:
libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x19b047767000)
libc.so.7 => /lib/libc.so.7 (0x19b048b36000)
/usr/local/lib/libgmp.so.10:
libc.so.7 => /lib/libc.so.7 (0x19b048b36000)
/lib/libm.so.5:
libc.so.7 => /lib/libc.so.7 (0x19b048b36000)
/lib/libc.so.7:
libsys.so.7 => /lib/libsys.so.7 (0x19b0490dc000)
[preloaded]
[vdso] (0x19b043c7d000)

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-03 Thread markmigm at gmail dot com via Gcc-bugs

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

--- Comment #19 from Mark Millard  ---
(In reply to Mark Millard from comment #18)

Summary:

Looks like linemap_lookup is returning the null pointer value
and the calling code does not check for that.

Details leading to that:

> Since there appear to be good vs. bad instances of the likes of:
> 
> /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/f951
> 
> or of:
> 
> /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./gcc/gfortran
> 
> might someone be able to report the ldd -a output for an
> instance of each status for one of those (or other such example)?

Turns out that gfortran is vforking to f951 which gets the
error.

(gdb) set follow-fork-mode child
(gdb) run -B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./gcc/
-B/usr/local/x86_64-portbld-freebsd16.0/bin/
-B/usr/local/x86_64-portbld-freebsd16.0/lib/ -isystem
/usr/local/x86_64-portbld-freebsd16.0/include -isystem
/usr/local/x86_64-portbld-freebsd16.0/sys-include   -fchecking=1
-DHAVE_CONFIG_H -I.
-I/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran 
-iquote/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/io
-I/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../gcc
-I/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../gcc/config
-I/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../libquadmath
-I../.././gcc
-I/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../libgcc
-I../libgcc
-I/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../libbacktrace
-I../libbacktrace -I../libbacktrace  -I . -Wall -Werror -fimplicit-none
-fno-repack-arrays -fno-underscoring   -fallow-leading-underscore
-fbuilding-libgfortran -g -c -o generated/_abs_c17.lo
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/generated/_abs_c17.F90
Starting program: /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/gfortran
-B/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./gcc/
-B/usr/local/x86_64-portbld-freebsd16.0/bin/
-B/usr/local/x86_64-portbld-freebsd16.0/lib/ -isystem
/usr/local/x86_64-portbld-freebsd16.0/include -isystem
/usr/local/x86_64-portbld-freebsd16.0/sys-include   -fchecking=1
-DHAVE_CONFIG_H -I.
-I/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran 
-iquote/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/io
-I/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../gcc
-I/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../gcc/config
-I/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../libquadmath
-I../.././gcc
-I/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../libgcc
-I../libgcc
-I/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../libbacktrace
-I../libbacktrace -I../libbacktrace  -I . -Wall -Werror -fimplicit-none
-fno-repack-arrays -fno-underscoring   -fallow-leading-underscore
-fbuilding-libgfortran -g -c -o generated/_abs_c17.lo
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/generated/_abs_c17.F90
[Attaching after LWP 102123 of process 41051 vfork to child LWP 102557 of
process 41052]
[New inferior 2 (process 41052)]
[Detaching vfork parent process 41051 after child exec]
[Inferior 1 (process 41051) detached]
process 41052 is executing new program:
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/f951

Thread 2.1 received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
[Switching to LWP 102557 of process 41052]
linemap_check_ordinary (map=0x0) at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/../libcpp/include/line-map.h:644
644   linemap_assert (MAP_ORDINARY_P (map));
(gdb) bt
#0  linemap_check_ordinary (map=0x0) at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/../libcpp/include/line-map.h:644
#1  maybe_print_line (src_loc=0) at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/fortran/cpp.cc:843
#2  0x00a50a2a in scan_translation_unit_trad (pfile=) at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/fortran/cpp.cc:828
#3  gfc_cpp_preprocess (source_file=) at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/fortran/cpp.cc:685
#4  0x00b3595c in gfc_new_file () at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/fortran/scanner.cc:2778
#5  0x00b683d3 in gfc_init () at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/fortran/f95-lang.cc:294
#6  0x00a23ac3 in lang_dependent_init (name=0x7fffe1b3
"/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/generated/_abs_c17.F90")
at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/toplev.cc:1911
#7  do_compile () at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/toplev.cc:2209
#8  toplev::main (this=this@entry=0x7fffdb8e, argc=,
argc@entry=65, argv=, argv@entry=0x7ff

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-02-03 Thread markmigm at gmail dot com via Gcc-bugs

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

Mark Millard  changed:

   What|Removed |Added

 CC||markmigm at gmail dot com

--- Comment #18 from Mark Millard  ---
Since there appear to be good vs. bad instances of the likes of:

/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/f951

or of:

/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./gcc/gfortran

might someone be able to report the ldd -a output for an
instance of each status for one of those (or other such example)?

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-28 Thread law at gcc dot gnu.org via Gcc-bugs

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-24 Thread dimitry at andric dot com via Gcc-bugs

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

--- Comment #17 from Dimitry Andric  ---
(In reply to Lorenzo Salvadore from comment #16)
> I am still working on understanding this issue and I believe I have found a
> way to reproduce the bug consistently: attempt to build GCC on a FreeBSD
> machine where no GCC version is already installed.
> 
> If a GCC is already installed, then the build succeeds. But if no GCC is
> found, then it will segfault.

Aha, that explains why it didn't segfault for me initially: I have several gcc
ports installed. :)  But in poudriere a clean jail is used, so then it won't
have any gcc. So maybe it's got something to do with the compiler used to build
the first stage, i.e. clang? Or some library that it's linking in?

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-24 Thread developer at lorenzosalvadore dot it via Gcc-bugs

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

--- Comment #16 from Lorenzo Salvadore  
---
I am still working on understanding this issue and I believe I have found a way
to reproduce the bug consistently: attempt to build GCC on a FreeBSD machine
where no GCC version is already installed.

If a GCC is already installed, then the build succeeds. But if no GCC is found,
then it will segfault.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-09 Thread sgk at troutmask dot apl.washington.edu via Gcc-bugs

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

--- Comment #15 from Steve Kargl  ---
On Fri, Jan 09, 2026 at 10:20:16AM +, developer at lorenzosalvadore dot it
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123366
> 
> --- Comment #10 from Lorenzo Salvadore  
> ---
> (In reply to Steve Kargl from comment #9)
> 
> > So, technically not a GCC bug?
> 
> I still believe that it is a GCC bug, but for now we are able to reproduce it
> only within the poudriere environment (poudriere is FreeBSD's official 
> packages
> builder; it works by creating a clean FreeBSD container where the software is
> compiled and packaged). I will compare my system's environment with 
> poudriere's
> environment and see if I can reproduce the segmentation fault directly on the
> OS.
> 
> I will also attempt to bisect the commit, since we already know the week when
> the fault started.

I build gcc daily; often times multiple times a day.  I have not
seen the issue you're reporting.  The only reason I spend so 
much effort on GCC is to ensure that gfortran works.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-09 Thread dimitry at andric dot com via Gcc-bugs

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

--- Comment #14 from Dimitry Andric  ---
Difference between "good" and "bad" builds seem to mainly in the resulting
CXXFLAGS and LDFLAGS for gcc/Makefile:

The "good" builds have CXXFLAGS=-g -O2 -fchecking=1 and
LDFLAGS=-static-libstdc++ -static-libgcc, while the "bad" builds have empty
CXXFLAGS and LDFLAGS.

Diff of the interesting files of the work directories (good first, bad second):

--- /wrkdirs/share/dim/ports/lang/gcc16-devel/work.good/.build/gcc/Makefile
2026-01-09 18:42:41.163059000 +0100
+++ /wrkdirs/share/dim/ports/lang/gcc16-devel/work.bad/.build/gcc/Makefile 
2026-01-09 19:17:11.799097000 +0100
@@ -153,8 +153,8 @@ CFLAGS = -g -O2 -fchecking=1
 TCFLAGS =
 TFLAGS =
 CFLAGS = -g -O2 -fchecking=1
-CXXFLAGS = -g -O2 -fchecking=1
-LDFLAGS = -static-libstdc++ -static-libgcc
+CXXFLAGS =
+LDFLAGS =

 # Should we build position-independent host code?
 PICFLAG = -fPIC
@@ -425,7 +425,7 @@ PLUGINCC =  /wrkdirs/share/dim/ports/lang/gcc16-devel/

 # Compiler and flags needed for plugin support
 PLUGINCC = 
/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/./prev-gcc/xg++
-B/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/./prev-gcc/
-B/usr/local/x86_64-portbld-freebsd16.0/bin/ -nostdinc++
-B/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-B/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/libsupc++/.libs
 -isystem
/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include/x86_64-portbld-freebsd16.0
 -isystem
/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include
 -isystem
/wrkdirs/share/dim/ports/lang/gcc16-devel/work/gcc-16-20251130/libstdc++-v3/libsupc++
-L/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-L/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/libsupc++/.libs
-PLUGINCFLAGS = -g -O2 -fchecking=1
+PLUGINCFLAGS =

 # Libs and linker options needed for plugin support
 PLUGINLIBS = -rdynamic
diff -uprd -I ^configure:[0-9]*:  -I /home/dim/tmp/cc.*\.o -I
/home/dim/tmp/conftest-.*\.o
/wrkdirs/share/dim/ports/lang/gcc16-devel/work.good/.build/gcc/config.log
/wrkdirs/share/dim/ports/lang/gcc16-devel/work.bad/.build/gcc/config.log
--- /wrkdirs/share/dim/ports/lang/gcc16-devel/work.good/.build/gcc/config.log  
2026-01-09 18:42:41.278156000 +0100
+++ /wrkdirs/share/dim/ports/lang/gcc16-devel/work.bad/.build/gcc/config.log   
2026-01-09 19:17:11.947281000 +0100
@@ -10014,7 +10014,7 @@ CXXDEPMODE='depmode=gcc3'
 CXX=' /wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/./prev-gcc/xg++
-B/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/./prev-gcc/
-B/usr/local/x86_64-portbld-freebsd16.0/bin/ -nostdinc++
-B/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-B/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/libsupc++/.libs
 -isystem
/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include/x86_64-portbld-freebsd16.0
 -isystem
/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include
 -isystem
/wrkdirs/share/dim/ports/lang/gcc16-devel/work/gcc-16-20251130/libstdc++-v3/libsupc++
-L/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-L/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/libsupc++/.libs'
 CXXCPP=' /wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/./prev-gcc/xg++
-B/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/./prev-gcc/
-B/usr/local/x86_64-portbld-freebsd16.0/bin/ -nostdinc++
-B/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-B/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/libsupc++/.libs
 -isystem
/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include/x86_64-portbld-freebsd16.0
 -isystem
/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/include
 -isystem
/wrkdirs/share/dim/ports/lang/gcc16-devel/work/gcc-16-20251130/libstdc++-v3/libsupc++
-L/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/src/.libs
-L/wrkdirs/share/dim/ports/lang/gcc16-devel/work/.build/prev-x86_64-portbld-freebsd16.0/libstdc++-v3/libsupc++/.libs
-E'
 CXXDEPMODE='depmode=gcc3'
-CXXFLAGS='-g -O2 -fchecking=1'
+CXXFLAGS=''
 CXX_FOR_BUILD='$(CXX)'
 DATADIRNAME=''
 DEFAULT_INSNEMIT_PARTITIONS='10'
@@ -10064,7 +10064,7 @@ LDEXP_LIB=''
 ISLLIBS=''
 LD='/usr/local/bin/ld'
 L

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-09 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #13 from Sam James  ---
(In reply to Dimitry Andric from comment #12)

Could you show us gcc/config.log before and after?

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-09 Thread dimitry at andric dot com via Gcc-bugs

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

Dimitry Andric  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #12 from Dimitry Andric  ---
Bisecting seems to point at commit
r16-5592-g56889bfec25e467deedb2750bdae7ec456a8f92c ("build: Save/restore
CXXFLAGS for zstd tests") by Rainer Orth.

I don't completely understand the mechanism though, so I hope somebody else has
a good insight. :)

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-09 Thread dimitry at andric dot com via Gcc-bugs

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

--- Comment #11 from Dimitry Andric  ---
After some fiddling, I could reproduce the error in a poudriere "interactive"
jail, i.e. starting "poudriere bulk" with the -I option.

The crashing process is "f951" which seems to be an intermediate build product,
but the backtrace doesn't tell me much, except that a "map" parameter is NULL,
upon which it segfaults:

Starting program: /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/f951
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/generated/_abs_c10.F90
-cpp=generated/_abs_c10.fii -quiet -v -I . -I
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran -I
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../gcc -I
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../gcc/config
-I
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../libquadmath
-I ../.././gcc -I
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../libgcc
-I ../libgcc -I
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../libbacktrace
-I ../libbacktrace -I ../libbacktrace -I . -iprefix
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/../lib/gcc16/gcc/x86_64-portbld-freebsd16.0/16.0.0/
-isystem /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./gcc/include -isystem
/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./gcc/include-fixed -D
HAVE_CONFIG_H -isystem /usr/local/x86_64-portbld-freebsd16.0/include -isystem
/usr/local/x86_64-portbld-freebsd16.0/sys-include -iquote
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/io
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/generated/_abs_c10.F90
-quiet -dumpdir generated/ -dumpbase _abs_c10.F90 -dumpbase-ext .F90
-mtune=generic -march=x86-64 -g -Wall -Werror -version -fchecking=1
-fimplicit-none -fno-repack-arrays -fno-underscoring -fallow-leading-underscore
-fbuilding-libgfortran -fintrinsic-modules-path finclude -o
generated/_abs_c10.s
GNU Fortran (FreeBSD Ports Collection) version 16.0.0 20251130 (experimental)
(x86_64-portbld-freebsd16.0)
compiled by GNU C version 16.0.0 20251130 (experimental), GMP version
6.3.0, MPFR version 4.2.2, MPC version 1.3.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/../lib/gcc16/gcc/x86_64-portbld-freebsd16.0/16.0.0/include"
ignoring nonexistent directory
"/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/../lib/gcc16/gcc/x86_64-portbld-freebsd16.0/16.0.0/include-fixed"
ignoring nonexistent directory
"/wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/../lib/gcc16/gcc/x86_64-portbld-freebsd16.0/16.0.0/../../../../../x86_64-portbld-freebsd16.0/include"
ignoring nonexistent directory
"/usr/local/lib/gcc16/gcc/x86_64-portbld-freebsd16.0/16.0.0/include"
ignoring nonexistent directory
"/usr/local/lib/gcc16/gcc/x86_64-portbld-freebsd16.0/16.0.0/include-fixed"
ignoring nonexistent directory
"/usr/local/lib/../x86_64-portbld-freebsd16.0/include"
ignoring duplicate directory "../libbacktrace"
ignoring duplicate directory "."
ignoring nonexistent directory "/usr/local/x86_64-portbld-freebsd16.0/include"
ignoring nonexistent directory
"/usr/local/x86_64-portbld-freebsd16.0/sys-include"
ignoring nonexistent directory "finclude"
#include "..." search starts here:
#include <...> search starts here:
 .
 /wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran
 /wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../gcc

/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../gcc/config

/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../libquadmath
 ../.././gcc
 /wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../libgcc
 ../libgcc

/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/../libbacktrace
 ../libbacktrace
 /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./gcc/include
 /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/./gcc/include-fixed
 /wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/libgfortran/io
 /usr/local/include
 /usr/include
End of search list.

Program received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
linemap_check_ordinary (map=0x0) at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/../libcpp/include/line-map.h:644
644   linemap_assert (MAP_ORDINARY_P (map));
(gdb) bt
#0  linemap_check_ordinary (map=0x0) at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/../libcpp/include/line-map.h:644
#1  maybe_print_line (src_loc=0) at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/fortran/cpp.cc:843
#2  0x00a50a2a in scan_translation_unit_trad (pfile=) at
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/fortran/cpp.cc:828
#3  gfc_cpp_preprocess (source_file=) at
/wrkdirs

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-09 Thread developer at lorenzosalvadore dot it via Gcc-bugs

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

--- Comment #10 from Lorenzo Salvadore  
---
(In reply to Steve Kargl from comment #9)

> So, technically not a GCC bug?

I still believe that it is a GCC bug, but for now we are able to reproduce it
only within the poudriere environment (poudriere is FreeBSD's official packages
builder; it works by creating a clean FreeBSD container where the software is
compiled and packaged). I will compare my system's environment with poudriere's
environment and see if I can reproduce the segmentation fault directly on the
OS.

I will also attempt to bisect the commit, since we already know the week when
the fault started.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-08 Thread sgk at troutmask dot apl.washington.edu via Gcc-bugs

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

--- Comment #9 from Steve Kargl  ---
On Thu, Jan 08, 2026 at 06:07:59PM +, dimitry at andric dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123366
> 
> --- Comment #8 from Dimitry Andric  ---
> (In reply to Lorenzo Salvadore from comment #7)
> > (In reply to Dimitry Andric from comment #6)
> > > FWIW, I can build the 20251130 snapshot just fine on:
> > > 
> > > FreeBSD 16.0-CURRENT #0 main-n282706-160077a4d751: Wed Dec 24 17:17:52 CET
> > > 2025
> > > 
> > > That is, I applied the following diff to my ports tree:
> > >
> > > and then built the devel/gcc16-devel port.
> > 
> > I have just tested building the port directly as you did and, indeed, the
> > build succeeds for me too. I guess that the bug must be related to something
> > in the poudriere environment then. Are you able to reproduce the bug if you
> > build the port through poudriere?
> 

So, technically not a GCC bug?

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-08 Thread dimitry at andric dot com via Gcc-bugs

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

--- Comment #8 from Dimitry Andric  ---
(In reply to Lorenzo Salvadore from comment #7)
> (In reply to Dimitry Andric from comment #6)
> > FWIW, I can build the 20251130 snapshot just fine on:
> > 
> > FreeBSD 16.0-CURRENT #0 main-n282706-160077a4d751: Wed Dec 24 17:17:52 CET
> > 2025
> > 
> > That is, I applied the following diff to my ports tree:
> >
> > and then built the devel/gcc16-devel port.
> 
> I have just tested building the port directly as you did and, indeed, the
> build succeeds for me too. I guess that the bug must be related to something
> in the poudriere environment then. Are you able to reproduce the bug if you
> build the port through poudriere?

Indeed, under poudriere it segfaults:

: internal compiler error: Segmentation fault
0x290764f internal_error(char const*, ...)
   
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/diagnostic-global-context.cc:787
0x12d728e crash_signal
   
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/toplev.cc:325
0xa4fc56 MAP_ORDINARY_P(line_map const*)
   
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/../libcpp/include/line-map.h:618
0xa4fc56 linemap_check_ordinary(line_map const*)
   
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/../libcpp/include/line-map.h:644
0xa4fc56 maybe_print_line
   
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/fortran/cpp.cc:843
0xa50a29 scan_translation_unit_trad
   
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/fortran/cpp.cc:828
0xa50a29 gfc_cpp_preprocess(char const*)
   
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/fortran/cpp.cc:685
0xb3595b gfc_new_file()
   
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/fortran/scanner.cc:2778
0xb683d2 gfc_init
   
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/fortran/f95-lang.cc:294
0xa23ac2 lang_dependent_init
   
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/toplev.cc:1911
0xa23ac2 do_compile
   
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20251130/gcc/toplev.cc:2209
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

I'll see if I can get poudriere to put a core dump somewhere. Unless you can
see a smoking gun in the stack trace?

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-08 Thread developer at lorenzosalvadore dot it via Gcc-bugs

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

--- Comment #7 from Lorenzo Salvadore  ---
(In reply to Dimitry Andric from comment #6)
> FWIW, I can build the 20251130 snapshot just fine on:
> 
> FreeBSD 16.0-CURRENT #0 main-n282706-160077a4d751: Wed Dec 24 17:17:52 CET
> 2025
> 
> That is, I applied the following diff to my ports tree:
>
> and then built the devel/gcc16-devel port.

I have just tested building the port directly as you did and, indeed, the build
succeeds for me too. I guess that the bug must be related to something in the
poudriere environment then. Are you able to reproduce the bug if you build the
port through poudriere?

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-07 Thread dimitry at andric dot com via Gcc-bugs

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

--- Comment #6 from Dimitry Andric  ---
FWIW, I can build the 20251130 snapshot just fine on:

FreeBSD 16.0-CURRENT #0 main-n282706-160077a4d751: Wed Dec 24 17:17:52 CET 2025

That is, I applied the following diff to my ports tree:

```diff
diff --git a/lang/gcc16-devel/Makefile b/lang/gcc16-devel/Makefile
index 06931dbc3957..b1e147eb8961 100644
--- a/lang/gcc16-devel/Makefile
+++ b/lang/gcc16-devel/Makefile
@@ -1,5 +1,5 @@
 PORTNAME=  gcc
-PORTVERSION=   16.0.0.s20251123
+PORTVERSION=   16.0.0.s20251130
 CATEGORIES=lang
 MASTER_SITES=  GCC/snapshots/${DIST_VERSION}
 PKGNAMESUFFIX= ${SUFFIX}-devel
diff --git a/lang/gcc16-devel/distinfo b/lang/gcc16-devel/distinfo
index 138f6d4c3446..d29aeeb121f6 100644
--- a/lang/gcc16-devel/distinfo
+++ b/lang/gcc16-devel/distinfo
@@ -1,3 +1,3 @@
-TIMESTAMP = 1764142589
-SHA256 (gcc-16-20251123.tar.xz) =
8a05121bb480eedfe39219be2d1ba290a885aecab21975b3d5b467233cab2b0d
-SIZE (gcc-16-20251123.tar.xz) = 97158532
+TIMESTAMP = 1767790650
+SHA256 (gcc-16-20251130.tar.xz) =
ca27fbf77ec1a702a4baab0309a5ab5d1b9a53516e2f90b14de57b31e07c7991
+SIZE (gcc-16-20251130.tar.xz) = 97478692
```

and then built the devel/gcc16-devel port.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-06 Thread kargl at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Steve Kargl  ---
(In reply to Steve Kargl from comment #4)
>
> Of these patches, it seems that patch-libcxxrt may be worth
> investigating.
>

Well, bootstrap is successful with that patch.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-06 Thread kargl at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Steve Kargl  ---
(In reply to Lorenzo Salvadore from comment #3)
> I see the bug in FreeBSD versions 14.3-RELEASE, 15.0-RELEASE and
> 16.0-CURRENT (16.0-CURRENT #2 main-n282366-8291ea8761c2: Sun Dec 14 14:18:53
> CET 2025). I have not tested other versions.
> 
> These are our configure arguments:
> 
> configure --without-isl --enable-multilib
> --with-build-config=bootstrap-debug --disable-nls --disable-libssp
> --enable-gnu-indirect-function --enable-host-shared --enable-plugin
> --libdir=/usr/local/lib/gcc16 --libexecdir=/usr/local/libexec/gcc16
> --program-suffix=16 --with-as=/usr/local/bin/as --with-gmp=/usr/local
> --with-gxx-include-dir=/usr/local/lib/gcc16/include/c++/
> --with-gxx-libcxx-include-dir=/usr/include/c++/v1
> --with-ld=/usr/local/bin/ld --with-pkgversion=FreeBSD Ports Collection
> --with-system-zlib --without-zstd --enable-languages=c,c++,objc,fortran,jit
> --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/share/man
> --infodir=/usr/local/share/info/gcc16 --build=x86_64-portbld-freebsd15.0

I just bootstrapped top-of-tree gcc with the above configure command line
where I needed to remove --build=x86_64-portbld-freebsd15.0 and
--with-pkgversion=FreeBSD Ports Collection.  The initial compiler in the
bootstrap process was FreeBSD's clang system compiler.  I do not see
the failure you are reporting.

However, I then remembered that the FreeBSD port has several patches that
have not been upstreamed.

% ls /usr/ports/lang/gcc16-devel/files
patch-arm-unwind-cxx-support
patch-gcc_Makefile.in
patch-gcc_configure
patch-gcc_jit_Make-lang.in
patch-gcc_jit_jit-recording.cc
patch-gcc_jit_libgccjit.cc
patch-gfortran-libgcc
patch-libcxxrt
patch-libgcc_unwind-dw2-fde-dip.c
patch-libgcc_unwind.inc
patch-libsanitizer_asan_asan__linux.cpp
patch-libsanitizer_asan_asan__thread.cpp
pkg-message.in

Of these patches, it seems that patch-libcxxrt may be worth
investigating.

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-06 Thread developer at lorenzosalvadore dot it via Gcc-bugs

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

--- Comment #3 from Lorenzo Salvadore  ---
I see the bug in FreeBSD versions 14.3-RELEASE, 15.0-RELEASE and 16.0-CURRENT
(16.0-CURRENT #2 main-n282366-8291ea8761c2: Sun Dec 14 14:18:53 CET 2025). I
have not tested other versions.

These are our configure arguments:

configure --without-isl --enable-multilib --with-build-config=bootstrap-debug
--disable-nls --disable-libssp --enable-gnu-indirect-function
--enable-host-shared --enable-plugin --libdir=/usr/local/lib/gcc16
--libexecdir=/usr/local/libexec/gcc16 --program-suffix=16
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc16/include/c++/
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-ld=/usr/local/bin/ld
--with-pkgversion=FreeBSD Ports Collection --with-system-zlib --without-zstd
--enable-languages=c,c++,objc,fortran,jit --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/share/man
--infodir=/usr/local/share/info/gcc16 --build=x86_64-portbld-freebsd15.0

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-04 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |16.0

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-02 Thread kargl at gcc dot gnu.org via Gcc-bugs

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

Steve Kargl  changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from Steve Kargl  ---
(In reply to Lorenzo Salvadore from comment #0)
> We are experiencing segmentation faults in latest GCC 16 snapshots builds
> related to libgfortran. Last working snapshot is 20251123.
> 

I do not see this issue on FreeBSD circa

% FreeBSD hotrats 16.0-CURRENT FreeBSD 16.0-CURRENT #2 \
  main-n281739-396fac022439: Thu Nov  6 10:50:27 PST 2025

Are you using a more up-to-date FreeBSD 16?

Also, note that you will hit PR 123316 if you get 
pass whatever yuo're doing with configure.

I use 

% ../gcc/configure --prefix=$HOME/work/15 \
   --enable-languages=c,c++,fortran,lto \
   --enable-bootstrap --disable-nls --disable-libssp \
   --disable-multilib --without-libintl

to configure gcc

[Bug libfortran/123366] [16 regression] Segmentation fault on FreeBSD when compiling libgfortran/generated

2026-01-02 Thread developer at lorenzosalvadore dot it via Gcc-bugs

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

--- Comment #1 from Lorenzo Salvadore  ---
Created attachment 63198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63198&action=edit
GCC 16 snapshot 20251130 build attempt log

46 matches

Mail list logo