F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates

[Jan Kurik]

= Proposed System Wide Change: Fedora 26 C/C++ Compilation Flags Updates =
https://fedoraproject.org/wiki/Changes/Fedora26CFlags

Change owner(s):
* Florian Weimer <fweimer AT redhat DOT com>

This change updates the default C/C++ compilation flags, as determined
by the redhat-rpm-config package.



== Detailed Description ==
This change covers the following modifications to the default C and
C++ compiler flags in the redhat-rpm-config package.

* Drop -mtune=atom on i686: This flag was added to improve performance
on the Intel Bonnell microarchitecture. Such CPUs are rare these days.
In addition, many users of the i686 packages download them for use
within a 64-bit x86_64 installation, and only a small part of these
Fedora installations use Atom CPUs. Current microarchitectures for
Atom CPUs are different from the original Bonnell microarchtecture and
would need different GCC flags for tuning, but many current Atom-based
devices cannot run Fedora because Fedora does not support their 32-bit
UEFI boot environment.
* Add -Werror=implicit-function-declaration: Implicit function
declarations allows a programmer to call functions without declaring
them (or including the relevant header files). The official C language
specification has not supported implicit function declarations for
almost two decades now. GCC still supports them as a GNU extension.
Implicit function declarations introduce bugs because these functions
use a different calling convention and have a fixed return type of
int. Resulting issues are pointer truncation (on 64-bit
architectures), exposure of padding bits (particular for
bool-returning functions on x86_64), and unexpected lack of hardening.
Implicit function declarations are not part of C++ (with or without
GNU extensions), and adjusting C code accordingly simplifies reuse in
C++ projects.
* Add -Werror=implicit-int: Implicit ints were removed from the C
programming language at the same time as implicit function
definitions, and were also retained as a GNU extension. Implicit ints
are usually source code bugs, and the presence of such code may
interfere with future C language directions (for example, consider how
C++ reused the auto keyword and an omitted type specifier).

The main risk from these changes are incorrect autoconf feature
checks, which often rely on technically invalid C fragments. However,
a review of existing configure scripts did not find any places where
they relied on these two problematic GNU extensions.

The technical side of this change is tracked in bug 1393492.



== Scope ==
* Proposal owners: The defaults in redhat-rpm-config need to be
changed, as described above.

* Other developers: Source code which relies on implicit function
declarations or implicit ints needs to be adjusted.

* Release engineering: This change requires a mass rebuild to become
fully effective.

* List of deliverables: No release blocking deliverables.

* Policies and guidelines: no changes proposed (change will be
implemented through redhat-rpm-config)

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

[Alexander Ploumistos]

On Thu, Nov 10, 2016 at 12:30 PM, Jan Kurik <jkurik(a)redhat.com&gt; wrote:
>  * Drop -mtune=atom on i686: This flag was added to improve
> performance
>  on the Intel Bonnell microarchitecture. 
Would you happen to have a ballpark estimate of the performance cost
that would incur on actual Bonnel CPUs?

[Florian Weimer]

On 11/10/2016 12:42 PM, Alexander Ploumistos wrote:
>  On Thu, Nov 10, 2016 at 12:30 PM, Jan Kurik <jkurik(a)redhat.com&gt;
> wrote:
> > * Drop -mtune=atom on i686: This flag was added to improve performance
> > on the Intel Bonnell microarchitecture.
>
>  Would you happen to have a ballpark estimate of the performance cost
>  that would incur on actual Bonnel CPUs? 
Unfortunately not.  I'm not sure which architecture revision could 
provide a reference CPU, and then there is the matter of obtaining 
access to that piece of hardware.

Florian

[Thomas Daede]

I have such a piece of hardware and could run a benchmark in ~1 week, if
you're curious. That said, Fedora Workstation is borderline unusable on
that hardware anyway - due to the integrated graphics, not the CPU. I
doubt most users would notice a slowdown from different CFLAGS when
gnome-shell can't repaint the screen faster than 15fps.

On 11/10/2016 04:22 AM, Florian Weimer wrote:
> On 11/10/2016 12:42 PM, Alexander Ploumistos wrote:
>> On Thu, Nov 10, 2016 at 12:30 PM, Jan Kurik <jkurik(a)redhat.com&gt; wrote:
>>> * Drop -mtune=atom on i686: This flag was added to improve performance
>>> on the Intel Bonnell microarchitecture.
>>
>> Would you happen to have a ballpark estimate of the performance cost
>> that would incur on actual Bonnel CPUs?
> 
> Unfortunately not.  I'm not sure which architecture revision could
> provide a reference CPU, and then there is the matter of obtaining
> access to that piece of hardware.
> 
> Florian
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Neal Gompa]

On Thu, Nov 10, 2016 at 5:30 AM, Jan Kurik <jkurik(a)redhat.com&gt; wrote:
>  but many current Atom-based
>  devices cannot run Fedora because Fedora does not support their 32-bit
>  UEFI boot environment. 
They *could* if people built 32-bit UEFI loader stuff for it. And
there have been efforts in the past for it. I wouldn't completely rule
this out, though it is uncommon.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Florian Weimer]

On 11/10/2016 12:49 PM, Neal Gompa wrote:
>  On Thu, Nov 10, 2016 at 5:30 AM, Jan Kurik <jkurik(a)redhat.com&gt;
> wrote:
> > but many current Atom-based
> > devices cannot run Fedora because Fedora does not support their 32-bit
> > UEFI boot environment.
>
>  They *could* if people built 32-bit UEFI loader stuff for it. And
>  there have been efforts in the past for it. I wouldn't completely rule
>  this out, though it is uncommon. 
Just to be clear, nothing in this change prevents people from booting 
via a 32-bit UEFI environment to run Fedora i686 or x86_64.  For current 
designs (the only ones with UEFI environments), the change should 
provide a slight performance improvement.

Florian

[Kevin Kofler]

Neal Gompa wrote:
>  They *could* if people built 32-bit UEFI loader stuff for it. And
>  there have been efforts in the past for it. I wouldn't completely rule
>  this out, though it is uncommon. 
32-bit grub2-efi is actually available. You should be able to install on 32-
bit UEFI with Calamares, if you remix the image to include grub2-efi and 
grub2-efi-modules ON the image. (Calamares itself can either be included too 
or installed with "dnf install calamares", but grub2-efi needs to be on the 
image itself.) But I have NOT tested it.

You may or may not also have to mess with the live media creation tools to 
add EFI stuff to the 32-bit image so that you can boot it. (For livecd-
tools, if needed, I take pull requests into my fork that I ported to dnf.)

        Kevin Kofler

[Dan Horák]

On Thu, 10 Nov 2016 11:30:47 +0100
Jan Kurik <jkurik(a)redhat.com&gt; wrote:

>  = Proposed System Wide Change: Fedora 26 C/C++ Compilation Flags
>  Updates = https://fedoraproject.org/wiki/Changes/Fedora26CFlags
>  
>  Change owner(s):
>  * Florian Weimer <fweimer AT redhat DOT com>
>  
>  This change updates the default C/C++ compilation flags, as determined
>  by the redhat-rpm-config package.
>  
>  
>  
>  == Detailed Description ==
>  This change covers the following modifications to the default C and
>  C++ compiler flags in the redhat-rpm-config package.
>  
>  * Drop -mtune=atom on i686: This flag was added to improve performance
>  on the Intel Bonnell microarchitecture. Such CPUs are rare these days.
>  In addition, many users of the i686 packages download them for use
>  within a 64-bit x86_64 installation, and only a small part of these
>  Fedora installations use Atom CPUs. Current microarchitectures for
>  Atom CPUs are different from the original Bonnell microarchtecture and
>  would need different GCC flags for tuning, but many current Atom-based
>  devices cannot run Fedora because Fedora does not support their 32-bit
>  UEFI boot environment. 
We are going to change the default -mcpu for s390(x) from the current
-mcpu=z9-109 to -mcpu=z10. z10 is the minimum level various projects
require - llvm/clang, OCaml, pypy3, ... Unfortunately we can't go
higher because our community guest VM is still running on a z10 machine.


		Dan

F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates - warning

[Orion Poplawski]

On 11/10/2016 03:30 AM, Jan Kurik wrote:
>  = Proposed System Wide Change: Fedora 26 C/C++ Compilation Flags
> Updates =
>  https://fedoraproject.org/wiki/Changes/Fedora26CFlags
>
>  Change owner(s):
>  * Florian Weimer <fweimer AT redhat DOT com>
>
>  This change updates the default C/C++ compilation flags, as determined
>  by the redhat-rpm-config package.
>
>
>
>  == Detailed Description ==
>  This change covers the following modifications to the default C and
>  C++ compiler flags in the redhat-rpm-config package.
>  
snip

>  * Add -Werror=implicit-function-declaration: Implicit function
>  declarations allows a programmer to call functions without declaring
>  them (or including the relevant header files). The official C language
>  specification has not supported implicit function declarations for
>  almost two decades now. GCC still supports them as a GNU extension.
>  Implicit function declarations introduce bugs because these functions
>  use a different calling convention and have a fixed return type of
>  int. Resulting issues are pointer truncation (on 64-bit
>  architectures), exposure of padding bits (particular for
>  bool-returning functions on x86_64), and unexpected lack of hardening.
>  Implicit function declarations are not part of C++ (with or without
>  GNU extensions), and adjusting C code accordingly simplifies reuse in
>  C++ projects.
>  * Add -Werror=implicit-int: Implicit ints were removed from the C
>  programming language at the same time as implicit function
>  definitions, and were also retained as a GNU extension. Implicit ints
>  are usually source code bugs, and the presence of such code may
>  interfere with future C language directions (for example, consider how
>  C++ reused the auto keyword and an omitted type specifier).
>
>  The main risk from these changes are incorrect autoconf feature
>  checks, which often rely on technically invalid C fragments. However,
>  a review of existing configure scripts did not find any places where
>  they relied on these two problematic GNU extensions. 
I've run into a reasonable number of failures of (custom) configure 
checks due to this.  Mainly calling exit() without including stdlib.h. 
So keep alert everyone.  Unfortunately this can lead to unpredictable 
and perhaps hard to detect changes.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: [phone]
3380 Mitchell Lane                  orion(a)cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates - warning

[Ralf Corsepius]

On 12/06/2016 04:44 AM, Orion Poplawski wrote:

>  I've run into a reasonable number of failures of (custom)
> configure
>  checks due to this.  Mainly calling exit() without including stdlib.h.
>  So keep alert everyone.  Unfortunately this can lead to unpredictable
>  and perhaps hard to detect changes. 
It's worse. This change contradicts autoconf's working principles. It 
causes configure-checks to produce bogus results and to produce 
mal-built packages.

That said, I am vehemently opposed to this step and ask the persons in 
charge to revert it.

Ralf

F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates - warning

[Florian Weimer]

On 12/06/2016 08:27 AM, Ralf Corsepius wrote:
>  On 12/06/2016 04:44 AM, Orion Poplawski wrote:
>
> > I've run into a reasonable number of failures of (custom) configure
> > checks due to this.  Mainly calling exit() without including stdlib.h.
> > So keep alert everyone.  Unfortunately this can lead to unpredictable
> > and perhaps hard to detect changes.
>
>  It's worse. This change contradicts autoconf's working principles. 
I doubt that it's deliberate that autoconf attempts to compile invalid C 
code.

>  It
>  causes configure-checks to produce bogus results and to produce
>  mal-built packages. 
These packages are unportable and will fail with other C compilers.

>  That said, I am vehemently opposed to this step and ask the persons
> in
>  charge to revert it. 
We could probably help with identifying packages affected by this 
change, but after seventeen years, it's time to clean up these broken 
autoconf checks.

Thanks,
Florian

F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates - warning

[Igor Gnatenko]

On Tue, Dec 6, 2016 at 9:01 AM, Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  On 12/06/2016 08:27 AM, Ralf Corsepius wrote:
> >
> > On 12/06/2016 04:44 AM, Orion Poplawski wrote:
> >
> >> I've run into a reasonable number of failures of (custom) configure
> >> checks due to this.  Mainly calling exit() without including stdlib.h.
> >> So keep alert everyone.  Unfortunately this can lead to unpredictable
> >> and perhaps hard to detect changes.
> >
> >
> > It's worse. This change contradicts autoconf's working principles.
>
>
>  I doubt that it's deliberate that autoconf attempts to compile invalid C
>  code.
>
> > It
> > causes configure-checks to produce bogus results and to produce
> > mal-built packages.
>
>
>  These packages are unportable and will fail with other C compilers.
>
> > That said, I am vehemently opposed to this step and ask the persons in
> > charge to revert it.
>
>
>  We could probably help with identifying packages affected by this change,
>  but after seventeen years, it's time to clean up these broken autoconf
>  checks. 
Totally agree here.

Florian, why only %__global_cflags were changed and not %optflags?
Many of packages which don't do %configure, use %optflags.
>  Thanks,
>  Florian
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
-Igor Gnatenko

F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates - warning

[Florian Weimer]

On 12/07/2016 08:04 AM, Igor Gnatenko wrote:

>  Florian, why only %__global_cflags were changed and not %optflags?
>  Many of packages which don't do %configure, use %optflags. 
%optflags is for both C and C++.  The new flags are meaningless for C++ 
and apparently accepted by the C++ front end merely by accident.

Thanks,
Florian