Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

On Tue, Jul 05, 2022 at 03:47:26PM -0400, Matthias Clasen wrote: > On Tue, Jul 5, 2022 at 3:40 PM Marek Polacek wrote: > > > > > Maybe not, but even ~1% is still an unacceptable slowdown. It would take > > about a year for the compiler to catch up. > > >

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

On Tue, Jul 05, 2022 at 03:15:02PM -0400, Matthias Clasen wrote: > On Thu, Jun 30, 2022 at 4:55 AM Kevin Kofler via devel < > devel@lists.fedoraproject.org> wrote: > > > Daan De Meyer via devel wrote: > > > Which shows a smaller than 1% slowdown between the binary built with > > frame > > >

Re: adding GCC Toolset usage docs

On Wed, Apr 13, 2022 at 07:08:13PM +0200, Germano Massullo wrote: > Hello, in my opinion we should add to Fedora Packaging Guidelines, a > paragraph concerning GCC Toolset usage. > > I recently experienced some problems in building darktable for > epel8/epel8-next due bad configuration of

Re: [fyi] Folly stack temporarily switched to Clang for Fedora 36+

On Thu, Mar 10, 2022 at 11:37:03AM -0800, Michel Alexandre Salim wrote: > Dear all, > > Just a heads-up that Folly and packages built against it are mostly* > switched to build using Clang for the time being, when compiled on > Fedora 36 and above. > > * the exception is watchman, which needs

Re: gcc-12.0.0-0.4.fc36 in rawhide

On Fri, Jan 21, 2022 at 06:33:21PM +0100, Dan Horák wrote: > On Fri, 21 Jan 2022 09:55:01 -0700 > Jerry James wrote: > > > On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek wrote: > > > Another important thing I wanted to say is that we'd like to switch > > > ppc64le from the numerically

Re: F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)

s the kernel that would most benefit from the option, and it looks like it already has support for it: CONFIG_INIT_STACK_ALL_ZERO CONFIG_INIT_STACK_ALL_PATTERN so maybe it's enough to enable it for the kernel. Or start there, see how it does, then add it to our hardening flags. -- Marek Polacek • Red Ha

Re: Packaging for EPEL8 with gcc-9+

On Wed, May 12, 2021 at 03:45:01PM +, Gary Buhrmaster wrote: > On Wed, May 12, 2021 at 9:49 AM Евгений Пивнев wrote: > > > > Is there any real package .spec that use cc-toolset-9 as example? > > SCL documentation is too extensive and mostly about creating new SCL, > > I cannot find short

Re: Possible gcc/s390x bug (was Re: Mass rebuild status)

On Tue, Feb 04, 2020 at 11:08:22AM -0500, Marek Polacek wrote: > On Tue, Feb 04, 2020 at 10:51:17AM -0500, Adam Jackson wrote: > > On Sat, 2020-02-01 at 16:59 -0800, Kevin Fenzi wrote: > > > > > See > > > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-fa

Re: Possible gcc/s390x bug (was Re: Mass rebuild status)

On Tue, Feb 04, 2020 at 10:51:17AM -0500, Adam Jackson wrote: > On Sat, 2020-02-01 at 16:59 -0800, Kevin Fenzi wrote: > > > See > > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html > > and > > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-need-rebuild.html > > > > for

GCC 8/9 ABI change: call for rebuilds

Recently a serious bug in the compiler was discovered whereby we miscompiled several packages. The problem only occurs in C++ programs that contain a class with a trivial move constructor and deleted copy constructor. For such programs, the calling convention changed inappropriately, in the sense

Re: GCC 8 ABI change on x86_64

On Wed, Mar 07, 2018 at 09:19:15PM -0800, Adam Williamson wrote: > On Wed, 2018-03-07 at 19:50 +0100, Marek Polacek wrote: > > Recently we discovered a serious bug in the compiler whereby we miscompiled > > several packages. The problem started with my ABI-changing patch whi

Re: GCC 8 ABI change on x86_64

On Wed, Mar 07, 2018 at 09:36:29PM +0100, Jakub Jelinek wrote: > On Wed, Mar 07, 2018 at 12:27:34PM -0800, Adam Williamson wrote: > > On Wed, 2018-03-07 at 19:50 +0100, Marek Polacek wrote: > > > Recently we discovered a serious bug in the compiler whereby we > > >

Re: GCC 8 ABI change on x86_64

On Wed, Mar 07, 2018 at 07:20:18PM +, Sérgio Basto wrote: > On Wed, 2018-03-07 at 19:50 +0100, Marek Polacek wrote: > > I did another mass rebuild with a specially-tweaked gcc in order to > > find out > > which packages need to be rebuild with patched gcc-8.0.1-0.16.

GCC 8 ABI change on x86_64

Recently we discovered a serious bug in the compiler whereby we miscompiled several packages. The problem started with my ABI-changing patch which changed how empty classes are passed, as per the x86_64 psABI (so this bug only affects x86_64). The problem could arise when the code contained

Re: Fedora mass rebuild 2018

On Fri, Feb 23, 2018 at 04:09:26PM +, Richard W.M. Jones wrote: > On Thu, Feb 22, 2018 at 06:49:02PM +0100, Marek Polacek wrote: > > libguestfs-1.37.35-2.fc28.src.rpm > > I'm not sure about these failures, but they don't seem to be GCC bugs. > > Is there a log file?

Fedora mass rebuild 2018

As many of you know, every year we (the GCC team) rebuild all the Fedora packages with the upcoming GCC, so as to reveal as many bugs as possible before we release the new version. As in the previous years, it is only performed on x86_64 only; we unfortunately lack the resources to deal with

Re: internal compiler error: in ix86_expand_prologue, at config/i386/i386.c:14572

On Thu, Jan 25, 2018 at 03:15:05PM +0100, Michael Schwendt wrote: > Are recent GCC changes we need to be aware of? > > i686 build ends due to various internal compiler errors. > The same code has built fine before a few months ago. > >

Re: ARM and AArch64 GCC 7.1 ABI change

On Tue, Apr 25, 2017 at 12:55:47PM -0500, Dennis Gilmore wrote: > El mar, 25-04-2017 a las 17:52 +0200, Jakub Jelinek escribió: > > Hi! > > > > A severe ABI bug on AArch64 and especially on ARM 32-bit has been > > recently discovered and GCC 7.1 is going to have that ABI change in. > > For

Re: Fedora mass rebuild 2017

On Tue, Feb 14, 2017 at 09:42:53PM -0500, Orcan Ogetbil wrote: > On 7 February 2017 at 16:32, Marek Polacek wrote: > > libffado-2.3.0-1.fc26.src.rpm > > sflphone-1.4.1-20.fc26.src.rpm > > error: no matching function for call to ... > > Invalid code. >

Re: undefined reference to `sf::String::operator std::__cxx11::basic_string

On Tue, Feb 14, 2017 at 01:27:27PM -, Martin Gansser wrote: > Hi, > > when compiling marsshooter on rawhide it fails with the following error > message: > undefined reference to `sf::String::operator std::__cxx11::basic_string std::char_traits, std::allocator >() const' > > This is

Fedora mass rebuild 2017

It's been a tradition now that every January we rebuild all the Fedora packages with the upcoming GCC, to reveal as many bugs as possible before we release the new version. This year is no different. There were 18811 packages overall (last year we had 17741 packages). 17263 built fine with the

Fedora mass rebuild 2016

In the past few days and weeks we did a mass rebuild of Fedora rawhide packages in mock with GCC 6 (and corresponding libtool) and for those packages that failed also rebuilt the same package with gcc-5.3.1-2.fc23.x86_64 to quickly remove from the list packages that fail for non-GCC related

Re: GCC 6 -Wnonnull is too aggressive

On Fri, Feb 19, 2016 at 01:04:04PM +0100, Petr Spacek wrote: > On 19.2.2016 08:50, Jakub Jelinek wrote: > > On Fri, Feb 19, 2016 at 03:12:29AM +0100, Kevin Kofler wrote: > >> Jakub Jelinek wrote: > >>> ASSERT(this) is pointless, it is testing if undefined behavior didn't > >>> happen after the

Re: GCC 6 Binaries segfaulting

On Mon, Feb 15, 2016 at 02:33:18PM -0600, Richard Shaw wrote: > I tried adding the workaround mentioned but it didn't seem to help. I responded in the BZ, but -fno-delete-null-pointer-checks really does help in this case, so this isn't a bug in the compiler. Marek -- devel mailing list

Re: gcc6 / arm rebuild issue

On Thu, Feb 11, 2016 at 06:35:25PM +0100, François Cami wrote: > Hi, > > openal-soft fails to build on arm / f24, probably due to a toolchain change: > " > /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0/include/arm_neon.h:9013:1: > error: inlining failed in call to always_inline 'vld1q_f32':

Re: Another GCC 6 & Rawhide build failure

On Wed, Feb 03, 2016 at 02:10:46PM -0500, Tom Callaway wrote: > On 02/03/2016 01:57 PM, Florian Weimer wrote: > > > Okay, self-contained test case is: > > > > struct GVector4 { > > GVector4(int); > > }; > > struct GNamedSVGcolor { > > char Name[22]; > > GVector4 RGBA; > > }; > > > >

Re: Access to failed builds [Was: gcc5 ICE xserver build on ARM]

On Tue, Feb 17, 2015 at 09:56:20AM +0100, Jakub Jelinek wrote: On Tue, Feb 17, 2015 at 08:45:09AM +, Andrew Haley wrote: On 17/02/15 07:21, David Airlie wrote: Well I can't provide any info, I don't have an ARM box here, and it happens in the buildroot which I don't think I can

Re: Access to failed builds [Was: gcc5 ICE xserver build on ARM]

On Tue, Feb 17, 2015 at 07:19:35AM -0500, Josh Boyer wrote: On Feb 17, 2015 7:10 AM, Peter Robinson pbrobin...@gmail.com wrote: Indeed, reproducing the failures only to get a /tmp/ccXX.out file is not exactly fun. In a related vein, I think ABRT should bundle the

Re: gcc5 ICE xserver build on ARM

On Tue, Feb 17, 2015 at 12:26:57AM -0500, David Airlie wrote: Just kicked off an Xserver build in rawhide, and it appears gcc ICE. http://koji.fedoraproject.org/koji/getfile?taskID=8960146name=build.log libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H -Wall

Re: gcc5 ICE xserver build on ARM

On Tue, Feb 17, 2015 at 07:14:43AM +0100, Marek Polacek wrote: On Tue, Feb 17, 2015 at 12:26:57AM -0500, David Airlie wrote: Just kicked off an Xserver build in rawhide, and it appears gcc ICE. http://koji.fedoraproject.org/koji/getfile?taskID=8960146name=build.log libtool: compile

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22

On Wed, Feb 11, 2015 at 02:58:25PM +0100, Jakub Jelen wrote: On 02/08/2015 06:17 PM, Marek Polacek wrote: To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek) have performed a test mass rebuild of rawhide (January 15th package list) using gcc-5.0.0-0.5.fc22 on x86_64

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22

On Wed, Feb 11, 2015 at 06:25:10AM -0500, Matej Stuchlik wrote: python3-3.4.2-3.fc22.src.rpm build started failing with http://gcc.gnu.org/PR60517 The code has an undefined behavior (returning address of a local variable); it tried to perform a stack overflow, but the

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22

On Sun, Feb 08, 2015 at 06:17:56PM +0100, Marek Polacek wrote: criu-1.4-1.fc22.src.rpm gcc bug - rejects valid code in C99 mode ([X ... Y] style initialization, a GNU extension). not fixed yet, http://gcc.gnu.org/PR64856 Fixed upstream now. Marek -- devel mailing

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22

On Mon, Feb 09, 2015 at 02:43:25PM -0700, Jerry James wrote: On Sun, Feb 8, 2015 at 10:17 AM, Marek Polacek pola...@redhat.com wrote: bigloo-4.1a-6.2.fc22.src.rpm memstomp-0.1.4-15.fc22.src.rpm build failure due to gnu11 change: -Wimplicit-int is turned on by default now

Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22

To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek) have performed a test mass rebuild of rawhide (January 15th package list) using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove