@Chris: 
IIRC you have (or atleast had) some programs that depends on exact gcc version so they would need a rebuild for this update...

Can you check if this is still the case...

CC: (none) => eatdirt

Remi, this one should now be a good fit for godot build testing :)

CC: (none) => rverschelde

I've been using the previous 8.4.0-0.RC1.1.mga7 over the past week with no issue. I just upgraded to 8.4.0-1.mga7 and rebuilt Godot from scratch without problem either.

Thanks for the test Rémi - beat me to it.
Adding the OK, assuming your test was on x86_64.  If not, we can repeat it.

CC: (none) => tarazed25
Whiteboard: (none) => MGA7-64-OK

dropping the ok for now, as we want it to be in active use by several users for a while... it's not only  the compiling of stuff, it's also all the libs being used at runtime...

So just update the packages and keep using the system as usual...

Whiteboard: MGA7-64-OK => (none)

mga7, x86_64

Updated all 35 packages.  Shall try out gfortran and asan when there is time.

Simple asan test based on https://github.com/google/sanitizers/wiki/AddressSanitizer

$ cat use-after-free.c
#include <stdlib.h>
int main() {
  char *x = (char*)malloc(10 * sizeof(char*));
  free(x);
  return x[5];
}

Making a guess here that gcc can use the same flags here as clang.
$ gcc -o useafterfree -fsanitize=address -O1 -fno-omit-frame-pointer -g use-after-free.c

$ ./useafterfree
=================================================================
==4688==ERROR: AddressSanitizer: heap-use-after-free on address 0x607000000025 at pc 0x0000004011a0 bp 0x7ffee166cc20 sp 0x7ffee166cc18
READ of size 1 at 0x607000000025 thread T0
    #0 0x40119f in main /home/lcl/use-after-free.c:5
    #1 0x7f319e3e4b0a in __libc_start_main (/lib64/libc.so.6+0x26b0a)
    #2 0x4010a9 in _start (/home/lcl/useafterfree+0x4010a9)

0x607000000025 is located 5 bytes inside of 80-byte region [0x607000000020,0x607000000070)
freed by thread T0 here:
    #0 0x7f319e671270 in __interceptor_free (/lib64/libasan.so.5+0xe9270)
    #1 0x40116f in main /home/lcl/use-after-free.c:4
    #2 0x7f319e3e4b0a in __libc_start_main (/lib64/libc.so.6+0x26b0a)

previously allocated by thread T0 here:
    #0 0x7f319e6715f0 in __interceptor_malloc (/lib64/libasan.so.5+0xe95f0)
    #1 0x401164 in main /home/lcl/use-after-free.c:3
    #2 0x7f319e3e4b0a in __libc_start_main (/lib64/libc.so.6+0x26b0a)

SUMMARY: AddressSanitizer: heap-use-after-free /home/lcl/use-after-free.c:5 in main
Shadow bytes around the buggy address:
  0x0c0e7fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0e7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0e7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0e7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0e7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c0e7fff8000: fa fa fa fa[fd]fd fd fd fd fd fd fd fd fd fa fa
  0x0c0e7fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0e7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0e7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0e7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0e7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==4688==ABORTING

Looks OK.

Compiled a very simple fortran program to calculate the sum of cubes of n numbers  supplied at the commandline.  Used gfortran to compile.  Worked a treat.

MGA7-64 Plasma on Lenovo B50
This laptop is fully updated, but I get:
Sorry, the following package cannot be selected:
- gcc-8.4.0-1.mga7.x86_64 (due to unsatisfied binutils[>= 1:2.33.1-1])

CC: (none) => herman.viaene

(In reply to Herman Viaene from comment #9)
> MGA7-64 Plasma on Lenovo B50
> This laptop is fully updated, but I get:
> Sorry, the following package cannot be selected:
> - gcc-8.4.0-1.mga7.x86_64 (due to unsatisfied binutils[>= 1:2.33.1-1])

yeah, that one is still in testing media (already validated)

I just havent had time/energy to add advisories and flush it out

you can install it from testing for now

@Herman, comment 9.  Yes, binutils was OK here after the update testing so gcc presented no problem.

Running urpmq --whatrequires-recursive on some of the libraries.

Turned up shotwell for libgomp1.
$ strace -o trace shotwell *
$ grep gomp trace
openat(AT_FDCWD, "/lib64/libgomp.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/libgomp.so.1.0.0", O_RDONLY) = 3

More than 32000 hits on libgcc1.

Tried some others but found nothing definitive.

Yes, no pb, push the update, I'll open another bug for the fortran-devel packages needing a rebuild!

To be more specific, they are:
openmpi
pgplot
aspic
sundials
pg2plplot
healpix

(In reply to Chris Denice from comment #14)
> To be more specific, they are:
> openmpi
> pgplot
> aspic
> sundials
> pg2plplot
> healpix

So you can submit them to testing already, set the buildrequires to 8.4.0-1 and have them depend on this bug

(In reply to Thomas Backlund from comment #5)
> dropping the ok for now, as we want it to be in active use by several users
> for a while... it's not only  the compiling of stuff, it's also all the libs
> being used at runtime...
> 
> So just update the packages and keep using the system as usual...

OK, then. My old Fortran skills atrophied years ago, so I'll leave checking out the development aspects to others. However, I used QARepo to download the entire update list, and Mageia Update only wanted these runtime libraries:

The following 5 packages are going to be installed:

- libgcc1-8.4.0-1.mga7.x86_64
- libgfortran5-8.4.0-1.mga7.x86_64
- libgomp1-8.4.0-1.mga7.x86_64
- libquadmath0-8.4.0-1.mga7.x86_64
- libstdc++6-8.4.0-1.mga7.x86_64

Those installed cleanly, and so far, so good. I will report back if anything untoward shows up.

CC: (none) => andrewsfarm

Advisory, added to svn.

type: security
subject: Updated gcc packages fix security vulnerability
src:
  7:
   core:
     - gcc-8.4.0-1.mga7
description: |
  This update provides gcc 8.4.0 stable release, containing important
  fixes for regressions and serious bugs in GCC 8.3 with more than 209
  bugs fixed since the previous release.

  It also fixes atleast the following security issue:

  every time the collect2 process is interrupted via a signal it can
  delete random files from the hard drive, since the signal handler may
  be using the path name, and passes it to the unlink function before it
  is initialized.
references:
 - https://bugs.mageia.org/show_bug.cgi?id=26294
 - https://gcc.gnu.org/ml/gcc/2020-03/msg00042.html

Keywords: (none) => advisory

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2020-0132.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED