Re: Guidance on individual packages requiring x86_64-v2 baseline ?

[Jakub Jelinek]

On Wed, Jun 12, 2024 at 05:35:24PM +0100, Daniel P. Berrangé wrote:
> It isn't as simple as changing the CFLAGS. QEMU used to check for
> the CPU feature at startup, set a flag, and then later use that flag
> to choose different codepaths, but this logic was removed. Avoiding
> the flag check in hot-paths makes a perf difference.

Can't QEMU upstream be convinced to make it configurable, perhaps with
default requiring SSE4 and when configured/built to support even older HW
take the performance hit to support it?

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Linux 40 Final Freeze

[Jakub Jelinek]

On Tue, Apr 02, 2024 at 12:33:04PM +0530, Samyak Jain wrote:
> Today, 2024-04-02, is an important day on the Fedora Linux 40 schedule
> [1], with significant cut-offs.
> 
> Today we have the Final Freeze [2] which starts at 14:00 UTC. This means
> that only packages that fix accepted blocker or freeze exception bugs
> [3][4][5] will be marked as 'stable' and included in the Final composes.

Will the currently testing->stable marked updates be still included in
stable without having to go through the exception/blocker process?

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Jakub Jelinek]

On Mon, Apr 01, 2024 at 01:36:48PM -0400, Peter Jones wrote:
> Unrelated to the idea that some packages are special in this way, it's
> probably worth writing some static analysis tools we could put into
> rpm-inspect to detect when (a) a binary grows new public keys it didn't
> have before, and (b) a shared object grows a new ifunc.  The latter is
> dramatically easier, of course, but both of those should be pretty rare
> events, so they're worth further inspection.

I don't see much difference between ifuncs and any other library
constructors from the exploit POV, at least with DT_BIND_NOW both is just
some extra code run during library initialization.  Sure, ifunc handlers
affect what ifunc target is later called whenever calling the ifunc
function, but harm can be done already when loading the library or the
library constructor could overwrite function pointers, vtable pointers or
just some data in the library to change its behavior later.
So, in addition to watching for new ifuncs (and more importantly, trying to
figure out if it is possible to statically prove the set of possible
functions it will resolve to and compare to the old set; and if it isn't
possible to statically figure out list of possible targets flag it for more
careful inspection) we should watch for additions of
__attribute__((constructor)) code or C++ namespace scope non-trivial ctors or
dynamic initializers of namespace scope variables.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Dropping libdv i686

[Jakub Jelinek]

On Sun, Feb 25, 2024 at 08:41:38PM +0100, Antonio T. sagitter wrote:
> libdv is currently failing in i686 architectures, it could be dropped.

Ugh, why?
The bug is not from upstream, but from the downstream libdv-pic.patch
patch, and is on i686 only because those changes are in i686 specific code.
Normally one wouldn't introduce these extra pointer arguments but instead
just use proper PIC accesses to the symbol, e.g. you could compile
extern unsigned char dv_quant_shifts[22][4];
int foo (void) { return dv_quant_shifts[0][0]; }
with -O2 -m32 -march=i686 -fpic -S and see what is needed.
Anyway, if it is done the way the patch does that, the assembly doesn't
care that much what exact pointer it gets as long as it points to the
dv_quant_shifts array.
So one fix is change the
+extern void _dv_quant_88_inverse_x86(dv_coeff_t *block,int qno,int klass, 
uint8_t *offset, uint8_t *shifts);
line in the patch to
+extern void _dv_quant_88_inverse_x86(dv_coeff_t *block,int qno,int klass, 
uint8_t *offset, uint8_t (*shifts)[4]);
and yet another would be to change
+  
_dv_quant_88_inverse_x86(mb->b[i].coeffs,mb->qno,mb->b[i].class_no,dv_quant_offset,dv_quant_shifts);
and
+   
_dv_quant_88_inverse_x86(bl->coeffs,mb->qno,bl->class_no,dv_quant_offset,dv_quant_shifts);
lines in the patch to
+  
_dv_quant_88_inverse_x86(mb->b[i].coeffs,mb->qno,mb->b[i].class_no,dv_quant_offset,(uint8_t
 *)dv_quant_shifts);
and
+   
_dv_quant_88_inverse_x86(bl->coeffs,mb->qno,bl->class_no,dv_quant_offset,(uint8_t
 *)dv_quant_shifts);
Fixing this is less work than dropping it from one arch and dealing with the
fallout.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC perhaps not honoring -std?

[Jakub Jelinek]

On Wed, Feb 21, 2024 at 11:34:37AM -0500, Steven A. Falco wrote:
> I am getting an error "template-id not allowed for constructor in C++20" but 
> according to the Copr log [0], the compiler is being given -std=c++17:

It is a warning, but you've asked for all warnings to be errors, right?
As documented
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wtemplate-id-cdtor
the warning is enabled by default when compiling with -std=c++20 or newer,
or when -Wc++20-compat warning is enabled, and the latter as documented
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wc_002b_002b20-compat
is enabled by default in -Wall, which you asked for.
The purpose of the warning is to warn that this won't be accepted in C++20
anymore and there is no reason not to make it valid C++20 right away by
removing the redundant part.

> Building CXX object 
> thirdparty/clipper2/CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o
> cd /builddir/build/BUILD/kicad-7.0.11/redhat-linux-build/thirdparty/clipper2 
> && /usr/bin/g++ -DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H 
> -DKICAD_CONFIG_DIR=kicad -DKICAD_SCRIPTING_WXPYTHON -DKICAD_SIGNAL_INTEGRITY 
> -DKICAD_SPICE -DUSINGZ -DWXUSINGDLL -DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 
> -D__WXGTK__ 
> -I/builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/include 
> -isystem /builddir/build/BUILD/kicad-7.0.11/thirdparty/pybind11/include 
> -isystem /usr/include/cairo -isystem /usr/include/pixman-1 -isystem 
> /usr/include/freetype2 -isystem /usr/include/harfbuzz -isystem 
> /usr/include/opencascade -isystem /usr/lib64/wx/include/gtk3-unicode-3.2 
> -isystem /usr/include/wx-3.2 -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
> -grecord-gcc-switches -pipe -Wall -Werror=format-security 
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -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=x86-64 
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
> -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
> -Wno-attributes -pthread -O2 -g -DNDEBUG -std=c++17 -fPIC -fvisibility=hidden 
> -fvisibility-inlines-hidden -Wall -Wextra -Wpedantic -Werror -MD -MT 
> thirdparty/clipper2/CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o
>  -MF CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o.d -o 
> CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o -c 
> /builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/src/clipper.engine.cpp
> 
> In file included from 
> /builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/include/clipper2/clipper.engine.h:22,
>  from 
> /builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/src/clipper.engine.cpp:17:
> /builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/include/clipper2/clipper.core.h:139:22:
>  error: template-id not allowed for constructor in C++20 
> [-Werror=template-id-cdtor]
>   139 | explicit Point(const Point& p)

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Help needed to fix FTBFS in scikit learn

[Jakub Jelinek]

On Sat, Feb 17, 2024 at 10:03:39PM +0100, Sergio Pascual wrote:
> Hello, currently python-scikit-learn fails to build in f40 and rawhide
> https://bugzilla.redhat.com/show_bug.cgi?id=2261602
> 
> The problem is a series of incompatible pointer conversions that
> appear in cython generated C code.
> The code has classes defined in cython and in the offending code
> "self" is passed as a pointer to the base class with a conversion to
> the derived class
> 
> sklearn/metrics/_dist_metrics.c: In function
> ‘__pyx_f_7sklearn_7metrics_13_dist_metrics_19EuclideanDistance32_dist_csr’:
> sklearn/metrics/_dist_metrics.c:51033:90: error: passing argument 1 of
> ‘__pyx_f_7sklearn_7metrics_13_dist_metrics_19EuclideanDistance32_rdist_csr’
> from incompatible pointer type [-Wincompatible-pointer-types]
> 
> note: expected ‘struct
> __pyx_obj_7sklearn_7metrics_13_dist_metrics_EuclideanDistance32 *’
> but argument is of type ‘struct
> __pyx_obj_7sklearn_7metrics_13_dist_metrics_DistanceMetric32 *’

If the conversion is correct and desirable, it needs to be explicit, not
implicit.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Modern C failures in Haskell stack

[Jakub Jelinek]

On Thu, Feb 15, 2024 at 12:57:21PM +0100, Florian Weimer wrote:
> For the first issue, please try this GHC patch (only compile-tested with
> the stage 0 compiler build this point):
> 
> diff --git a/compiler/GHC/HsToCore/Foreign/C.hs 
> b/compiler/GHC/HsToCore/Foreign/C.hs
> index 2164ded112..8beaa8986e 100644
> --- a/compiler/GHC/HsToCore/Foreign/C.hs
> +++ b/compiler/GHC/HsToCore/Foreign/C.hs
> @@ -560,7 +560,7 @@ mkFExportCBits dflags c_nm maybe_target arg_htys res_hty 
> is_IO_res_ty cc
>   ,   ppUnless res_hty_is_unit $
>   if libffi
>then char '*' <> parens (ffi_cResType <> char '*') <>
> -   text "resp = cret;"
> +   text "resp = " <> parens ffi_cResType <> text "cret;"
>else text "return cret;"
>   , rbrace
>   ]
> 
> I'm not even sure if there is a better fix for this.  Perhaps emitting a
> memcpy call to avoid the aliasing violation?

I thought it isn't an aliasing violation (though I only looked at the
diagnostics, nothing else), I thought the problem is that cret has some
pointer type and ffi_arg has integer type.  The above will work
if cret has non-pointer type (changes implicit conversion to explicit) but
with pointers still will emit a warning if say ffi_arg is 64-bit and pointers
are 32-bit or ffi_arg is 32-bit and pointers are 64-bit.
For that (ffi_arg) (uintptr_t) cret;
casts would be desirable, but one would need to find out if cret is a
pointer or not.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Modern C failures in Haskell stack

[Jakub Jelinek]

On Thu, Feb 15, 2024 at 11:13:08AM +, Richard W.M. Jones wrote:
> We noticed that some ghc-* packages FTBFS with Modern C failures eg
> these two picked at random:
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602
> 
> I think what's happening here is that ghc is generating C FFI code
> which is fed to GCC 14.  The code being generated is buggy.
> 
> So probably the fix for this is just in ghc itself.  I looked at
> upstream ghc and wasn't able to identify any commits which fix this
> (except maybe
> https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
> But I didn't look especially hard and the code is very complicated.
> 
> An alternative to fixing this in the compiler is to throw up our hands
> and add:
> 
>   %global build_type_safety_c 0

Please don't if at all possible.

> to every affected ghc-* package.  eg This fixes ghc-readline:
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113535426
> 
> Any thoughts on this?

The diagnostics is quite clear what needs to be done, in some cases
#include , in others (uintptr_t) cast added when you want to
assign a pointer to ffi_arg which is integral type.  Perhaps stdint.h
include for that.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: FYI: AFL++ now builds a GCC plugin

[Jakub Jelinek]

On Tue, Feb 06, 2024 at 01:50:14PM +0100, Jakub Jelinek wrote:
> On Tue, Feb 06, 2024 at 12:38:31PM +, Richard W.M. Jones wrote:
> > Not sure if it helps but it seems these source files implement the
> > plugin:
> > 
> > https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-cmplog-pass.so.cc
> > https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-cmptrs-pass.so.cc
> > https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-pass.so.cc
> > 
> > and this header:
> > 
> > https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-common.h
> > 
> > At a glance it seems like it uses a lot of APIs ...
> 
> >From quick skimming, I've only noticed
> set_decl_tls_model(
> decl, (flag_pic ? TLS_MODEL_INITIAL_EXEC : TLS_MODEL_LOCAL_EXEC));
> where flag_pic can change any time some option is added or removed from
> *.opt files.
> But, it doesn't seem correct either, I think it should use
> set_decl_tls_model(decl, decl_default_tls_model(decl));
> instead.  Or call decl_default_tls_model(decl) and adjust the result
> depending on what it will return.

BTW, if flag_pic ? TLS_MODEL_INITIAL_EXEC : TLS_MODEL_LOCAL_EXEC is
really what the plugins wants (e.g. that the TLS variable will be
defined in the same executable or same shared library and for shared
library doesn't mind making it non-dlopenable if other libraries deplete
the static TLS size), one hack might be to use e.g.
default_reloc_rw_mask () ? TLS_MODEL_INITIAL_EXEC : TLS_MODEL_LOCAL_EXEC
where default_reloc_rw_mask () is defined as return flag_pic ? 3 : 0;
for almost 17 years already, so could be a quick hack around trying to
remap flag_pic.

I'd really like to avoid exact gcc NVR dependency, at least if any gcc
updates would be refused because of that until somebody rebuilds the plugin
as well.  That was a reason why annobin has been changed to do the option
remapping...

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: FYI: AFL++ now builds a GCC plugin

[Jakub Jelinek]

On Tue, Feb 06, 2024 at 12:38:31PM +, Richard W.M. Jones wrote:
> Not sure if it helps but it seems these source files implement the
> plugin:
> 
> https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-cmplog-pass.so.cc
> https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-cmptrs-pass.so.cc
> https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-pass.so.cc
> 
> and this header:
> 
> https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-common.h
> 
> At a glance it seems like it uses a lot of APIs ...

From quick skimming, I've only noticed
set_decl_tls_model(
decl, (flag_pic ? TLS_MODEL_INITIAL_EXEC : TLS_MODEL_LOCAL_EXEC));
where flag_pic can change any time some option is added or removed from
*.opt files.
But, it doesn't seem correct either, I think it should use
set_decl_tls_model(decl, decl_default_tls_model(decl));
instead.  Or call decl_default_tls_model(decl) and adjust the result
depending on what it will return.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: FYI: AFL++ now builds a GCC plugin

[Jakub Jelinek]

On Tue, Feb 06, 2024 at 11:54:23AM +, Richard W.M. Jones wrote:
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113035034
>   https://bugzilla.redhat.com/show_bug.cgi?id=2262539
> 
> The new AFL++ (American Fuzzy Lop, a fuzzing tool) in Rawhide appears
> to be building a GCC plugin, contained in one or all of these newly
> added files:
> 
>   %global afl_helper_path %{_libdir}/afl
>   %{_bindir}/afl-gcc-fast
>   %{_bindir}/afl-g++-fast
>   %{afl_helper_path}/afl-gcc-cmplog-pass.so
>   %{afl_helper_path}/afl-gcc-cmptrs-pass.so
>   %{afl_helper_path}/afl-gcc-pass.so
>   %{afl_helper_path}/afl-gcc-rt.o
>   %{afl_helper_path}/injection-pass.so
> 
> I'm going to guess this will introduce a dependency on the exact
> version of GCC (major only? or major.minor? not sure).  Just like
> annobin.  Which might require that this package is rebuilt when GCC is
> rebuilt (only major? or all rebuilds? again, don't know).
> 
> If this proves to be a problem then I can drop the GCC plugin usage,
> or we could work out a process to deal with rebuilding.
> 
> Anyway, let's look out for this and see if it causes trouble, and then
> decide what to do.

Guess it depends on what exactly it uses.
Obviously, there must be a dependency on the major version.  The plugin API
(which is essentilly everything in the compiler) can change obviously at any
time, but in reality on release branches (at least past the major.1 release)
it doesn't change much very often, from the annobin experience the only
major problematic thing are accesses to options - global_options{,_set} and
the like, including through macros like flag_* or opt_for_fn etc.

As described in https://gcc.gnu.org/r11-5149 , annobin has some code to find
out offsets of options in global_options{,_set} etc. even if it has been
built against different version of gcc (same major, but from different
date), where perhaps some options have been added or removed and that in
turn caused reshuffling of options which were there before and are still in
there but at different offsets.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: internal compiler error: in backward_pass, at tree-vect-slp.cc

[Jakub Jelinek]

On Fri, Jan 26, 2024 at 10:59:55AM -0500, Yaakov Selkowitz wrote:
> On Fri, 2024-01-26 at 15:45 +, Sérgio Basto wrote:
> > Hi,
> > 
> > MLT failed to build [2] with [1] , what do you suggest ? 
> > 
> > Best regards,
> > 
> > [1] 
> > builddir/build/BUILD/mlt-7.22.0/src/modules/gdk/pixops.c: In function
> > ‘scale_line_22_yuv’:
> > /builddir/build/BUILD/mlt-7.22.0/src/modules/gdk/pixops.c:188:1:
> > internal compiler error: in backward_pass, at tree-vect-slp.cc:5346
> >   188 | scale_line_22_yuv ( int *weights, int n_x, int n_y,
> >   | ^
> > [ 33%] Building C object
> > src/modules/kdenlive/CMakeFiles/mltkdenlive.dir/filter_wave.c.o
> > 
> > [2] 
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=2376836
> > https://kojipkgs.fedoraproject.org//work/tasks/7413/112327413/build.log
> 
> File a bug on bugzilla.redhat.com, Fedora product, gcc component,
> rawhide version, and include the information above, and the GCC
> maintainers will take a look.

That is almost certainly https://gcc.gnu.org/PR113205
No need to track it further, it is already tracked.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC 14 error for asio

[Jakub Jelinek]

On Sun, Jan 21, 2024 at 12:23:27PM +0100, Julian Sikorski wrote:
> asio started failing to build with gcc-14 [1]. The error is:

Seems (thanks Patrick for reducing and analyzing it) it is
a GCC bug, https://gcc.gnu.org/PR113544

Hopefully it will be fixed soon.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: AusweisApp2 build failed on rawhide/x86_64 (unsupported reloc 43)

[Jakub Jelinek]

On Sat, Jan 20, 2024 at 02:27:58PM +0100, Julian Sikorski wrote:
> AusweisApp2-2.0.3 build failed on rawhide/x86_64 with unsupported reloc 43
> errors [1]. Other architectures have built fine, similarly to released
> branches. Is this a problem with rawhide ld.gold?

I thought reloc 43 (aka R_X86_64_CODE_4_GOTPCRELX) is a relocation for APX
code (i.e. when an instruction uses %r16-%r31 registers and needs GOTPCREL),
it surprises me a package in the distro would use it so quickly.

In any case, ld.gold is an unmaintained linker for years, just use ld.bfd
instead.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Build error with GCC 14, not even a warning in GCC 13

[Jakub Jelinek]

On Tue, Jan 16, 2024 at 03:32:14PM -0800, Aleksei Bavshin wrote:
> On Tue, Jan 16, 2024 at 3:07 PM Richard Shaw  wrote:
> >
> > I'm working on getting a new dependency of one of my packages into Fedora:
> >
> > https://github.com/socketio/socket.io-client-cpp/releases
> >
> > After doing successful test builds locally in mock (no error output at all) 
> > I used fedora-create-review but all the builds failed with:
> >
> > In file included from 
> > /builddir/build/BUILD/socket.io-client-cpp-3.1.0/src/internal/sio_packet.cpp:8:
> > /usr/include/rapidjson/document.h: In member function 
> > ‘rapidjson::GenericStringRef& 
> > rapidjson::GenericStringRef::operator=(const 
> > rapidjson::GenericStringRef&)’:
> > /usr/include/rapidjson/document.h:319:82: error: assignment of read-only 
> > member ‘rapidjson::GenericStringRef::length’
> >   319 | GenericStringRef& operator=(const GenericStringRef& rhs) { s = 
> > rhs.s; length = rhs.length; }
> >   | 
> >   ~~~^~~~
> > gmake[2]: *** [CMakeFiles/sioclient.dir/build.make:121: 
> > CMakeFiles/sioclient.dir/src/internal/sio_packet.cpp.o] Error 1
> >
> > Full logs: https://koji.fedoraproject.org/koji/taskinfo?taskID=111852023
> >
> > Is this a real error?
> 
> Yes, see https://github.com/Tencent/rapidjson/issues/718. The operator
> implementation is most certainly not legal, but previous versions of
> the compiler may have been ignoring that due to not being asked to
> instantiate the specific method.
> This was fixed 8 years ago, apparently bundled deps in
> socket.io-client-cpp are even older.

Yeah, basically what rapidjson does is something like
using size_t = decltype (sizeof 0); 

  
template

  
struct S {  

  
  template

  
  S (const T (&str)[N]) : s (str), length (N - 1) {}

  
  S (const T *str, size_t len) : s (str), length (len) {}   

  
  S (const S &rhs) : s (rhs.s), length (rhs.length) {}  

  
  S &operator= (const S &rhs) { s = rhs.s; length = rhs.length; }   

  
  const T *const s; 

  
  const size_t length;  

  
};  

  
and gcc only diagnoses that starting with https://gcc.gnu.org/r14-4111
when operator= doesn't need to be instantiated (C++ generally allows
but doesn't require such diagnostics on uninstantiated always invalid
templates), though only for the length store, the s store is invalid
too but it has a dependent type in that case.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: side-tag with GCC 14.0.1 snapshot for Fedora 40

[Jakub Jelinek]

On Tue, Jan 16, 2024 at 01:21:19PM +0100, Björn Persson wrote:
> Jakub Jelinek wrote:
> > The f40-build-side-81394 side-tag contains new
> > gcc, annobin, libtool and redhat-rpm-config for f40, meant to be
> > tagged into rawhide shortly before the mass rebuild.
> > 
> > If there is anything you'd like to rebuild against it before the mass
> > rebuild (such as packages depending on Ada which like every year bumped
> > sonames of its shared libraries), please do so soon.
> 
> Thanks for the side-tag. Most of the Ada packages – those that I have
> access to – are now rebuilt if I did everything right. The rebuild went
> smoothly this time.

Thanks.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: side-tag with GCC 14.0.1 snapshot for Fedora 40

[Jakub Jelinek]

On Mon, Jan 15, 2024 at 09:33:34PM +, Richard W.M. Jones wrote:
> On Mon, Jan 15, 2024 at 02:01:06PM +0100, Jakub Jelinek wrote:
> > Hi!
> > 
> > The f40-build-side-81394 side-tag contains new
> > gcc, annobin, libtool and redhat-rpm-config for f40, meant to be
> > tagged into rawhide shortly before the mass rebuild.
> > 
> > If there is anything you'd like to rebuild against it before the mass
> > rebuild (such as packages depending on Ada which like every year bumped
> > sonames of its shared libraries), please do so soon.
> 
> I didn't build anything into the side tag, but I did download the
> packages and rebuilt a few virt-related packages like qemu, libvirt,
> virt tools, libguestfs, nbdkit.
> 
> One thing I noticed (not virt related) was this PHP bindings failure:

See https://github.com/php/php-src/pull/12821

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: side-tag with GCC 14.0.1 snapshot for Fedora 40

[Jakub Jelinek]

On Mon, Jan 15, 2024 at 01:15:12PM +, Sérgio Basto wrote:
> On Mon, 2024-01-15 at 14:01 +0100, Jakub Jelinek wrote:
> > The f40-build-side-81394 side-tag contains new
> > gcc, annobin, libtool and redhat-rpm-config for f40, meant to be
> > tagged into rawhide shortly before the mass rebuild.
> > 
> > If there is anything you'd like to rebuild against it before the mass
> > rebuild (such as packages depending on Ada which like every year
> > bumped
> > sonames of its shared libraries), please do so soon.
> 
> 
> I'd like bump soname of libjxl [1] and opencv 
> 
> [1]
> https://src.fedoraproject.org/rpms/jpegxl 

If that soname bump is not GCC 14 related, please do that independently,
the side-tag is meant solely for packages which depend on GCC major version.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

side-tag with GCC 14.0.1 snapshot for Fedora 40

[Jakub Jelinek]

Hi!

The f40-build-side-81394 side-tag contains new
gcc, annobin, libtool and redhat-rpm-config for f40, meant to be
tagged into rawhide shortly before the mass rebuild.

If there is anything you'd like to rebuild against it before the mass
rebuild (such as packages depending on Ada which like every year bumped
sonames of its shared libraries), please do so soon.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Update on the Modern C initiative

[Jakub Jelinek]

On Tue, Dec 05, 2023 at 04:38:55AM +0100, Kevin Kofler via devel wrote:
> Florian Weimer wrote:
> > The final patches for GCC 14 are currently under upstream review and
> > should land very soon.  Earlier, I had received feedback that the larger
> > community desires just one transition, so we end up with the following
> > warnings which turn into errors by default:
> > 
> >   -Wimplicit-function-declaration
> >   -Wimplicit-int
> >   -Wint-conversion
> >   -Wreturn-mismatch (new, previously part of -Wreturn-types)
> >   -Wdeclaration-missing-parameter-type (new, previously unnamed)
> >   -Wincompatible-pointer-types
> > 
> > Only the first two were covered in the initial Fedora conversion work.
> 
> As much as I understand the point of -Werror=implicit-function-declaration 
> (since implicit function declarations can cause several subtle bugs), and 
> implicit int is obscure enough for its removal to not be a big problem (even 
> though its potential for causing bugs is much lower), as much I have to 
> wonder about the others. Especially the incompatible pointer types sound 
> more like nitpicking than actual bugs (though I guess strict aliasing can 
> cause issues with those, but then I would expect to see -Wstrict-aliasing 
> warnings).

Look at the gimp case, where a function prototype was expecting double *
argument but caller was calling it with address of float.
void foo (double *);
void
bar ()
{
  float f = 5.0f;
  foo (&f);
}
While this resulted in a warning even without -Wall, clearly nobody noticed
until this was made an error:
file-tiff-load.c:1372:56: warning: passing argument 2 of 
‘gimp_image_get_resolution’ from incompatible pointer type 
[-Wincompatible-pointer-types]
 1372 | gimp_image_get_resolution (*image, &xres, &yres);
  |^
  ||
  |gfloat * {aka 
float *}
In file included from ../../libgimp/gimp_pdb_headers.h:55,
 from ../../libgimp/gimp.h:66,
 from file-tiff-load.c:52:
../../libgimp/gimpimage_pdb.h:179:86: note: expected ‘gdouble *’ {aka ‘double 
*’} but argument is of type ‘gfloat *’ {aka ‘float *’}
  179 | gdouble 
*xresolution,
  | 
~^~~
file-tiff-load.c:1372:63: warning: passing argument 3 of 
‘gimp_image_get_resolution’ from incompatible pointer type 
[-Wincompatible-pointer-types]
 1372 | gimp_image_get_resolution (*image, &xres, &yres);
  |   ^
  |   |
  |   gfloat * 
{aka float *}
../../libgimp/gimpimage_pdb.h:180:86: note: expected ‘gdouble *’ {aka ‘double 
*’} but argument is of type ‘gfloat *’ {aka ‘float *’}
  180 | gdouble 
*yresolution);
  | 
~^~~

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 39 Mass Rebuild

[Jakub Jelinek]

On Tue, Jul 25, 2023 at 12:40:15PM +0200, Florian Weimer wrote:
> * Samyak Jain:
> 
> > - GNU Toolchain Update (gcc 13.2, binutils 2.40, glibc 2.38, gdb 13.2)
> 
> This change has not yet been voted on by Fesco, so it's largely not
> included in the rebuild: gcc was still using a 13.1 version, glibc was

GCC 13.2 isn't out yet either, will be hopefully on Thursday, the mass
rebuild was done using ~ 1 month old GCC 13 branch snapshot, so compared to
what will be in 13.2 lacks that roughly a month of bugfixes.  I'll build new
GCC 13.2 into F39 at the end of the week.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: C-specific compiler parameters (was: Update on Changes/PortingToModernC)

[Jakub Jelinek]

On Wed, May 10, 2023 at 12:09:10AM +0200, Björn Persson wrote:
> Florian Weimer wrote:
> > I am going to explore a way to land -Werror=implicit-int
> > -Werror=implicit-function-declaration among the default compiler flags.
> > There's a bit of an issue because the C++ front end warns on
> > those flags, so we need another -specs= kludge that is incompatible with
> > Clang.
> 
> It sounds like those parameters should be added only to CFLAGS, not to
> CXXFLAGS.
> 
> __global_compiler_flags already contains things that cause warnings
> from the Ada and Fortran compilers. The Ada packages get the warning
> “'-Werror=' argument '-Werror=format-security' is not valid for Ada”
> over and over. It doesn't break any builds but it's annoying noise in
> the build logs.

GCC 13 has a solution for that, one can add
-Wno-complain-wrong-lang
to
-Werror=format-security
etc. and avoid such warnings (that some compiler option is only appropriate
for a subset of GCC languages and it is compiling some other language).

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[Jakub Jelinek]

On Tue, Apr 04, 2023 at 07:37:59AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Apr 02, 2023 at 09:54:04PM +0200, Dan Čermák wrote:
> > The only benchmark that *I* am aware of is this one done by Martin
> > Jambor: https://jamborm.github.io/spec-2022-07-29-levels/
> 
> This is very … underwhelming. x86-64-v2 is essentially identical to x86-64-v1.
> x86-64-v3 is better. It even shows speed-ups of 20%, but only with -Ofast.
> And -Ofast is not something that can be enabled as a default build flag,
> because it leads to surprising and unpredictable behaviour in some cases. (*)
> At -O2, which we use, the speed up is maybe 10%.

Given that GCC 12 and later autovectorizes at -O2, it might be more than
10%.

> > tl;dr; v2 does not really bring notable improvements, only v3 but also
> > only in some selected synthetic benchmarks.
> > 
> > openSUSE Tumbleweed went a different route and chose to utilize
> > glibc-hwcaps instead:
> > https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels
> > https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/ZOHLT4CQ7TDOJJ2VV7HKMN5G2MR2CTMD
> 
> Yeah, I think that's the way to go. I think we should identify 100
> shared libraries which would be positively impacted by x86-64-v3
> and provide a -v3 subrpm for them. This would be a nice feature for
> F40.

Why a subrpm?  Should be possible to just arrange for one src.rpm to
build the library twice and install the x86-64-v3 into
/usr/lib64/glibc-hwcaps/x86-64-v3/
Perhaps come with some macro to simplify that for packagers.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Some boost breakage in Fedora Rawhide

[Jakub Jelinek]

On Thu, Feb 23, 2023 at 01:11:13PM +, Jonathan Wakely wrote:
> On Thu, 23 Feb 2023 at 13:03, Richard W.M. Jones wrote:
> > Do you know anything about what's happening with Ceph?
> 
> No idea, sorry.

Ceph is likely #2169364 aka https://gcc.gnu.org/PR108773 , still unresolved
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 mass rebuild is finished

[Jakub Jelinek]

On Tue, Jan 24, 2023 at 02:01:39PM -0600, Richard Shaw wrote:
> On Tue, Jan 24, 2023 at 7:20 AM Richard Shaw  wrote:
> 
> > hobbes1069 (9):
> > cqrlog - Fails for some weird lazbuild issue I don't understand
> > flnet - Spec conditional oops. Fixed.
> > flrig - Needed cstdint. Fixed
> > freecad - Needs cstdint. Working on it.
> > gmsh - Needed cstdint. Fixed.
> > openCOLLADA - error: possibly dangling reference to a temporary. Don't
> > know how to fix this one.
> > opencascade - error: declaration of 'tbb::task&
> > tbb::internal::task_prefix::task()' changes meaning of 'task'
> > openexr - Needed cstdint. Fixed.
> > spnavcfg - https://github.com/FreeSpacenav/spnavcfg/issues/30
> >
> 
> I think I've gotten everything situated except openCOLLADA.

See https://gcc.gnu.org/PR107532 and
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/thread.html#610188
It is a new warning, which has some false positives and some further work
is being done on that, but whether openCOLLADA triggers a false positive
or has a real bug is something that somebody needs to analyze.
E.g. -fsanitize=address should diagnose similar use after scope bugs
at runtime.
Of course, packages which use -Werror need to be prepared to deal with new
warnings at any time.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 mass rebuild is finished

[Jakub Jelinek]

On Tue, Jan 24, 2023 at 10:00:47AM +0300, Vascom wrote:
> I have some packages failed.
> One of them libtins. Problem is that:
> 
> error: 'uint32_t' is not a member of 'std';
> 
> Is it normal? Is it GCC 13 change?

See
https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
Some libstdc++ headers included  in older versions
as an implementation detail but no longer do.

Including stdint.h will introduce ::uint32_t type among others,
but not std::uint32_t, if you use the latter, you need to
include .

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Yet another unwinding approach

[Jakub Jelinek]

On Wed, Jan 18, 2023 at 03:01:19PM +0100, Florian Weimer wrote:
> > On Wed, 2023-01-18 at 07:22 +0100, Florian Weimer wrote:
> 
> >> If the unwind information is incomplete, this …
> >> 
> >> > 7) signal handler unwinds the calling thread however it wants (and can
> >> > sleep and take page faults if needed)
> >> 
> >> … might encounter segmentation faults and terminate the process.  So
> >> far, incorrect unwind information (whether it's a clobbered frame
> >> pointer, or missing DWARF information about clobbered registers) is not
> >> a problem, but it's kind of hard to validate this information from
> >> within the process itself.  Maybe we'd have to add a magic memcpy first
> >> to the vDSO, which the kernel recognizes based on the code addresses,
> >> and suppresses sending the signal for it.
> >
> > Yeah, I am not too afraid of that happening with an .eh_frame based
> > unwinder unless someone deliberately produced a bad table (or dlcloses
> > a library which still has code on the call stack). You still have to be
> > careful about the stack bounds of course.
> 
> We won't have unwind data for JIT-compiled code, including libffi
> trampolines.  We could stop backtracing there (what does the ABI say
> about frames without unwinding information?), but I'm not sure if that's
> going to be useful for the desktop.

I think some JITs register their on the fly created unwind info using
__{,de}register_frame_info* APIs (at least I think that was the reason
of Thomas Neumann's libgcc unwinder changes).

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()

[Jakub Jelinek]

On Tue, Jan 17, 2023 at 03:24:16PM +0100, Björn Persson wrote:
> Jakub Jelinek wrote:
> > On Tue, Jan 17, 2023 at 01:24:45PM +0100, Miro Hrončok wrote:
> > > Hello. GCC was updated to 13 in rawhide while the Fedora change was still
> > > being voted about by FESCo.
> > > 
> > > Apparently, the following packages now don't install:  
> > 
> > There is a mass rebuild tomorrow.  The Ada soname changes every year
> > and we've never rebuilt Ada packages separately for that, just during the
> > mass rebuild.
> 
> Pavel and I have always rebuilt the Ada packages separately for the
> yearly soname change. They must be rebuilt in dependency order, and
> that's not how the mass rebuild does it.

Thanks.

> I'd be willing to cooperate to do the rebuild in a side tag, but I
> can't promise to always be available at a moment's notice.

I've been using a side-tag for gcc 13 for a couple of weeks so that annobin
and libtool can be rebuilt against gcc 13.
For trying to rebuild other packages, the problem is to find the right time,
if it is done too early (weeks before it is actually merged into rawhide),
it will make the Ada (or whatever else needs to be rebuilt) packages
buildable either in the side-tag or in rawhide but pain if needed in both,
and if it is too short before the tagging then there won't be enough time to
rebuild those.
E.g. even the annobin and libtool in the side-tag I had to rebuild again
because it was bumped several times in rawhide in between.
It is already pain now to find the right time for this (based on what
critical bugs are already fixed and what is the general state of the
compiler snapshot at that point, plus when is the scheduled mass rebuild
time) and having to do the decision several days or more before it can be
done would be even more painful.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()

[Jakub Jelinek]

On Tue, Jan 17, 2023 at 01:24:45PM +0100, Miro Hrončok wrote:
> Hello. GCC was updated to 13 in rawhide while the Fedora change was still
> being voted about by FESCo.
> 
> Apparently, the following packages now don't install:

There is a mass rebuild tomorrow.  The Ada soname changes every year
and we've never rebuilt Ada packages separately for that, just during the
mass rebuild.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: vtk build failure with gcc 13.0.0 - enum class

[Jakub Jelinek]

On Mon, Jan 16, 2023 at 09:36:39PM -0700, Orion Poplawski wrote:
> elaborated-type-specifier for a scoped enum must not use the 'class' keyword
>33 | enum class EndiannessType : std::uint8_t
>   |  ^

The actual bug is shown in later errors.
> 'int32_t' is not a member of 'std'; did you mean 'int32_t'?
>   103 |   std::array ComputeExtent() const;
>   |   ^~~

See https://gcc.gnu.org/gcc-13/porting_to.html , in particular (something
that is there every year) Header dependency changes:

Some C++ Standard Library headers have been changed to no longer include other 
headers that were being used internally by the library. As such, C++ programs 
that used standard library components without including the right headers will 
no longer compile.

The following headers are used less widely in libstdc++ and may need to be 
included explicitly when compiling with GCC 13: 

 (for std::int8_t, std::int32_t etc.) // This case

So, likely with GCC 12 and older cstdint has been included as implementation
detail by one of the libstdc++ headers VTK includes but isn't included
anymore.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: -Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python

[Jakub Jelinek]

On Mon, Jan 16, 2023 at 08:42:32PM +0100, Miro Hrončok wrote:
> On 16. 01. 23 20:30, Siddhesh Poyarekar wrote:
> > If it is for distribution packages then I reckon the flags should be
> > as close as possible for the mere reason of consistency within the
> > distribution.
> 
> Nope, the individual packages with extension modules all¹ use the
> %{build_cflags} flags by default.
> 
> ¹: Technically they are required to and it is really hard not to do that 
> noways.
> 
> > If they're used for custom built modules (e.g. through
> > a tool that python auto-generates to build modules), then a very small
> > subset of the above flags would be necessary to retain binary
> > compatibility; you should be able to remove most of it.
> 
> That is what I thought. Thank you.

Options like -m64/-m32 are ABI changing (but in %{optflags} these days
mostly uselessly because we don't usually cross-compile and gcc defaults to
those), -fsigned-char/-funsigned-char (I see it in redhat-rpm-config but
for armv3l/armv4b/armv4l which we don't build - in the past it was used on
more platforms) would be ABI changing, again on arm the various
-march=, -mfpu=, -mfloat-abi=, -mabi= options (but note that e.g. on most
other arches the -march= options aren't ABI changing, one just needs hw with
all the ISAs required by the built code), -fexceptions could be considered
partly ABI changing (at least say pthread_cancel through some objects
built with -fexceptions and others without that or with -fno-exceptions 
will not destruct everything that should be after reaching frames without
it or similarly throwing C++ exceptions won't work well), so I'd suggest
to keep that one in.  -mlong-double-{64,128} would be ABI changing, but
we just use compiler's default.  -mabi={ibm,ieee}longdouble are ABI changing
on ppc64le too, but again we use the compiler defaults.
If you look at gcc documentation, many options are marked as ABI changing,
but I don't see them used in our %{optflags}...

So, when talking about options actually in use currently in f36/f37/f38 on
Fedora supported arches, I think -fexceptions is the only one I'd list.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[Jakub Jelinek]

On Thu, Jan 12, 2023 at 06:29:10PM -0500, Siddhesh Poyarekar wrote:
> On Thu, Jan 12, 2023 at 12:41 PM Jakub Jelinek  wrote:
> > > I've filed a ccache bug.  It looks like ccache is moving the compiler
> > > arguments around, causing one of the -U_FORTIFY_SOURCE to the end.
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2160275
> >
> > Why we do have those -U_FORTIFY_SOURCE and -Wp,-U_FORTIFY_SOURCE options
> > in there at all?  Previously we just had -Wp,-D_FORTIFY_SOURCE=2
> > and I think just changing it to -Wp,-D_FORTIFY_SOURCE=3 is more than enough.
> > If you think some programs are adding -D_FORTIFY_SOURCE=2 to their *FLAGS
> > make vars etc., then perhaps -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
> > But having both -U_FORTIFY_SOURCE and -Wp,-U_FORTIFY_SOURCE seems completely
> > pointless to me.
> 
> A number of packages have -D_FORTIFY_SOURCE=2 in their default build
> flags, which was fine before because the redefinition didn't actually
> change the value of the macro.  That unfortunately fails with
> -D_FORTIFY_SOURCE=3 since the macro now gets redefined to a different
> value, resulting in a compile time warning.
> 
> As a result we need to undefine any previous macro definition and
> define it to 3.  There were more than 20 packages IIRC and asking the
> upstreams to change for this didn't make sense, but I'm happy to
> explore other ideas, if any.

But at least you don't need both -U_FORTIFY_SOURCE and
-Wp,-U_FORTIFY_SOURCE, one of them is enough.  And the latter I think
better gets through libtool and other tools; especially if you put it
into a single -Wp, option together with the redefinition...

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[Jakub Jelinek]

On Wed, Jan 11, 2023 at 06:44:22PM -0500, Siddhesh Poyarekar wrote:
> On Wed, Jan 11, 2023 at 4:43 PM Siddhesh Poyarekar  
> wrote:
> > On Wed, Jan 11, 2023 at 4:37 PM Siddhesh Poyarekar  
> > wrote:
> > >
> > > On Wed, Jan 11, 2023 at 3:05 PM Michel Alexandre Salim
> > >  wrote:
> > > > Just `mock -r fedora-rawhide-x86_64 ./*.src.rpm`
> > > >
> > > > I have these additional knobs in ~/.config/mock.cfg:
> > > >
> > > >
> > > > config_opts['plugin_conf']['ccache_enable'] = True
> > > > config_opts['plugin_conf']['ccache_opts']['max_cache_size'] = '10G'
> > > >
> > > > # False: build from Koji, e.g. to grab packages just put into Rawhide
> > > > # config_opts['mirrored'] = False
> > > >
> > >
> > > OK I see the warning now.  Let me dig deeper.
> >
> > So if you want the quick answer to unblock you, it is ccache; I
> > disabled it and the warning went away.  That should help you get your
> > -Werror going.  I'll look closer at why that's happening.
> 
> I've filed a ccache bug.  It looks like ccache is moving the compiler
> arguments around, causing one of the -U_FORTIFY_SOURCE to the end.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2160275

Why we do have those -U_FORTIFY_SOURCE and -Wp,-U_FORTIFY_SOURCE options
in there at all?  Previously we just had -Wp,-D_FORTIFY_SOURCE=2
and I think just changing it to -Wp,-D_FORTIFY_SOURCE=3 is more than enough.
If you think some programs are adding -D_FORTIFY_SOURCE=2 to their *FLAGS
make vars etc., then perhaps -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
But having both -U_FORTIFY_SOURCE and -Wp,-U_FORTIFY_SOURCE seems completely
pointless to me.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC Fedora - relocation truncated to fit: R_X86_64_32S against `.rodata'

[Jakub Jelinek]

On Tue, Dec 20, 2022 at 01:49:00PM +0100, Jakub Jelinek wrote:
> On Tue, Dec 20, 2022 at 12:12:42PM +, Daniel P. Berrangé wrote:
> > For KVM AMD SEV-SNP virtualization we're trying to get SVSM guest
> > firmware built on Fedora.
> > 
> >   https://github.com/svsm-vtpm/linux-svsm
> > 
> > It builds successfully on Ubuntu 22.04 (gcc 11.3.0) which is what upstream
> > uses as their primary dev platform. On Fedora 37 (gcc 12.2.1) though, we're
> > getting errors at the final link stage. To eliminate version as a factor,
> > I also tried Fedora 35 with gcc 11.3.1 and got the same errors:
> > 
> > gcc -m64 -nostdlib -Wl,-Tsrc/start/svsm.lds -Wl,--build-id=none -o 
> > svsm.bin.elf src/start/start.o 
> > target/x86_64-unknown-none/debug/liblinux_svsm.a -Wl,--start-group 
> > ./external/build/lib/libtpm.a ./external/build/lib/libplatform.a 
> > ./external/build/lib/libwolfssl.a ./external/build/lib/libcrt.a 
> > ./external/build/lib/libm.a -Wl,--end-group
> > ./external/build/lib/libwolfssl.a(src_libwolfssl_la-sha256.o): in function 
> > `Transform_Sha256':
> > sha256.c:(.text+0xba): relocation truncated to fit: R_X86_64_32 against 
> > `.rodata'
> > ./external/build/lib/libwolfssl.a(src_libwolfssl_la-aes.o): in function 
> > `wc_AesEncrypt':
> > aes.c:(.text+0x50): relocation truncated to fit: R_X86_64_32S against 
> > `.rodata'
> > aes.c:(.text+0x68): relocation truncated to fit: R_X86_64_32S against 
> > `.rodata'
> > aes.c:(.text+0x7e): relocation truncated to fit: R_X86_64_32S against 
> > `.rodata'
> > aes.c:(.text+0x8c): relocation truncated to fit: R_X86_64_32S against 
> > `.rodata'
> > aes.c:(.text+0x9e): relocation truncated to fit: R_X86_64_32S against 
> > `.rodata'
> > aes.c:(.text+0xa9): relocation truncated to fit: R_X86_64_32S against 
> > `.rodata'
> > aes.c:(.text+0xc5): relocation truncated to fit: R_X86_64_32S against 
> > `.rodata'
> > aes.c:(.text+0xd3): relocation truncated to fit: R_X86_64_32S against 
> > `.rodata'
> > aes.c:(.text+0xe9): relocation truncated to fit: R_X86_64_32S against 
> > `.rodata'
> > aes.c:(.text+0xf8): additional relocation overflows omitted from the output
> > collect2: error: ld returned 1 exit status
> > make: *** [Makefile:54: svsm.bin.elf] Error 1
> 
> That would mean either that your text + data segment are larger than 2GB, or
> src/start/svsm.lds you are using places the sections somewhere high in the
> address space, incompatible with the x86-64 default -mcmodel=small.
> Ubuntu defaults to -fpie -pie like we use in Fedora when hardening isn't
> disabled through specs from redhat-rpm-config, so it uses a different
> code model (small pic).
> You can build stuff with -fpie and link with -pie if you want, or
> -mcmodel=medium or -mcmodel=large etc., depends really on what 
> src/start/svsm.lds
> is doing and how large the binary is.
> As documented:
> '-mcmodel=small'
>  Generate code for the small code model: the program and its symbols
>  must be linked in the lower 2 GB of the address space.  Pointers
>  are 64 bits.  Programs can be statically or dynamically linked.
>  This is the default code model.
> 
> '-mcmodel=medium'
>  Generate code for the medium model: the program is linked in the
>  lower 2 GB of the address space.  Small symbols are also placed
>  there.  Symbols with sizes larger than '-mlarge-data-threshold' are
>  put into large data or BSS sections and can be located above 2GB.
>  Programs can be statically or dynamically linked.
> 
> '-mcmodel=large'
>  Generate code for the large model.  This model makes no assumptions
>  about addresses and sizes of sections.
> etc.

The linker script has:
SECTIONS
{
. = SVSM_GPA_LDS;
and
#ifndef SVSM_GPA_LDS
#define SVSM_GPA_LDS0x80
#endif /* SVSM_GPA_LDS */

So, this is indeed incompatible with both small and medium code models,
so everything that is linked into that binary should be compiled with
-mcmodel=large and pay the code performance price for that.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC Fedora - relocation truncated to fit: R_X86_64_32S against `.rodata'

[Jakub Jelinek]

On Tue, Dec 20, 2022 at 12:12:42PM +, Daniel P. Berrangé wrote:
> For KVM AMD SEV-SNP virtualization we're trying to get SVSM guest
> firmware built on Fedora.
> 
>   https://github.com/svsm-vtpm/linux-svsm
> 
> It builds successfully on Ubuntu 22.04 (gcc 11.3.0) which is what upstream
> uses as their primary dev platform. On Fedora 37 (gcc 12.2.1) though, we're
> getting errors at the final link stage. To eliminate version as a factor,
> I also tried Fedora 35 with gcc 11.3.1 and got the same errors:
> 
> gcc -m64 -nostdlib -Wl,-Tsrc/start/svsm.lds -Wl,--build-id=none -o 
> svsm.bin.elf src/start/start.o 
> target/x86_64-unknown-none/debug/liblinux_svsm.a -Wl,--start-group 
> ./external/build/lib/libtpm.a ./external/build/lib/libplatform.a 
> ./external/build/lib/libwolfssl.a ./external/build/lib/libcrt.a 
> ./external/build/lib/libm.a -Wl,--end-group
> ./external/build/lib/libwolfssl.a(src_libwolfssl_la-sha256.o): in function 
> `Transform_Sha256':
> sha256.c:(.text+0xba): relocation truncated to fit: R_X86_64_32 against 
> `.rodata'
> ./external/build/lib/libwolfssl.a(src_libwolfssl_la-aes.o): in function 
> `wc_AesEncrypt':
> aes.c:(.text+0x50): relocation truncated to fit: R_X86_64_32S against 
> `.rodata'
> aes.c:(.text+0x68): relocation truncated to fit: R_X86_64_32S against 
> `.rodata'
> aes.c:(.text+0x7e): relocation truncated to fit: R_X86_64_32S against 
> `.rodata'
> aes.c:(.text+0x8c): relocation truncated to fit: R_X86_64_32S against 
> `.rodata'
> aes.c:(.text+0x9e): relocation truncated to fit: R_X86_64_32S against 
> `.rodata'
> aes.c:(.text+0xa9): relocation truncated to fit: R_X86_64_32S against 
> `.rodata'
> aes.c:(.text+0xc5): relocation truncated to fit: R_X86_64_32S against 
> `.rodata'
> aes.c:(.text+0xd3): relocation truncated to fit: R_X86_64_32S against 
> `.rodata'
> aes.c:(.text+0xe9): relocation truncated to fit: R_X86_64_32S against 
> `.rodata'
> aes.c:(.text+0xf8): additional relocation overflows omitted from the output
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:54: svsm.bin.elf] Error 1

That would mean either that your text + data segment are larger than 2GB, or
src/start/svsm.lds you are using places the sections somewhere high in the
address space, incompatible with the x86-64 default -mcmodel=small.
Ubuntu defaults to -fpie -pie like we use in Fedora when hardening isn't
disabled through specs from redhat-rpm-config, so it uses a different
code model (small pic).
You can build stuff with -fpie and link with -pie if you want, or
-mcmodel=medium or -mcmodel=large etc., depends really on what 
src/start/svsm.lds
is doing and how large the binary is.
As documented:
'-mcmodel=small'
 Generate code for the small code model: the program and its symbols
 must be linked in the lower 2 GB of the address space.  Pointers
 are 64 bits.  Programs can be statically or dynamically linked.
 This is the default code model.

'-mcmodel=medium'
 Generate code for the medium model: the program is linked in the
 lower 2 GB of the address space.  Small symbols are also placed
 there.  Symbols with sizes larger than '-mlarge-data-threshold' are
 put into large data or BSS sections and can be located above 2GB.
 Programs can be statically or dynamically linked.

'-mcmodel=large'
 Generate code for the large model.  This model makes no assumptions
 about addresses and sizes of sections.
etc.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[Jakub Jelinek]

On Tue, Dec 06, 2022 at 05:46:11PM -, Andrii Nakryiko wrote:
> Now, about prologues/epilogues. What percentage of useful workload is spent 
> in those? Tiny fraction of a percent at best? Even if we don't get accurate 
> stack trace in such cases it doesn't matter in the grand scheme of things.

Depends on how large functions are.  If you have lots of small functions,
it can be more than 50% of instructions you get the frame pointer wrong.

> As for hand-written assembly functions. I looked at strcmp, memcpy and 
> similar very frequent and hot functions in glibc.

You haven't looked carefully enough.

find . -name \*.S | xargs grep -l %rbp | xargs grep -L movq.*%rsp.*%rbp
./sysdeps/x86_64/fpu/multiarch/svml_s_tanhf16_core_avx512.S
./sysdeps/x86_64/fpu/multiarch/svml_s_tanhf8_core_avx2.S
./sysdeps/x86_64/fpu/multiarch/svml_s_atanhf16_core_avx512.S
./sysdeps/x86_64/fpu/multiarch/svml_s_atanhf8_core_avx2.S
./sysdeps/x86_64/fpu/svml_d_sincos2_core.S
./sysdeps/x86_64/fpu/svml_s_sincosf4_core.S
./sysdeps/x86_64/addmul_1.S
./sysdeps/x86_64/__longjmp.S
./sysdeps/x86_64/setjmp.S
./sysdeps/x86_64/_mcount.S
./sysdeps/unix/sysv/linux/x86_64/longjmp_chk.S
./sysdeps/unix/sysv/linux/x86_64/setcontext.S
./sysdeps/unix/sysv/linux/x86_64/swapcontext.S
./sysdeps/unix/sysv/linux/x86_64/getcontext.S

E.g. mpn_addmul_1 is used by printf, which certainly shows up a lot in
normal workloads.  The above cases mean the bp register contains total
garbage if one tries to use it for backtrace purposes.  And obviously
glibc isn't the only library with inline assembly out there...
As I said, you can't rely on frame pointers making sense, with unwind info
such as in DWARF you know that in this case rbp is used as a frame pointer
and in this case it is not, use some other register or this offset from
stack pointer etc.

AFAIK systemtap already uses DWARF unwinder in the kernel and as I said, for
the profiling purposes one can use only a small subset of that for the vast
majority of cases.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[Jakub Jelinek]

On Tue, Dec 06, 2022 at 08:13:51AM -0500, Neal Gompa wrote:
> "may improve" is proven to be "does improve significantly". We had

That is nonsense.  Even with -fno-omit-frame-pointers, you can't rely
on frame pointers, they are not accurate in function prologues and epilogues
and they are total garbage e.g. in a lot of functions written in assembly.
The only reliable way to get backtraces is DWARF info or something derived
from it, that is for code emitted by the compilers (with the default
-fasynchronous-unwind-tables) accurate for all instructions and for
hand written assembly one has at least a way to describe that through
.cfi_* directives.

As has been written multiple times, for profiling there doesn't need to be
full DWARF unwinder in the kernel, it is enough that there is something
that can handle the wast majority of cases and punt (copy to userland full
stack) in case of anything unexpected as long as it is rare.
Say on x86-64 and various other targets, the stack pointer, CFA (how to get
caller's stack pointer), frame pointer if any or return address is very
rarely stored anywhere but on the stack, so it should be enough to consider
CFA, sp, bp, ip during unwinding and ignore everything else and from the
harder DW_CFA_* ops (those that need DWARF expression evaluation)
perhaps only pattern recognize the most common ones (say PLT slot, signal
frame).

Frame pointers will never result in anything reliable though, it results
purely in severe performance degradation and false feeling they can be
relied 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[Jakub Jelinek]

On Tue, Dec 06, 2022 at 11:13:38AM +0100, Vitaly Zaitsev via devel wrote:
> On 05/12/2022 20:58, Ben Cotton wrote:
> > Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to
> > improve mitigation of security issues arising from buffer overflows in
> > packages in Fedora.
> 
> AFAIK, _FORTIFY_SOURCE=3 enables runtime checks for every mem*() function
> call. This should result in significant performance degradation.

That is misunderstanding.
The way _FORTIFY_SOURCE works is that say for memcpy if the destination
has known upper bound on size (__builtin_object_size (dst, 0) returns
something other than ~(size_t)0), then __memcpy_chk is used instead of
memcpy, unless the compiler can prove that the length will always fit into
that destination (in that case it is folded back to (builtin) memcpy).
So, "every" is definitely not the case.  In many cases nothing is known
about the size of the destination, and in a lot of cases it is provable that
no overflow will happen.
#define _FORTIFY_SOURCE 2 // or 3
#include 
void qux (void *);
void foo (void *dst, void *src, size_t len) { memcpy (dst, src, len); }
// Nothing is known about the length of dst above, so it will be normal memcpy
void bar (void *src) { char dst[64]; memcpy (dst, src, 32); qux (dst); }
// __builtin_object_size (dst, 0) is 64, but 32 <= 64, so again it will be
// normal memcpy.
void baz (void *src, size_t len) { char dst[64]; memcpy (dst, src, len); qux 
(dst); }
// __builtin_object_size (dst, 0) is 64, we don't know if len <= 64, so
// with _FORTIFY_SOURCE 1 and higher there will be __memcpy_chk (dst, src, len, 
64);
// call.
The only change that happens between _FORTIFY_SOURCE 2 and 3 is that in the
former case only constant upper bounds are computed, while
__builtin_dynamic_object_size can compute either constant (including
~(size_t) 0 for don't know, no upper bound) or something computed at
runtime.
void quux (void *src, size_t len) { char dst = malloc (64); memcpy (dst, src, 
len); qux (dst); }
// The above will still have even with _FORTIFY_SOURCE 2 __bos0 (dst) 64, so
// again __memcpy_chk (dst, src, len, 64);
void corge (void *src, size_t sz, size_t len) { char dst = malloc (sz); memcpy 
(dst, src, len); qux (dst); }
// But the above case changes with -D_FORTIFY_SOURCE=3, with 2 __bos0 (dst)
// is -1, with 3 __bdos0 (dst) is sz.  In this case it is still quite cheap
// to compute, just means extending the lifetime of sz until the
// __memcpy_chk (dst, src, len, sz); call.  True, in some other cases it
// might be more expensive to compute, but the goal is still that the
// compiler can punt at any time to -1 if the computation of the length
// would be too expensive.

> To proposal owner: add information about potential performance degradation,
> including benchmark results.

Deferring that to Siddhesh, I haven't done that benchmarking myself.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

[Jakub Jelinek]

On Wed, Oct 26, 2022 at 07:06:43AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > == User Experience ==
> > User experience does not change.
> 
> "The new default for C standard is -c99. Users who want to use
> an older standard need to specify something like -c89." (???)

It is -std=c89/-std=gnu89 actually.

> > == Dependencies ==
> > To avoid regressing the porting effort, GCC as the system compiler
> > needs to reject obsolete constructs by default. This is expected for
> > GCC 14, to be released as part of Fedora 40 in Spring 2024.
> > 
> > == Contingency Plan ==
> > * Contingency mechanism: Upstream GCC will probably accept obsolete
> > constructs longer in case distributions like Fedora cannot port to
> > modern C in time.
> 
> Hmm, this sounds ominous, like if GCC might stop accepting old C syntax
> altogether. Isn't this just a question of specifying the right standard
> in compilation options?

GCC hasn't changed anything yet, the obsolete constructs are accepted
for decades with warnings, some of them in -Wall, others in -Wextra.
The goal of Florian's work is to determine if it is feasible to reject them
in -std={c,gnu}{9x,99,1x,11,17,18,2x} modes by default in GCC 14.

Examples of the obsolescent syntax:

qux (); // implicit int, + () args
int baz (a, b)  // old style function definition
  a, b; // even implicit int here
{
}

foo ()  // implicit int, + () args
{
  bar (1, 2);   // implicitly declared
  baz (1, 2);
}

a;  // implicit int

-Werror=implicit -Werror=implicit-function-declaration 
-Werror=old-style-definition
will reject these even now.  Though, I think -Wold-style-definition warns
even about the no argument case which in C2X is the same as in C++ - ()
being equivalent to (void).

> > == Documentation ==
> > This section will be updated once more documentation of the porting
> > effort will become available.
> > 
> > == Release Notes ==
> > Probably not needed because no user visible impact is intended.
> 
> It's not clear from the description: what about users who compile programs?

It would be GCC that rejects those by default, so it would affect users
compiling programs as well.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: glibc 2.36 and DT_HASH (preserving it for F37+)

[Jakub Jelinek]

On Sun, Aug 21, 2022 at 09:51:42AM -0700, John Reiser wrote:
> > it's clear there's a documentation problem [with DT_GNU_HASH]
> Partly due to lack of documentation, already I have seen "abuses"

So what is
https://akkadia.org/drepper/dsohowto.pdf
https://sourceware.org/legacy-ml/binutils/2006-10/msg00377.html
https://flapenguin.me/elf-dt-gnu-hash
then?

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: glibc 2.36 and DT_HASH (preserving it for F37+)

[Jakub Jelinek]

On Sun, Aug 21, 2022 at 12:05:11PM +0200, Jan Drögehoff wrote:
> > It's Epic's fault. They must update their anti-cheat to use the modern
> > API.
> 
> More reports have come out claiming this also affects the game Shovel
> Knight[2] and the open source library libstrangle[3], there is the non 0
> chance that there are more programs out there in the wild that this will
> break.
> 
> It feels irresponsible of the glibc maintainers to suddenly respect the
> toolchains desired hash type when they haven't for years and then do it with
> little to no announcement resulting in broken software

To be precise, everything in Fedora except glibc is only built with
DT_GNU_HASH and no DT_HASH since July 2006, glibc has been an exception
that has been built with both because of statically linked programs from 16+
years ago that wouldn't support it.
If all they want is be able to interpose dlsym, they could just use
dlvsym to look up the original sym, instead of diving into the hash tables.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: FESCo wants to know what you use i686 packages for

[Jakub Jelinek]

On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
> If you use i686 packages for something now, please respond to this thread.

I use {glibc{,-devel,-static},{gmp,mpfr,libmpc}{,-devel}}.i686 for
development and testing of GCC, even in Fedora packages I'd strongly prefer
to keep the -m32 support around which also requires at least those packages
(well, currently it requires far more so that it can build documentation
etc.).

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: mold linker

[Jakub Jelinek]

On Wed, Mar 02, 2022 at 04:26:11PM -0500, Ken Dreyer wrote:
> Some of the Ceph developers were investigating mold, since Ceph takes
> so long to build. Linking time is a problem for us with Ceph. But I
> don't know if those interested Ceph developers have done benchmarks
> yet.
> 
> And the lack of s390x and ppc64le is problematic for us in Ceph too.
> But overall I'm amazed at how fast mold development is progressing.

I think a linker that can be trusted is more important than speed,
especially when part of that speed comes from not performing any checking
and just blindly assuming things look the way it expects.
I've only spent 15 minutes on it to find that mold (1.1) does significantly
less effective SHF_MERGE | SHF_STRINGS constant merging (so ends up with
significantly larger .debug_str or the .rodata string sections), or
supports only small portion of TLS transitions ld.bfd supports and does no
checking.  Small testcase found during that time:
a.c:
__thread int a = 42;

__attribute__((noipa)) int
foo (void)
{
  return a;
}

int
main ()
{
  return foo () != 42;
}
gcc -O2 -mcmodel=large -fpic -c a.c  -o a.o
gcc -o a_ a.o
./a_; echo $?
yields expected 0,
gcc -o a a.o -fuse-ld=mold
./a
Segmentation fault (core dumped)

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: mold linker

[Jakub Jelinek]

On Wed, Mar 02, 2022 at 01:29:00PM -0500, Ben Beasley wrote:
> In RPM packaging, of course, everything is built from scratch, usually with
> LTO, and a package that takes a minute to link probably takes an hour to
> build. While any work that can be saved in an RPM build is helpful, I think
> the gains from a fast linker are likely to be much less dramatic here.
> 
> [1] https://src.fedoraproject.org/rpms/mold/blob/rawhide/f/mold.spec#_24

Note, until a few days ago mold didn't support linker plugins, so was
incompatible with GCC LTO.  There is some support in now but still a WIP.

Linking speed is just one of the factors in choosing a linker,
reliability (e.g. known races in gold which is now effectively unmaintained
are a problem), or what features it supports.
mold doesn't support linker scripts so it is out of question for many use
cases, for other use cases it might matter more how large binaries and with
what security features in it it creates, etc.
I think for building Fedora packages in koji those other factors are much
more important than a few seconds saved during the package build.

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: strange ppc64le failures

[Jakub Jelinek]

On Thu, Feb 17, 2022 at 07:49:45PM +0100, Peter Lemenkov wrote:
> Hello,
> I've got a very suspiciously looking compilation issues while building
> PSPP package. All other arches are good except for ppc64le. Just grep
> for "error:" in the log attached.
> 
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=82939449
> * https://kojipkgs.fedoraproject.org//work/tasks/9583/82939583/build.log
> (ppc64le build log)
> 
> Is it a known issue or something new?

That typically means using old gnulib headers which contained a copy of
what glibc did, but weren't updated to what glibc does now.

See https://bugzilla.redhat.com/show_bug.cgi?id=2044656 for more details.

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.1-0.3.fc36 now in rawhide

[Jakub Jelinek]

On Tue, Feb 01, 2022 at 02:55:14PM +0100, Thomas Haller wrote:
> > > Apparently it was annobin (although it passed the test done during
> > > gcc.spec
> > > testing, apparently it was incompatible again).
> > > Florian has rebuilt it, so please just retry.
> 
> 
> Hi,
> 
> after a few days, it seems, the problem still exists in the buildroot
> for copr:
> https://copr.fedorainfracloud.org/coprs/networkmanager/NetworkManager-main/build/3288936/
> 
> Should we just wait longer and it solves itself?

I bet it depends on whether there was a successful rawhide compose or not.

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: openCOLLADA armv7hl only build failure

[Jakub Jelinek]

On Sun, Jan 30, 2022 at 08:00:48AM -0600, Richard Shaw wrote:
> /builddir/build/BUILD/OpenCOLLADA-1.6.68/Externals/MathMLSolver/src/MathMLEvaluatorVisitor.cpp:1:
> /builddir/build/BUILD/OpenCOLLADA-1.6.68/Externals/MathMLSolver/include/MathMLError.h:
> In destructor 'virtual MathML::Error::~Error()':
> /builddir/build/BUILD/OpenCOLLADA-1.6.68/Externals/MathMLSolver/include/MathMLError.h:62:26:
> warning: pointer used after 'void operator delete(void*, std::size_t)'
> [-Wuse-after-free]
>62 | virtual ~Error(){}
>   |  ^
> 
> This doesn't strike me as an arch related error but I built the package
> twice with the same result so I'm stumped.

This ought to be fixed in gcc-12.0.1-0.4.fc36 now in rawhide.

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: -D_FORTIFY_SOURCE not defined errors

[Jakub Jelinek]

On Sat, Jan 29, 2022 at 04:03:06PM +1000, Bob Hepple wrote:
> One of my packages, stable for a long time, is now getting exotic
> errors in rawhide such as
> 
> -D_FORTIFY_SOURCE not defined
> -D_GLIBCXX_ASSERTIONS not defined
> 
> Yesterday I saw (somewhere in here) that those errors are fixed in the
> latest annobin.
> 
> Should I just wait for that fix to land in koji? If so, how long?

It was fixed yesterday.
Are you sure your builds were against
gcc-12.0.1-0.3.fc36 annobin-10.51-2.fc36
and not an older version of annobin?

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: mass rebuild status - 2022-01-25

[Jakub Jelinek]

On Thu, Jan 27, 2022 at 02:01:40PM +0100, František Šumšal wrote:
> Looks like the culprit is:
> 
> In file included from common/mptPathString.cpp:13:
> ./src/mpt/uuid/uuid.hpp: In constructor 'constexpr 
> mpt::mpt_libopenmpt::UUID::UUID()':
> ./src/mpt/uuid/uuid.hpp:195:17: error: 'goto' is not a constant expression
>   195 | return;
>   | ^~
> ./src/mpt/uuid/uuid.hpp: In constructor 'constexpr 
> mpt::mpt_libopenmpt::UUID::UUID(mpt::mpt_libopenmpt::uint32, 
> mpt::mpt_libopenmpt::uint16, mpt::mpt_libopenmpt::uint16, 
> mpt::mpt_libopenmpt::uint64)':
> ./src/mpt/uuid/uuid.hpp:202:17: error: 'goto' is not a constant expression
>   202 | return;
>   | ^~

That is weird.
Tried
struct UUID
{
private:
  unsigned int Data1;
  unsigned short Data2;
  unsigned short Data3;
  unsigned long long Data4;
public:
  constexpr inline UUID() noexcept : Data1(0), Data2(0), Data3(0), Data4(0) { 
return; }
  constexpr inline explicit UUID(unsigned int Data1, unsigned short Data2, 
unsigned short Data3, unsigned long long Data4) noexcept : Data1(Data1), 
Data2(Data2), Data3(Data3), Data4(Data4) { return; }
};

constexpr UUID a;
constexpr UUID b{1, 2, 3, 4};
constexpr UUID c(1, 2, 3, 4);
but that compiles just fine, so I'll need a preprocessed source
+ g++ command line options.

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.1-0.3.fc36 now in rawhide

[Jakub Jelinek]

On Thu, Jan 27, 2022 at 10:32:22AM +0100, Thomas Haller wrote:
> On Wed, 2022-01-26 at 23:57 +0100, Jakub Jelinek wrote:
> > A new gcc with most importantly the https://gcc.gnu.org/PR104172
> > bug (that caused a lot of ppc64le failures) fixed and various other
> > fixes (e.g. std::basic_string(std::nullptr_t) = deleted only done
> > for C++23 etc.) is now in rawhide.
> > 
> > Can rel-eng please retry all FTBS builds that failed on ppc64le?
> 
> it appears to me, that this breaks build of NetworkManager:
>https://koji.fedoraproject.org/koji/taskinfo?taskID=81998774
> 
> 
>   checking if gcc supports flag -fno-strict-aliasing in envvar CFLAGS... yes
>   checking if gcc supports flag -flto -flto-partition=none in envvar 
> CFLAGS... no
>   configure: error: Link Time Optimization -flto is not supported.
>   error: Bad exit status from /var/tmp/rpm-tmp.FQqAFe (%build)

Apparently it was annobin (although it passed the test done during gcc.spec
testing, apparently it was incompatible again).
Florian has rebuilt it, so please just retry.

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

gcc-12.0.1-0.3.fc36 now in rawhide

[Jakub Jelinek]

Hi!

A new gcc with most importantly the https://gcc.gnu.org/PR104172
bug (that caused a lot of ppc64le failures) fixed and various other
fixes (e.g. std::basic_string(std::nullptr_t) = deleted only done
for C++23 etc.) is now in rawhide.

Can rel-eng please retry all FTBS builds that failed on ppc64le?

Thanks

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: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

[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: mass rebuild status - 2022-01-24

[Jakub Jelinek]

On Mon, Jan 24, 2022 at 09:15:42PM +0100, Dan Horák wrote:
> > Perhaps we could merge today and then do another pass of failed builds
> > into f36-rebuild tag and merge that back on thursday or something?
> > Can we easily identify those builds that failed due to these ppc64le
> > issues?
> 
> it sounds like a good plan to me
> 
> regarding the list of builds to retry - I would rebuild everything that
> has a failed buildArch task on ppc64le

Yeah.
Note, there will be other fixes in the upcoming gcc, like some libstdc++
changes, or -fsanitize-coverage=trace-cmp,trace-pc working again etc.,
but bet those are just a handful packages instead of lots of them.
So yes, retrying everything that failed on ppc64le looks like a good plan.

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: mass rebuild status - 2022-01-24

[Jakub Jelinek]

On Mon, Jan 24, 2022 at 08:00:31PM +0100, Vitaly Zaitsev via devel wrote:
> On 24/01/2022 19:06, Kevin Fenzi wrote:
> > This seems kind of high, so we are going to resubmit all the failed
> > builds in a short second round to reduce the chance of transitory issues
> > causing the build failures.
> 
> I think the ppc64 GCC regressions should be fixed first.

Yeah.
The current state is that both the ppc64le long double related bugs have
been discussed with IBM, I have patches for both, bootstrapping/regtesting
them now on GCCFarm and am also doing a scratch koji build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81773481
If the first testing looks ok, will submit them for upstream review,
if that is approved tonight or tomorrow will include those in tomorrow's
gcc rebuild (unlike the scratch build, that will include various other
fixes).  But ETA from the build start is ~ 20 or more hours, so Wednesday.

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 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

[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

[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

[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 breaks build with vdr-live with ppc64le on rawhide

[Jakub Jelinek]

On Sat, Jan 22, 2022 at 12:01:51PM -, Martin Gansser wrote:
> gcc-12 breaks build [1] with vdr-live with ppc64le on rawhide
> 
> g++ -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 -std=gnu++11 -fPIC -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 -shared 
> live.o thread.o tntconfig.o setup.o i18n.o timers.o tools.o recman.o tasks.o 
> status.o epg_events.o epgsearch.o grab.o md5.o filecache.o livefeatures.o 
> preload.o timerconflict.o users.o osd_status.o ffmpeg.o StringMatch.o 
> -Wl,--whole-archive pages/libpages.a css/libcss.a javascript/libjavascript.a 
> -Wl,--no-whole-archive -ltntnet  -lpcre2-8  -ltntnet  -lpcre2-8  -o 
> libvdr-live.so
> {standard input}: Assembler messages:
> {standard input}:40809: Error: junk at end of line, first unrecognized 
> character is `='
> {standard input}:40810: Error: expected comma after "operator"
> {standard input}:43903: Error: junk at end of line, first unrecognized 
> character is `+'
> {standard input}:43904: Error: expected comma after "operator"
> {standard input}:45705: Error: junk at end of line, first unrecognized 
> character is `+'
> {standard input}:45706: Error: expected comma after "operator"
> {standard input}: Assembler messages:
> {standard input}:43994: Error: junk at end of line, first unrecognized 
> character is `.'
> {standard input}:43995: Error: expected comma after "__ct_base"
> {standard input}:45212: Error: junk at end of line, first unrecognized 
> character is `('
> {standard input}:45213: Error: expected comma after "operator"
> {standard input}:53960: Error: junk at end of line, first unrecognized 
> character is `('
> {standard input}:53961: Error: expected comma after "operator"
> make[2]: *** [/tmp/ccKrB6Z5.mk:2: /tmp/cce7FcJC.ltrans0.ltrans.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> make[2]: *** [/tmp/ccKrB6Z5.mk:77: /tmp/cce7FcJC.ltrans25.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
> make[1]: *** [Makefile:210: libvdr-live.so] Error 1
> RPM build errors:
> make: *** [Makefile:143: recursive-sofile] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.BRIequ (%build)
> Bad exit status from /var/tmp/rpm-tmp.BRIequ (%build)
> Child return code was: 1
> EXCEPTION: [Error()]
> 
> 
> [1] https://kojipkgs.fedoraproject.org//work/tasks/1156/81651156/build.log
> 
> How can i fix this ?

I suspect it is https://gcc.gnu.org/PR104172, we'll fix it on the compiler
side.

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: F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)

[Jakub Jelinek]

On Sat, Jan 22, 2022 at 11:51:37AM +, Jonathan Wakely wrote:
> IIRC it wasn't that simple. The necessary entropy was *not* coming
> from uninitialized bytes. There were other sources of *real* entropy,
> but the Debian patch caused *none* of it to be added to the pool
> (except for the PID). Zeroing the uninitialized bytes would *not* hurt
> as long as the *real* sources of entropy still get added.

And one really can't rely on entropy from uninitialized variables, using
them is UB, so the compiler may already use zeros in there instead, or could
have optimized those entirely etc.

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 related issues in rawhide

[Jakub Jelinek]

On Fri, Jan 21, 2022 at 07:10:53PM +0100, Miro Hrončok wrote:
> On 21. 01. 22 19:07, Jakub Jelinek wrote:
> > On Fri, Jan 21, 2022 at 07:00:41PM +0100, Miro Hrončok wrote:
> > > On 21. 01. 22 17:55, Jakub Jelinek wrote:
> > > > In all cases, if it is some compiler error or internal compiler error,
> > > > preprocessed source + gcc command line would be highly appreciated,
> > > > having us to try to rebuild all the packages again and dig those up
> > > > will be very time consuming.
> > > 
> > > But I suppose you know the best way to obtain those?
> > > 
> > > I build the package in mock and share the entire
> > > .../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?
> > 
> > The reports are from various architectures, and mock takes some time,
> > especially if the error is hours into building.
> > I'm not saying I won't do it if what I'm asking for is not provided,
> > just that if somebody provides it to me, I will greatly appreciate it
> > and I (and my team collegues) can spend more time on fixing the bugs
> > and less on trying to reproduce them.
> > Several people already mailed me preprocessed sources (thanks a lot for
> > that) and I've been able to reply quickly to those.
> > 
> 
> Sorry for not speaking clearly. That was supposed to be a question.
> 
> What is the best way to obtain the files you need in order to share them with 
> you?

Unless it is LTO related (that complicates things), best is to rerun
whatever gcc/g++ invocation failed with an unexpected error
or internal compiler error with additional -save-temps option, that will
leave the preprocessed file around.  For ICEs, the gcc/g++ driver even tries
to reproduce ICEs and if successful stores everything I need into
/tmp/cc*.out file and writes the name of that file to stderr.
So, if one sees that, using fedpkg to request tarball from the failed build
is one possibility and then copying the /tmp/cc*.out file out of there.
When it is reproducible in a local mock, rerunning the command by hand with
-save-temps is easy too, without access to the arch, one option is to hack
up the spec file, such that it will do:
make usual_stuff || \
( Either uuencode compressed /tmp/cc*.out to stdout here so that it shows up
in build.log or rerun failing gcc/g++ command line with the added
-save-temps here and uuencode compressed *.i or *.ii to stdout etc.
exit 1 )
(done that several times in the past when needed).

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 related issues in rawhide

[Jakub Jelinek]

On Fri, Jan 21, 2022 at 07:00:41PM +0100, Miro Hrončok wrote:
> On 21. 01. 22 17:55, Jakub Jelinek wrote:
> > In all cases, if it is some compiler error or internal compiler error,
> > preprocessed source + gcc command line would be highly appreciated,
> > having us to try to rebuild all the packages again and dig those up
> > will be very time consuming.
> 
> But I suppose you know the best way to obtain those?
> 
> I build the package in mock and share the entire
> .../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?

The reports are from various architectures, and mock takes some time,
especially if the error is hours into building.
I'm not saying I won't do it if what I'm asking for is not provided,
just that if somebody provides it to me, I will greatly appreciate it
and I (and my team collegues) can spend more time on fixing the bugs
and less on trying to reproduce them.
Several people already mailed me preprocessed sources (thanks a lot for
that) and I've been able to reply quickly to those.

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 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

GCC 12 related issues in rawhide

[Jakub Jelinek]

Hi!

There have been way too many mails recently in the
gcc-12.0.0-0.4.fc36 in rawhide thread and separate threads,
so for those which we haven't responded to yet or new issues,
can I ask you to track it in bugzilla instead of mailing list?

For issues where you suspect it is a bug on a package side and
you'd just like the compiler team to help answer questions,
please file a FTBS bug against the package which fails to build
and CC me and/or Marek Polacek and/or for libstdc++ related questions
Jonathan Wakely.
For issues where you suspect or are sure about a bug on the compiler
side please file a bug against GCC (worst case the component can
be changed against the package).

In all cases, if it is some compiler error or internal compiler error,
preprocessed source + gcc command line would be highly appreciated,
having us to try to rebuild all the packages again and dig those up
will be very time consuming.

Thanks

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 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 no longer understands -fsanitize-coverage=trace-pc,trace-cmp

[Jakub Jelinek]

On Fri, Jan 21, 2022 at 09:15:04AM +, Richard W.M. Jones wrote:
> 
> honggfuzz fails to build in Rawhide with:
> 
>   + hfuzz_cc/hfuzz-gcc hello.c -o hello
>   gcc: error: unrecognized argument in option 
> '-fsanitize-coverage=trace-pc,trace-cmp'
>   gcc: note: valid arguments to '-fsanitize-coverage=' are: trace-cmp trace-pc
> 
> Note the flag is added by honggfuzz itself when it instruments a
> binary:
> 
>   
> https://github.com/google/honggfuzz/blob/876ff411938b1ab911c213bf640e2696e7ebd695/hfuzz_cc/hfuzz-cc.c#L375
> 
> This worked with older GCC.  It also works if I patch honggfuzz like this:

Filed https://gcc.gnu.org/PR104158 and am going to look at it.

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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

[Jakub Jelinek]

On Fri, Jan 21, 2022 at 09:08:35AM +, Richard W.M. Jones wrote:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81468000
> 
> This seems like a compiler bug or a bug in the standard switches being
> added by RPM on ppc64le.  SLOF itself does not appear to add or adjust
> the -mtune flag.
> 
> Rich.
> 
> powerpc64-linux-gnu-gcc -m64  -I../libc/include -DCPU_PPCP7 
> -I/builddir/build/BUILD/SLOF-qemu-slof-20210217/include 
> -I/builddir/build/BUILD/SLOF-qemu-slof-20210217/include/ppcp7 -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  -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -o 
> elf32.o -c /builddir/build/BUILD/SLOF-qemu-slof-20210217/lib/libelf/elf32.c
> make[3]: Leaving directory 
> '/builddir/build/BUILD/SLOF-qemu-slof-20210217/lib/libelf'
> powerpc64-linux-gnu-gcc: error: unrecognized argument in option 
> '-mtune=generic'
> powerpc64-linux-gnu-gcc: note: valid arguments to '-mtune=' are: 401 403 405 
> 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 
> 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell e300c2 e300c3 
> e500mc e500mc64 e5500 e6500 ec603e native power10 power3 power4 power5 
> power5+ power6 power6x power7 power8 power9 powerpc powerpc64 powerpc64le 
> rs64 titan

gcc has never supported -mtune=generic on ppc*, and redhat-rpm-config
doesn't list it either for ppc* (only i386/i586/i686/x86_64).
But if something puts that into CFLAGS, I'd expect all ppc64le builds to
fail, not just this one.

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 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

[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 
> > > /builddir/build

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

[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

[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

[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

[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

[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

[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

[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

[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&dirty 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

[Jakub Jelinek]

On Sat, Jan 15, 2022 at 01:06:48PM +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.
> 
> On ppc64le:
> 
> gcc -c -std=gnu99 -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
> -pipe -Iinclude/ -IOpenCL/ -Ideps/LZMA-SDK/C -I/usr/include
> -I/usr/include/contrib -I/usr/include -DWITH_BRAIN -I/usr/include
> -DWITH_CUBIN -DWITH_HWMON src/affinity.c -o obj/affinity.NATIVE.o -fpic
> In file included from /usr/include/CL/cl_platform.h:379,
>  from /usr/include/CL/cl.h:21,
>  from include/ext_OpenCL.h:17,
>  from include/types.h:1095,
>  from src/affinity.c:7:
> /usr/lib/gcc/ppc64le-redhat-linux/12/include/altivec.h:58:10: fatal error:
> rs6000-vecdefines.h: No such file or directory
>58 | #include "rs6000-vecdefines.h"
>   |  ^
> compilation terminated.
> make: *** [src/Makefile:565: obj/affinity.NATIVE.o] Error 1

That is #2040825 and gcc-12.0.0-0.5.fc36 that should fix it is building in
koji for 12 hours already.

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]

CCing Martin.

On Sat, Jan 15, 2022 at 09:04:35AM +, Richard W.M. Jones wrote:
> There is a new warning in gcc-12.0.0-0.4.fc36.x86_64.  In this code:
> 
>   int
>   guestfs_int_create_socketname (guestfs_h *g, const char *filename,
>  char (*sockpath)[UNIX_PATH_MAX])
>   {
> if (guestfs_int_lazy_make_sockdir (g) == -1)
>   return -1;
>   
> if (strlen (g->sockdir) + 1 + strlen (filename) > UNIX_PATH_MAX-1) {
>   error (g, _("socket path too long: %s/%s"), g->sockdir, filename);
>   return -1;
> }
>   
> snprintf (*sockpath, UNIX_PATH_MAX, "%s/%s", g->sockdir, filename);
>   
> return 0;
>   }
> 
> [https://github.com/libguestfs/libguestfs/blob/d1e7e1a323619d8f1e913a7833d07009f02a2d33/lib/launch.c#L324]
> 
> the new warning is:
> 
>   launch.c: In function ‘guestfs_int_create_socketname’:
>   launch.c:336:43: error: ‘%s’ directive output may be truncated writing up 
> to 106 bytes into a region of size between 1 and 107 
> [-Werror=format-truncation=]
> 336 |   snprintf (*sockpath, UNIX_PATH_MAX, "%s/%s", g->sockdir, 
> filename);
> |   ^~
>   In file included from /usr/include/stdio.h:894,
>from launch.c:30:
>   In function ‘snprintf’,
>   inlined from ‘guestfs_int_create_socketname’ at launch.c:336:3:
> /usr/include/bits/stdio2.h:71:10: note: ‘__snprintf_chk’ output between 2 and 
> 2  14 bytes into a destination of size 108
>  71 |   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 
> 1,
> |  
> ^~~~
>  72 |__glibc_objsize (__s), __fmt,
> |~
>  73 |__va_arg_pack ());
> |~
>   cc1: all warnings being treated as errors
> 
> *sockpath is a fixed buffer of size UNIX_PATH_MAX == 108.  We check
> that strlen (g->sockdir) + strlen (filename) + 1 (for the '/'
> character) > UNIX_PATH_MAX - 1 (for the terminating '\0').
> 
> The check seems correct as far as I can tell.  I don't think I'm
> making a fencepost error here.  Why does GCC 12 think there should be
> a warning when GCC 11 didn't?
> 
> I've attached a standalone test case.
> 
>   $ gcc -O2 -Wall sp.c -o sp
>   sp.c: In function ‘create_sockpath’:
>   sp.c:12:43: warning: ‘%s’ directive output may be truncated writing up to 
> 106 bytes into a region of size between 1 and 107 [-Wformat-truncation=]
>  12 |   snprintf (*sockpath, UNIX_PATH_MAX, "%s/%s", sockdir, filename);
> |   ^~
>   sp.c:12:3: note: ‘snprintf’ output between 2 and 214 bytes into a 
> destination of size 108
>  12 |   snprintf (*sockpath, UNIX_PATH_MAX, "%s/%s", sockdir, filename);
> |   ^~~
> 
> (No warning with gcc-11.2.1-1.fc35.x86_64)
> 
> 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

> /* gcc -O2 -Wall sp.c -o sp */
> 
> #include 
> #include 
> #include 
> #include 
> 
> void
> create_sockpath (const char *sockdir, const char *filename,
>  char (*sockpath)[UNIX_PATH_MAX])
> {
>   if (strlen (sockdir) + 1 + strlen (filename) > UNIX_PATH_MAX - 1)
> abort ();
>   snprintf (*sockpath, UNIX_PATH_MAX, "%s/%s", sockdir, filename);
> }
> 
> int
> main (int argc, char *argv[])
> {
>   char sockpath[UNIX_PATH_MAX];
> 
>   if (argc != 3) {
> fprintf (stderr, "%s sockdir filename\n", argv[0]);
> exit (EXIT_FAILURE);
>   }
> 
>   create_sockpath (argv[1], argv[2], &sockpath);
>   printf ("sockpath = %s\n", sockpath);
>   exit (EXIT_SUCCESS);
> }

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

gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

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

Re: GCC crash on Fedora Rawhide armv7

[Jakub Jelinek]

On Tue, Nov 23, 2021 at 05:19:09PM +0100, Dan Horák wrote:
> > | ^
> >   Please submit a full bug report,
> >   with preprocessed source if appropriate.
> >   See  for instructions.
> >   Preprocessed source stored into /tmp/ccOFlWwZ.out file, please attach 
> > this to your bugreport.
> > 
> > Unfortunately the crash happened in Koji:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=79160330
> > 
> > I'm not able to reproduce it locally, which is strange.  I've got an
> > armv7 guest which has the same version of gcc, binutils and annobin,
> > yet it does not crash compiling the same file.
> > 
> > I wonder if anyone can manage to reproduce this and capture the
> > /tmp/*.out file?  In theory all you need to do is build qemu from
> > dist-git on armv7.
> 
> I was able to get the preprocessed file from the builder, it's
> available at https://fedora.danny.cz/tmp/ccOFlWwZ.out now

Reproduced with current GCC trunk, will reduce/bisect it tomorrow and file an
upstream 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: LTO objects after build: Rebuilding vs erroring out

[Jakub Jelinek]

On Mon, Nov 15, 2021 at 12:13:19PM -0700, Jeff Law wrote:
> > with somehting that errors out (fails the build) if any relocatable
> > object files (.o) or static archives (.a) by default, and stop producing
> > object code by default, only LTO representation.  If a special
> > redhat-rpm-config flag is set, brp-strip-lto comes back, and GCC is
> > configured to produce both object code and LTO representation (basically
> > what we have today).
> Right.  In fact, I had a brp-strip-lto which did precisely this and I did a
> Fedora build with that brp-strip-lto to get a set of packages that wanted to
> install a .o or .a composed from .o files. I did a build with that, but I
> don't have the results anymore.

What we perhaps could try (but not sure how far we could get) if we detect
in an installed *.a or *.o GCC LTO bytecode, instead of erroring out and
failing the build try to convert it to normal *.o file (for *.a recursively
for each *.o file in there with LTO bytecode) - at least if debug info
is emitted and there is DW_AT_producer, try to reconstruct gcc command line
and gcc -r that_perhaps_slightly_massaged_command_line -o new.o old.o

Or if we recorded all command line options we care about into LTO bytecode
(Optimization/Target options are recorded already on a per-function basis
but I'm worried about others), just have a gcc driver mode that turns
a non-fat LTO object into normal non-LTO object.

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: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Jakub Jelinek]

On Thu, Nov 04, 2021 at 10:26:20AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > We checked compression, and it just isn't worth it. When you compress
> > 100–200 bytes, the output might be a tiny bit smaller, but then the
> > compression alg header is added it becomes a wash. And we lose an important
> > properties of simplicity and ability to read this in a text dump without
> > further processing. It just isn't worth it.
> 
> Example:
> $ cat /tmp/payload
> {"type":"rpm","name":"systemd","version":"249.4-1.fc35","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:35"}
> $ for c in zstd gzip xz; do $c -k /tmp/payload; done
> $ ls -l /tmp/f*
>  122 /tmp/f
>  125 /tmp/f.gz
>  172 /tmp/f.xz
>  120 /tmp/f.zst

But a binary representation of that could strip it down into ~50%.

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: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Jakub Jelinek]

On Thu, Nov 04, 2021 at 10:56:04AM +0100, Florian Weimer wrote:
> >> The general case of any statically linked code.  It could be libgcc,
> >> startup files, the non-shared bits of glibc, static-only libraries, or
> >> header-only C++ libraries.
> 
> > This would be indeed useful, but quite harder to do automagically I
> > think?
> 
> It requires some level of toolchain support, in compilers and linkers.
> 
> It's unlikely that this would use a JSON-based approach, though.  I
> think what we want in the linker for this is that it de-duplicates and
> merges individual artifact identifiers, so that one ends up with a
> single string "glibc-2.34-7.fc35" instead of multiple copies of it.  But
> I can't see us implementing JSON processing in the linker (all four of
> them).

I think JSON is a bad idea for the notes in this proposal either, it really
wastes memory per process and so should be encoded in some binary form in as
few bytes as possible, or perhaps at least compressed JSON.

For the package NVR gathering from all the *.o/*.a files, I'm not sure you
need much toolchain support, just let some brp-* policy file inject
a SHF_MERGE|SHF_STRINGS (and please, non-SHF_ALLOC!) note section with
sh_addralign 1 and the linkers should DTRT already.

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: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Jakub Jelinek]

On Mon, Oct 25, 2021 at 03:09:00PM -0400, Ben Cotton wrote:
> === New system: `.note.package` ===
> 
> The new note is created and propagated similarly to
> `.note.gnu.build-id`. The difference is that we inject the information
> about package ''nevra'' from the build system.

Is the .note.package an allocated note or not?
I.e. is it not just up to ~ 13MB on disk, but also ~ 200 bytes for each
process in memory?

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: Stability of armv7hl builders

[Jakub Jelinek]

On Wed, Oct 20, 2021 at 03:22:13PM +0200, Iñaki Ucar wrote:
> I asked this in another thread, but maybe this is related to [1]? How
> do we disable just link-time parallelism?

gcc uses its --with-build-config=bootstrap-lto --enable-link-serialization=1
when building gcc with LTO is enabled and the latter option ensures through
Makefile dependencies that for the large link commands only one is done at a
time.
And, for the new builds I've disabled the building with LTO, i.e.
%if 0%{?fedora} >= 35 || 0%{?rhel} >= 9
%ifnarch %{arm}
--with-build-config=bootstrap-lto --enable-link-serialization=1 \
%endif
%endif
and so it should consume even less memory.
Also, even when watching the LTO build that took more than 6 days,
several times I saw it going into the %check phase with running just the
testsuite.

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

Stability of armv7hl builders

[Jakub Jelinek]

Hi!

I've been trying to build gcc in rawhide and f35 for more than a week now,
but haven't succeeded due to instability of the armv7hl builders.
E.g. the
https://koji.fedoraproject.org/koji/taskinfo?taskID=77117620
build succeeded on all but armv7hl in less than 22 hours (on aarch64
even took less than 5 hours), but armv7hl kept rebooting or whatever
(impossible to find out from the logs) 8 times, see
https://koji.fedoraproject.org/koji/taskinfo?taskID=77117797
Buildroots list.
Eventually I've cancelled that build after 151 hours, disabled
LTO on armv7hl (for GCC bootstrap) and am building now
https://koji.fedoraproject.org/koji/taskinfo?taskID=77518894
https://koji.fedoraproject.org/koji/taskinfo?taskID=77518968
but those again show total time of ~ 21 hours, but armv7hl task times
of 1.5 and 10 hours, so the f35 build was retried already 2 times and f36
once.

Any recent kernel changes on the boxes, or is there any way to find out
what's going on with them, whether it oopses, OOMs or something else?

In late August the package built just fine and took ~ 27 hours to build on
armv7hl.

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: i686 build OOMing

[Jakub Jelinek]

On Thu, May 20, 2021 at 04:57:03AM +1000, David Airlie wrote:
> > On Tue, May 18, 2021 at 04:59:50PM -0600, Jeff Law wrote:
> > >
> > > On 5/18/2021 4:44 PM, David Airlie wrote:
> > > > https://kojipkgs.fedoraproject.org//work/tasks/3814/68223814/build.log
> > > >
> > > > cd 
> > > > /builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu/layers
> > > > && /usr/bin/g++ -DAPI_NAME=\"Vulkan\" -DVK_ENABLE_BETA_EXTENSIONS
> > > > -DVK_USE_PLATFORM_WAYLAND_KHR -DVK_USE_PLATFORM_WAYLAND_KHX
> > > > -DVK_USE_PLATFORM_XCB_KHR -DVK_USE_PLATFORM_XCB_KHX
> > > > -DVK_USE_PLATFORM_XLIB_KHR -DVK_USE_PLATFORM_XLIB_KHX
> > > > -DVK_USE_PLATFORM_XLIB_XRANDR_EXT -DVkLayer_khronos_validation_EXPORTS
> > > > -I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/layers
> > > > -I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/layers/generated
> > > > -I/usr/include/glslang -I/usr/include/spirv/include
> > > > -I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu
> > > > -I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu/layers
> > > > -O2 -flto=auto -ffat-lto-objects -fexceptions -g1
> > > > -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
> > > > -m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign
> > > > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> > > > -Wpointer-arith -Wno-unused-function -Wno-sign-compare -DNDEBUG -fPIC
> > > > -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
> > > > -fno-strict-aliasing -fno-builtin-memcmp -fvisibility=hidden
> > > > -Wimplicit-fallthrough=0 -std=gnu++11 -MD -MT
> > > > layers/CMakeFiles/VkLayer_khronos_validation.dir/generated/chassis.cpp.o
> > > > -MF CMakeFiles/VkLayer_khronos_validation.dir/generated/chassis.cpp.o.d
> > > > -o CMakeFiles/VkLayer_khronos_validation.dir/generated/chassis.cpp.o
> > > > -c 
> > > > /builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/layers/generated/chassis.cpp
> > > > cc1plus: out of memory allocating 65536 bytes after a total of 
> > > > 3310292992 bytes
> > > >
> > > > We already use -g1 to try and reduce memory usage, and I tried not
> > > > doing parallel jobs in case it was too much? any suggestions, is this
> > > > LTO?
> > >
> > > Not likely LTO since this isn't a link phase AFAICT.
> >
> > And parallel jobs reduction isn't likely to help out, it looks like the
> > single cc1plus process is hitting the 3GB/1GB split anyhow. ;(
> 
> Oh wow I forgot that existed, so it's not even a VM configuration issue.
> 
> I'll go reproduce somewhere locally and experiment in more detail by
> removing my hair.

As a start, it would be useful to have preprocessed source so that it can be
looked at without the rest of the package.
One interesting thing is try to compile it (the preprocessed testcase with
the same command line options) on x86_64 with -m32 -fmem-report and see
where the memory is spent there (of course, on x86_64 it will take slightly
more memory as pointers are larger).
Removing -flto could save some memory; otherwise, it ddepends on where most
of the memory goes, if into optimizations, perhaps disable some of them or
compile with -O1 etc., either for the whole file or just some of the largest
functions.  If the memory is eaten already in the C++ FE, like instantiation
of excessively large (or too many) templates, then splitting the source
might be the only way to make it compile.

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: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Jakub Jelinek]

On Mon, Apr 26, 2021 at 09:51:50AM -0600, Jeff Law wrote:
> 
> On 4/24/2021 8:26 AM, Michael Catanzaro wrote:
> > On Fri, Apr 23 2021 at 08:01:03 PM +0200, Jakub Jelinek
> >  wrote:
> > > I'll be probably repeating myself, but the two compilers are known to be
> > > ABI incompatible in very important ways, none of the
> > > https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207
> > > 
> > > bugs have been touched since last time this was discussed and I'm
> > > not aware
> > > of any ABI compatibility testing between the two compilers.
> > > So if some library packages switch compilers and programs using those
> > > libraries don't or vice versa, this proposal has quite high risks of
> > > introducing hard to debug debugs.
> > 
> > Perhaps this proposal should be revisited in the future when there are
> > fewer scary ABI bugs.
> 
> That's not really a scary ABI bug.   There's disagreement about a fairly
> unusual case involving extension of 8 bit arguments and some issues with 128

There is disagreement on passing all 8-bit and 16-bit arguments by value on
x86_64, which in many cases works just by pure luck because GCC often
emits the extension even on the caller side where it is not mandated by the 
psABI,
while LLVM relies on an extension the psABI doesn't guarantee.
Several packages already ran into this in the past, I don't think we can
ignore that one.

The va_arg passing bug for __int128 is less important, sure, most packages
don't use 128-bit integers and if they do, they rarely pass it through
va_arg.  But having 8-bit and 16-bit arguments on ABI boundaries is very
common.

That is one thing and the other one is that the interoperability testing
between the two compilers wasn't really performed, so besides those known
bugs there can be unknown ones.

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: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Jakub Jelinek]

On Mon, Apr 26, 2021 at 09:43:34AM -0600, Jeff Law wrote:
> 
> On 4/26/2021 8:20 AM, Kevin Kofler via devel wrote:
> > Vít Ondruch wrote:
> > > Kevin, I'd love to support your stance and use GCC. However, there are
> > > reasons why we will need to consider Clang for e.g. Ruby:
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1721553
> > > 
> > > And the reason is not even that upstream favors Clang. The situation is
> > > unfortunately not just black and white.
> > Looks like the best solution there is to disable PCH support in the Ruby
> > JIT.
> 
> FWIW Vit, myself and others have already extensively discussed this
> situation.  Clang is really the best solution in the case of the Ruby JIT
> given the various constraints in play.

Isn't that MIR instead?

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: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Jakub Jelinek]

On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
> The Red Hat tools team believes that LLVM/Clang and GCC should be
> considered equals from
> a Fedora policy standpoint.  Selection of one toolchain over the other should 
> be
> driven by the packager's preferences not by Fedora specific policy.
> The only policy restriction should be that the compiler must exist in
> Fedora.

I'll be probably repeating myself, but the two compilers are known to be
ABI incompatible in very important ways, none of the
https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207
bugs have been touched since last time this was discussed and I'm not aware
of any ABI compatibility testing between the two compilers.
So if some library packages switch compilers and programs using those
libraries don't or vice versa, this proposal has quite high risks of
introducing hard to debug debugs.

I agree that for open source software and generally for users it is useful
if there are multiple competing implementations, in this case for the
toolchain, and the competition has been IMHO quite fruitful for both GCC and
LLVM over the past years.  It is also very useful if open source packages
are made portable or kept portable, so that one can use multiple compilers
to compile them, one can benefit from different diagnostics, instrumentation
etc.  But I'm not sure this proposal is a step in the right direction
though, e.g. in the Firefox case that is being used as an example for this
proposal that leads in a completely different direction, a package that has
been formerly portable and supported multiple compilers will turn into a
single compiler only application and will lose its portability.
Google, Apple, BSDs don't really care about toolchain choice and they push
a single toolchain only.

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: unrecognized DWARF version in .debug_info at 6

[Jakub Jelinek]

On Wed, Jan 27, 2021 at 05:54:48AM -0700, Jeff Law wrote:
> On 1/27/21 5:48 AM, Sandro Mani wrote:
> > Apitrace is currently failing to build, with [1]
> >
> > Test project 
> > /builddir/build/BUILD/apitrace-37c36e66b8cfa534797ca565c22e8c30923f35d4/x86_64-redhat-linux-gnu
> > Start 1: libbacktrace_btest
> > 1/6 Test #1: libbacktrace_btest ...***Exception: SegFault  0.11 
> > sec
> > unrecognized DWARF version in .debug_info at 6
> >
> > Some dwz issues were mentioned in the runup to the mass rebuild, is this a 
> > related issue?
> More likely it doesn't understand dwarf5.  GCC changed from defaulting
> from dwarf-v4 to dwarf-v5.
> 
> I don't offhand recall if apitrace has a copy of GCC's libbacktrace or
> its own complete reimplementation.  If it's the former, then you might
> consider resyncing with GCC or picking up these changes from
> gcc.gnu.org/git/gcc.git:
> 
> 
> commit bfde774667fbce6d7d326c8a36a098138e224a95
> Author: Ian Lance Taylor 
> Date:   Mon Jan 18 14:45:57 2021 -0800
> 
>     libbacktrace: don't fail tests if dwz fails
>    
>     * Makefile.am (%_dwz): If dwz fails, use uncompressed debug
> info.
>     * Makefile.in: Regenerate.
>     * configure: Regenerate.
> 
> commit 325e70b47c6c321710c7b9c792b8fbee95cecd63
> Author: Ian Lance Taylor 
> Date:   Mon Jan 18 14:38:10 2021 -0800
> 
>     libbacktrace: use correct directory/filename for DWARF 5
>    
>     PR debug/98716
>     * dwarf.c (read_v2_paths): Allocate zero entry for dirs and
>     filenames.
>     (read_line_program): Remove parameter u, change caller.  Don't
>     subtract one from dirs and filenames index.
>     (read_function_entry): Don't subtract one from filenames index.

unrecognized DWARF version means that
2019-12-13  Ian Lance Taylor  

Add DWARF 5 support.
must be missing there 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