Re: gcc-12.0.0-0.4.fc36 in rawhide

[Benjamin Beasley]

> * Jakub Jelinek:
> 
> 
> I think Kevin has posted a GDB patch for the crash:
> 
>   [PATCH] Fix GDB internal error by using text (instead of data) section 
> offset
>   
> 
> The bug was exposed by the loss of the .data section in libgcc_s,
> presumably caused by the unwinder changes.  The GCC change is fine by
> itself, it's a real GDB bug.
> 
> Thanks,
> Florian

Thanks for the pointer! I did a successful local mock-build of debugbreak with 
the patched RPMs from the scratch build linked in 
https://bugzilla.redhat.com/show_bug.cgi?id=2042664#c4, which confirms I really 
am seeing that particular GDB bug.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Frantisek Zatloukal]

So, going over FTBFS bugs I've seen against bunch of my packages since the
mass rebuild, there is bunch of "undefined reference to
`std::type_info::operator==(std::type_info const&) const'" returned by ld,
affecting only armv7hl arch. The affected packages are: mozjs68, mozjs78,
mozjs91. I've tried to rebuild mozjs91 once again, but it failed the same
way: https://koji.fedoraproject.org/koji/taskinfo?taskID=82187552

Is there any way I can help?

Thanks!

On Wed, Jan 26, 2022 at 1:42 PM Jakub Jelinek  wrote:

> On Wed, Jan 26, 2022 at 01:36:43PM +0100, Jakub Jelinek wrote:
> > On Wed, Jan 26, 2022 at 01:29:37PM +0100, Dan Horák wrote:
> > > > > **Compilation error from a dependency header:**
> > > > >
> > > > > dependency “boost”: “# error "Never use  directly;
> include
> > > > >  instead."”, via
> > > > > boost/multiprecision/cpp_int/intel_intrinsics.hpp
> > > >
> > > > This is weird.
> > > > bmiintrin.h had:
> > > > #ifndef _X86GPRINTRIN_H_INCLUDED
> > > > # error "Never use  directly; include 
> instead."
> > > > #endif
> > > > in both gcc 11 and 12.  In fact, most of the more recent *intrin.h
> headers
> > > > want users to only use one of x86intrin.h, x86gprintrin.h or maybe
> > > > immintrin.h.
> > >
> > > this is being discussed in
> > > https://github.com/boostorg/multiprecision/issues/419
> >
> > Ah, ppc*, that indeed looks like a gcc bug.
>
> https://gcc.gnu.org/PR104239
>
> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

[Remi Collet]

Tracked as https://bugzilla.redhat.com/show_bug.cgi?id=2048565
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

[Dan Horák]

On Mon, 31 Jan 2022 14:53:08 +0100
Remi Collet  wrote:

> Hi,
> 
> Le 19/01/2022 à 11:53, Jakub Jelinek a écrit :
> > That error means that there is difference in the target attribute or 
> > #pragma
> > GCC target between the caller of the always_inline function and the
> > always_inline function which prevents the inlining (and always_inline
> > requires to be inlined).
> > I'd need preprocessed source + gcc command line to say more.
> 
> Command is
> 
> $ gcc -IZend/ -I/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/ 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/include 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/main 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/ext/date/lib 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/ext/date/lib 
> -I/usr/include/libxml2 -I/usr/include/enchant-2 -I/usr/include/glib-2.0 
> -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 
> -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/harfbuzz 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/ext/mbstring/libmbfl 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/ext/mbstring/libmbfl 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/ext/mbstring/libmbfl/mbfl 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/ext/mbstring/libmbfl/mbfl 
> -I/usr/include/pspell -I/usr/include/editline 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/TSRM 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/Zend 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/main 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/Zend 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/TSRM 
> -I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/ -fno-common 
> -Wstrict-prototypes -Wformat-truncation -Wlogical-op -Wduplicated-cond 
> -Wno-clobbered -Wall -Wextra -Wno-strict-aliasing -Wno-unused-parameter 
> -Wno-sign-compare -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall 
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 
> -m64 -march=zEC12 -mtune=z13 -fasynchronous-unwind-tables 
> -fstack-clash-protection -fno-strict-aliasing -Wno-pointer-sign 
> -fvisibility=hidden -Wimplicit-fallthrough=1 -DZEND_SIGNALS 
> -DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 -c 
> /home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_execute.c -MMD -MF 
> Zend/zend_execute.dep -MT Zend/zend_execute.lo -fPIC -DPIC -o 
> Zend/.libs/zend_execute.o
> In file included from /home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend.h:36,
> from /home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_execute.c:26:
> /home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_variables.h: In function 
> ‘ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER’:
> /home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: 
> inlining failed in call to ‘always_inline’ ‘zval_ptr_dtor_nogc’: target 
> specific option mismatch
> 32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr)
> | ^~
> In file included from 
> /home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_execute.c:5071:
> /home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: 
> called from here
> 8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var));
> | ^~~
> 
> preprocessed sources:
> 
> https://server.famillecollet.com/nextcloud/s/6txXHtdnGYfnC37/download?path=%2F=pre.txt.bz2

the error message is the same as in
https://bugzilla.redhat.com/show_bug.cgi?id=1996330


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

[Remi Collet]

Hi,

Le 19/01/2022 à 11:53, Jakub Jelinek a écrit :
That error means that there is difference in the target attribute or 
#pragma

GCC target between the caller of the always_inline function and the
always_inline function which prevents the inlining (and always_inline
requires to be inlined).
I'd need preprocessed source + gcc command line to say more.


Command is

$ gcc -IZend/ -I/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/ 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/include 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/main 
-I/home/remi/rpmbuild/BUILD/php-8.1.2 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/ext/date/lib 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/ext/date/lib 
-I/usr/include/libxml2 -I/usr/include/enchant-2 -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 
-I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/harfbuzz 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/ext/mbstring/libmbfl 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/ext/mbstring/libmbfl 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/ext/mbstring/libmbfl/mbfl 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/ext/mbstring/libmbfl/mbfl 
-I/usr/include/pspell -I/usr/include/editline 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/TSRM 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/Zend 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/main 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/Zend 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/TSRM 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/ -fno-common 
-Wstrict-prototypes -Wformat-truncation -Wlogical-op -Wduplicated-cond 
-Wno-clobbered -Wall -Wextra -Wno-strict-aliasing -Wno-unused-parameter 
-Wno-sign-compare -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 
-m64 -march=zEC12 -mtune=z13 -fasynchronous-unwind-tables 
-fstack-clash-protection -fno-strict-aliasing -Wno-pointer-sign 
-fvisibility=hidden -Wimplicit-fallthrough=1 -DZEND_SIGNALS 
-DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 -c 
/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_execute.c -MMD -MF 
Zend/zend_execute.dep -MT Zend/zend_execute.lo -fPIC -DPIC -o 
Zend/.libs/zend_execute.o

In file included from /home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend.h:36,
from /home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_execute.c:26:
/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_variables.h: In function 
‘ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER’:
/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: 
inlining failed in call to ‘always_inline’ ‘zval_ptr_dtor_nogc’: target 
specific option mismatch

32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr)
| ^~
In file included from 
/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_execute.c:5071:
/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: 
called from here

8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var));
| ^~~

preprocessed sources:

https://server.famillecollet.com/nextcloud/s/6txXHtdnGYfnC37/download?path=%2F=pre.txt.bz2



Any help welcome, as I really don't see what is wrong there

Remi





Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Florian Weimer]

* Jakub Jelinek:

>> debugbreak: %check uses gdb, which now crashes (“(core dumped) gdb -q -x
>> "${exe}-rpm-test.gdb" --batch < /dev/null”) on ppc64le/x86_64, but not on
>> aarch64
>
> If gdb crashes, it would be nice if somebody from the gdb team had a look,
> of course it can be a gcc bug too.

I think Kevin has posted a GDB patch for the crash:

  [PATCH] Fix GDB internal error by using text (instead of data) section offset
  

The bug was exposed by the loss of the .data section in libgcc_s,
presumably caused by the unwinder changes.  The GCC change is fine by
itself, it's a real GDB bug.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Wed, Jan 26, 2022 at 01:36:43PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 26, 2022 at 01:29:37PM +0100, Dan Horák wrote:
> > > > **Compilation error from a dependency header:**
> > > > 
> > > > dependency “boost”: “# error "Never use  directly; include
> > > >  instead."”, via
> > > > boost/multiprecision/cpp_int/intel_intrinsics.hpp  
> > > 
> > > This is weird.
> > > bmiintrin.h had:
> > > #ifndef _X86GPRINTRIN_H_INCLUDED
> > > # error "Never use  directly; include  
> > > instead."
> > > #endif
> > > in both gcc 11 and 12.  In fact, most of the more recent *intrin.h headers
> > > want users to only use one of x86intrin.h, x86gprintrin.h or maybe
> > > immintrin.h.
> > 
> > this is being discussed in
> > https://github.com/boostorg/multiprecision/issues/419
> 
> Ah, ppc*, that indeed looks like a gcc bug.

https://gcc.gnu.org/PR104239

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Wed, Jan 26, 2022 at 01:29:37PM +0100, Dan Horák wrote:
> > > **Compilation error from a dependency header:**
> > > 
> > > dependency “boost”: “# error "Never use  directly; include
> > >  instead."”, via
> > > boost/multiprecision/cpp_int/intel_intrinsics.hpp  
> > 
> > This is weird.
> > bmiintrin.h had:
> > #ifndef _X86GPRINTRIN_H_INCLUDED
> > # error "Never use  directly; include  
> > instead."
> > #endif
> > in both gcc 11 and 12.  In fact, most of the more recent *intrin.h headers
> > want users to only use one of x86intrin.h, x86gprintrin.h or maybe
> > immintrin.h.
> 
> this is being discussed in
> https://github.com/boostorg/multiprecision/issues/419

Ah, ppc*, that indeed looks like a gcc bug.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Dan Horák]

> > **Compilation error from a dependency header:**
> > 
> > dependency “boost”: “# error "Never use  directly; include
> >  instead."”, via
> > boost/multiprecision/cpp_int/intel_intrinsics.hpp  
> 
> This is weird.
> bmiintrin.h had:
> #ifndef _X86GPRINTRIN_H_INCLUDED
> # error "Never use  directly; include  instead."
> #endif
> in both gcc 11 and 12.  In fact, most of the more recent *intrin.h headers
> want users to only use one of x86intrin.h, x86gprintrin.h or maybe
> immintrin.h.

this is being discussed in
https://github.com/boostorg/multiprecision/issues/419


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Mon, Jan 17, 2022 at 09:00:13AM -0500, Ben Beasley wrote:
> **Internal compiler or debugger error:**
> 
> abseil-cpp: “internal compiler error: tree code 'template_type_parm' is not
> supported in LTO streams”

Dunno, would need to reproduce.

> debugbreak: %check uses gdb, which now crashes (“(core dumped) gdb -q -x
> "${exe}-rpm-test.gdb" --batch < /dev/null”) on ppc64le/x86_64, but not on
> aarch64

If gdb crashes, it would be nice if somebody from the gdb team had a look,
of course it can be a gcc bug too.

> **Compilation error from a dependency header:**
> 
> dependency “boost”: “# error "Never use  directly; include
>  instead."”, via
> boost/multiprecision/cpp_int/intel_intrinsics.hpp

This is weird.
bmiintrin.h had:
#ifndef _X86GPRINTRIN_H_INCLUDED
# error "Never use  directly; include  instead."
#endif
in both gcc 11 and 12.  In fact, most of the more recent *intrin.h headers
want users to only use one of x86intrin.h, x86gprintrin.h or maybe
immintrin.h.

>     octave-iso2mesh
> 
> dependency “boost”: “error: use of deleted function
> 'std::__cxx11::basic_string<_CharT, _Traits,
> _Alloc>::basic_string(std::nullptr_t)” via
> boost/graph/bellman_ford_shortest_paths.hpp

the basic_string(std::nullptr_t) = deleted; is now at least in
gcc-12.0.1-0.3.fc36 that is almost finished building for C++23 and up only,
so for the time being it will work again.  But if it is really
std::string s = nullptr;
or so, then it would be a good to fix it in the package, it is still
undefined.
> 
>     python-graph-tool
> 
> dependency “json”: https://github.com/nlohmann/json/issues/3138

This will be fixed with the above mentioned change.

>     giada
> 
> dependency “opencv”: “invalid parameter combination for AltiVec intrinsic
> '__builtin_vec_sldw'” on ppc64le, in opencv4/opencv2/core/vsx_utils.hpp

vec_sldw with vector float is now supported in gcc-12.0.1-0.3.fc36.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Adam Williamson]

On Tue, 2022-01-25 at 08:50 -0600, Michael Catanzaro wrote:
> On Mon, Jan 24 2022 at 03:19:00 PM -0800, Adam Williamson 
>  wrote:
> > I do hope this can be cleaned up soon. Dropping arches from packages 
> > is
> > a very big hammer and should be wielded extremely sparingly. Unless
> > ceph was unusable without a rebuild on the other arches, it would've
> > been better to wait until this issue was resolved before rebuilding
> > ceph.
> 
> Hi, until the toolchain is fixed, the only options are ExcludeArch: 
> ppc64le or just stop doing work in rawhide. I decided to leave 
> rawhide's WebKitGTK vulnerable to the worst security issue we've seen 
> in years [1] rather than exclude ppc64le, because removing WebKitGTK it 
> would take out the entire desktop on ppc64le, and I trust our GCC 
> maintainers are working to fix ppc64le expeditiously, but I totally 
> understand other maintainers aren't so willing to wait. It will be easy 
> to reenable ceph for ppc64le once GCC is working again.

Well, the consequence of making that choice in this case was to prevent
*other people* from doing work in Rawhide (unless they also disable
ppc64le, which I don't want to do since we do actually *use* os-
autoinst on ppc64le), so it doesn't seem like a straightforward one :D
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Michael Catanzaro]

On Mon, Jan 24 2022 at 03:19:00 PM -0800, Adam Williamson 
 wrote:
I do hope this can be cleaned up soon. Dropping arches from packages 
is

a very big hammer and should be wielded extremely sparingly. Unless
ceph was unusable without a rebuild on the other arches, it would've
been better to wait until this issue was resolved before rebuilding
ceph.


Hi, until the toolchain is fixed, the only options are ExcludeArch: 
ppc64le or just stop doing work in rawhide. I decided to leave 
rawhide's WebKitGTK vulnerable to the worst security issue we've seen 
in years [1] rather than exclude ppc64le, because removing WebKitGTK it 
would take out the entire desktop on ppc64le, and I trust our GCC 
maintainers are working to fix ppc64le expeditiously, but I totally 
understand other maintainers aren't so willing to wait. It will be easy 
to reenable ceph for ppc64le once GCC is working again.


Michael

[1] https://safarileaks.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Adam Williamson]

On Mon, 2022-01-24 at 07:15 -0500, Kaleb Keithley wrote:
> On Sat, Jan 22, 2022 at 2:28 PM Kaleb Keithley  wrote:
> 
> > 
> > > The long double change is an ABI change, so this is kind of expected.
> > > Mass rebuild unfortunately doesn't go according to the dependency graph
> > > (and
> > > unfortunately it isn't a tree, there are cycles).
> > > 
> > 
> > Indeed. fmt has not been rebuilt, or more accurately, it failed in the
> > mass rebuild. Specifically the ppc64le build failed.  see
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199
> > 
> 
> I may have missed the email about this. (Sorry if I have.)
> 
> Is there an action on someone's part to fix the assembler, or fix the
> assembly that gcc-12 is emitting on ppc64le that the assembler is puking on?

So, it seems you rebuilt ceph with ppc64le disabled because of this?

That now means there are no ceph packages for ppc64le in Rawhide, which
means that anything that depends on them - which includes qemu - cannot
be installed, and nothing that hits that dep chain can be built.

I just ran into this trying to rebuild os-autoinst, which buildrequires
qemu. :(

I do hope this can be cleaned up soon. Dropping arches from packages is
a very big hammer and should be wielded extremely sparingly. Unless
ceph was unusable without a rebuild on the other arches, it would've
been better to wait until this issue was resolved before rebuilding
ceph.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Mon, Jan 24, 2022 at 07:15:19AM -0500, Kaleb Keithley wrote:
> On Sat, Jan 22, 2022 at 2:28 PM Kaleb Keithley  wrote:
> 
> >
> >> The long double change is an ABI change, so this is kind of expected.
> >> Mass rebuild unfortunately doesn't go according to the dependency graph
> >> (and
> >> unfortunately it isn't a tree, there are cycles).
> >>
> >
> > Indeed. fmt has not been rebuilt, or more accurately, it failed in the
> > mass rebuild. Specifically the ppc64le build failed.  see
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199
> >
> 
> I may have missed the email about this. (Sorry if I have.)
> 
> Is there an action on someone's part to fix the assembler, or fix the
> assembly that gcc-12 is emitting on ppc64le that the assembler is puking on?

It is https://gcc.gnu.org/PR104172 , I have done my part there, but I'm not
PowerPC backend maintainer, so the decision what to do isn't mine.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Tom Hughes via devel]

On 24/01/2022 12:15, Kaleb Keithley wrote:



On Sat, Jan 22, 2022 at 2:28 PM Kaleb Keithley > wrote:



The long double change is an ABI change, so this is kind of
expected.
Mass rebuild unfortunately doesn't go according to the
dependency graph (and
unfortunately it isn't a tree, there are cycles).


Indeed. fmt has not been rebuilt, or more accurately, it failed in
the mass rebuild. Specifically the ppc64le build failed.  see
https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199



I may have missed the email about this. (Sorry if I have.)

Is there an action on someone's part to fix the assembler, or fix the 
assembly that gcc-12 is emitting on ppc64le that the assembler is puking on?


Yes as Jakub said yesterday morning that is https://gcc.gnu.org/PR104172 
and he's waiting for a decision from the powerpc backend maintainers on

the best fix.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Kaleb Keithley]

On Sat, Jan 22, 2022 at 2:28 PM Kaleb Keithley  wrote:

>
>> The long double change is an ABI change, so this is kind of expected.
>> Mass rebuild unfortunately doesn't go according to the dependency graph
>> (and
>> unfortunately it isn't a tree, there are cycles).
>>
>
> Indeed. fmt has not been rebuilt, or more accurately, it failed in the
> mass rebuild. Specifically the ppc64le build failed.  see
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199
>

I may have missed the email about this. (Sorry if I have.)

Is there an action on someone's part to fix the assembler, or fix the
assembly that gcc-12 is emitting on ppc64le that the assembler is puking on?

Thanks,

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

about abidiff Re: gcc-12.0.0-0.4.fc36 in rawhide

[Sérgio Basto]

On Sun, 2022-01-23 at 10:56 +0100, Vitaly Zaitsev via devel wrote:
> On 22/01/2022 17:22, Jakub Jelinek wrote:
> > The long double change is an ABI change, so this is kind of expected.
> 
> abidiff automatic test found no ABI changes between 8.0 and 8.1.

Since early 2021 at least
https://sourceware.org/bugzilla/show_bug.cgi?id=27275 I notice
fedabipkgdiff doesn't produce any results . 

But by reactions of the developers seems that all was working without
problems, yesterday finally found the problem
https://bugzilla.redhat.com/show_bug.cgi?id=1811602#c3

also wiki page is outdate ... 
https://fedoraproject.org/wiki/How_to_check_for_ABI_changes_with_abipkgdiff#Comparing_RPMs


Best regards, 
> -- 
> Sincerely,
>    Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Kaleb Keithley]

On Sun, Jan 23, 2022 at 4:58 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 22/01/2022 17:22, Jakub Jelinek wrote:
> > The long double change is an ABI change, so this is kind of expected.
>
> abidiff automatic test found no ABI changes between 8.0 and 8.1.


 I think you might be missing the point.

The long double format changed (on ppc64le only?) between gcc-11 and gcc-12.

Compiling something that uses fmt (e.g. ceph) with gcc-12 now produces
references (calls) to:
  int fmt::v8::detail::format_float<__ieee128>(__ieee128, int,
fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)
and
  int fmt::v8::detail::snprintf_float<__ieee128>(__ieee128, int,
fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)

Those functions are not in the libfmt.so that was last successfully built
with gcc-11.

That's because when fmt was compiled with gcc-11, the symbols were:
  int fmt::v8::detail::format_float<__float128>(__float128, int,
fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)
and
  int fmt::v8::detail::snprintf_float<__float128>(__float128, int,
fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)

That is an ABI change, no matter what abidiff might be telling you. (It's a
change we knew was coming though.)

And going forward, anything (e.g. ceph) compiled with gcc-11 is not going
to work with fmt and libfmt.so compiled with gcc-12 because of the ABI
change.

If you already understood all this then I apologize for telling you
something you already know. ;-)

Regards

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Fabio Valentini]

On Mon, Jan 24, 2022 at 12:01 PM Jakub Jelinek  wrote:
>
> On Mon, Jan 24, 2022 at 11:55:39AM +0100, Fabio Valentini wrote:
> > Have the command line arguments that are accepted by gcc?
> >
> > The test suite of the "cc" crate (used for compiling and linking to C
> > code within Rust projects) started failing with GCC 12 with this
> > error:
> >
> > gcc: error: unrecognized command-line option '-arbitrary'
>
> That was never a gcc command line option.

Ok, thanks for confirming ...

Upon further investigation, it looks like something very weird is
going on instead, because other tests that really *should* be working
(or at least, definitely passed until a few days ago) started breaking
in hilarious ways.
So I think the new problems might actually be caused by some broken
interaction between gcc 12, the new change to set CFLAGS / CXXFLAGS by
default, and the way the cc test suite works, and other recent
redhat-rpm-config changes. But I have no idea how this is so broken
all of a sudden.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Mon, Jan 24, 2022 at 11:55:39AM +0100, Fabio Valentini wrote:
> Have the command line arguments that are accepted by gcc?
> 
> The test suite of the "cc" crate (used for compiling and linking to C
> code within Rust projects) started failing with GCC 12 with this
> error:
> 
> gcc: error: unrecognized command-line option '-arbitrary'

That was never a gcc command line option.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Fabio Valentini]

On Fri, Jan 14, 2022 at 3:32 PM Jakub Jelinek  wrote:
>
> Hi!
>
> gcc 12 snapshot has landed as the system compiler into rawhide today.
> GCC 12 is going to enter its stage4 development phase (only regression
> and documentation bugfixes allowed) on Monday 17th, so there should be
> just those bugfixes and not new features etc. anymore.
> https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> most important is probably that vectorization is enabled at -O2 now
> which is the option with most of the distribution is built with.
>
> https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> some cases where people need to adjust their code.  Other things
> include the usual C++ header changes, where previously some standard
> header included some other header as an implementation detail but it doesn't
> any longer and so code that relied on such indirect include that isn't
> required by the standard needs to include the header that provides whatever
> it relies on.  Or e.g. packages using -Werror where new warnings are
> reported with the newer compiler and -Werror results in build failures.
>
> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.
>
> Another important thing I wanted to say is that we'd like to switch
> ppc64le from the numerically problematic IBM extended long double to
> IEEE 754 quad long double.  This is an ABI change.  Some libraries
> are already built so that they support both ABIs at the same time,
> including glibc, libstdc++, libgcc, libgfortran etc.
> For other libraries and binaries, the compiler, assembler and linker
> will notice if they use long double and flag them as using either
> IBM or IEEE long double and linker (or I think dynamic linker too)
> might complain when things are mixed.
> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> but the glibc/gcc libraries are built compatibly with both.
> We'd like to configure gcc shortly before the mass rebuild with
> --with-long-double-format=ieee so that it will default to
> -mabi=ieeelongdouble, probably on a side-tag build first, and it
> will be highly desirable to rebuild at least some of the most commonly
> used library packages in the order of dependencies there, otherwise
> I'd be afraid the mass rebuild could fail for way too many packages
> (as the mass rebuild doesn't do dependency order rebuilds but just
> goes through packages alphabetically or so).
> Any suggestions on which packages have commonly used library packages
> that use long double?
> readelf -A on libraries on ppc64le prints either nothing (either
> the library is thought not to use long double or supports both ABIs
> transparently or hasn't been rebuilt for some years), or
> Attribute Section: gnu
> File Attributes
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> for libraries (or binaries or object files) that use IBM long double
> only or
> Attribute Section: gnu
> File Attributes
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
> for IEEE long doubles.
> So I think we want to rebuild on a side-tag packages that
> provide shared libraries used by hundreds of other packages that
> are
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> right now.

Hi!

Have the command line arguments that are accepted by gcc?

The test suite of the "cc" crate (used for compiling and linking to C
code within Rust projects) started failing with GCC 12 with this
error:

gcc: error: unrecognized command-line option '-arbitrary'

I looked that the docs for gcc 12 (gcc-12/porting_to.html and
gcc-12/changes.html) but neither mention any change in accepted
command line arguments.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jan 23, 2022 at 10:54:49AM +0100, Vitaly Zaitsev via devel wrote:
> On 22/01/2022 15:56, Kaleb Keithley wrote:
> >Which I presume is related to the failed rebuild of fmt[2] with gcc-12 and
> >thus I'm still getting a version of fmt compiled with gcc-11.
> 
> Fmt build failed on ppc64le due to another GCC 12 regression:
> 
> FAILED: libfmt.so.8.1.1
> : && /usr/bin/g++ -fPIC -O2 -flto=auto -ffat-lto-objects -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mcpu=power8
> -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -O2 -g
> -DNDEBUG  -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1
> -Wl,-dT,/builddir/build/BUILD/.package_note-fmt-8.1.1-2.fc36.ppc64le.ld
> -shared -Wl,-soname,libfmt.so.8 -o libfmt.so.8.1.1
> CMakeFiles/fmt.dir/src/format.cc.o CMakeFiles/fmt.dir/src/os.cc.o
> -Wl,--as-needed && :
> {standard input}: Assembler messages:
> {standard input}:31583: Error: junk at end of line, first unrecognized
> character is `('
> {standard input}:31584: Error: expected comma after "operator"
> {standard input}:32352: Error: junk at end of line, first unrecognized
> character is `('
> {standard input}:32353: Error: expected comma after "operator"
> make: *** [/tmp/ccKWFwzK.mk:2: /tmp/ccqbVJLh.ltrans0.ltrans.o] Error 1
> lto-wrapper: fatal error: make returned 2 exit status
> compilation terminated.
> /usr/bin/ld: error: lto-wrapper failed
> collect2: error: ld returned 1 exit status

This looks similar to an issue I saw with dolfin, also only on ppc64le [1].
Disabling lto "solved" the issue.

Zbyszek

[1] https://kojipkgs.fedoraproject.org//work/tasks/2369/81482369/build.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Sun, Jan 23, 2022 at 11:39:58AM +0100, Vitaly Zaitsev via devel wrote:
> On 14/01/2022 15:31, Jakub Jelinek wrote:
> > gcc 12 snapshot has landed as the system compiler into rawhide today.
> 
> Another ICE on ppc64le with all packages contains catch2 library.
> Task: https://koji.fedoraproject.org/koji/taskinfo?taskID=81641415

IMHO no need to report further and further instances of the same
https://gcc.gnu.org/PR104172 bug (i.e. bugs where only ppc64le fails with
either internal compiler errors or assembler errors about weirdo
identifiers), I need to wait for a decision from powerpc backend maintainers,
then fix one way or another, if all goes well start fixed builds Monday
evening, + ~ 24 hours for build and then it can be tagged into rawhide
if all goes well.  AFAIK packages that failed mass rebuild are usually
attempted to be rebuilt once again before FTBS bugs are filed.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Tom Hughes via devel]

On 23/01/2022 10:39, Vitaly Zaitsev via devel wrote:

On 14/01/2022 15:31, Jakub Jelinek wrote:

gcc 12 snapshot has landed as the system compiler into rawhide today.


Another ICE on ppc64le with all packages contains catch2 library.
Task: https://koji.fedoraproject.org/koji/taskinfo?taskID=81641415


I've got https://bugzilla.redhat.com/show_bug.cgi?id=2043040 open
for that - possibly the same as 2043517.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Vitaly Zaitsev via devel]

On 14/01/2022 15:31, Jakub Jelinek wrote:

gcc 12 snapshot has landed as the system compiler into rawhide today.


Another ICE on ppc64le with all packages contains catch2 library.
Task: https://koji.fedoraproject.org/koji/taskinfo?taskID=81641415

Log:

FAILED: test/CMakeFiles/semver-cpp17.t.dir/test.cpp.o
/usr/bin/g++  -I/builddir/build/BUILD/semver-0.3.0/test/3rdparty/Catch2 
-I/builddir/build/BUILD/semver-0.3.0/include -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 
-m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables 
-fstack-clash-protection -DNDEBUG -Wall -Wextra -pedantic-errors -Werror 
-std=c++17 -MD -MT test/CMakeFiles/semver-cpp17.t.dir/test.cpp.o -MF 
test/CMakeFiles/semver-cpp17.t.dir/test.cpp.o.d -o 
test/CMakeFiles/semver-cpp17.t.dir/test.cpp.o -c 
/builddir/build/BUILD/semver-0.3.0/test/test.cpp
*** WARNING *** there are active plugins, do not report this as a bug 
unless you can reproduce it without enabling any plugins.

Event| Plugins
PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
PLUGIN_START_UNIT| annobin: Generate global annotations
PLUGIN_ALL_PASSES_START  | annobin: Generate per-function 
annotations
PLUGIN_ALL_PASSES_END| annobin: Register per-function end 
symbols

during RTL pass: final
In file included from /builddir/build/BUILD/semver-0.3.0/test/test.cpp:24:
/builddir/build/BUILD/semver-0.3.0/test/3rdparty/Catch2/catch.hpp: In 
member function 'Catch::LazyExpression::LazyExpression(bool)':
/builddir/build/BUILD/semver-0.3.0/test/3rdparty/Catch2/catch.hpp:8185:5: internal 
compiler error: Segmentation fault

 8185 | LazyExpression::LazyExpression( bool isNegated )
  | ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
[6/8] /usr/bin/g++ 
-I/builddir/build/BUILD/semver-0.3.0/test/3rdparty/Catch2 
-I/builddir/build/BUILD/semver-0.3.0/include -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 
-m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables 
-fstack-clash-protection -DNDEBUG -Wall -Wextra -pedantic-errors -Werror 
-std=c++20 -MD -MT test/CMakeFiles/semver-cpp20.t.dir/test.cpp.o -MF 
test/CMakeFiles/semver-cpp20.t.dir/test.cpp.o.d -o 
test/CMakeFiles/semver-cpp20.t.dir/test.cpp.o -c 
/builddir/build/BUILD/semver-0.3.0/test/test.cpp

FAILED: test/CMakeFiles/semver-cpp20.t.dir/test.cpp.o
/usr/bin/g++  -I/builddir/build/BUILD/semver-0.3.0/test/3rdparty/Catch2 
-I/builddir/build/BUILD/semver-0.3.0/include -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 
-m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables 
-fstack-clash-protection -DNDEBUG -Wall -Wextra -pedantic-errors -Werror 
-std=c++20 -MD -MT test/CMakeFiles/semver-cpp20.t.dir/test.cpp.o -MF 
test/CMakeFiles/semver-cpp20.t.dir/test.cpp.o.d -o 
test/CMakeFiles/semver-cpp20.t.dir/test.cpp.o -c 
/builddir/build/BUILD/semver-0.3.0/test/test.cpp
*** WARNING *** there are active plugins, do not report this as a bug 
unless you can reproduce it without enabling any plugins.

Event| Plugins
PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
PLUGIN_START_UNIT| annobin: Generate global annotations
PLUGIN_ALL_PASSES_START  | annobin: Generate per-function 
annotations
PLUGIN_ALL_PASSES_END| annobin: Register per-function end 
symbols

during RTL pass: final
In file included from /builddir/build/BUILD/semver-0.3.0/test/test.cpp:24:
/builddir/build/BUILD/semver-0.3.0/test/3rdparty/Catch2/catch.hpp: In 
member function 'Catch::LazyExpression::LazyExpression(bool)':
/builddir/build/BUILD/semver-0.3.0/test/3rdparty/Catch2/catch.hpp:8185:5: internal 
compiler error: Segmentation fault

 8185 | LazyExpression::LazyExpression( bool isNegated )
  | ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
ninja: build stopped: subcommand failed.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Dan Horák]

On Sun, 23 Jan 2022 10:56:32 +0100
Vitaly Zaitsev via devel  wrote:

> On 22/01/2022 17:22, Jakub Jelinek wrote:
> > The long double change is an ABI change, so this is kind of expected.
> 
> abidiff automatic test found no ABI changes between 8.0 and 8.1.

it's an internal implementation change of the "long double" type, from
C/C++ point of view it's always the same "long double" type

https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Vitaly Zaitsev via devel]

On 22/01/2022 17:22, Jakub Jelinek wrote:

The long double change is an ABI change, so this is kind of expected.


abidiff automatic test found no ABI changes between 8.0 and 8.1.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Vitaly Zaitsev via devel]

On 22/01/2022 15:56, Kaleb Keithley wrote:
Which I presume is related to the failed rebuild of fmt[2] with gcc-12 
and thus I'm still getting a version of fmt compiled with gcc-11.


Fmt build failed on ppc64le due to another GCC 12 regression:

FAILED: libfmt.so.8.1.1
: && /usr/bin/g++ -fPIC -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mcpu=power8 
-mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -O2 
-g -DNDEBUG  -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 
-Wl,-dT,/builddir/build/BUILD/.package_note-fmt-8.1.1-2.fc36.ppc64le.ld 
-shared -Wl,-soname,libfmt.so.8 -o libfmt.so.8.1.1 
CMakeFiles/fmt.dir/src/format.cc.o CMakeFiles/fmt.dir/src/os.cc.o 
-Wl,--as-needed && :

{standard input}: Assembler messages:
{standard input}:31583: Error: junk at end of line, first unrecognized 
character is `('

{standard input}:31584: Error: expected comma after "operator"
{standard input}:32352: Error: junk at end of line, first unrecognized 
character is `('

{standard input}:32353: Error: expected comma after "operator"
make: *** [/tmp/ccKWFwzK.mk:2: /tmp/ccqbVJLh.ltrans0.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Kaleb Keithley]

On Sat, Jan 22, 2022 at 11:22 AM Jakub Jelinek  wrote:

> On Sat, Jan 22, 2022 at 09:56:24AM -0500, Kaleb Keithley wrote:
> > I know you want FTBFS bugs now for gcc-12 issues, but let me run this by
> > you first and I will open a BZ if necessary.
> >
> > For ceph I've hacked up a fix for all the other gcc-12isms in ceph and
> now
> > it fails to build on ppc64le[1] with
> > ...
> >
> > /usr/bin/ld:
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/lib/libceph-common.so.2:
> > undefined reference to `int
> > fmt::v8::detail::format_float<__ieee128>(__ieee128, int,
> > fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)'
> > /usr/bin/ld:
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/lib/libceph-common.so.2:
> > undefined reference to `int
> > fmt::v8::detail::snprintf_float<__ieee128>(__ieee128, int,
> > fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)'
> > collect2: error: ld returned 1 exit status
>
> That looks like libceph-common.so.2 being linked against a library that
> has long double in its public ABI and has not been rebuilt.
> Once the dependence is rebuilt, packages depending on it need to be
> rebuilt.
>
> The long double change is an ABI change, so this is kind of expected.
> Mass rebuild unfortunately doesn't go according to the dependency graph
> (and
> unfortunately it isn't a tree, there are cycles).
>

Indeed. fmt has not been rebuilt, or more accurately, it failed in the mass
rebuild. Specifically the ppc64le build failed.  see
https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Sat, Jan 22, 2022 at 09:56:24AM -0500, Kaleb Keithley wrote:
> I know you want FTBFS bugs now for gcc-12 issues, but let me run this by
> you first and I will open a BZ if necessary.
> 
> For ceph I've hacked up a fix for all the other gcc-12isms in ceph and now
> it fails to build on ppc64le[1] with
> ...
> 
> /usr/bin/ld: 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/lib/libceph-common.so.2:
> undefined reference to `int
> fmt::v8::detail::format_float<__ieee128>(__ieee128, int,
> fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)'
> /usr/bin/ld: 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/lib/libceph-common.so.2:
> undefined reference to `int
> fmt::v8::detail::snprintf_float<__ieee128>(__ieee128, int,
> fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)'
> collect2: error: ld returned 1 exit status

That looks like libceph-common.so.2 being linked against a library that
has long double in its public ABI and has not been rebuilt.
Once the dependence is rebuilt, packages depending on it need to be rebuilt.

The long double change is an ABI change, so this is kind of expected.
Mass rebuild unfortunately doesn't go according to the dependency graph (and
unfortunately it isn't a tree, there are cycles).

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Kaleb Keithley]

I know you want FTBFS bugs now for gcc-12 issues, but let me run this by
you first and I will open a BZ if necessary.

For ceph I've hacked up a fix for all the other gcc-12isms in ceph and now
it fails to build on ppc64le[1] with
...

/usr/bin/ld: 
/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/lib/libceph-common.so.2:
undefined reference to `int
fmt::v8::detail::format_float<__ieee128>(__ieee128, int,
fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)'
/usr/bin/ld: 
/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/lib/libceph-common.so.2:
undefined reference to `int
fmt::v8::detail::snprintf_float<__ieee128>(__ieee128, int,
fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)'
collect2: error: ld returned 1 exit status

...

Which I presume is related to the failed rebuild of fmt[2] with gcc-12 and
thus I'm still getting a version of fmt compiled with gcc-11.

For which I propose to exclude ppc64le until such time as the fmt build
gets fixed, when I will reënable it.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=81628812
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199




On Fri, Jan 14, 2022 at 9:33 AM Jakub Jelinek  wrote:

> Hi!
>
> gcc 12 snapshot has landed as the system compiler into rawhide today.
> GCC 12 is going to enter its stage4 development phase (only regression
> and documentation bugfixes allowed) on Monday 17th, so there should be
> just those bugfixes and not new features etc. anymore.
> https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> most important is probably that vectorization is enabled at -O2 now
> which is the option with most of the distribution is built with.
>
> https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> some cases where people need to adjust their code.  Other things
> include the usual C++ header changes, where previously some standard
> header included some other header as an implementation detail but it
> doesn't
> any longer and so code that relied on such indirect include that isn't
> required by the standard needs to include the header that provides whatever
> it relies on.  Or e.g. packages using -Werror where new warnings are
> reported with the newer compiler and -Werror results in build failures.
>
> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.
>
> Another important thing I wanted to say is that we'd like to switch
> ppc64le from the numerically problematic IBM extended long double to
> IEEE 754 quad long double.  This is an ABI change.  Some libraries
> are already built so that they support both ABIs at the same time,
> including glibc, libstdc++, libgcc, libgfortran etc.
> For other libraries and binaries, the compiler, assembler and linker
> will notice if they use long double and flag them as using either
> IBM or IEEE long double and linker (or I think dynamic linker too)
> might complain when things are mixed.
> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> but the glibc/gcc libraries are built compatibly with both.
> We'd like to configure gcc shortly before the mass rebuild with
> --with-long-double-format=ieee so that it will default to
> -mabi=ieeelongdouble, probably on a side-tag build first, and it
> will be highly desirable to rebuild at least some of the most commonly
> used library packages in the order of dependencies there, otherwise
> I'd be afraid the mass rebuild could fail for way too many packages
> (as the mass rebuild doesn't do dependency order rebuilds but just
> goes through packages alphabetically or so).
> Any suggestions on which packages have commonly used library packages
> that use long double?
> readelf -A on libraries on ppc64le prints either nothing (either
> the library is thought not to use long double or supports both ABIs
> transparently or hasn't been rebuilt for some years), or
> Attribute Section: gnu
> File Attributes
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> for libraries (or binaries or object files) that use IBM long double
> only or
> Attribute Section: gnu
> File Attributes
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
> for IEEE long doubles.
> So I think we want to rebuild on a side-tag packages that
> provide shared libraries used by hundreds of other packages that
> are
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> right now.
>
> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> 

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Marek Polacek]

On Fri, Jan 21, 2022 at 06:33:21PM +0100, Dan Horák wrote:
> On Fri, 21 Jan 2022 09:55:01 -0700
> Jerry James  wrote:
> 
> > On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek  wrote:
> > > Another important thing I wanted to say is that we'd like to switch
> > > ppc64le from the numerically problematic IBM extended long double to
> > > IEEE 754 quad long double.  This is an ABI change.  Some libraries
> > > are already built so that they support both ABIs at the same time,
> > > including glibc, libstdc++, libgcc, libgfortran etc.
> > > For other libraries and binaries, the compiler, assembler and linker
> > > will notice if they use long double and flag them as using either
> > > IBM or IEEE long double and linker (or I think dynamic linker too)
> > > might complain when things are mixed.
> > > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> > > but the glibc/gcc libraries are built compatibly with both.
> > > We'd like to configure gcc shortly before the mass rebuild with
> > > --with-long-double-format=ieee so that it will default to
> > > -mabi=ieeelongdouble, probably on a side-tag build first, and it
> > > will be highly desirable to rebuild at least some of the most commonly
> > > used library packages in the order of dependencies there, otherwise
> > > I'd be afraid the mass rebuild could fail for way too many packages
> > > (as the mass rebuild doesn't do dependency order rebuilds but just
> > > goes through packages alphabetically or so).
> > 
> > I don't know if this change is involved, but I've got several packages
> > that failed to build on ppc64le only, with what look like gcc
> > segfaults:
> > - dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527
> > - libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813
> > - libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797
> > - mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297
> 
> ^^^ those are probably
> https://bugzilla.redhat.com/show_bug.cgi?id=2043517

I think you're right.  And #2043517 is the same as #2043357.

Marek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Fri, Jan 21, 2022 at 06:42:23PM +0100, Dan Horák wrote:
> > > 
> > > Also note that libmpc failed to build on ppc64le only:
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783
> > 
> > one test core-dumps, I will try a local build to see what's in the core
> 
> Error for mpc_pow_ld (1)
> expected (-9 46)
> got (1.00e0 0)
> FAIL tpow_ld (exit status: 1)
> 
> ^^^ might be related to
> https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition
> 
> 
> dd1.c:545: MPFR assertion failed: rnd_mode == MPFR_RNDA
> FAIL tset (exit status: 134)
> 
> ^^^ dunno

I'd bet the rebuilds need to go in gmp, then mpfr, then libmpc order
so that the first ones pick the new long double ABI.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Dan Horák]

> > 
> > Also note that libmpc failed to build on ppc64le only:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783
> 
> one test core-dumps, I will try a local build to see what's in the core

Error for mpc_pow_ld (1)
expected (-9 46)
got (1.00e0 0)
FAIL tpow_ld (exit status: 1)

^^^ might be related to
https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition


dd1.c:545: MPFR assertion failed: rnd_mode == MPFR_RNDA
FAIL tset (exit status: 134)

^^^ dunno


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Dan Horák]

On Fri, 21 Jan 2022 09:55:01 -0700
Jerry James  wrote:

> On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek  wrote:
> > Another important thing I wanted to say is that we'd like to switch
> > ppc64le from the numerically problematic IBM extended long double to
> > IEEE 754 quad long double.  This is an ABI change.  Some libraries
> > are already built so that they support both ABIs at the same time,
> > including glibc, libstdc++, libgcc, libgfortran etc.
> > For other libraries and binaries, the compiler, assembler and linker
> > will notice if they use long double and flag them as using either
> > IBM or IEEE long double and linker (or I think dynamic linker too)
> > might complain when things are mixed.
> > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> > but the glibc/gcc libraries are built compatibly with both.
> > We'd like to configure gcc shortly before the mass rebuild with
> > --with-long-double-format=ieee so that it will default to
> > -mabi=ieeelongdouble, probably on a side-tag build first, and it
> > will be highly desirable to rebuild at least some of the most commonly
> > used library packages in the order of dependencies there, otherwise
> > I'd be afraid the mass rebuild could fail for way too many packages
> > (as the mass rebuild doesn't do dependency order rebuilds but just
> > goes through packages alphabetically or so).
> 
> I don't know if this change is involved, but I've got several packages
> that failed to build on ppc64le only, with what look like gcc
> segfaults:
> - dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527
> - libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813
> - libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797
> - mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297

^^^ those are probably
https://bugzilla.redhat.com/show_bug.cgi?id=2043517

> - cli11: https://koji.fedoraproject.org/koji/taskinfo?taskID=81476792
> - python-fpylll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81597035

^^^ those are different, but also LTO related

> 
> Also note that libmpc failed to build on ppc64le only:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783

one test core-dumps, I will try a local build to see what's in the core


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Dan Horák]

On Fri, 21 Jan 2022 10:09:39 -0700
Jerry James  wrote:

> On Fri, Jan 21, 2022 at 10:06 AM Dan Horák  wrote:
> > could be https://bugzilla.redhat.com/show_bug.cgi?id=2043517
> 
> Thanks for the pointer, Dan.

I think the keyword for this bug is "during RTL pass: final" followed
by an ICE segfault

But there could be other issues too ...


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jerry James]

On Fri, Jan 21, 2022 at 10:06 AM Dan Horák  wrote:
> could be https://bugzilla.redhat.com/show_bug.cgi?id=2043517

Thanks for the pointer, Dan.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Dan Horák]

On Fri, 21 Jan 2022 09:55:01 -0700
Jerry James  wrote:

> On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek  wrote:
> > Another important thing I wanted to say is that we'd like to switch
> > ppc64le from the numerically problematic IBM extended long double to
> > IEEE 754 quad long double.  This is an ABI change.  Some libraries
> > are already built so that they support both ABIs at the same time,
> > including glibc, libstdc++, libgcc, libgfortran etc.
> > For other libraries and binaries, the compiler, assembler and linker
> > will notice if they use long double and flag them as using either
> > IBM or IEEE long double and linker (or I think dynamic linker too)
> > might complain when things are mixed.
> > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> > but the glibc/gcc libraries are built compatibly with both.
> > We'd like to configure gcc shortly before the mass rebuild with
> > --with-long-double-format=ieee so that it will default to
> > -mabi=ieeelongdouble, probably on a side-tag build first, and it
> > will be highly desirable to rebuild at least some of the most commonly
> > used library packages in the order of dependencies there, otherwise
> > I'd be afraid the mass rebuild could fail for way too many packages
> > (as the mass rebuild doesn't do dependency order rebuilds but just
> > goes through packages alphabetically or so).
> 
> I don't know if this change is involved, but I've got several packages
> that failed to build on ppc64le only, with what look like gcc
> segfaults:
> - cli11: https://koji.fedoraproject.org/koji/taskinfo?taskID=81476792
> - dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527
> - libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813
> - libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797
> - mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297
> - python-fpylll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81597035

could be https://bugzilla.redhat.com/show_bug.cgi?id=2043517


Dan
 
> Also note that libmpc failed to build on ppc64le only:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783
> 
> Since gcc uses libmpc, it's probably important to look at that one carefully.
> -- 
> Jerry James
> http://www.jamezone.org/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jerry James]

On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek  wrote:
> Another important thing I wanted to say is that we'd like to switch
> ppc64le from the numerically problematic IBM extended long double to
> IEEE 754 quad long double.  This is an ABI change.  Some libraries
> are already built so that they support both ABIs at the same time,
> including glibc, libstdc++, libgcc, libgfortran etc.
> For other libraries and binaries, the compiler, assembler and linker
> will notice if they use long double and flag them as using either
> IBM or IEEE long double and linker (or I think dynamic linker too)
> might complain when things are mixed.
> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> but the glibc/gcc libraries are built compatibly with both.
> We'd like to configure gcc shortly before the mass rebuild with
> --with-long-double-format=ieee so that it will default to
> -mabi=ieeelongdouble, probably on a side-tag build first, and it
> will be highly desirable to rebuild at least some of the most commonly
> used library packages in the order of dependencies there, otherwise
> I'd be afraid the mass rebuild could fail for way too many packages
> (as the mass rebuild doesn't do dependency order rebuilds but just
> goes through packages alphabetically or so).

I don't know if this change is involved, but I've got several packages
that failed to build on ppc64le only, with what look like gcc
segfaults:
- cli11: https://koji.fedoraproject.org/koji/taskinfo?taskID=81476792
- dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527
- libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813
- libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797
- mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297
- python-fpylll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81597035

Also note that libmpc failed to build on ppc64le only:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783

Since gcc uses libmpc, it's probably important to look at that one carefully.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Thu, Jan 20, 2022 at 07:50:58AM -0500, Kaleb Keithley wrote:
> I thought I'd solved all my gcc-12-isms in ceph by running --scratch
> --arch-override=x86_64 builds, so I tried a full build and ran into this on
> aarch64. :-(
> 
> In file included from /usr/include/boost/integer.hpp:20,
>  from /usr/include/boost/integer/integer_mask.hpp:16,
>  from /usr/include/boost/random/mersenne_twister.hpp:26,
>  from /usr/include/boost/uuid/random_generator.hpp:17,
>  from /usr/include/boost/uuid/uuid_generators.hpp:17,
>  from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
>  from
> /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18,
>  from
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16:
> /usr/include/boost/integer_traits.hpp:83:64: error: narrowing
> conversion of '255' from 'int' to 'char' [-Wnarrowing]
>83 | public detail::integer_traits_base
>   |
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773
> 
> Are we expecting an update to boost by any chance?

Thanks for the preprocessed source.  That clearly shows a bug in
python3:
# 1681 "/usr/include/python3.10/pyconfig-64.h" 3 4
#define _DARWIN_C_SOURCE 1
#define _FILE_OFFSET_BITS 64
#define _GNU_SOURCE 1
#define _LARGEFILE_SOURCE 1
#define _NETBSD_SOURCE 1
#define _POSIX_C_SOURCE 200809L
#define _PYTHONFRAMEWORK ""
#define _REENTRANT 1
#define _XOPEN_SOURCE 700
#define _XOPEN_SOURCE_EXTENDED 1
#define __BSD_VISIBLE 1
#define __CHAR_UNSIGNED__ 1

__CHAR_UNSIGNED__ is a gcc predefined macro that is defined iff
-funsigned-char is in effect (by default or explicit), while it
shouldn't be defined if -fsigned-char is in effect (by default or
explicit).  As you used -fsigned-char option on -funsigned-char
defaulting arch, gcc correctly doesn't predefine __CHAR_UNSIGNED__.

But this python header defines it anyway which is just wrong,
because it breaks -fsigned-char explicit option on arches that default
to -funsigned-char - glibc limits.h that is included later will:
/* Minimum and maximum values a `char' can hold.  */
#  ifdef __CHAR_UNSIGNED__
#   define CHAR_MIN 0
#   define CHAR_MAX UCHAR_MAX
#  else
#   define CHAR_MIN SCHAR_MIN
#   define CHAR_MAX SCHAR_MAX
#  endif
and so CHAR_{MIN,MAX} won't match what char actually is.
If python wants in configure some macro for its own purposes,
it shouldn't use __CHAR_UNSIGNED__ but should use some
ideally non-reserved namespace identifier of its own.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

[Dan Horák]

On Fri, 21 Jan 2022 10:55:51 +0100
Remi Collet  wrote:

> Le 19/01/2022 à 11:53, Jakub Jelinek a écrit :
> > On Wed, Jan 19, 2022 at 07:27:44AM +0100, Remi Collet wrote:
> >> Le 14/01/2022 à 15:31, Jakub Jelinek a écrit :
> >>> gcc 12 snapshot has landed as the system compiler into rawhide today.
> >>
> >> PHP is now FTBFS on s390x only
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=81436437
> >>
> >>
> >> Any help welcome,
> >> Remi
> >>
> >>
> >> P.S. from build.log
> >>
> >>
> >> /builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h: In function
> >> 'ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER':
> >> /builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: 
> >> inlining
> >> failed in call to 'always_inline' 'zval_ptr_dtor_nogc': target specific
> >> option mismatch
> >> 32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr)
> >>|^~
> >> In file included from
> >> /builddir/build/BUILD/php-8.1.2/Zend/zend_execute.c:5071:
> >> /builddir/build/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: called
> >> from here
> >>   8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var));
> >>| ^~~
> > 
> > That error means that there is difference in the target attribute or #pragma
> > GCC target between the caller of the always_inline function and the
> > always_inline function which prevents the inlining (and always_inline
> > requires to be inlined).
> > I'd need preprocessed source + gcc command line to say more.
> 
> Still failing with 12.0.1-0.2 recently built on rawhide
> 
> Trying to disabled the always_inline don't solves the problem
> (same issue with memcpy call)
> 
> Sorry, but I have no idea how to check the "target" used
> can't find anything in the source code
> and don't have (simple) access to s390x computer

we have both public and internal s390x machines with Fedora, if needed,
please ping me for details.


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

[Remi Collet]

Le 19/01/2022 à 11:53, Jakub Jelinek a écrit :

On Wed, Jan 19, 2022 at 07:27:44AM +0100, Remi Collet wrote:

Le 14/01/2022 à 15:31, Jakub Jelinek a écrit :

gcc 12 snapshot has landed as the system compiler into rawhide today.


PHP is now FTBFS on s390x only
https://koji.fedoraproject.org/koji/taskinfo?taskID=81436437


Any help welcome,
Remi


P.S. from build.log


/builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h: In function
'ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER':
/builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: inlining
failed in call to 'always_inline' 'zval_ptr_dtor_nogc': target specific
option mismatch
32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr)
   |^~
In file included from
/builddir/build/BUILD/php-8.1.2/Zend/zend_execute.c:5071:
/builddir/build/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: called
from here
  8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var));
   | ^~~


That error means that there is difference in the target attribute or #pragma
GCC target between the caller of the always_inline function and the
always_inline function which prevents the inlining (and always_inline
requires to be inlined).
I'd need preprocessed source + gcc command line to say more.


Still failing with 12.0.1-0.2 recently built on rawhide

Trying to disabled the always_inline don't solves the problem
(same issue with memcpy call)

Sorry, but I have no idea how to check the "target" used
can't find anything in the source code
and don't have (simple) access to s390x computer


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Olivier Fourdan]

Hi Jakub,

On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek  wrote:
> […]
>
> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.
> […]

I am not sure whether this is a bug in gcc 12 or not.

There is a change which is currently preventing the xserver from
building, reported upstream here:

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1256

Which was raised in gcc first:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103292 eventually marked
as duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503

Looks like a patch was submitted
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564483.html

but it is unclear to me whether this will eventually be fixed in gcc
or not (the patch is a year old now and hasn't seen much traction
apparently). Meanwhile, I cannot build the xserver in rawhide (like
e.g. the recently released xwayland 22.1 rc1) because of that.

I posted a possible fix upstream:

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/853

But this is considered more of a workaround… Not sure how to proceed there.

Cheers
Olivier
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Thu, Jan 20, 2022 at 02:31:52PM +, Richard W.M. Jones wrote:
> On Thu, Jan 20, 2022 at 02:30:24PM +, Richard W.M. Jones wrote:
> > 
> > The qemu bug led to this optimizer mis-compilation bug which seems
> > very serious:
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
> > 
> > I'm not sure I would try GCC 12 generated code until this gets fixed.
> 
> s/try/trust/

It is a serious bug, but the likelyhood that it triggers on other packages
is low.  We don't mass rebuild again any time we fix some wrong-code issue
in gcc, that would be many times a year, only if we know it affects
significant amounts of packages.  And even in those cases it can be a
targetted test mass rebuild with instrumented compiler to warn us that it
triggers that bug and from that determine what needs to be rebuilt (we've
done it several times in the past).

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Richard W.M. Jones]

On Thu, Jan 20, 2022 at 02:30:24PM +, Richard W.M. Jones wrote:
> 
> The qemu bug led to this optimizer mis-compilation bug which seems
> very serious:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
> 
> I'm not sure I would try GCC 12 generated code until this gets fixed.

s/try/trust/

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Richard W.M. Jones]

The qemu bug led to this optimizer mis-compilation bug which seems
very serious:

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

I'm not sure I would try GCC 12 generated code until this gets fixed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Thu, Jan 20, 2022 at 01:32:26PM +, Jonathan Wakely wrote:
> On Thu, 20 Jan 2022 at 13:05, Jonathan Wakely  wrote:
> >
> > On Thu, 20 Jan 2022 at 12:54, Kaleb Keithley  wrote:
> > >
> > >
> > > I thought I'd solved all my gcc-12-isms in ceph by running --scratch 
> > > --arch-override=x86_64 builds, so I tried a full build and ran into this 
> > > on aarch64. :-(
> > >
> > > /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> > > -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> > > -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> > > -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> > > -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> > > -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> > > /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include 
> > > -isystem /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> > > /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> > > /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> > > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> > > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> > > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> > > -mbranch-protection=standard -fasynchronous-unwind-tables 
> > > -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> > > -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> > > -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> > > -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> > > -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> > > -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> > > -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> > > -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> > > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> > > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> > > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> > > /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> > > FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
> > > /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> > > -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> > > -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> > > -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> > > -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> > > -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> > > /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include 
> > > -isystem /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> > > /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> > > /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> > > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> > > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> > > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> > > -mbranch-protection=standard -fasynchronous-unwind-tables 
> > > -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> > > -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> > > -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> > > -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> > > -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> > > -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> > > -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> > > -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> > > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> > > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> > > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> > > /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> > > In file included from /usr/include/boost/integer.hpp:20,
> > >  from /usr/include/boost/integer/integer_mask.hpp:16,
> > >  from /usr/include/boost/random/mersenne_twister.hpp:26,
> > >  from /usr/include/boost/uuid/random_generator.hpp:17,
> > >  from /usr/include/boost/uuid/uuid_generators.hpp:17,
> > >  from 
> > > /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
> > >  from 
> > > /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
> > >  from 
> > > /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
> > >  from 
> > > /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
> > >  from 
> > > /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
> > >  from 
> > > 

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Thu, 20 Jan 2022 at 13:05, Jonathan Wakely  wrote:
>
> On Thu, 20 Jan 2022 at 12:54, Kaleb Keithley  wrote:
> >
> >
> > I thought I'd solved all my gcc-12-isms in ceph by running --scratch 
> > --arch-override=x86_64 builds, so I tried a full build and ran into this on 
> > aarch64. :-(
> >
> > /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> > -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> > -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> > -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> > -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> > -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> > /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> > -mbranch-protection=standard -fasynchronous-unwind-tables 
> > -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> > -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> > -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> > -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> > -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> > -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> > -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> > -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> > /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> > FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
> > /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> > -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> > -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> > -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> > -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> > -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> > /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> > -mbranch-protection=standard -fasynchronous-unwind-tables 
> > -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> > -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> > -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> > -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> > -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> > -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> > -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> > -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> > /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> > In file included from /usr/include/boost/integer.hpp:20,
> >  from /usr/include/boost/integer/integer_mask.hpp:16,
> >  from /usr/include/boost/random/mersenne_twister.hpp:26,
> >  from /usr/include/boost/uuid/random_generator.hpp:17,
> >  from /usr/include/boost/uuid/uuid_generators.hpp:17,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16:
> > /usr/include/boost/integer_traits.hpp:83:64: error: narrowing conversion of 
> > 

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Thu, 20 Jan 2022 at 12:54, Kaleb Keithley  wrote:
>
>
> I thought I'd solved all my gcc-12-isms in ceph by running --scratch 
> --arch-override=x86_64 builds, so I tried a full build and ran into this on 
> aarch64. :-(
>
> /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> -mbranch-protection=standard -fasynchronous-unwind-tables 
> -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
> /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> -mbranch-protection=standard -fasynchronous-unwind-tables 
> -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> In file included from /usr/include/boost/integer.hpp:20,
>  from /usr/include/boost/integer/integer_mask.hpp:16,
>  from /usr/include/boost/random/mersenne_twister.hpp:26,
>  from /usr/include/boost/uuid/random_generator.hpp:17,
>  from /usr/include/boost/uuid/uuid_generators.hpp:17,
>  from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16:
> /usr/include/boost/integer_traits.hpp:83:64: error: narrowing conversion of 
> '255' from 'int' to 'char' [-Wnarrowing]
>83 | public detail::integer_traits_base
>   |
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773
>
> Are we expecting an update to boost by any chance?

No, 

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Kaleb Keithley]

On Thu, Jan 20, 2022 at 7:50 AM Kaleb Keithley  wrote:

>
> I thought I'd solved all my gcc-12-isms in ceph by running --scratch
> --arch-override=x86_64 builds, so I tried a full build and ran into this on
> aarch64. :-(
>

ppc64le and s390x as well.


>
> /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> -mbranch-protection=standard -fasynchronous-unwind-tables 
> -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
> /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> -mbranch-protection=standard -fasynchronous-unwind-tables 
> -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> In file included from /usr/include/boost/integer.hpp:20,
>  from /usr/include/boost/integer/integer_mask.hpp:16,
>  from /usr/include/boost/random/mersenne_twister.hpp:26,
>  from /usr/include/boost/uuid/random_generator.hpp:17,
>  from /usr/include/boost/uuid/uuid_generators.hpp:17,
>  from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16:
> /usr/include/boost/integer_traits.hpp:83:64: error: narrowing conversion of 
> '255' from 'int' to 'char' [-Wnarrowing]
>83 | public detail::integer_traits_base
>   |
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773
>
> Are we expecting an update 

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Kaleb Keithley]

I thought I'd solved all my gcc-12-isms in ceph by running --scratch
--arch-override=x86_64 builds, so I tried a full build and ran into this on
aarch64. :-(

/usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION
-DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H
-D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT
-D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__
-I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include
-I/builddir/build/BUILD/ceph-16.2.7/src -isystem
/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include
-isystem /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem
/builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem
/usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -mbranch-protection=standard -fasynchronous-unwind-tables
-fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE
-Wall -fno-strict-aliasing -fsigned-char -Wtype-limits
-Wignored-qualifiers -Wpointer-arith -Werror=format-security
-Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor
-Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move
-Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual
-fno-new-ttp-matching -fstack-protector-strong
-fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc
-fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT
src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF
src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o
src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c
/builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
/usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION
-DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H
-D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT
-D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__
-I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include
-I/builddir/build/BUILD/ceph-16.2.7/src -isystem
/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include
-isystem /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem
/builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem
/usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -mbranch-protection=standard -fasynchronous-unwind-tables
-fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE
-Wall -fno-strict-aliasing -fsigned-char -Wtype-limits
-Wignored-qualifiers -Wpointer-arith -Werror=format-security
-Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor
-Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move
-Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual
-fno-new-ttp-matching -fstack-protector-strong
-fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc
-fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT
src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF
src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o
src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c
/builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
In file included from /usr/include/boost/integer.hpp:20,
 from /usr/include/boost/integer/integer_mask.hpp:16,
 from /usr/include/boost/random/mersenne_twister.hpp:26,
 from /usr/include/boost/uuid/random_generator.hpp:17,
 from /usr/include/boost/uuid/uuid_generators.hpp:17,
 from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
 from /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
 from /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
 from
/builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
 from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
 from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18,
 from
/builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16:
/usr/include/boost/integer_traits.hpp:83:64: error: narrowing
conversion of '255' from 'int' to 'char' [-Wnarrowing]
   83 | public detail::integer_traits_base
  |

https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773

Are we expecting an update to boost by any chance?


On Fri, Jan 14, 2022 at 9:33 AM Jakub Jelinek  wrote:

> Hi!
>
> gcc 12 snapshot has landed as the system compiler into rawhide today.
> GCC 12 is going to enter its stage4 development phase (only regression
> and documentation bugfixes allowed) on Monday 17th, so there should 

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Michel Alexandre Salim]

On Wed, Jan 19, 2022 at 04:09:09PM -0700, Jerry James wrote:
> On Wed, Jan 19, 2022 at 3:56 PM Michel Alexandre Salim
>  wrote:
> > Rebuilding folly, and building the latest tagged release, both fail with
> > GCC 12:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2042690
> >
> > It happens that libfmt has also been upgraded, so it's hard to pinpoint.
> > I'm going to see if I can tag a scratch build of the newer fmt on a F35
> > sidetag so we can rule that out.
> 
> I don't know if GCC 12 has anything to do with poppler/texlive
> breakage in Rawhide, but mentioning it here just in case:
> https://bugzilla.redhat.com/show_bug.cgi?id=2042421.  The fact that
> GDB is broken in Rawhide
> (https://bugzilla.redhat.com/show_bug.cgi?id=2042664) is making
> investigation difficult.

This seems unrelated, alebastr pointed out that the folly issue (on
ppc64le only) is likely due to the floating point ABI change Jakub
announced in the initial message.

It's likely fmt will needs to be rebuilt, but I'm hesitant to just try
bumping and pray unless I can try that in a side tag. Going to try that
next.

Best regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jerry James]

On Wed, Jan 19, 2022 at 3:56 PM Michel Alexandre Salim
 wrote:
> Rebuilding folly, and building the latest tagged release, both fail with
> GCC 12:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2042690
>
> It happens that libfmt has also been upgraded, so it's hard to pinpoint.
> I'm going to see if I can tag a scratch build of the newer fmt on a F35
> sidetag so we can rule that out.

I don't know if GCC 12 has anything to do with poppler/texlive
breakage in Rawhide, but mentioning it here just in case:
https://bugzilla.redhat.com/show_bug.cgi?id=2042421.  The fact that
GDB is broken in Rawhide
(https://bugzilla.redhat.com/show_bug.cgi?id=2042664) is making
investigation difficult.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Michel Alexandre Salim]

On Sat, Jan 15, 2022 at 09:30:25PM -0800, Michel Alexandre Salim wrote:
> Hi Jakub,
> 
> On Fri, Jan 14, 2022 at 03:31:43PM +0100, Jakub Jelinek wrote:
> > Hi!
> > 
> > gcc 12 snapshot has landed as the system compiler into rawhide today.
> > GCC 12 is going to enter its stage4 development phase (only regression
> > and documentation bugfixes allowed) on Monday 17th, so there should be
> > just those bugfixes and not new features etc. anymore.
> > https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> > most important is probably that vectorization is enabled at -O2 now
> > which is the option with most of the distribution is built with.
> > 
> > https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> > some cases where people need to adjust their code.  Other things
> > include the usual C++ header changes, where previously some standard
> > header included some other header as an implementation detail but it doesn't
> > any longer and so code that relied on such indirect include that isn't
> > required by the standard needs to include the header that provides whatever
> > it relies on.  Or e.g. packages using -Werror where new warnings are
> > reported with the newer compiler and -Werror results in build failures.
> 
> Can this be documented soon?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99032
> 
> It hit nextcloud-client:
> https://bugzilla.redhat.com/show_bug.cgi?id=2041135 which compiles fine
> with GCC 11 for F34 and F35.
> 
> > 
> > If there are bugs on the compiler side, please let me know immediately,
> > so that those bugs can be fixed before the mass rebuild next week.
> > 
> I'm going to exercise this with the new Folly stack on Monday once the
> weekly tags are created. Will try and report ASAP.
>
Rebuilding folly, and building the latest tagged release, both fail with
GCC 12:

https://bugzilla.redhat.com/show_bug.cgi?id=2042690

It happens that libfmt has also been upgraded, so it's hard to pinpoint.
I'm going to see if I can tag a scratch build of the newer fmt on a F35
sidetag so we can rule that out.

Regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

[Jakub Jelinek]

On Wed, Jan 19, 2022 at 07:27:44AM +0100, Remi Collet wrote:
> Le 14/01/2022 à 15:31, Jakub Jelinek a écrit :
> > gcc 12 snapshot has landed as the system compiler into rawhide today.
> 
> PHP is now FTBFS on s390x only
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81436437
> 
> 
> Any help welcome,
> Remi
> 
> 
> P.S. from build.log
> 
> 
> /builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h: In function
> 'ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER':
> /builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: inlining
> failed in call to 'always_inline' 'zval_ptr_dtor_nogc': target specific
> option mismatch
>32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr)
>   |^~
> In file included from
> /builddir/build/BUILD/php-8.1.2/Zend/zend_execute.c:5071:
> /builddir/build/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: called
> from here
>  8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var));
>   | ^~~

That error means that there is difference in the target attribute or #pragma
GCC target between the caller of the always_inline function and the
always_inline function which prevents the inlining (and always_inline
requires to be inlined).
I'd need preprocessed source + gcc command line to say more.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

[Remi Collet]

Le 14/01/2022 à 15:31, Jakub Jelinek a écrit :

Hi!

gcc 12 snapshot has landed as the system compiler into rawhide today.


PHP is now FTBFS on s390x only
https://koji.fedoraproject.org/koji/taskinfo?taskID=81436437


Any help welcome,
Remi


P.S. from build.log


/builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h: In function 
'ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER':
/builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: 
inlining failed in call to 'always_inline' 'zval_ptr_dtor_nogc': target 
specific option mismatch

   32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr)
  |^~
In file included from 
/builddir/build/BUILD/php-8.1.2/Zend/zend_execute.c:5071:
/builddir/build/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: 
called from here

 8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var));
  | ^~~
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Tue, Jan 18, 2022 at 03:13:22PM +, Sérgio Basto wrote:
> On Mon, 2022-01-17 at 14:36 +, Sérgio Basto wrote:
> > On Mon, 2022-01-17 at 15:10 +0100, Vitaly Zaitsev via devel wrote:
> > > On 17/01/2022 15:00, Ben Beasley wrote:
> > > > dependency “json”: https://github.com/nlohmann/json/issues/3138
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2041187
> > > 
> > 
> > Rawhide compose doomed again [1] :( , I still haven't the results of 
> > koschei opencv altivec build with gcc-12.0.0-0.5, it failed with gcc-
> > 12.0.0-0.4 [2] 
> > 
> 
> 
> Build with gcc-12.0.0-0.5 not fixed the error related with altivec 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2041573

It fixed the error related to altivec others were reporting - 
#2040825.  For the above I'd need preprocessed source + gcc command line,
can be a gcc bug, can be a package bug of using altivec incorrectly.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Tue, Jan 18, 2022 at 07:22:00PM +0100, Florian Weimer wrote:
> >> On aarch64 I actually got a slightly different error message:
> >> 
> >>  ld: criu/pie/restorer.o: in function `lsm_set_label':
> >>  /drone/src/criu/pie/restorer.c:174: undefined reference to `strlen'
> >> 
> >> Line 174 is: "for (len = 0; label[len]; len++)"
> >> 
> >> Although there is no direct use of strlen(), it seems GCC 12 uses
> >> strlen() for that line which did not happen with GCC 11. Using
> >> '-ffreestanding' makes the compilation work with GCC 12 and CI still
> >> looks happy. Thanks.
> >
> > https://gcc.gnu.org/r12-4283-g6f966f06146be76
> > Note, gcc has been doing something similar for years for memcpy and memset.
> > -fno-tree-loop-distribute-patterns
> > will work too.
> 
> Shouldn't it be -ffreestanding?

-ffreestanding works too.  Both of these options disable the pattern
matching, -fno-tree-loop-distribute-patterns is a targetted option that
disables just these kind of optimizations, -ffreestanding has various
further effects, it implies -fno-builtin, changes some preprocessor macros
and generally will disable far more optimizations than
-fno-tree-loop-distribute-patterns will.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Florian Weimer]

* Jakub Jelinek:

> On Tue, Jan 18, 2022 at 07:08:00PM +0100, Adrian Reber wrote:
>> On Tue, Jan 18, 2022 at 05:56:45PM +0100, Jakub Jelinek wrote:
>> > On Tue, Jan 18, 2022 at 05:40:31PM +0100, Adrian Reber wrote:
>> > > > If there are bugs on the compiler side, please let me know immediately,
>> > > > so that those bugs can be fixed before the mass rebuild next week.
>> > > 
>> > > Not sure if it is a bug, CRIU no longer works with GCC 12.
>> > > 
>> > > CRIU creates something called 'parasite code' which is injected into
>> > > running processes for checkpointing and that part is built with
>> > > '-nostdlib'. Starting with GCC 12 we see 'strlen()' being pulled into
>> > > the parasite code which it wasn't with GCC 11.
>> > 
>> > strlen is a standard C function, so I don't see any bug in that being used
>> > unless you do a freestanding compilation (-nostdlib isn't that).
>> > If you mail me preprocessed source of handle-elf-host.c + gcc
>> > command line used to compile it, I can have a look what exactly changed.
>> 
>> Thanks for mentioning freestanding compilations. That seems to have been
>> the problem.
>> 
>> On aarch64 I actually got a slightly different error message:
>> 
>>  ld: criu/pie/restorer.o: in function `lsm_set_label':
>>  /drone/src/criu/pie/restorer.c:174: undefined reference to `strlen'
>> 
>> Line 174 is: "for (len = 0; label[len]; len++)"
>> 
>> Although there is no direct use of strlen(), it seems GCC 12 uses
>> strlen() for that line which did not happen with GCC 11. Using
>> '-ffreestanding' makes the compilation work with GCC 12 and CI still
>> looks happy. Thanks.
>
> https://gcc.gnu.org/r12-4283-g6f966f06146be76
> Note, gcc has been doing something similar for years for memcpy and memset.
> -fno-tree-loop-distribute-patterns
> will work too.

Shouldn't it be -ffreestanding?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Tue, Jan 18, 2022 at 07:08:00PM +0100, Adrian Reber wrote:
> On Tue, Jan 18, 2022 at 05:56:45PM +0100, Jakub Jelinek wrote:
> > On Tue, Jan 18, 2022 at 05:40:31PM +0100, Adrian Reber wrote:
> > > > If there are bugs on the compiler side, please let me know immediately,
> > > > so that those bugs can be fixed before the mass rebuild next week.
> > > 
> > > Not sure if it is a bug, CRIU no longer works with GCC 12.
> > > 
> > > CRIU creates something called 'parasite code' which is injected into
> > > running processes for checkpointing and that part is built with
> > > '-nostdlib'. Starting with GCC 12 we see 'strlen()' being pulled into
> > > the parasite code which it wasn't with GCC 11.
> > 
> > strlen is a standard C function, so I don't see any bug in that being used
> > unless you do a freestanding compilation (-nostdlib isn't that).
> > If you mail me preprocessed source of handle-elf-host.c + gcc
> > command line used to compile it, I can have a look what exactly changed.
> 
> Thanks for mentioning freestanding compilations. That seems to have been
> the problem.
> 
> On aarch64 I actually got a slightly different error message:
> 
>  ld: criu/pie/restorer.o: in function `lsm_set_label':
>  /drone/src/criu/pie/restorer.c:174: undefined reference to `strlen'
> 
> Line 174 is: "for (len = 0; label[len]; len++)"
> 
> Although there is no direct use of strlen(), it seems GCC 12 uses
> strlen() for that line which did not happen with GCC 11. Using
> '-ffreestanding' makes the compilation work with GCC 12 and CI still
> looks happy. Thanks.

https://gcc.gnu.org/r12-4283-g6f966f06146be76
Note, gcc has been doing something similar for years for memcpy and memset.
-fno-tree-loop-distribute-patterns
will work too.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Artur Frenszek-Iwicki]

I pulled a Rawhide container and tried building there via "fedpkg local".
When I took the g++ command line and replaced "-flto=auto -ffat-lto-objects"
with "-flto=none", the file was compiled without errors.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Adrian Reber]

On Tue, Jan 18, 2022 at 05:56:45PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 18, 2022 at 05:40:31PM +0100, Adrian Reber wrote:
> > > If there are bugs on the compiler side, please let me know immediately,
> > > so that those bugs can be fixed before the mass rebuild next week.
> > 
> > Not sure if it is a bug, CRIU no longer works with GCC 12.
> > 
> > CRIU creates something called 'parasite code' which is injected into
> > running processes for checkpointing and that part is built with
> > '-nostdlib'. Starting with GCC 12 we see 'strlen()' being pulled into
> > the parasite code which it wasn't with GCC 11.
> 
> strlen is a standard C function, so I don't see any bug in that being used
> unless you do a freestanding compilation (-nostdlib isn't that).
> If you mail me preprocessed source of handle-elf-host.c + gcc
> command line used to compile it, I can have a look what exactly changed.

Thanks for mentioning freestanding compilations. That seems to have been
the problem.

On aarch64 I actually got a slightly different error message:

 ld: criu/pie/restorer.o: in function `lsm_set_label':
 /drone/src/criu/pie/restorer.c:174: undefined reference to `strlen'

Line 174 is: "for (len = 0; label[len]; len++)"

Although there is no direct use of strlen(), it seems GCC 12 uses
strlen() for that line which did not happen with GCC 11. Using
'-ffreestanding' makes the compilation work with GCC 12 and CI still
looks happy. Thanks.

Adrian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Tue, 18 Jan 2022 at 11:01, Jonathan Wakely  wrote:

>
>
> On Mon, 17 Jan 2022 at 14:01, Ben Beasley  wrote:
>
>> Skimming through Koschei, here are a sampling of regressions that seem
>> to be associated with GCC 12. Some of these are in packages I maintain
>> directly; others are via @neuro-sig.
>>
>> With a few exceptions, I have triaged these only to the extent of
>> confirming the problem appeared at the same time as GCC 12 and noting
>> the initial error. I mostly haven’t gotten around to filing or searching
>> for bugs, upstream or downstream.
>>
>> Explicit deletion of the
>> std::string(nullptr_t)/std::string_view(nullptr_t) constructors seems
>> like it is going to be a popular cause of FTBFS in C++ packages. Use of
>> this constructor mostly happens implicitly. I think explicit use of the
>> default constructor, e.g. std::string_view(), will usually be the
>> simplest correct substitute.
>>
>
> All such uses were undefined behaviour (and should have thrown an
> exception at runtime if the code was ever executed. Fixing those is good.
>

That change now only applies when compiling as C++23, so won't affect most
packages (once the fix makes it from upstream GCC to rawhide). It would
still be good to fix code that really does construct strings and
string_views from nullptr, otherwise it will break again in a few years
when GCC defaults to -std=gnu++23.




>
>
>> New compilation errors:
>>
>> COPASI: “error: passing 'const CDataVectorN' as 'this'
>> argument discards qualifiers [-fpermissive]”
>>
>
> What's the context? Is that being used as a comparison function in a std::
> container or something?
>
>
>>
>> grpc: initializing std::string_view/absl::string_view with nullptr –
>> fixed and PR sent upstream
>>
>> python-steps: “static assertion failed: key equality predicate must be
>> invocable with two arguments of key type” via
>> c++/12/bits/hashtable_policy.h
>>
>
> Maybe a variant of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923
>
>
>
>>
>> vxl: “error: conversion from 'int' to 'std::__cxx11::basic_string'
>> is ambiguous” – looks like an attempt to initialize a string by
>> std::string(nullptr), which is now explicitly deleted
>> (“basic_string(nullptr_t) = delete”)
>>
>
> If it's actually initializing it with nullptr, that's just undefined (and
> going to be ill-formed in C++23) and the code should be fixed.
>
> If it's like the nlohmann:json case, I need to investigate more whether
> it's a defect in the C++23 spec or the code should be fixed.
>

Turns out it's both. The C++23 change breaks the json lib (and they have a
fix) but I made it apply to all of C++11/14/17/20/23, which is incorrect
because it breaks code that should be valid in C++20. Fixed in GCC upstream
now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Tue, 18 Jan 2022 at 11:04, Jonathan Wakely  wrote:

>
>
> On Tue, 18 Jan 2022 at 10:29, Frantisek Zatloukal 
> wrote:
>
>>
>>
>> On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek  wrote:
>>
>>> If there are bugs on the compiler side, please let me know immediately,
>>> so that those bugs can be fixed before the mass rebuild next week.
>>>
>>
>> While I was trying to rebuild some Intel components, i've encountered
>> this issue, which seems to be caused by libstdc. It affects
>> intel-graphics-compiler (not yet in Fedora). That is compiled with clang,
>> however, since gcc/libstdc 12, I am hitting this:
>>
>> /builddir/build/BUILD/intel-graphics-compiler-igc-1.0.9933/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp:590:46:
>> error: call to constructor of 'LiveRangeMap_t::value_type' (aka 'pair> llvm::genx::SimpleValue, llvm::genx::LiveRange *>') is ambiguous
>>   auto [i, isInserted] =
>> LiveRangeMap.insert(LiveRangeMap_t::value_type(V, 0));
>>  ^
>>  
>> /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:425:17:
>> note: candidate constructor [with _U1 = const llvm::genx::SimpleValue, _U2
>> = llvm::genx::LiveRange *, $2 = true]
>>   constexpr pair(const _T1& __a, const _T2& __b)
>> ^
>> /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:492:18:
>> note: candidate constructor [with _U1 = llvm::genx::SimpleValue &, $1 =
>> true]
>>constexpr pair(_U1&& __x, __null_ptr_constant)
>>  ^
>> 1 error generated.
>>
>> I've tried to locally recompile clang and llvm against the new libstdc
>> (as it seems ambiguousness is caused by #if _GLIBCXX_USE_DEPRECATED being
>> met), but that didn't help. Maybe I am missing some library that needs to
>> be recompiled too. Anyhow, is this expected behavior?
>>
>> The affected file is this one:
>> https://github.com/intel/intel-graphics-compiler/blob/master/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp
>>
>
>
> I think the code is just wrong, and should use nullptr instead of 0 in
> that initializer on line 590.
>
> It's related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101124
> though. I tried to keep that old incorrect code working, but apparently
> failed.
>

It was a GCC regression in my std::pair changes, fixed now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Tue, Jan 18, 2022 at 05:40:31PM +0100, Adrian Reber wrote:
> > If there are bugs on the compiler side, please let me know immediately,
> > so that those bugs can be fixed before the mass rebuild next week.
> 
> Not sure if it is a bug, CRIU no longer works with GCC 12.
> 
> CRIU creates something called 'parasite code' which is injected into
> running processes for checkpointing and that part is built with
> '-nostdlib'. Starting with GCC 12 we see 'strlen()' being pulled into
> the parasite code which it wasn't with GCC 11.

strlen is a standard C function, so I don't see any bug in that being used
unless you do a freestanding compilation (-nostdlib isn't that).
If you mail me preprocessed source of handle-elf-host.c + gcc
command line used to compile it, I can have a look what exactly changed.

> https://kojipkgs.fedoraproject.org/work/tasks/6033/81406033/build.log
> 
> gcc -c -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall 
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g 
> -Wall -Wformat-security -Wdeclaration-after-statement -Wstrict-prototypes 
> -DCONFIG_X86_64 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DCONFIG_HAS_LIBBSD 
> -DCONFIG_HAS_SELINUX -DCONFIG_GNUTLS -DCONFIG_HAS_NFTABLES_LIB_API_1 
> -DCONFIG_COMPAT -iquote include/ -DCONFIG_HAS_LIBBSD -DCONFIG_HAS_SELINUX 
> -DCONFIG_GNUTLS -DCONFIG_HAS_NFTABLES_LIB_API_1 -DCONFIG_COMPAT -I 
> ./compel/include/uapi -fno-strict-aliasing -iquote criu/include -iquote 
> include -iquote images -iquote criu/arch/x86/include -iquote . 
> -I/usr/include/libnl3 -DSYSCONFDIR='"/etc"' 
> -DGLOBAL_CONFIG_DIR='"/etc/criu/"' -DDEFAULT_CONFIG_FILENAME='"default.conf"' 
> -DUSER_CONFIG_DIR='".criu/"' -DCR_NOGLIBC -Wstrict-prototypes 
> -fno-stack-protector -nostdlib -fomit-frame-pointer -fpie -I 
> ./compel/include/uapi -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 
> -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=0 criu/pie/restorer.c -o 
> criu/pie/restorer.o
> ld  -r -z noexecstack -T ./compel/arch/x86/scripts/compel-pack.lds.S  -o 
> criu/pie/restorer.built-in.o  criu/pie/parasite-vdso.o 
> ./criu/arch/x86/vdso-pie.o ./criu/arch/x86/restorer.o 
> ./criu/arch/x86/restorer_unmap.o ./criu/arch/x86/sigaction_compat_pie.o 
> criu/pie/restorer.o criu/pie/pie.lib.a ./compel/plugins/std.lib.a
> ./compel/compel-host hgen -f criu/pie/restorer.built-in.o -o 
> criu/pie/restorer-blob.h
> Error (compel/src/lib/handle-elf-host.c:337): Unexpected undefined symbol: 
> `strlen'. External symbol in PIE?
> make[2]: *** [criu/pie/Makefile:58: criu/pie/restorer-blob.h] Error 255
> make[1]: *** [criu/Makefile:59: pie] Error 2
> make: *** [Makefile:250: criu] Error 2
> 
> Not sure why there is 'strlen()' pulled in with GCC 12. Any ideas?

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Adrian Reber]

On Fri, Jan 14, 2022 at 03:31:43PM +0100, Jakub Jelinek wrote:
> gcc 12 snapshot has landed as the system compiler into rawhide today.
> GCC 12 is going to enter its stage4 development phase (only regression
> and documentation bugfixes allowed) on Monday 17th, so there should be
> just those bugfixes and not new features etc. anymore.
> https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> most important is probably that vectorization is enabled at -O2 now
> which is the option with most of the distribution is built with.
> 
> https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> some cases where people need to adjust their code.  Other things
> include the usual C++ header changes, where previously some standard
> header included some other header as an implementation detail but it doesn't
> any longer and so code that relied on such indirect include that isn't
> required by the standard needs to include the header that provides whatever
> it relies on.  Or e.g. packages using -Werror where new warnings are
> reported with the newer compiler and -Werror results in build failures.
> 
> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.

Not sure if it is a bug, CRIU no longer works with GCC 12.

CRIU creates something called 'parasite code' which is injected into
running processes for checkpointing and that part is built with
'-nostdlib'. Starting with GCC 12 we see 'strlen()' being pulled into
the parasite code which it wasn't with GCC 11.

https://kojipkgs.fedoraproject.org/work/tasks/6033/81406033/build.log

gcc -c -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g 
-Wall -Wformat-security -Wdeclaration-after-statement -Wstrict-prototypes 
-DCONFIG_X86_64 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DCONFIG_HAS_LIBBSD 
-DCONFIG_HAS_SELINUX -DCONFIG_GNUTLS -DCONFIG_HAS_NFTABLES_LIB_API_1 
-DCONFIG_COMPAT -iquote include/ -DCONFIG_HAS_LIBBSD -DCONFIG_HAS_SELINUX 
-DCONFIG_GNUTLS -DCONFIG_HAS_NFTABLES_LIB_API_1 -DCONFIG_COMPAT -I 
./compel/include/uapi -fno-strict-aliasing -iquote criu/include -iquote include 
-iquote images -iquote criu/arch/x86/include -iquote . -I/usr/include/libnl3 
-DSYSCONFDIR='"/etc"' -DGLOBAL_CONFIG_DIR='"/etc/criu/"' 
-DDEFAULT_CONFIG_FILENAME='"default.conf"' -DUSER_CONFIG_DIR='".criu/"' 
-DCR_NOGLIBC -Wstrict-prototypes -fno-stack-protector -nostdlib 
-fomit-frame-pointer -fpie -I ./compel/include/uapi -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=0 -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=0 
criu/pie/restorer.c -o criu/pie/restorer.o
ld  -r -z noexecstack -T ./compel/arch/x86/scripts/compel-pack.lds.S  -o 
criu/pie/restorer.built-in.o  criu/pie/parasite-vdso.o 
./criu/arch/x86/vdso-pie.o ./criu/arch/x86/restorer.o 
./criu/arch/x86/restorer_unmap.o ./criu/arch/x86/sigaction_compat_pie.o 
criu/pie/restorer.o criu/pie/pie.lib.a ./compel/plugins/std.lib.a
./compel/compel-host hgen -f criu/pie/restorer.built-in.o -o 
criu/pie/restorer-blob.h
Error (compel/src/lib/handle-elf-host.c:337): Unexpected undefined symbol: 
`strlen'. External symbol in PIE?
make[2]: *** [criu/pie/Makefile:58: criu/pie/restorer-blob.h] Error 255
make[1]: *** [criu/Makefile:59: pie] Error 2
make: *** [Makefile:250: criu] Error 2

Not sure why there is 'strlen()' pulled in with GCC 12. Any ideas?

Adrian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Sérgio Basto]

On Mon, 2022-01-17 at 14:36 +, Sérgio Basto wrote:
> On Mon, 2022-01-17 at 15:10 +0100, Vitaly Zaitsev via devel wrote:
> > On 17/01/2022 15:00, Ben Beasley wrote:
> > > dependency “json”: https://github.com/nlohmann/json/issues/3138
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2041187
> > 
> 
> Rawhide compose doomed again [1] :( , I still haven't the results of 
> koschei opencv altivec build with gcc-12.0.0-0.5, it failed with gcc-
> 12.0.0-0.4 [2] 
> 


Build with gcc-12.0.0-0.5 not fixed the error related with altivec 

https://bugzilla.redhat.com/show_bug.cgi?id=2041573



> 
> [2]
> https://koschei.fedoraproject.org/package/opencv?collection=f36
> 
> [1]
> https://kojipkgs.fedoraproject.org/compose/rawhide/
> 
> 
> -- 
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Frantisek Zatloukal]

On Tue, Jan 18, 2022 at 12:25 PM Jonathan Wakely  wrote:

> PR sent:
> https://github.com/intel/intel-graphics-compiler/pull/226
>

Thanks! Added a comment to that, works flawlessly!


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Marc Dionne]

On Fri, Jan 14, 2022 at 10:32 AM Jakub Jelinek  wrote:
>
> Hi!
>
> gcc 12 snapshot has landed as the system compiler into rawhide today.
> GCC 12 is going to enter its stage4 development phase (only regression
> and documentation bugfixes allowed) on Monday 17th, so there should be
> just those bugfixes and not new features etc. anymore.
> https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> most important is probably that vectorization is enabled at -O2 now
> which is the option with most of the distribution is built with.

Hi,

Don't think I've seen this reported, but I get the following warnings
for code that uses memset, memcpy, etc. while compiling an external
kernel module against the current rawhide kernel:

./include/linux/fortify-string.h: In function ‘memset’:
./include/linux/fortify-string.h:201:24: warning: infinite recursion
detected [-Winfinite-recursion]
  201 | __FORTIFY_INLINE void *memset(void *p, int c, __kernel_size_t size)
  |^~
./include/linux/fortify-string.h:43:33: note: recursive call
   43 | #define __underlying_memset __builtin_memset
  | ^
./include/linux/fortify-string.h:209:16: note: in expansion of macro
‘__underlying_memset’
  209 | return __underlying_memset(p, c, size);
  |^~~

The resulting module still works fine btw, afaict.

Marc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Tue, Jan 18, 2022 at 10:23:07AM +0100, Dan Horák wrote:
> > The -mabi=ieeelongdouble defaulting gcc is now in the
> > f36-build-side-49600 side-tag (gcc -0.5.1.fc36, same as -0.5.fc36 in
> > rawhide except for the different ppc64le default ABI).
> 
> is it right, that the attribute appears only in static libs? I did a
> scratch build for glib2
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=81396901) and
> "readelf -A libglib-2.0.so.0.7100.0" shows nothing,
> but "readelf -A libglib-2.0.a" returns "Tag_GNU_Power_ABI_FP: hard
> float, 128-bit IEEE long double" for some *.o files in the archive.

Strange.  In my test (admittedly not on rawhide but on f34) show that
all of *.o files, executables and shared libraries get the attribute
if long double is used and -mno-gnu-attributes isn't used.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Tue, Jan 18, 2022 at 12:38:26PM +0100, Iñaki Ucar wrote:
> On Mon, 17 Jan 2022 at 15:53, Iñaki Ucar  wrote:
> >
> > FlexiBLAS is FTBFS in rawhide [1], and upstream has managed to create a MWE 
> > that doesn't involve FlexiBLAS [2]. So it seems like an issue specific to 
> > CMake + GCC/GFortran 12 + CMake's FortranC Interface. Possible regression 
> > in gcc?
> >
> > [1] https://koschei.fedoraproject.org/package/flexiblas?collection=f36
> > [2] https://github.com/mpimd-csc/flexiblas/issues/20#issuecomment-1014597590
> 
> I found this is due to the LTO flags in FFLAGS, but this error doesn't
> happen with gcc 11. Should I disable LTO in FlexiBLAS for the time
> being?

I have no idea, the "MWE" above is far from minimal, there are no
sources that the compiler compiles, the cmake in there hides everything...

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Iñaki Ucar]

On Mon, 17 Jan 2022 at 15:53, Iñaki Ucar  wrote:
>
> FlexiBLAS is FTBFS in rawhide [1], and upstream has managed to create a MWE 
> that doesn't involve FlexiBLAS [2]. So it seems like an issue specific to 
> CMake + GCC/GFortran 12 + CMake's FortranC Interface. Possible regression in 
> gcc?
>
> Iñaki
>
> [1] https://koschei.fedoraproject.org/package/flexiblas?collection=f36
> [2] https://github.com/mpimd-csc/flexiblas/issues/20#issuecomment-1014597590

I found this is due to the LTO flags in FFLAGS, but this error doesn't
happen with gcc 11. Should I disable LTO in FlexiBLAS for the time
being?

Iñaki


> On Fri, 14 Jan 2022 at 15:40, Jakub Jelinek  wrote:
>>
>> Hi!
>>
>> gcc 12 snapshot has landed as the system compiler into rawhide today.
>> GCC 12 is going to enter its stage4 development phase (only regression
>> and documentation bugfixes allowed) on Monday 17th, so there should be
>> just those bugfixes and not new features etc. anymore.
>> https://gcc.gnu.org/gcc-12/changes.html lists important changes,
>> most important is probably that vectorization is enabled at -O2 now
>> which is the option with most of the distribution is built with.
>>
>> https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
>> some cases where people need to adjust their code.  Other things
>> include the usual C++ header changes, where previously some standard
>> header included some other header as an implementation detail but it doesn't
>> any longer and so code that relied on such indirect include that isn't
>> required by the standard needs to include the header that provides whatever
>> it relies on.  Or e.g. packages using -Werror where new warnings are
>> reported with the newer compiler and -Werror results in build failures.
>>
>> If there are bugs on the compiler side, please let me know immediately,
>> so that those bugs can be fixed before the mass rebuild next week.
>>
>> Another important thing I wanted to say is that we'd like to switch
>> ppc64le from the numerically problematic IBM extended long double to
>> IEEE 754 quad long double.  This is an ABI change.  Some libraries
>> are already built so that they support both ABIs at the same time,
>> including glibc, libstdc++, libgcc, libgfortran etc.
>> For other libraries and binaries, the compiler, assembler and linker
>> will notice if they use long double and flag them as using either
>> IBM or IEEE long double and linker (or I think dynamic linker too)
>> might complain when things are mixed.
>> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
>> but the glibc/gcc libraries are built compatibly with both.
>> We'd like to configure gcc shortly before the mass rebuild with
>> --with-long-double-format=ieee so that it will default to
>> -mabi=ieeelongdouble, probably on a side-tag build first, and it
>> will be highly desirable to rebuild at least some of the most commonly
>> used library packages in the order of dependencies there, otherwise
>> I'd be afraid the mass rebuild could fail for way too many packages
>> (as the mass rebuild doesn't do dependency order rebuilds but just
>> goes through packages alphabetically or so).
>> Any suggestions on which packages have commonly used library packages
>> that use long double?
>> readelf -A on libraries on ppc64le prints either nothing (either
>> the library is thought not to use long double or supports both ABIs
>> transparently or hasn't been rebuilt for some years), or
>> Attribute Section: gnu
>> File Attributes
>>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
>> for libraries (or binaries or object files) that use IBM long double
>> only or
>> Attribute Section: gnu
>> File Attributes
>>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
>> for IEEE long doubles.
>> So I think we want to rebuild on a side-tag packages that
>> provide shared libraries used by hundreds of other packages that
>> are
>>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
>> right now.
>>
>> Jakub
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam on the list, report it: 
>> https://pagure.io/fedora-infrastructure
>
>
>
> --
> Iñaki Úcar



-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Tue, 18 Jan 2022 at 11:07, Jonathan Wakely  wrote:

>
>
> On Tue, 18 Jan 2022 at 11:04, Jonathan Wakely  wrote:
>
>>
>>
>> On Tue, 18 Jan 2022 at 10:29, Frantisek Zatloukal 
>> wrote:
>>
>>>
>>>
>>> On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek  wrote:
>>>
 If there are bugs on the compiler side, please let me know immediately,
 so that those bugs can be fixed before the mass rebuild next week.

>>>
>>> While I was trying to rebuild some Intel components, i've encountered
>>> this issue, which seems to be caused by libstdc. It affects
>>> intel-graphics-compiler (not yet in Fedora). That is compiled with clang,
>>> however, since gcc/libstdc 12, I am hitting this:
>>>
>>> /builddir/build/BUILD/intel-graphics-compiler-igc-1.0.9933/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp:590:46:
>>> error: call to constructor of 'LiveRangeMap_t::value_type' (aka 'pair>> llvm::genx::SimpleValue, llvm::genx::LiveRange *>') is ambiguous
>>>   auto [i, isInserted] =
>>> LiveRangeMap.insert(LiveRangeMap_t::value_type(V, 0));
>>>  ^
>>>  
>>> /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:425:17:
>>> note: candidate constructor [with _U1 = const llvm::genx::SimpleValue, _U2
>>> = llvm::genx::LiveRange *, $2 = true]
>>>   constexpr pair(const _T1& __a, const _T2& __b)
>>> ^
>>> /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:492:18:
>>> note: candidate constructor [with _U1 = llvm::genx::SimpleValue &, $1 =
>>> true]
>>>constexpr pair(_U1&& __x, __null_ptr_constant)
>>>  ^
>>> 1 error generated.
>>>
>>> I've tried to locally recompile clang and llvm against the new libstdc
>>> (as it seems ambiguousness is caused by #if _GLIBCXX_USE_DEPRECATED being
>>> met), but that didn't help. Maybe I am missing some library that needs to
>>> be recompiled too. Anyhow, is this expected behavior?
>>>
>>> The affected file is this one:
>>> https://github.com/intel/intel-graphics-compiler/blob/master/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp
>>>
>>
>>
>> I think the code is just wrong, and should use nullptr instead of 0 in
>> that initializer on line 590.
>>
>
> Even better would be to stop creating the unnecessary temporary:
>
> auto [i, isInserted] = LiveRangeMap.emplace(V, nullptr);
>

PR sent:
https://github.com/intel/intel-graphics-compiler/pull/226



>
>
>
>>
>> It's related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101124
>> though. I tried to keep that old incorrect code working, but apparently
>> failed.
>>
>>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Tue, 18 Jan 2022 at 11:04, Jonathan Wakely  wrote:

>
>
> On Tue, 18 Jan 2022 at 10:29, Frantisek Zatloukal 
> wrote:
>
>>
>>
>> On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek  wrote:
>>
>>> If there are bugs on the compiler side, please let me know immediately,
>>> so that those bugs can be fixed before the mass rebuild next week.
>>>
>>
>> While I was trying to rebuild some Intel components, i've encountered
>> this issue, which seems to be caused by libstdc. It affects
>> intel-graphics-compiler (not yet in Fedora). That is compiled with clang,
>> however, since gcc/libstdc 12, I am hitting this:
>>
>> /builddir/build/BUILD/intel-graphics-compiler-igc-1.0.9933/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp:590:46:
>> error: call to constructor of 'LiveRangeMap_t::value_type' (aka 'pair> llvm::genx::SimpleValue, llvm::genx::LiveRange *>') is ambiguous
>>   auto [i, isInserted] =
>> LiveRangeMap.insert(LiveRangeMap_t::value_type(V, 0));
>>  ^
>>  
>> /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:425:17:
>> note: candidate constructor [with _U1 = const llvm::genx::SimpleValue, _U2
>> = llvm::genx::LiveRange *, $2 = true]
>>   constexpr pair(const _T1& __a, const _T2& __b)
>> ^
>> /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:492:18:
>> note: candidate constructor [with _U1 = llvm::genx::SimpleValue &, $1 =
>> true]
>>constexpr pair(_U1&& __x, __null_ptr_constant)
>>  ^
>> 1 error generated.
>>
>> I've tried to locally recompile clang and llvm against the new libstdc
>> (as it seems ambiguousness is caused by #if _GLIBCXX_USE_DEPRECATED being
>> met), but that didn't help. Maybe I am missing some library that needs to
>> be recompiled too. Anyhow, is this expected behavior?
>>
>> The affected file is this one:
>> https://github.com/intel/intel-graphics-compiler/blob/master/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp
>>
>
>
> I think the code is just wrong, and should use nullptr instead of 0 in
> that initializer on line 590.
>

Even better would be to stop creating the unnecessary temporary:

auto [i, isInserted] = LiveRangeMap.emplace(V, nullptr);




>
> It's related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101124
> though. I tried to keep that old incorrect code working, but apparently
> failed.
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Tue, 18 Jan 2022 at 10:29, Frantisek Zatloukal 
wrote:

>
>
> On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek  wrote:
>
>> If there are bugs on the compiler side, please let me know immediately,
>> so that those bugs can be fixed before the mass rebuild next week.
>>
>
> While I was trying to rebuild some Intel components, i've encountered this
> issue, which seems to be caused by libstdc. It affects
> intel-graphics-compiler (not yet in Fedora). That is compiled with clang,
> however, since gcc/libstdc 12, I am hitting this:
>
> /builddir/build/BUILD/intel-graphics-compiler-igc-1.0.9933/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp:590:46:
> error: call to constructor of 'LiveRangeMap_t::value_type' (aka 'pair llvm::genx::SimpleValue, llvm::genx::LiveRange *>') is ambiguous
>   auto [i, isInserted] = LiveRangeMap.insert(LiveRangeMap_t::value_type(V,
> 0));
>  ^
>  
> /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:425:17:
> note: candidate constructor [with _U1 = const llvm::genx::SimpleValue, _U2
> = llvm::genx::LiveRange *, $2 = true]
>   constexpr pair(const _T1& __a, const _T2& __b)
> ^
> /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:492:18:
> note: candidate constructor [with _U1 = llvm::genx::SimpleValue &, $1 =
> true]
>constexpr pair(_U1&& __x, __null_ptr_constant)
>  ^
> 1 error generated.
>
> I've tried to locally recompile clang and llvm against the new libstdc (as
> it seems ambiguousness is caused by #if _GLIBCXX_USE_DEPRECATED being met),
> but that didn't help. Maybe I am missing some library that needs to be
> recompiled too. Anyhow, is this expected behavior?
>
> The affected file is this one:
> https://github.com/intel/intel-graphics-compiler/blob/master/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp
>


I think the code is just wrong, and should use nullptr instead of 0 in that
initializer on line 590.

It's related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101124 though.
I tried to keep that old incorrect code working, but apparently failed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Mon, 17 Jan 2022 at 14:01, Ben Beasley  wrote:

> Skimming through Koschei, here are a sampling of regressions that seem
> to be associated with GCC 12. Some of these are in packages I maintain
> directly; others are via @neuro-sig.
>
> With a few exceptions, I have triaged these only to the extent of
> confirming the problem appeared at the same time as GCC 12 and noting
> the initial error. I mostly haven’t gotten around to filing or searching
> for bugs, upstream or downstream.
>
> Explicit deletion of the
> std::string(nullptr_t)/std::string_view(nullptr_t) constructors seems
> like it is going to be a popular cause of FTBFS in C++ packages. Use of
> this constructor mostly happens implicitly. I think explicit use of the
> default constructor, e.g. std::string_view(), will usually be the
> simplest correct substitute.
>

All such uses were undefined behaviour (and should have thrown an exception
at runtime if the code was ever executed. Fixing those is good.


> New compilation errors:
>
> COPASI: “error: passing 'const CDataVectorN' as 'this'
> argument discards qualifiers [-fpermissive]”
>

What's the context? Is that being used as a comparison function in a std::
container or something?


>
> grpc: initializing std::string_view/absl::string_view with nullptr –
> fixed and PR sent upstream
>
> python-steps: “static assertion failed: key equality predicate must be
> invocable with two arguments of key type” via
> c++/12/bits/hashtable_policy.h
>

Maybe a variant of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923



>
> vxl: “error: conversion from 'int' to 'std::__cxx11::basic_string'
> is ambiguous” – looks like an attempt to initialize a string by
> std::string(nullptr), which is now explicitly deleted
> (“basic_string(nullptr_t) = delete”)
>

If it's actually initializing it with nullptr, that's just undefined (and
going to be ill-formed in C++23) and the code should be fixed.

If it's like the nlohmann:json case, I need to investigate more whether
it's a defect in the C++23 spec or the code should be fixed.




>
> On 1/14/22 09:31, Jakub Jelinek wrote:
> > Hi!
> >
> > gcc 12 snapshot has landed as the system compiler into rawhide today.
> > GCC 12 is going to enter its stage4 development phase (only regression
> > and documentation bugfixes allowed) on Monday 17th, so there should be
> > just those bugfixes and not new features etc. anymore.
> > https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> > most important is probably that vectorization is enabled at -O2 now
> > which is the option with most of the distribution is built with.
> >
> > https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and
> lists
> > some cases where people need to adjust their code.  Other things
> > include the usual C++ header changes, where previously some standard
> > header included some other header as an implementation detail but it
> doesn't
> > any longer and so code that relied on such indirect include that isn't
> > required by the standard needs to include the header that provides
> whatever
> > it relies on.  Or e.g. packages using -Werror where new warnings are
> > reported with the newer compiler and -Werror results in build failures.
> >
> > If there are bugs on the compiler side, please let me know immediately,
> > so that those bugs can be fixed before the mass rebuild next week.
> >
> > Another important thing I wanted to say is that we'd like to switch
> > ppc64le from the numerically problematic IBM extended long double to
> > IEEE 754 quad long double.  This is an ABI change.  Some libraries
> > are already built so that they support both ABIs at the same time,
> > including glibc, libstdc++, libgcc, libgfortran etc.
> > For other libraries and binaries, the compiler, assembler and linker
> > will notice if they use long double and flag them as using either
> > IBM or IEEE long double and linker (or I think dynamic linker too)
> > might complain when things are mixed.
> > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> > but the glibc/gcc libraries are built compatibly with both.
> > We'd like to configure gcc shortly before the mass rebuild with
> > --with-long-double-format=ieee so that it will default to
> > -mabi=ieeelongdouble, probably on a side-tag build first, and it
> > will be highly desirable to rebuild at least some of the most commonly
> > used library packages in the order of dependencies there, otherwise
> > I'd be afraid the mass rebuild could fail for way too many packages
> > (as the mass rebuild doesn't do dependency order rebuilds but just
> > goes through packages alphabetically or so).
> > Any suggestions on which packages have commonly used library packages
> > that use long double?
> > readelf -A on libraries on ppc64le prints either nothing (either
> > the library is thought not to use long double or supports both ABIs
> > transparently or hasn't been rebuilt for some years), or
> > Attribute Section: gnu
> > File 

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Frantisek Zatloukal]

On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek  wrote:

> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.
>

While I was trying to rebuild some Intel components, i've encountered this
issue, which seems to be caused by libstdc. It affects
intel-graphics-compiler (not yet in Fedora). That is compiled with clang,
however, since gcc/libstdc 12, I am hitting this:

/builddir/build/BUILD/intel-graphics-compiler-igc-1.0.9933/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp:590:46:
error: call to constructor of 'LiveRangeMap_t::value_type' (aka 'pair') is ambiguous
  auto [i, isInserted] = LiveRangeMap.insert(LiveRangeMap_t::value_type(V,
0));
 ^  
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:425:17:
note: candidate constructor [with _U1 = const llvm::genx::SimpleValue, _U2
= llvm::genx::LiveRange *, $2 = true]
  constexpr pair(const _T1& __a, const _T2& __b)
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:492:18:
note: candidate constructor [with _U1 = llvm::genx::SimpleValue &, $1 =
true]
   constexpr pair(_U1&& __x, __null_ptr_constant)
 ^
1 error generated.

I've tried to locally recompile clang and llvm against the new libstdc (as
it seems ambiguousness is caused by #if _GLIBCXX_USE_DEPRECATED being met),
but that didn't help. Maybe I am missing some library that needs to be
recompiled too. Anyhow, is this expected behavior?

The affected file is this one:
https://github.com/intel/intel-graphics-compiler/blob/master/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp

-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Dan Horák]

On Sun, 16 Jan 2022 19:27:44 +0100
Jakub Jelinek  wrote:

> On Fri, Jan 14, 2022 at 04:07:08PM +0100, Dan Horák wrote:
> > > Another important thing I wanted to say is that we'd like to switch
> > > ppc64le from the numerically problematic IBM extended long double to
> > > IEEE 754 quad long double.  This is an ABI change.  Some libraries
> > > are already built so that they support both ABIs at the same time,
> > > including glibc, libstdc++, libgcc, libgfortran etc.
> > > For other libraries and binaries, the compiler, assembler and linker
> > > will notice if they use long double and flag them as using either
> > > IBM or IEEE long double and linker (or I think dynamic linker too)
> > > might complain when things are mixed.
> > > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> > > but the glibc/gcc libraries are built compatibly with both.
> > > We'd like to configure gcc shortly before the mass rebuild with
> > > --with-long-double-format=ieee so that it will default to
> > > -mabi=ieeelongdouble, probably on a side-tag build first, and it
> > > will be highly desirable to rebuild at least some of the most commonly
> > > used library packages in the order of dependencies there, otherwise
> > > I'd be afraid the mass rebuild could fail for way too many packages
> > > (as the mass rebuild doesn't do dependency order rebuilds but just
> > > goes through packages alphabetically or so).
> > > Any suggestions on which packages have commonly used library packages
> > > that use long double?
> > > readelf -A on libraries on ppc64le prints either nothing (either
> > > the library is thought not to use long double or supports both ABIs
> > > transparently or hasn't been rebuilt for some years), or
> > > Attribute Section: gnu
> > > File Attributes
> > >   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> > > for libraries (or binaries or object files) that use IBM long double
> > > only or
> > > Attribute Section: gnu
> > > File Attributes
> > >   Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
> > > for IEEE long doubles.
> > > So I think we want to rebuild on a side-tag packages that
> > > provide shared libraries used by hundreds of other packages that
> > > are
> > >   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> > > right now.
> > 
> > a quick scan of /usr/lib64 on my F-34 workstation shows
> > many ./libQt5*
> > many ./libLLVM*
> > ./libgobject-2.0
> > ./libgio-2.0
> > ./libglib-2.0
> > ./libexiv2-xmp
> > ./libhwy
> > ./python3.9/site-packages/numpy/*
> > ./libSDL2
> > ./libiberty
> > ./clang/12.0.1/lib/libclang_rt.builtins-powerpc64le.a
> > ./ghdl/llvm/libgrt.a
> > ./libc
> > 
> > as users of the Tag_GNU_Power_ABI_FP attribute. A vast majority of the
> > hits are "Tag_GNU_Power_ABI_FP: hard float, unspecified long double"
> > 
> > Translated to packages it is qt5-*, llvm + clang, numpy, SDL2, glib2,
> > exiv2, glibc, highway
> 
> The -mabi=ieeelongdouble defaulting gcc is now in the
> f36-build-side-49600 side-tag (gcc -0.5.1.fc36, same as -0.5.fc36 in
> rawhide except for the different ppc64le default ABI).

is it right, that the attribute appears only in static libs? I did a
scratch build for glib2
(https://koji.fedoraproject.org/koji/taskinfo?taskID=81396901) and
"readelf -A libglib-2.0.so.0.7100.0" shows nothing,
but "readelf -A libglib-2.0.a" returns "Tag_GNU_Power_ABI_FP: hard
float, 128-bit IEEE long double" for some *.o files in the archive.


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Björn Persson]

Jakub Jelinek wrote:
> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.

Certain Ada source files trigger what looks like infinite tail
recursion in add_sibling_attributes in dwarf2out.c:

https://bugzilla.redhat.com/show_bug.cgi?id=2041667

Björn Persson


pgpaayNBpxRq6.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Mon, Jan 17, 2022 at 01:37:08PM -0600, Justin Forbes wrote:
> > For kernel, the only bug on the GCC side I'm aware of is
> > https://gcc.gnu.org/PR101941
> 
> We are seeing similar issues in a few different files depending on
> arch.  Largely due to options compiled in and compile order, nothing
> particularly arch specific.  All of the failures are with
> fortify_string, some are read beyond size of object.  Some are write
> beyond size of object.  Some are directive output may be truncated.
> These kernels all build fine against f35 and stable fedora kernels
> fail against rawhide, so it is definitely the toolchain changes, and
> not limited to bad code brought in through the 5.17 merge window.  A
> good sampling of the errors can be seen in the build log for
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81369256 with most
> arches failing in different places.

All I've looked at (besides PR101941) was
check.c:2836:58: error: '%d' directive output may be truncated writing between 
1 and 10 bytes into a region of size 9 [-Werror=format-truncation=]
which boils down to roughly:
char a[16];
void f (int x, int y)
{
  int idx;
  if (y)
{
  idx = x / sizeof (void *);
  snprintf (a, sizeof a, "pv_ops[%d]", idx);
}
}
where the warning doesn't seem to be a false positive,
though perhaps it would need to be a very large module.
pv_ops[-268435456] is the longest string for lp64 and
pv_ops[-536870912] for ilp32, but even when not negative,
pv_ops[536870911] is 18 bytes including zero termination, not 16.
If you have other warnings and they seem to be false positives, please
send them to Martin Sebor.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Justin Forbes]

On Mon, Jan 17, 2022 at 12:32 PM Jakub Jelinek  wrote:
>
> On Mon, Jan 17, 2022 at 12:27:15PM -0600, Justin Forbes wrote:
> > > gcc 12 snapshot has landed as the system compiler into rawhide today.
> > > GCC 12 is going to enter its stage4 development phase (only regression
> > > and documentation bugfixes allowed) on Monday 17th, so there should be
> > > just those bugfixes and not new features etc. anymore.
> > > https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> > > most important is probably that vectorization is enabled at -O2 now
> > > which is the option with most of the distribution is built with.
> > >
> > > https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> > > some cases where people need to adjust their code.  Other things
> > > include the usual C++ header changes, where previously some standard
> > > header included some other header as an implementation detail but it 
> > > doesn't
> > > any longer and so code that relied on such indirect include that isn't
> > > required by the standard needs to include the header that provides 
> > > whatever
> > > it relies on.  Or e.g. packages using -Werror where new warnings are
> > > reported with the newer compiler and -Werror results in build failures.
> > >
> > > If there are bugs on the compiler side, please let me know immediately,
> > > so that those bugs can be fixed before the mass rebuild next week.
> > >
> >
> > I suppose I should have checked fedora-devel before trying to chase
> > down build failures as kernel merge window issues.  Kernel builds are
> > failing in a few places (depending on arch).
>
> For kernel, the only bug on the GCC side I'm aware of is
> https://gcc.gnu.org/PR101941

We are seeing similar issues in a few different files depending on
arch.  Largely due to options compiled in and compile order, nothing
particularly arch specific.  All of the failures are with
fortify_string, some are read beyond size of object.  Some are write
beyond size of object.  Some are directive output may be truncated.
These kernels all build fine against f35 and stable fedora kernels
fail against rawhide, so it is definitely the toolchain changes, and
not limited to bad code brought in through the 5.17 merge window.  A
good sampling of the errors can be seen in the build log for
https://koji.fedoraproject.org/koji/taskinfo?taskID=81369256 with most
arches failing in different places.

Justin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Mon, Jan 17, 2022 at 12:27:15PM -0600, Justin Forbes wrote:
> > gcc 12 snapshot has landed as the system compiler into rawhide today.
> > GCC 12 is going to enter its stage4 development phase (only regression
> > and documentation bugfixes allowed) on Monday 17th, so there should be
> > just those bugfixes and not new features etc. anymore.
> > https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> > most important is probably that vectorization is enabled at -O2 now
> > which is the option with most of the distribution is built with.
> >
> > https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> > some cases where people need to adjust their code.  Other things
> > include the usual C++ header changes, where previously some standard
> > header included some other header as an implementation detail but it doesn't
> > any longer and so code that relied on such indirect include that isn't
> > required by the standard needs to include the header that provides whatever
> > it relies on.  Or e.g. packages using -Werror where new warnings are
> > reported with the newer compiler and -Werror results in build failures.
> >
> > If there are bugs on the compiler side, please let me know immediately,
> > so that those bugs can be fixed before the mass rebuild next week.
> >
> 
> I suppose I should have checked fedora-devel before trying to chase
> down build failures as kernel merge window issues.  Kernel builds are
> failing in a few places (depending on arch).

For kernel, the only bug on the GCC side I'm aware of is
https://gcc.gnu.org/PR101941

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Justin Forbes]

On Fri, Jan 14, 2022 at 8:32 AM Jakub Jelinek  wrote:
>
> Hi!
>
> gcc 12 snapshot has landed as the system compiler into rawhide today.
> GCC 12 is going to enter its stage4 development phase (only regression
> and documentation bugfixes allowed) on Monday 17th, so there should be
> just those bugfixes and not new features etc. anymore.
> https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> most important is probably that vectorization is enabled at -O2 now
> which is the option with most of the distribution is built with.
>
> https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> some cases where people need to adjust their code.  Other things
> include the usual C++ header changes, where previously some standard
> header included some other header as an implementation detail but it doesn't
> any longer and so code that relied on such indirect include that isn't
> required by the standard needs to include the header that provides whatever
> it relies on.  Or e.g. packages using -Werror where new warnings are
> reported with the newer compiler and -Werror results in build failures.
>
> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.
>

I suppose I should have checked fedora-devel before trying to chase
down build failures as kernel merge window issues.  Kernel builds are
failing in a few places (depending on arch).

Justin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Mon, Jan 17, 2022 at 02:59:15PM -, Artur Frenszek-Iwicki wrote:
> I tried compiling colobot with the new gcc, expecting it to break in some
> new and fascinating way, and got the following error:
> 
> In function 'std::char_traits::copy(char*, char const*, unsigned long)',
> inlined from 'std::__cxx11::basic_string, 
> std::allocator >::_S_copy(char*, char const*, unsigned long)' at 
> /usr/include/c++/12/bits/basic_string.h:423:21,
> inlined from 'std::__cxx11::basic_string, 
> std::allocator >::_S_copy(char*, char const*, unsigned long)' at 
> /usr/include/c++/12/bits/basic_string.h:418:7,
> inlined from 'std::__cxx11::basic_string, 
> std::allocator >::_M_replace(unsigned long, unsigned long, char const*, 
> unsigned long)' at /usr/include/c++/12/bits/basic_string.tcc:532:22,
> inlined from 'std::__cxx11::basic_string, 
> std::allocator >::assign(char const*)' at 
> /usr/include/c++/12/bits/basic_string.h:1645:19,
> inlined from 'std::__cxx11::basic_string, 
> std::allocator >::operator=(char const*)' at 
> /usr/include/c++/12/bits/basic_string.h:813:28,
> inlined from 'Ui::CList::SetItemName(int, 
> std::__cxx11::basic_string, std::allocator 
> > const&)' at 
> /builddir/build/BUILD/colobot-colobot-gold-0.2.0-alpha/src/ui/controls/list.cpp:664:28:
> /usr/include/c++/12/bits/char_traits.h:431:56: error: 'memcpy' accessing 
> 9223372036854775810 or more bytes at offsets -4611686018427387902 and 
> [-4611686018427387903, 4611686018427387904] may overlap up to 
> 9223372036854775813 bytes at offset -3 [-Werror=restrict]
>   431 | return static_cast(__builtin_memcpy(__s1, __s2, 
> __n));
>   |
> ^
> 
> The relevant bit of code is this line:
> m_items[i].text =  " ";
> Where the ".text" struct member is an std::string.
> 
> Any suggestions on how to fix this will be appreciated.

Please send me preprocessed source + g++ command line, provided the warning
is reproduceable without -flto.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Sun, Jan 16, 2022 at 01:18:51PM -0500, Kaleb Keithley wrote:
> Ceph fails with gcc-12 too.
> 
> scratch build at
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81280838
> 
> upstream ceph bug at https://tracker.ceph.com/issues/53896

That looks like a ceph bug.
C++ says std::unique_ptr is defined in , and while
that TU includes , it includes it only after
src/include/rados/buffer.h has on line 97+
template 
struct unique_leakable_ptr : public std::unique_ptr> {
  using std::unique_ptr>::unique_ptr;
};

Most likely with earlier g++ releases you got  or parts of
it indirectly from some other header.
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
are the standard C++ headers that are included before the std::unique_ptr
use in the source, looking at g++ 10 output seems that  included
bits/unique_ptr as implementation detail.
https://gcc.gnu.org/r12-2696 removed that implementation detail.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Artur Frenszek-Iwicki]

I tried compiling colobot with the new gcc, expecting it to break in some
new and fascinating way, and got the following error:

In function 'std::char_traits::copy(char*, char const*, unsigned long)',
inlined from 'std::__cxx11::basic_string, 
std::allocator >::_S_copy(char*, char const*, unsigned long)' at 
/usr/include/c++/12/bits/basic_string.h:423:21,
inlined from 'std::__cxx11::basic_string, 
std::allocator >::_S_copy(char*, char const*, unsigned long)' at 
/usr/include/c++/12/bits/basic_string.h:418:7,
inlined from 'std::__cxx11::basic_string, 
std::allocator >::_M_replace(unsigned long, unsigned long, char const*, 
unsigned long)' at /usr/include/c++/12/bits/basic_string.tcc:532:22,
inlined from 'std::__cxx11::basic_string, 
std::allocator >::assign(char const*)' at 
/usr/include/c++/12/bits/basic_string.h:1645:19,
inlined from 'std::__cxx11::basic_string, 
std::allocator >::operator=(char const*)' at 
/usr/include/c++/12/bits/basic_string.h:813:28,
inlined from 'Ui::CList::SetItemName(int, std::__cxx11::basic_string, std::allocator > const&)' at 
/builddir/build/BUILD/colobot-colobot-gold-0.2.0-alpha/src/ui/controls/list.cpp:664:28:
/usr/include/c++/12/bits/char_traits.h:431:56: error: 'memcpy' accessing 
9223372036854775810 or more bytes at offsets -4611686018427387902 and 
[-4611686018427387903, 4611686018427387904] may overlap up to 
9223372036854775813 bytes at offset -3 [-Werror=restrict]
  431 | return static_cast(__builtin_memcpy(__s1, __s2, 
__n));
  |^

The relevant bit of code is this line:
m_items[i].text =  " ";
Where the ".text" struct member is an std::string.

Any suggestions on how to fix this will be appreciated.

Thanks in advance,
A.FI.

colobot scm: https://src.fedoraproject.org/rpms/colobot/
colobot upstream: https://github.com/colobot/colobot/
koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=81361550
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Iñaki Ucar]

FlexiBLAS is FTBFS in rawhide [1], and upstream has managed to create a MWE
that doesn't involve FlexiBLAS [2]. So it seems like an issue specific to CMake
+ GCC/GFortran 12 + CMake's FortranC Interface. Possible regression in gcc?

Iñaki

[1] https://koschei.fedoraproject.org/package/flexiblas?collection=f36
[2] https://github.com/mpimd-csc/flexiblas/issues/20#issuecomment-1014597590

On Fri, 14 Jan 2022 at 15:40, Jakub Jelinek  wrote:

> Hi!
>
> gcc 12 snapshot has landed as the system compiler into rawhide today.
> GCC 12 is going to enter its stage4 development phase (only regression
> and documentation bugfixes allowed) on Monday 17th, so there should be
> just those bugfixes and not new features etc. anymore.
> https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> most important is probably that vectorization is enabled at -O2 now
> which is the option with most of the distribution is built with.
>
> https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> some cases where people need to adjust their code.  Other things
> include the usual C++ header changes, where previously some standard
> header included some other header as an implementation detail but it
> doesn't
> any longer and so code that relied on such indirect include that isn't
> required by the standard needs to include the header that provides whatever
> it relies on.  Or e.g. packages using -Werror where new warnings are
> reported with the newer compiler and -Werror results in build failures.
>
> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.
>
> Another important thing I wanted to say is that we'd like to switch
> ppc64le from the numerically problematic IBM extended long double to
> IEEE 754 quad long double.  This is an ABI change.  Some libraries
> are already built so that they support both ABIs at the same time,
> including glibc, libstdc++, libgcc, libgfortran etc.
> For other libraries and binaries, the compiler, assembler and linker
> will notice if they use long double and flag them as using either
> IBM or IEEE long double and linker (or I think dynamic linker too)
> might complain when things are mixed.
> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> but the glibc/gcc libraries are built compatibly with both.
> We'd like to configure gcc shortly before the mass rebuild with
> --with-long-double-format=ieee so that it will default to
> -mabi=ieeelongdouble, probably on a side-tag build first, and it
> will be highly desirable to rebuild at least some of the most commonly
> used library packages in the order of dependencies there, otherwise
> I'd be afraid the mass rebuild could fail for way too many packages
> (as the mass rebuild doesn't do dependency order rebuilds but just
> goes through packages alphabetically or so).
> Any suggestions on which packages have commonly used library packages
> that use long double?
> readelf -A on libraries on ppc64le prints either nothing (either
> the library is thought not to use long double or supports both ABIs
> transparently or hasn't been rebuilt for some years), or
> Attribute Section: gnu
> File Attributes
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> for libraries (or binaries or object files) that use IBM long double
> only or
> Attribute Section: gnu
> File Attributes
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
> for IEEE long doubles.
> So I think we want to rebuild on a side-tag packages that
> provide shared libraries used by hundreds of other packages that
> are
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> right now.
>
> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Sérgio Basto]

On Mon, 2022-01-17 at 15:10 +0100, Vitaly Zaitsev via devel wrote:
> On 17/01/2022 15:00, Ben Beasley wrote:
> > dependency “json”: https://github.com/nlohmann/json/issues/3138
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2041187
> 

Rawhide compose doomed again [1] :( , I still haven't the results of 
koschei opencv altivec build with gcc-12.0.0-0.5, it failed with gcc-
12.0.0-0.4 [2] 


[2]
https://koschei.fedoraproject.org/package/opencv?collection=f36

[1]
https://kojipkgs.fedoraproject.org/compose/rawhide/


-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Vitaly Zaitsev via devel]

On 17/01/2022 15:00, Ben Beasley wrote:

dependency “json”: https://github.com/nlohmann/json/issues/3138


https://bugzilla.redhat.com/show_bug.cgi?id=2041187

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Paolo Bonzini]

On 1/17/22 12:32, Jakub Jelinek wrote:

Perhaps Paolo Bonzini is familiar with both qemu and gcc...


/me waves hands.  This is now https://gcc.gnu.org/PR104067.

Paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Ben Beasley]

Skimming through Koschei, here are a sampling of regressions that seem 
to be associated with GCC 12. Some of these are in packages I maintain 
directly; others are via @neuro-sig.


With a few exceptions, I have triaged these only to the extent of 
confirming the problem appeared at the same time as GCC 12 and noting 
the initial error. I mostly haven’t gotten around to filing or searching 
for bugs, upstream or downstream.


Explicit deletion of the 
std::string(nullptr_t)/std::string_view(nullptr_t) constructors seems 
like it is going to be a popular cause of FTBFS in C++ packages. Use of 
this constructor mostly happens implicitly. I think explicit use of the 
default constructor, e.g. std::string_view(), will usually be the 
simplest correct substitute.


Problems in popular dependencies (boost, json, opencv) are also 
impacting a lot of packages.



**Internal compiler or debugger error:**

abseil-cpp: “internal compiler error: tree code 'template_type_parm' is 
not supported in LTO streams”


debugbreak: %check uses gdb, which now crashes (“(core dumped) gdb -q -x 
"${exe}-rpm-test.gdb" --batch < /dev/null”) on ppc64le/x86_64, but not 
on aarch64



**Compilation error from a dependency header:**

dependency “boost”: “# error "Never use  directly; include 
 instead."”, via 
boost/multiprecision/cpp_int/intel_intrinsics.hpp


    octave-iso2mesh

dependency “boost”: “error: use of deleted function 
'std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(std::nullptr_t)” via 
boost/graph/bellman_ford_shortest_paths.hpp


    python-graph-tool

dependency “json”: https://github.com/nlohmann/json/issues/3138

    dicomanonymizer

    giada

dependency “opencv”: “invalid parameter combination for AltiVec 
intrinsic '__builtin_vec_sldw'” on ppc64le, in 
opencv4/opencv2/core/vsx_utils.hpp


    fasttrack

    highfive


**New test failures:**

moose: “Error: SetGet::strGet: Field Vm not found on Element z”, 
multiple SIGABRT/SIGSEGV


mpir: “mpn_get_d wrong, didn't get 0.0 on underflow” on aarch64, ppc64le

python-numpoly: multiple results have dtype 'int64' where 'int32' is 
expected


sleef: https://github.com/shibatch/sleef/issues/439 – failing tests 
skipped for now



New compilation errors:

COPASI: “error: passing 'const CDataVectorN' as 'this' 
argument discards qualifiers [-fpermissive]”


grpc: initializing std::string_view/absl::string_view with nullptr – 
fixed and PR sent upstream


python-steps: “static assertion failed: key equality predicate must be 
invocable with two arguments of key type” via c++/12/bits/hashtable_policy.h


vxl: “error: conversion from 'int' to 'std::__cxx11::basic_string' 
is ambiguous” – looks like an attempt to initialize a string by 
std::string(nullptr), which is now explicitly deleted 
(“basic_string(nullptr_t) = delete”)



On 1/14/22 09:31, Jakub Jelinek wrote:

Hi!

gcc 12 snapshot has landed as the system compiler into rawhide today.
GCC 12 is going to enter its stage4 development phase (only regression
and documentation bugfixes allowed) on Monday 17th, so there should be
just those bugfixes and not new features etc. anymore.
https://gcc.gnu.org/gcc-12/changes.html lists important changes,
most important is probably that vectorization is enabled at -O2 now
which is the option with most of the distribution is built with.

https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
some cases where people need to adjust their code.  Other things
include the usual C++ header changes, where previously some standard
header included some other header as an implementation detail but it doesn't
any longer and so code that relied on such indirect include that isn't
required by the standard needs to include the header that provides whatever
it relies on.  Or e.g. packages using -Werror where new warnings are
reported with the newer compiler and -Werror results in build failures.

If there are bugs on the compiler side, please let me know immediately,
so that those bugs can be fixed before the mass rebuild next week.

Another important thing I wanted to say is that we'd like to switch
ppc64le from the numerically problematic IBM extended long double to
IEEE 754 quad long double.  This is an ABI change.  Some libraries
are already built so that they support both ABIs at the same time,
including glibc, libstdc++, libgcc, libgfortran etc.
For other libraries and binaries, the compiler, assembler and linker
will notice if they use long double and flag them as using either
IBM or IEEE long double and linker (or I think dynamic linker too)
might complain when things are mixed.
Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
but the glibc/gcc libraries are built compatibly with both.
We'd like to configure gcc shortly before the mass rebuild with
--with-long-double-format=ieee so that it will default to
-mabi=ieeelongdouble, probably on a side-tag build first, and it
will be highly desirable to rebuild at least some of the most 

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Caolán McNamara]

On Fri, 2022-01-14 at 15:31 +0100, Jakub Jelinek wrote:
> If there are bugs on the compiler side, please let me know
> immediately, so that those bugs can be fixed before the mass rebuild
> next week.

One of LibreOffice's import tests started to crash during rebuild with
gcc-12, sbergman filed a little reproducer as:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104007
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Richard W.M. Jones]

On Mon, Jan 17, 2022 at 12:32:36PM +0100, Jakub Jelinek wrote:
> On Sun, Jan 16, 2022 at 05:58:10PM +, Richard W.M. Jones wrote:
> > I tried recompiling qemu and it fails with an odd error in the RCU
> > torture test.  Bug submitted upstream here:
> > 
> > https://gitlab.com/qemu-project/qemu/-/issues/823
> > 
> > ... but since GCC 12 is the only big thing that has changed since we
> > just rebuilt qemu, could that be a reason?
> > 
> > https://gitlab.com/qemu-project/qemu/-/blob/1cd2ad11d37c48f284f557954e1df675b126264c/tests/unit/rcutorture.c#L320
> > 
> > Anyway I'll try to nudge someone on the virt team who knows about
> > these things to take a look.
> 
> Does -O0 help?  -flto vs. -fno-lto?  -fno-ipa-modref (gcc 12 is slightly
> more aggressive in the interprocedural TBAA)?
> If -O0 helps, can you find out if it is the test or something in a library or
> whatever that the test uses, and if the latter, try to bisect it to one *.o
> file?  If -O0 doesn't help, try to mix and match gcc 11 and gcc 12 built
> objects.  I know next to nothing about qemu, so it would help if somebody
> familiar with it did that.  Perhaps Paolo Bonzini is familiar with both
> qemu and gcc...
> Having just one preprocessed source + compiler command line and knowing
> roughly what to look for allows bisection and further analysis.

Partially answered here:

https://gitlab.com/qemu-project/qemu/-/issues/823

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Sun, Jan 16, 2022 at 05:58:10PM +, Richard W.M. Jones wrote:
> I tried recompiling qemu and it fails with an odd error in the RCU
> torture test.  Bug submitted upstream here:
> 
> https://gitlab.com/qemu-project/qemu/-/issues/823
> 
> ... but since GCC 12 is the only big thing that has changed since we
> just rebuilt qemu, could that be a reason?
> 
> https://gitlab.com/qemu-project/qemu/-/blob/1cd2ad11d37c48f284f557954e1df675b126264c/tests/unit/rcutorture.c#L320
> 
> Anyway I'll try to nudge someone on the virt team who knows about
> these things to take a look.

Does -O0 help?  -flto vs. -fno-lto?  -fno-ipa-modref (gcc 12 is slightly
more aggressive in the interprocedural TBAA)?
If -O0 helps, can you find out if it is the test or something in a library or
whatever that the test uses, and if the latter, try to bisect it to one *.o
file?  If -O0 doesn't help, try to mix and match gcc 11 and gcc 12 built
objects.  I know next to nothing about qemu, so it would help if somebody
familiar with it did that.  Perhaps Paolo Bonzini is familiar with both
qemu and gcc...
Having just one preprocessed source + compiler command line and knowing
roughly what to look for allows bisection and further analysis.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Sun, Jan 16, 2022 at 01:18:51PM -0500, Kaleb Keithley wrote:
> Ceph fails with gcc-12 too.
> 
> scratch build at
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81280838
> 
> upstream ceph bug at https://tracker.ceph.com/issues/53896

Can you please mail me preprocessed source on which this now fails
and the g++ command line?  If it is a compiler change rather than
libstdc++ I could bisect and try to find out what's going on.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Fri, Jan 14, 2022 at 04:07:08PM +0100, Dan Horák wrote:
> > Another important thing I wanted to say is that we'd like to switch
> > ppc64le from the numerically problematic IBM extended long double to
> > IEEE 754 quad long double.  This is an ABI change.  Some libraries
> > are already built so that they support both ABIs at the same time,
> > including glibc, libstdc++, libgcc, libgfortran etc.
> > For other libraries and binaries, the compiler, assembler and linker
> > will notice if they use long double and flag them as using either
> > IBM or IEEE long double and linker (or I think dynamic linker too)
> > might complain when things are mixed.
> > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> > but the glibc/gcc libraries are built compatibly with both.
> > We'd like to configure gcc shortly before the mass rebuild with
> > --with-long-double-format=ieee so that it will default to
> > -mabi=ieeelongdouble, probably on a side-tag build first, and it
> > will be highly desirable to rebuild at least some of the most commonly
> > used library packages in the order of dependencies there, otherwise
> > I'd be afraid the mass rebuild could fail for way too many packages
> > (as the mass rebuild doesn't do dependency order rebuilds but just
> > goes through packages alphabetically or so).
> > Any suggestions on which packages have commonly used library packages
> > that use long double?
> > readelf -A on libraries on ppc64le prints either nothing (either
> > the library is thought not to use long double or supports both ABIs
> > transparently or hasn't been rebuilt for some years), or
> > Attribute Section: gnu
> > File Attributes
> >   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> > for libraries (or binaries or object files) that use IBM long double
> > only or
> > Attribute Section: gnu
> > File Attributes
> >   Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
> > for IEEE long doubles.
> > So I think we want to rebuild on a side-tag packages that
> > provide shared libraries used by hundreds of other packages that
> > are
> >   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> > right now.
> 
> a quick scan of /usr/lib64 on my F-34 workstation shows
> many ./libQt5*
> many ./libLLVM*
> ./libgobject-2.0
> ./libgio-2.0
> ./libglib-2.0
> ./libexiv2-xmp
> ./libhwy
> ./python3.9/site-packages/numpy/*
> ./libSDL2
> ./libiberty
> ./clang/12.0.1/lib/libclang_rt.builtins-powerpc64le.a
> ./ghdl/llvm/libgrt.a
> ./libc
> 
> as users of the Tag_GNU_Power_ABI_FP attribute. A vast majority of the
> hits are "Tag_GNU_Power_ABI_FP: hard float, unspecified long double"
> 
> Translated to packages it is qt5-*, llvm + clang, numpy, SDL2, glib2,
> exiv2, glibc, highway

The -mabi=ieeelongdouble defaulting gcc is now in the
f36-build-side-49600 side-tag (gcc -0.5.1.fc36, same as -0.5.fc36 in
rawhide except for the different ppc64le default ABI).

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Kaleb Keithley]

Ceph fails with gcc-12 too.

scratch build at
https://koji.fedoraproject.org/koji/taskinfo?taskID=81280838

upstream ceph bug at https://tracker.ceph.com/issues/53896

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Richard W.M. Jones]

I tried recompiling qemu and it fails with an odd error in the RCU
torture test.  Bug submitted upstream here:

https://gitlab.com/qemu-project/qemu/-/issues/823

... but since GCC 12 is the only big thing that has changed since we
just rebuilt qemu, could that be a reason?

https://gitlab.com/qemu-project/qemu/-/blob/1cd2ad11d37c48f284f557954e1df675b126264c/tests/unit/rcutorture.c#L320

Anyway I'll try to nudge someone on the virt team who knows about
these things to take a look.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Vitaly Zaitsev via devel]

On 15/01/2022 19:40, Ben Beasley wrote:
To clarify, this is affecting the 
https://src.fedoraproject.org/rpms/json package and (since it is a 
header-only library) some or all of the many packages that use it.


nheko package:

/builddir/build/BUILD/nheko-0.9.1/src/Cache.cpp:4530:34: error: 
ambiguous overload for 'operator=' (operand types are 'std::string' {aka 
'std::__cxx11::basic_string'} and 'const 
nlohmann::basic_json<>::value_type' {aka 'const nlohmann::basic_json<>'})

 4530 | info.name   = j.at("name");
  |  ^
In file included from /usr/include/c++/12/string:53,
 from 
/builddir/build/BUILD/nheko-0.9.1/redhat-linux-build/CMakeFiles/nheko.dir/cmake_pch.hxx:5,

 from :
/usr/include/c++/12/bits/basic_string.h:733:21: note: candidate: 
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& 
std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::operator=(std::nullptr_t) [with _CharT = char; _Traits = 
std::char_traits; _Alloc = std::allocator; std::nullptr_t = 
std::nullptr_t]' (deleted)

  733 |   basic_string& operator=(nullptr_t) = delete;
  | ^~~~
/usr/include/c++/12/bits/basic_string.h:801:7: note: candidate: 
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = 
char; _Traits = std::char_traits; _Alloc = std::allocator]'

  801 |   operator=(const basic_string& __str)
  |   ^~~~
/usr/include/c++/12/bits/basic_string.h:842:7: note: candidate: 
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& 
std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>&&) [with _CharT = char; _Traits = std::char_traits; _Alloc 
= std::allocator]'

  842 |   operator=(basic_string&& __str)
  |   ^~~~
/builddir/build/BUILD/nheko-0.9.1/src/Cache.cpp:4531:35: error: 
ambiguous overload for 'operator=' (operand types are 'std::string' {aka 
'std::__cxx11::basic_string'} and 'const 
nlohmann::basic_json<>::value_type' {aka 'const nlohmann::basic_json<>'})

 4531 | info.topic  = j.at("topic");
  |   ^

mtxclient package:

/builddir/build/BUILD/mtxclient-0.6.1/lib/structs/pushrules.cpp: In 
function 'void mtx::pushrules::from_json(const nlohmann::json&, 
PushCondition&)':
/builddir/build/BUILD/mtxclient-0.6.1/lib/structs/pushrules.cpp:23:35: 
error: ambiguous overload for 'operator=' (operand types are 
'std::string' {aka 'std::__cxx11::basic_string'} and 'const 
nlohmann::basic_json<>::value_type' {aka 'const nlohmann::basic_json<>'})

   23 | condition.kind= obj["kind"];
  |   ^
In file included from /usr/include/c++/12/string:53,
 from /usr/include/nlohmann/json_fwd.hpp:7,
 from 
/builddir/build/BUILD/mtxclient-0.6.1/include/mtx/pushrules.hpp:7,
 from 
/builddir/build/BUILD/mtxclient-0.6.1/lib/structs/pushrules.cpp:1:
/usr/include/c++/12/bits/basic_string.h:733:21: note: candidate: 
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& 
std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::operator=(std::nullptr_t) [with _CharT = char; _Traits = 
std::char_traits; _Alloc = std::allocator; std::nullptr_t = 
std::nullptr_t]' (deleted)

  733 |   basic_string& operator=(nullptr_t) = delete;
  | ^~~~
/usr/include/c++/12/bits/basic_string.h:801:7: note: candidate: 
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = 
char; _Traits = std::char_traits; _Alloc = std::allocator]'

  801 |   operator=(const basic_string& __str)
  |   ^~~~
/usr/include/c++/12/bits/basic_string.h:842:7: note: candidate: 
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& 
std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>&&) [with _CharT = char; _Traits = std::char_traits; _Alloc 
= std::allocator]'

  842 |   operator=(basic_string&& __str)
  |   ^~~~

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Richard W.M. Jones]

On Sat, Jan 15, 2022 at 01:50:19PM -0700, Martin Sebor wrote:
> Having said that, checking and handling possible truncation before
> calling snprintf() is doing double the work.  I would suggest to get
> rid of the check and instead handle the truncation after it happens.
> This is both simpler and faster, and avoids the warning:
> 
> if (snprintf (*sockpath, UNIX_PATH_MAX,
>   "%s/%s", g->sockdir, filename) < UNIX_PATH_MAX)
>   return 0;
> 
> error (g, _("socket path too long: %s/%s"), g->sockdir, filename);
> return -1;
>   }

Oh that's a good idea, thanks!

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure