[Bug target/81907] memset called when it does not need to be; -mtune=cortex-a9

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
Summary|undefined reference to  |memset called when it does
   |`memset'|not need to be;
   ||-mtune=cortex-a9
   Severity|normal  |enhancement

--- Comment #8 from Andrew Pinski  ---
>This is not related to freestanding implementations.

Huh?  Since you are not linking against the C library, it has to be.
or you mean this should be optimized not to use memset; different question from
what your summary is about.

[Bug target/81907] undefined reference to `memset'

[dongkyun.s at samsung dot com]

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

dongkyun.s at samsung dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |---

--- Comment #7 from dongkyun.s at samsung dot com ---
> Different tuning.  Though maybe at -Os should be almost the same except for 
> the allowance for using the instructions that are in cortex-a12 rather than 
> a9 (for the -mcpu case). 
I attached .o files made by '-mtune=cortex-a9' and 'mtune=cortex-a12' (same as
-mcpu case).
Could you describe more in detail about this why memset is added on cortex-a9
or below ?

memset_test_cortex-a9.o: file format elf32-littlearm
Disassembly of section .text:
...
0022 :
  22:   b51fpush{r0, r1, r2, r3, r4, lr}
  24:   2210movsr2, #16
  26:   2100movsr1, #0
  28:   4668mov r0, sp
  2a:   f7ff fffe   bl  0 

> But really memset is part of the C standard here and you don't use 
> -fno-hoisting option; 
Which option do you mean? (I'm sorry, but, fno-hoisting is not found)

> Not a bug, see PR 63393 comment #5 for explanation of why.
This is not related to freestanding implementations. Again, option is different
by '-mcpu or -mtune' only.

(1) CFLAGS: -Os -mtune=cortex-a9
(CC) memset_test.o
(CC) main.o
gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-ld
-Bstatic -o memset_test \
memset_test.o main.o \
--start-group
-L/home/dongkyun.s/tmp/memset_test/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/6.3.1
-lgcc --end-group -Map memset_test.map #--gc-sections
memset_test.c:(.text+0x2a): undefined reference to `memset'

(2) CFLAGS: -Os -mtune=cortex-a12
(CC) memset_test.o
(CC) main.o
gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-ld
-Bstatic -o memset_test \
memset_test.o main.o \
--start-group
-L/home/dongkyun.s/tmp/memset_test/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/6.3.1
-lgcc --end-group -Map memset_test.map #--gc-sections
BUILD_TARGETS=memset_test.bin memset_test.txt memset_test.dis memset_test.ver
Build Done!

[Bug inline-asm/81890] asm memory constraints are difficult and not well documented

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2017-08/msg01174.ht
   ||ml
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com

[Bug target/81907] undefined reference to `memset'

[dongkyun.s at samsung dot com]

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

--- Comment #6 from dongkyun.s at samsung dot com ---
Created attachment 42017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42017=edit
obj made by '-Os -mtune=cortex-a12'

./gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump
-d memset_test_cortex-a12.o

memset_test_cortex-a12.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:   b530push{r4, r5, lr}
   2:   f1a0 0208   sub.w   r2, r0, #8
   6:   460cmov r4, r1
   8:   2300movsr3, #0
   a:   2000movsr0, #0
   c:   2100movsr1, #0
   e:   42a3cmp r3, r4
  10:   db00blt.n   14 
  12:   bd30pop {r4, r5, pc}
  14:   f852 5f08   ldr.w   r5, [r2, #8]!
  18:   3301addsr3, #1
  1a:   1940addsr0, r0, r5
  1c:   eb41 71e5   adc.w   r1, r1, r5, asr #31
  20:   e7f5b.n e 

0022 :
  22:   b51fpush{r0, r1, r2, r3, r4, lr}
  24:   2200movsr2, #0
  26:   490cldr r1, [pc, #48]   ; (58 )
  28:   2300movsr3, #0
  2a:   e9cd 2300   strdr2, r3, [sp]
  2e:   e9cd 2302   strdr2, r3, [sp, #8]
  32:   780cldrbr4, [r1, #0]
  34:   7908ldrbr0, [r1, #4]
  36:   4623mov r3, r4
  38:   4302orrsr2, r0
  3a:   e9cd 2300   strdr2, r3, [sp]
  3e:   788aldrbr2, [r1, #2]
  40:   2300movsr3, #0
  42:   4668mov r0, sp
  44:   f043 0307   orr.w   r3, r3, #7
  48:   2102movsr1, #2
  4a:   e9cd 2302   strdr2, r3, [sp, #8]
  4e:   f7ff fffe   bl  0 
  52:   b004add sp, #16
  54:   bd10pop {r4, pc}
  56:   bf00nop
  58:   .word   0x

[Bug target/81907] undefined reference to `memset'

[dongkyun.s at samsung dot com]

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

dongkyun.s at samsung dot com changed:

   What|Removed |Added

  Attachment #42014|0   |1
is obsolete||

--- Comment #5 from dongkyun.s at samsung dot com ---
Created attachment 42016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42016=edit
obj made by '-Os -mtune=cortex-a9'

./gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump
-d memset_test_cortex-a9.o

memset_test_cortex-a9.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:   b530push{r4, r5, lr}
   2:   f1a0 0208   sub.w   r2, r0, #8
   6:   460cmov r4, r1
   8:   2300movsr3, #0
   a:   2000movsr0, #0
   c:   2100movsr1, #0
   e:   42a3cmp r3, r4
  10:   db00blt.n   14 
  12:   bd30pop {r4, r5, pc}
  14:   f852 5f08   ldr.w   r5, [r2, #8]!
  18:   3301addsr3, #1
  1a:   1940addsr0, r0, r5
  1c:   eb41 71e5   adc.w   r1, r1, r5, asr #31
  20:   e7f5b.n e 

0022 :
  22:   b51fpush{r0, r1, r2, r3, r4, lr}
  24:   2210movsr2, #16
  26:   2100movsr1, #0
  28:   4668mov r0, sp
  2a:   f7ff fffe   bl  0 
  2e:   490aldr r1, [pc, #40]   ; (58 )
  30:   2200movsr2, #0
  32:   780cldrbr4, [r1, #0]
  34:   7908ldrbr0, [r1, #4]
  36:   4623mov r3, r4
  38:   4302orrsr2, r0
  3a:   4668mov r0, sp
  3c:   e9cd 2300   strdr2, r3, [sp]
  40:   2300movsr3, #0
  42:   788aldrbr2, [r1, #2]
  44:   f043 0307   orr.w   r3, r3, #7
  48:   2102movsr1, #2
  4a:   e9cd 2302   strdr2, r3, [sp, #8]
  4e:   f7ff fffe   bl  0 
  52:   b004add sp, #16
  54:   bd10pop {r4, pc}
  56:   bf00nop
  58:   .word   0x

[Bug fortran/81903] compiler reports a language problem (Invalid character in name at)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-21
 CC||janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
Slightly reduced test case:


Module TestMod_C
  Implicit None

  Type :: TestType_A
Real :: a
  End type

  Type :: TestType_B
   Real :: a
  End type

  Type :: TestType_C
Class(TestType_A), Pointer :: TT_A(:)
Type(TestType_B), Allocatable :: TT_B(:)
  End type

contains

Subroutine SubSetPt(this)
  class(TestType_C), Intent(InOut), Target :: this
  integer :: i
  associate(x=>this%TT_B,y=>this%TT_A)
Do i=1,size(x)
  x(i)%a=>y(i)%a
End Do
  end associate
End Subroutine

End Module

[Bug target/81907] undefined reference to `memset'

[dongkyun.s at samsung dot com]

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

--- Comment #4 from dongkyun.s at samsung dot com ---
Created attachment 42014
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42014=edit
memset_test_cortex-a9.o (made by '-Os -mtune=cortex-a12')

./gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump
-d memset_test_cortex-a12.o

memset_test_cortex-a12.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:   b530push{r4, r5, lr}
   2:   f1a0 0208   sub.w   r2, r0, #8
   6:   460cmov r4, r1
   8:   2300movsr3, #0
   a:   2000movsr0, #0
   c:   2100movsr1, #0
   e:   42a3cmp r3, r4
  10:   db00blt.n   14 
  12:   bd30pop {r4, r5, pc}
  14:   f852 5f08   ldr.w   r5, [r2, #8]!
  18:   3301addsr3, #1
  1a:   1940addsr0, r0, r5
  1c:   eb41 71e5   adc.w   r1, r1, r5, asr #31
  20:   e7f5b.n e 

0022 :
  22:   b51fpush{r0, r1, r2, r3, r4, lr}
  24:   2200movsr2, #0
  26:   490cldr r1, [pc, #48]   ; (58 )
  28:   2300movsr3, #0
  2a:   e9cd 2300   strdr2, r3, [sp]
  2e:   e9cd 2302   strdr2, r3, [sp, #8]
  32:   780cldrbr4, [r1, #0]
  34:   7908ldrbr0, [r1, #4]
  36:   4623mov r3, r4
  38:   4302orrsr2, r0
  3a:   e9cd 2300   strdr2, r3, [sp]
  3e:   788aldrbr2, [r1, #2]
  40:   2300movsr3, #0
  42:   4668mov r0, sp
  44:   f043 0307   orr.w   r3, r3, #7
  48:   2102movsr1, #2
  4a:   e9cd 2302   strdr2, r3, [sp, #8]
  4e:   f7ff fffe   bl  0 
  52:   b004add sp, #16
  54:   bd10pop {r4, pc}
  56:   bf00nop
  58:   .word   0x

[Bug target/81907] undefined reference to `memset'

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Not a bug, see PR 63393 comment #5 for explanation of why.

*** This bug has been marked as a duplicate of bug 63393 ***

[Bug c/63393] [regression]-ffreestanding not work: memset call cause valgrind crash

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dongkyun.s at samsung dot com

--- Comment #7 from Andrew Pinski  ---
*** Bug 81907 has been marked as a duplicate of this bug. ***

[Bug target/81907] undefined reference to `memset'

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to dongkyun.s from comment #0)
> Found related issue in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888.

Unrelated bug report.

[Bug target/81907] undefined reference to `memset'

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|link-failure|
 Target|arm |arm-*-*
  Component|middle-end  |target
   Host|x86 |
Version|6.3.1   |unknown
  Build|x86 |

--- Comment #1 from Andrew Pinski  ---
>What is different optimization behavior(implementation) in GCC between 
>cortex-a9 and cortex-a12 -given by mcpu or mtune option ?

Different tuning.  Though maybe at -Os should be almost the same except for the
allowance for using the instructions that are in cortex-a12 rather than a9 (for
the -mcpu case). 

But really memset is part of the C standard here and you don't use
-fno-hoisting option; though IIRC that still requires memset being included in
your libc.

[Bug middle-end/81907] New: undefined reference to `memset'

[dongkyun.s at samsung dot com]

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

Bug ID: 81907
   Summary: undefined reference to `memset'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dongkyun.s at samsung dot com
  Target Milestone: ---

Created attachment 42013
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42013=edit
memset_test

Compiling the attached source without memset trivial implementation,

Failed by undefined reference to `memset'
OPTFLAGS = -Os -g -mabi=aapcs -fno-function-sections -Wall -mfloat-abi=soft
-mtune=cortex-a9

Succeeded with option
OPTFLAGS = -Os -g -mabi=aapcs -fno-function-sections -Wall -mfloat-abi=soft
-mtune=cortex-a12

Using -O2 instead of -Os (Optimization level) also fix this fail.
What is different optimization behavior(implementation) in GCC between
cortex-a9 and cortex-a12 -given by mcpu or mtune option ?

Found related issue in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888.

[Bug fortran/81296] derived type I/o problem

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
Created attachment 42012
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42012=edit
A patch being tested.

This patch adds a check for the DT descriptor in the format label. Preliminary
test show that this fixes it. Regression testing now.

[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  ---
(In reply to Vadim Zeitlin from comment #5)
> Perhaps you could consider this as a QoI issue, but it would be really great
> if gcc could give a warning if the code tries to use fesetround() without
> -frounding-math being on.

First note that even with -frounding-math, there are several bugs related to
rounding (maybe rint isn't considered pure, but operators like +-*/ are). Also,
there are ways (inline asm that hides optimization opportunities) to use
fesetround safely even with -fno-rounding-math (and it avoids the perf penalty
in places where we don't care about the rounding). Still, I guess we could
consider such a warning, if someone is willing to implement it...

[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[vz-gcc at zeitlins dot org]

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

--- Comment #7 from Vadim Zeitlin  ---
(In reply to Andrew Pinski from comment #6)
> https://gcc.gnu.org/wiki/FloatingPointMath

Yes, I've seen this, thanks. But do you think it's easily discoverable? I admit
I had even seen this page (and knew about -frounding-math option) before
running into this problem after an upgrade to gcc 6 and it still wasn't obvious
to me that the problem was due to this. You might just think that I'm
abnormally clueless, but it seems to me that most people wouldn't be able to
realize the source of the problem immediately. So a warning from the compiler
would be really helpful IMO.

[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
https://gcc.gnu.org/wiki/FloatingPointMath

[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[vz-gcc at zeitlins dot org]

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

--- Comment #5 from Vadim Zeitlin  ---
Yes, I did find this documentation myself in the meanwhile and I agree that
you're formally correct, just as gcc developers are formally correct in the
long discussion at #34678 (which I really wouldn't want to reopen), but this is
not very helpful in practice because this information is completely
undiscoverable, i.e. you can only find it if you already know what you're
looking for (or enjoy reading compiler optimization options documentation as a
hobby, of course).

Perhaps you could consider this as a QoI issue, but it would be really great if
gcc could give a warning if the code tries to use fesetround() without
-frounding-math being on.

[Bug c/81141] missing warning using sizeof a/sizeof *a with a zero-length array

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
(In reply to comment #3)

What I meant to say is: See also bug 81141 for a related request (limited to
strncpy).  The patch submitted there issues a warning for a small subset of the
problem (strncpy) but doesn't specifically deal with zero-length arrays.

[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Vadim Zeitlin from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > You want -frounding-math
> 
> OK, thanks, this does indeed solve my immediate problem. However is it
> really normal that the compiler behaviour silently (!) changes like this, in
> backwards incompatible way between versions? I didn't remember seeing this
> change mentioned in gcc 6 release notes and I just reread them again and
> can't find it anywhere. I think changes silently breaking existing working
> (and standard conforming) code should be at the very least prominently
> documented (and, of course, ideally completely avoided IMO, but this ship
> has probably already sailed).

Yes and no.  Since this behavior has been documented this way since 4.4.0:
https://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Optimize-Options.html
-frounding-math
Disable transformations and optimizations that assume default floating point
rounding behavior. This is round-to-zero for all floating point to integer
conversions, and round-to-nearest for all other arithmetic truncations. ___This
option should be specified for programs that change the FP rounding mode
dynamically, or that may be executed with a non-default rounding mode. This
option disables constant folding of floating point expressions at compile-time
(which may be affected by rounding mode) and arithmetic transformations that
are unsafe in the presence of sign-dependent rounding modes.

Note I add ___.  So basically what changed between 5 and 6 was constant folding
of rint.  Since that is covered in the documentation, the change itself does
not need to be documented as happening.

[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[vz-gcc at zeitlins dot org]

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

--- Comment #3 from Vadim Zeitlin  ---
(In reply to Andrew Pinski from comment #1)
> You want -frounding-math

OK, thanks, this does indeed solve my immediate problem. However is it really
normal that the compiler behaviour silently (!) changes like this, in backwards
incompatible way between versions? I didn't remember seeing this change
mentioned in gcc 6 release notes and I just reread them again and can't find it
anywhere. I think changes silently breaking existing working (and standard
conforming) code should be at the very least prominently documented (and, of
course, ideally completely avoided IMO, but this ship has probably already
sailed).

[Bug c/81854] weak alias of an incompatible symbol accepted

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Sun Aug 20 21:31:39 2017
New Revision: 251211

URL: https://gcc.gnu.org/viewcvs?rev=251211=gcc=rev
Log:
libstdc++/ChangeLog:

PR c/81854
* src/c++98/compatibility.cc (_GLIBCXX_3_4_SYMVER): Declare alias
target as a C++ function with no prototype.
(_GLIBCXX_3_4_5_SYMVER): Ditto.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++98/compatibility.cc

[Bug c++/81867] Internal completer error: Segmentation Fault

[al_thomason at iname dot com]

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

--- Comment #3 from Al Thomason  ---
I will see if I am able to test using a newer rev, the GCC compiler seems to be
rather deeply embedded into the Arduino IDE...

[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"

[roland.illig at gmx dot de]

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

Roland Illig  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #11 from Roland Illig  ---
Commit r250156 introduced a typo in avr.c: "indentifier" should be
"identifier".

[Bug c++/53782] Pointer to static function member expression rejected in class template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to work||7.2.0, 8.0
 Resolution|WORKSFORME  |FIXED
  Known to fail||4.8.0, 5.4.0, 6.3.0

--- Comment #2 from Martin Sebor  ---
Bisection shows that this bug was fixed in r236221 (GCC 7.0).

[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2017-08-20
 Resolution|INVALID |---
Summary|Calls to rint() wrongly |[7/8 Regression] Calls to
   |optimized away starting in  |rint() wrongly optimized
   |g++ 6   |away starting in g++ 6
 Ever confirmed|0   |1

--- Comment #2 from Marc Glisse  ---
Indeed you want -frounding-math, and with gcc-6 that makes things work, but
starting with gcc-7 it doesn't anymore. (gimple looks fine, the problem comes
later)

[Bug c++/81906] Calls to rint() wrongly optimized away starting in g++ 6

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
You want -frounding-math

. This option should be specified for programs that change the FP rounding mode
dynamically, or that may be executed with a non-default rounding mode.

[Bug c++/81906] New: Calls to rint() wrongly optimized away starting in g++ 6

[vz-gcc at zeitlins dot org]

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

Bug ID: 81906
   Summary: Calls to rint() wrongly optimized away starting in g++
6
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vz-gcc at zeitlins dot org
  Target Milestone: ---

Here is a test case:

-- >8 --
#include 
#include 
#include 

int main()
{
printf("--- Test built with gcc %d.%d.%d ---\n",
   __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__ );

auto const x = -2.5;

printf("Default round mode : rint(%g)=%g\n", x, std::rint(x));
fesetround(FE_DOWNWARD);
printf("Downward round mode: rint(%g)=%g\n", x, std::rint(x));

return 0;
}
-- >8 --

% g++-7 -O1 -Wall -std=c++11 rint.cpp && ./a.out
--- Test built with gcc 7.1.0 ---
Default round mode : rint(-2.5)=-2
Downward round mode: rint(-2.5)=-2

Replacing -O1 with -O0 yields the expected -3 in the last line, but with -O1
(and -O2 etc), the second call to rint() is completely eliminated as can be
seen by examining the generated assembly.

The same bug is also present in 6.4.0 but not in 5.4.1 nor previous versions,
so it looks like rint() has somehow become marked as pure in gcc 6.

[Bug testsuite/81056] [7/8 Regression] FAIL: 17_intro/names.cc (test for excess errors)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from John David Anglin  ---
Fixed.

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

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

--- Comment #9 from Jack Howarth  ---
Note that the main deviation from the previous back porting for gcc-6-branch is
that the ipa-icf-gimple.c source file must define INCLUDE_LIST since it is used
in that file for gcc-5-branch unlike gcc-6-branch.

[Bug testsuite/81056] [7/8 Regression] FAIL: 17_intro/names.cc (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Author: danglin
Date: Sun Aug 20 19:00:59 2017
New Revision: 251209

URL: https://gcc.gnu.org/viewcvs?rev=251209=gcc=rev
Log:
PR testsuite/81056
* testsuite/17_intro/names.cc: Undef 'd' and 'r' on __hpux__.


Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/testsuite/17_intro/names.cc

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

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

--- Comment #8 from Jack Howarth  ---
Verified that proposed changes in PR81037_gcc5.patch with Xcode 8.2.1 on
darwin15.6.0 and Xcode 9 beta 5 on 10.13.

[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  ---
Patch submitted here:

https://gcc.gnu.org/ml/fortran/2017-08/msg00045.html

[Bug testsuite/81056] [7/8 Regression] FAIL: 17_intro/names.cc (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
Author: danglin
Date: Sun Aug 20 18:52:59 2017
New Revision: 251208

URL: https://gcc.gnu.org/viewcvs?rev=251208=gcc=rev
Log:
PR testsuite/81056
* testsuite/17_intro/names.cc: Undef 'd' and 'r' on __hpux__


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/17_intro/names.cc

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

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

--- Comment #7 from Jack Howarth  ---
Created attachment 42011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42011=edit
proposed back port of changes from trunk for gcc-5-branch

[Bug c++/45065] -fvisibility-inlines-hidden: Decl order in derived class affects visibility of inlines in base.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-20
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
(In reply to Dean Edmonds from comment #0)
> Compiling with -fvisibility=hidden and -fvisibility-inlines-hidden.
> 
> I have a Base class with default visibility which contains two virtual
> methods, one inlined and the other not. A Derived class with hidden
> visibility overrides the non-inlined method and doesn't touch the inlined
> one. If the declaration of the overridden method appears *before* the
> Derived's virtual destructor then the object file for Derived weakly exports
> the Base class's inlined method. But if the declaration appears *after*
> Derived's virtual destructor then the object for Derived doesn't export the
> Base class's inlined method at all.
> 
> Given that I'm compiling with -fvisibility-inlines-hidden I *think* that
> means that the Base class's inlined method should never be exported. Even if
> I'm wrong about that, surely it should not matter the order in which the
> Derived class's methods are declared.
> 
> Here's an example which demonstrates the problem:
> 
> class __attribute__ ((visibility("default"))) Base
> {
> public:
> Base();
> virtual ~Base();
> virtual void func()  const;
> virtual void inlineFunc() {}
> };
> 
> class Derived : public Base
> {
> public:
> Derived();
> void func() const;
> virtual ~Derived();
> };
> 
> void Derived::func() const
> {}
> 
> Compiled on OSX 10.6.4 with g++ 4.2.1, using the following command:
> 
>   g++-4.2 -Wall -c -arch x86_64 -fvisibility=hidden
> -fvisibility-inlines-hidden -O3 -m64 -isysroot
> /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -o Derived.o
> Derived.cpp
> 
> Looking at the object file using 'nm -m Derived.o | grep inlineFunc' gives:
> 
>   0010 (__TEXT,__textcoal_nt) weak private external
> __ZN6Common10inlineFuncEv
>   0098 (__TEXT,__eh_frame) weak private external
> __ZN6Common10inlineFuncEv.eh
> 
> If I move the declaration of Derived::func() so that it comes after
> ~Derived() then 'nm -m Derived.o | grep inlineFunc' returns nothing.
> 
> 

On 10.5 with gcc8, the grep only returns one line:

$ /usr/local/bin/g++ -Wall -c -arch x86_64 -fvisibility=hidden
-fvisibility-inlines-hidden -O3 -m64 -isysroot /Developer/SDKs/MacOSX10.5.sdk
-mmacosx-version-min=10.5 -Wextra -pedantic -o 45065.o 45065.cc
$ nm -m 45065.o | grep inlineFunc
0010 (__TEXT,__textcoal_nt) weak private external
__ZN4Base10inlineFuncEv

The difference is no version suffixed with '.eh' so I think it's a 10.5 to 10.6
difference.

> I see similar behaviour on GNU/Linux (2.6.30.9-96.fc11.x86_64) using g++
> 4.4.1. Compiling with this command:
> 
>   g++ -Wall -c -fvisibility=hidden -fvisibility-inlines-hidden -O3 -m64 -o
> Derived.o Derived.cpp
> 
> and using 'objdump -t Derived.o | grep inlineFunc' to inspect the result
> gives this when Derived::func() is declared before ~Derived():
> 
>    ld  .text._ZN4Base10inlineFuncEv   
> .text._ZN4Base10inlineFuncEv
>     wF .text._ZN4Base10inlineFuncEv   0002
> .hidden _ZN4Base10inlineFuncEv
> 
> and gives nothing when Derived::func() is declared after ~Derived().

(In reply to Paolo Carlini from comment #2)
> I can confirm the behavior with today's mainline. And seems weird indeed.

Changing status to NEW then since it's confirmed.

[Bug ipa/77732] FAIL: gcc.dg/ipa/ipcp-cstagg-7.c scan-ipa-dump-times cp "Discovered an indirect call to a known target" 3

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  ---
Author: danglin
Date: Sun Aug 20 18:40:28 2017
New Revision: 251207

URL: https://gcc.gnu.org/viewcvs?rev=251207=gcc=rev
Log:
PR ipa/77732
* gcc.dg/ipa/ipcp-cstagg-7.c: Xfail on 32-bit hppa.


Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c

[Bug c++/54574] G++ accepts parameters with wrong types in parent constructor

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
gcc8 errors as you expected it to:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 54574.cc
54574.cc: In instantiation of ‘A::A(int*) [with T = int]’:
54574.cc:16:13:   required from here
54574.cc:11:13: error: no matching function for call to ‘C::C(int*&)’
   : C (Items) {// C is called with wrong parameter type, expects int**
 ^
54574.cc:4:3: note: candidate: ‘C::C(int**)’
   C (int* Items[]);
   ^
54574.cc:4:3: note:   no known conversion for argument 1 from ‘int*’ to ‘int**’
54574.cc:1:7: note: candidate: ‘constexpr C::C(const C&)’
 class C
   ^
54574.cc:1:7: note:   no known conversion for argument 1 from ‘int*’ to ‘const
C&’
54574.cc:1:7: note: candidate: ‘constexpr C::C(C&&)’
54574.cc:1:7: note:   no known conversion for argument 1 from ‘int*’ to ‘C&&’
$

[Bug ipa/77732] FAIL: gcc.dg/ipa/ipcp-cstagg-7.c scan-ipa-dump-times cp "Discovered an indirect call to a known target" 3

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Author: danglin
Date: Sun Aug 20 18:23:41 2017
New Revision: 251206

URL: https://gcc.gnu.org/viewcvs?rev=251206=gcc=rev
Log:
PR ipa/77732
* gcc.dg/ipa/ipcp-cstagg-7.c: Xfail on 32-bit hppa.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c

[Bug c++/53972] array constant expression not valid as template argument

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-20
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Huh, there's an extra error message in c++11 compared to c++14:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=gnu++11 53972.cc
53972.cc: In function ‘int main()’:
53972.cc:27:24: warning: statement has no effect [-Wunused-value]
  Constify::value;
^
53972.cc: In instantiation of ‘constexpr char sub1(const char (&)[N], unsigned
int) [with unsigned int N = 4]’:
53972.cc:23:15:   required from here
53972.cc:10:29: error: ‘array’ is not a constant expression
  return Constify::value;
 ^
53972.cc:10:23: note: in template argument for type ‘unsigned int’ 
  return Constify::value;
  ~^
53972.cc:11:1: error: body of constexpr function ‘constexpr char sub1(const
char (&)[N], unsigned int) [with unsigned int N = 4]’ not a return-statement
 }
 ^
$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=gnu++14 53972.cc
53972.cc: In function ‘int main()’:
53972.cc:27:24: warning: statement has no effect [-Wunused-value]
  Constify::value;
^
53972.cc: In instantiation of ‘constexpr char sub1(const char (&)[N], unsigned
int) [with unsigned int N = 4]’:
53972.cc:23:15:   required from here
53972.cc:10:29: error: ‘array’ is not a constant expression
  return Constify::value;
 ^
53972.cc:10:23: note: in template argument for type ‘unsigned int’ 
  return Constify::value;
  ~^
$

Confirmed.

[Bug c++/53782] Pointer to static function member expression rejected in class template

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
gcc8 accepts it with neither warning nor error when I try to compile it.

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

[peter at cordes dot ca]

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

--- Comment #3 from Peter Cordes  ---
Seems to be fixed in gcc7.2.0: https://godbolt.org/g/jRwtZN

gcc7.2 is fine with -m32, -mx32, and -m64, but x32 is the most compact.  -m64
just calls __atomic_load_16


gcc7.2 -O3 -mx32 output:
follow_nounion(std::atomic*):
movq(%edi), %rax
movl%eax, %eax
ret

vs.

gcc7.1 -O3 -mx32
follow_nounion(std::atomic*):
movq(%edi), %rcx
xorl%edx, %edx
movzbl  %ch, %eax
movb%cl, %dl
movq%rcx, %rsi
movb%al, %dh
andl$16711680, %esi
andl$4278190080, %ecx
movzwl  %dx, %eax
orq %rsi, %rax
orq %rcx, %rax
ret

---


gcc7.2 -O3 -m64 just forwards its arg to __atomic_load_16 and then returns:

follow_nounion(std::atomic*):
subq$8, %rsp
movl$2, %esi
call__atomic_load_16
addq$8, %rsp
ret

It unfortunately doesn't optimize the tail-call to

movl$2, %esi
jmp __atomic_load_16

presumably because it hasn't realized early enough that it takes zero
instructions to extract the 8-byte low half of the 16-byte __atomic_load_16
return value.

[Bug c++/81901] New: false-positive -Warray-bounds

[webrown.cpp at gmail dot com]

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

Bug ID: 81901
   Summary: false-positive -Warray-bounds
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vermaelen.wouter at gmail dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

When switching from gcc-6 to gcc-7 my application triggers some new compiler
warnings (with -Wall). I believe these warnings are false-positives. But I
don't see an easy way to work around them. I also tested with a gcc-8 snapshot
(2017/08/19) and the problem persists.

I managed to reduce my program to the following:

int a[8];

extern void f2();

void f() {
for (int i = 0x3F; i >= 0x10; --i) {
switch (i & 0xF0) {
case 0x00:
if ((i & 0x0F) < 8) a[i] = 0;
break;
case 0x10:
f2();
}
}
}

Compile with
g++ -O2 -Wall test.cpp

warning: array subscript is above array bounds [-Warray-bounds]

[Bug libstdc++/81905] New: partial_sort slower than sort

[glisse at gcc dot gnu.org]

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

Bug ID: 81905
   Summary: partial_sort slower than sort
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

(from https://stackoverflow.com/q/45455345/1918193 )

std::partial_sort of half an array can be slower than std::sort of the whole
array, because it uses heap sort vs introsort. There may be a size threshold
above which we could use a different algorithm than heap_select+sort_heap (say
a variant of introsort where after partitioning (possibly with a biased pivot),
depending where the pivot ends up, either we partial_sort the left and ignore
the right, or we sort the left and partial_sort the right), or some other
compromise.

[Bug c++/53360] g++ prints 'invalid use of incomplete type' error when compiling code with -std=gnu++0x and newer

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
If we add this to expression it compiles OK:

expression& operator=(const expression&) { return *this; }

So the invalid instantiation of column::operator=(const column&) comes
from the compiler-generated copy assignment operator. That presumably gets
defined during overload resolution.

I don't know what the difference is between C++98 and C++11 that causes that
(or if it's reasonable to expect a c++11-compat warning).

[Bug fortran/81898] [7/8 Regression] [OOP] Issue with polymorphic container class

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |7.3
Summary|[7/8 Regression] Issue with |[7/8 Regression] [OOP]
   |polymorphic container class |Issue with polymorphic
   ||container class

[Bug fortran/81898] [7/8 Regression] Issue with polymorphic container class

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-20
 CC||janus at gcc dot gnu.org
Summary|Issue with polymorphic  |[7/8 Regression] Issue with
   |container class |polymorphic container class
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
Here is a further reduced and modified version of the original test case:


module AModule

  implicit none

  type :: BType
  end type

  type:: AType
class(BType), allocatable :: obj
type(BType), pointer  :: bobj
  contains
procedure :: a_rd
  end type

  contains

subroutine a_rd(this)
  ! -- dummy
  class(AType) :: this
  write(*,*) 'in a_rd'
end subroutine

end module


program main
  use AModule
  implicit none
  class(AType), allocatable, target :: a

  allocate(a)

  allocate(a%obj)
  a%bobj => a%obj

  write(*,*) 'calling a_rd'
  call a%a_rd()

end



It compiles and runs file with gfortran 6 and earlier, but fails with a runtime
segfault with gfortran 7 and trunk. Indeed looks like a wrong-code regression.

[Bug target/81904] New: FMA and addsub instructions

[glisse at gcc dot gnu.org]

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

Bug ID: 81904
   Summary: FMA and addsub instructions
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

(asked in
https://stackoverflow.com/questions/45298855/how-to-write-portable-simd-code-for-complex-multiplicative-reduction/45401182#comment77780455_45401182
)

Intel has instructions like vfmaddsubps. Gcc manages, under certain
circumstances, to merge mult and plus or mult and minus into FMA, but not mult
and this strange addsub mix.

#include 
__m128d f(__m128d x, __m128d y, __m128d z){
  return _mm_addsub_pd(_mm_mul_pd(x,y),z);
}
__m128d g(__m128d x, __m128d y, __m128d z){
  return _mm_fmaddsub_pd(x,y,z);
}

(the order of the arguments is probably not right)

My first guess as to how this could be implemented without too much trouble is
in ix86_gimple_fold_builtin: for IX86_BUILTIN_ADDSUBPD and others, check that
we are late enough in the optimization pipeline (roughly where "widening_mul"
is), that contractions are enabled, and that the first (?) argument is a
single-use MULT_EXPR.

I didn't check what the situation is with the vectorizer (which IIRC can now
generate code that ends up as addsub).

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

Version|7.1.0   |7.2.0

--- Comment #5 from Francois-Xavier Coudert  ---
Same bug exists with GCC 7.2.0 and GCC 6.4.0, when compiled on a APFS
filesystem.