[Bug other/82301] [8 regression] Updated test case g++.dg/ext/attr-ifunc-1.C (and others) in r253041 segfault on powerpc64

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01603.html

[Bug c++/82304] GCC compiles constexpr function with double reinterpret_cast in a constant context

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-25
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug target/82305] gcc.c-torture/execute/20000822-1.c fails on x86_64 Cygwin

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-*-cygwin
  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
It might be the case trampolines in cygwin are not supported.

[Bug c++/82316] unexpected warning for using 'register' storage class in extern "C" declarations

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> extern "C" just means the linkage and not actual C code.
> 
> This is true with other differences between C and C++ like auto and typedef
> of void types and arguments.

It's a common mistake to make; I got confused about that, too, in the
conversation on bug 37041

[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||i?86-*-*

--- Comment #1 from Andrew Pinski  ---
This is interesting because log2 should have already done a rounding to double
before returning.

What glibc version are you using because that matters here too.

Re: Possible Bug with Building on Current Tree

[Andrew Pinski]

On Sun, Sep 24, 2017 at 2:28 PM, nick  wrote:
> Greetings All,
>
> Probably me doing something stupid what I am configuring gcc on current git 
> with:
> $PWD/../gcc/configure --prefix=$HOME/GCC-7.0.1 
> --enable-languages=c,c++,fortran,go
>
> This is in a directory called objdir for building gcc as according to docs. 
> It makes
> with this:
>
> make: *** No rule to make target 
> '../build-x86_64-pc-linux-gnu/libiberty/libiberty.a', needed by 
> 'build/genmodes'.  Stop.
> make: *** Waiting for unfinished jobs
> tm_p.h is unchanged
> config.h is unchanged
> bconfig.h is unchanged
> tm.h is unchanged
>

It seems like you are just configuring the gcc subdirectory rather
than the toplevel directory.

Thanks,
Andrew

>
> I tried googling on line and tried using a clean tree which was the fix 
> before. That doesn't find it, either
> the build is currently broken as it worked yesterday or something is wrong 
> with my config command.
>
> Nick

[Bug target/79041] aarch64 backend emits R_AARCH64_ADR_PREL_PG_HI21 relocation despite -mpc-relative-literal-loads option being used

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski  ---
This test also fails with -fpic.

[Bug c/82318] New: -fexcess-precision=standard has no effect on a libm function call

[vincent-gcc at vinc17 dot net]

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

Bug ID: 82318
   Summary: -fexcess-precision=standard has no effect on a libm
function call
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Consider the following C program:

#include 

int main (void)
{
  double r = 5.0;
  return (double) log2 (r) == (double) log2 (r) ? 0 : 1;
}

When compiled on x86_64 with -O0 -m32 -fexcess-precision=standard, the program
returns 1 instead of 0.

The generated asm code contains:

[...]
fldl.LC0
fstpl   -16(%ebp)
subl$8, %esp
pushl   -12(%ebp)
pushl   -16(%ebp)
calllog2
addl$16, %esp
fstpl   -32(%ebp)
subl$8, %esp
pushl   -12(%ebp)
pushl   -16(%ebp)
calllog2
addl$16, %esp
fldl-32(%ebp)
fucomi  %st(1), %st
[...]

If I understand correctly, the result of the first log2 is stored into memory,
but not the second one.

[Bug target/82267] x32: unnecessary address-size prefixes. Why isn't -maddress-mode=long the default?

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #4 from H.J. Lu  ---
(In reply to Peter Cordes from comment #0)
> 
> Even (%rsp) is avoided for some reason, even though -mx32 still uses
> push/pop/call/ret which use the full %rsp, so it has to be valid.
> 
> int stackuse(void) {
> volatile int foo = 2;
> return foo * 3;
> }
> movl$2, -4(%esp)# 0x67 prefix
> movl-4(%esp), %eax  # 0x67 prefix
> leal(%rax,%rax,2), %eax # no prefixes
> ret
> 

GCC 8 generates:

movl$2, -4(%rsp)
movl-4(%rsp), %eax
leal(%rax,%rax,2), %eax
ret

[Bug target/82267] x32: unnecessary address-size prefixes. Why isn't -maddress-mode=long the default?

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Sun Sep 24 21:37:09 2017
New Revision: 253127

URL: https://gcc.gnu.org/viewcvs?rev=253127=gcc=rev
Log:
x32: Encode %esp as %rsp to avoid 0x67 prefix

Since the upper 32 bits of stack register are always zero for x32, we
can encode %esp as %rsp to avoid 0x67 prefix in address if there is no
index or base register.

gcc/

PR target/82267
* config/i386/i386.c (ix86_print_operand_address_as): Encode
%esp as %rsp to avoid 0x67 prefix if there is no index or base
register.

gcc/testsuite/

PR target/82267
* gcc.target/i386/pr82267.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr82267.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

Possible Bug with Building on Current Tree

[nick]

Greetings All,

Probably me doing something stupid what I am configuring gcc on current git 
with:
$PWD/../gcc/configure --prefix=$HOME/GCC-7.0.1 
--enable-languages=c,c++,fortran,go

This is in a directory called objdir for building gcc as according to docs. It 
makes
with this:

make: *** No rule to make target 
'../build-x86_64-pc-linux-gnu/libiberty/libiberty.a', needed by 
'build/genmodes'.  Stop.
make: *** Waiting for unfinished jobs
tm_p.h is unchanged
config.h is unchanged
bconfig.h is unchanged
tm.h is unchanged


I tried googling on line and tried using a clean tree which was the fix before. 
That doesn't find it, either
the build is currently broken as it worked yesterday or something is wrong with 
my config command.

Nick

[Bug bootstrap/82300] Bootstrapping gcc-8 does not work on darwin

[physiker at toast2 dot net]

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

--- Comment #4 from physiker at toast2 dot net ---
I was able to bootstrap revision 253118 (see
https://gcc.gnu.org/ml/gcc-testresults/2017-09/msg02107.html).
Thank you very much for fixing this issue.

[Bug target/82092] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
(I don't see the reported problem on Darwin15 with any assembler/linker pair I
have)

However,we're certain there's an underlying issue.

We're seeing a variety of problems which are all pointing some difficulty
introduced by reorder and partition.  My current suspicion is that some code
fragment isn't a legal atom.

With current trunk I'm seeing repeatable dwarf verify errors for eh sections in
some of the libgcc objects - will be debugging these.

Most likely this is also a dup of 81733.

So - Dominique's comment #3 is worth testing to determine if the issue you see
is another in this series.

I don't think it's the same underlying cause as 57438 (that was caused by
function bodies being elided when the function contained an inline
__builtin_unreachable()).

Arguably, 0-sized FDEs could be dropped by ld64 (I have a patch that does
this), since an exception cannot originate from a 0-sized region.  However, it
would still be worth warning even so since it probably indicates a code-gen
issue earlier in the toolchain (as we suspect here).

[Bug target/68014] ICE when using Flag Output Operands

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uroš Bizjak  ---
Fixed in gcc-7 and gcc-8:

pr68014.c: In function ‘main’:
pr68014.c:8:7: error: invalid 'asm': invalid use of asm flag output
   asm volatile("# %0" : "=@ccc"(x));
   ^~~

[Bug target/82317] New: error "'__builtin_s390_vec_min' matching variant requires z14 or higher" for __vector(2) double when it should work on -march=z13 as well

[markos at freevec dot org]

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

Bug ID: 82317
   Summary: error "'__builtin_s390_vec_min' matching variant
requires z14 or higher" for __vector(2) double when it
should work on -march=z13 as well
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markos at freevec dot org
  Target Milestone: ---
  Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
 Build: s390x-ibm-linux-gnu

While trying to extend SIMD code that worked on z13 to z14, I ran into this
error (using latest gcc snapshot:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/lib64/gcc/s390x-ibm-linux-gnu/8.0.0/lto-wrapper
Target: s390x-ibm-linux-gnu
Configured with: ../configure --prefix=/usr/local --libdir=/usr/local/lib64
--libexecdir=/usr/local/lib64 --enable-languages=c,c++
--enable-checking=release --enable-ssp --disable-libssp --disable-libvtv
--disable-plugin --disable-libgcj --with-system-zlib --enable-__cxa_atexit
--enable-linker-build-id --enable-linux-futex --without-system-libunwind
--with-tune=z13 --with-arch=z13 --with-long-double-128 --enable-decimal-float
Thread model: posix
gcc version 8.0.0 20170924 (experimental) (GCC)

$ /usr/local/bin/g++-pedantic -Wall -Wextra -Wundef -Wcast-align
-Wchar-subscripts -Wnon-virtual-dtor -Wunused-local-typedefs -Wpointer-arith
-Wwrite-strings -Wformat-security -Wlogical-op -Wdouble-promotion -Wno-psabi
-Wno-variadic-macros -Wno-long-long -fno-check-new -fno-common
-fstrict-aliasing -ansi -march=z13 -mzvector -std=c++11 -g
-I/srv/data/eigen.mine/build/test -I/srv/data/eigen.mine/test
-I/srv/data/eigen.mine -I/srv/data/eigen.mine/build
-DEIGEN_TEST_MAX_SIZE=320 -DEIGEN_TEST_FUNC=packetmath -DEIGEN_FAST_MATH=1
-DEIGEN_TEST_PART_1=1 -o CMakeFiles/packetmath_1.dir/packetmath.cpp.o -c
/srv/data/eigen.mine/test/packetmath.cpp
In file included from /srv/data/eigen.mine/Eigen/Core:426:0,
 from /srv/data/eigen.mine/Eigen/QR:11,
 from /srv/data/eigen.mine/test/main.h:259,
 from /srv/data/eigen.mine/test/packetmath.cpp:11:
/srv/data/eigen.mine/Eigen/src/Core/arch/ZVector/PacketMath.h: In function
'Packet Eigen::internal::pmin(const Packet&, const Packet&) [with Packet =
__vector(2) double]':
/srv/data/eigen.mine/Eigen/src/Core/arch/ZVector/PacketMath.h:425:115: error:
'__builtin_s390_vec_min' matching variant requires z14 or higher
 template<> EIGEN_STRONG_INLINE Packet2d pmin(const Packet2d& a,
const Packet2d& b) { return vec_min(a, b); }

Packet2d is a typedef of __vector double.

This code is compiled with both -march=z13 and z14 options as I need to keep
compatibility with existing z13 systems and it compiles fine with an older
compiler (gcc 6), meaning vec_min() is available on z13 for double vectors. So
either the intrinsic name has changed in latest version (gcc 8 snapshot) or
this is a bug?

Thanks

[Bug c++/82316] unexpected warning for using 'register' storage class in extern "C" declarations

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
extern "C" just means the linkage and not actual C code.

This is true with other differences between C and C++ like auto and typedef of
void types and arguments.

[Bug fortran/82143] add a -fdefault-real-16 flag

[janus at gcc dot gnu.org]

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

--- Comment #22 from janus at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #21)
> The promotion_4.f90 test fails due to bad assumptions:
> 
> (gdb) whatis d
> type = real(kind=10)

This can be fixed by:

Index: promotion_4.f90
===
--- promotion_4.f90 (revision 253117)
+++ promotion_4.f90 (working copy)
@@ -12,5 +12,5 @@ double precision :: d
 if (kind(r4) /= 4) call abort
 if (kind(r8) /= 8) call abort
 if (kind(r) /= 10) call abort
-if (kind(d) /= 16) call abort
+if (kind(d) < 10) call abort
 end


I guess we need to xfail promotion_3 and promotion_4 on those targets where
REAL(10) or REAL(16) are not supported or restrict them to those targets where
they are supported (in a similar way as in promotion.f90?).

[Bug target/68014] ICE when using Flag Output Operands

[mirq-gccboogs at rere dot qmqm.pl]

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

Michał Mirosław  changed:

   What|Removed |Added

 CC||mirq-gccboogs at rere dot 
qmqm.pl

--- Comment #3 from Michał Mirosław  ---
Just accidentally tripped on this one using gcc 6.3.0.

[Bug target/82092] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres  ---
On darwin10, starting at revision r249105, bootstrap fails with

Undefined symbols:
  "CIE.eh", referenced from:
  CIE in _negvdi2_s.o

unless I use

--- ../_clean/gcc/config/darwin.c   2017-09-18 15:49:48.0 +0200
+++ gcc/config/darwin.c 2017-09-23 21:00:41.0 +0200
@@ -3201,6 +3201,10 @@ darwin_override_options (void)
   flag_reorder_blocks = 1;
 }

+// FIXME ; Jam this off until we figure out what codegen issues are caused
+flag_reorder_blocks_and_partition = 0;
+flag_reorder_blocks = 1;
+
 /* FIXME: flag_objc_sjlj_exceptions is no longer needed since there is
only
one valid choice of exception scheme for each runtime.  */
 if (!global_options_set.x_flag_objc_sjlj_exceptions)

Could you please test this patch?

[Bug middle-end/53917] Wuninitialized warning points to place where variable doesn't occur

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-24
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
(In reply to Paulo J. Matos from comment #0)
> Created attachment 27771 [details]
> Testcase
> 
> Hi,
> 
> I have noticed that when compiling the following test case (will attach to
> the bug):
> 
> test1.c:
> int a, b;
> void fn1 ();
> typedef enum
> {
> READ_WRITE
> } TAG_STATE;
> TAG_STATE fn2 ();
> void
> fn3 ()
> {
> int c;
> if (a)
> c = 0;
> else
> switch (fn2 ())
> case 0:
> c = 1;
> b = c;
> if (b)
> fn1 ();
> }
> 
> gcc says:
> $  gcc -Os -S -Wall test1.c
> test1.c: In function 'fn3':
> test1.c:19:8: warning: 'c' may be used uninitialized in this function
> [-Wuninitialized]
> 
> However line 19 is 'if (b)'.
> 
> Used gcc46 but also reproducible with gcc47.

gcc8 seems to get this one right now:

$ /usr/local/bin/gcc -c -Os -S -Wall -Wextra 53917.c
53917.c: In function ‘fn3’:
53917.c:18:7: warning: ‘c’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
 b = c;
 ~~^~~
$

(In reply to Paulo J. Matos from comment #1)
> Here's another example:
> void fn1 ();
> typedef struct
> {
> int hdr[0];
> } foo;
> typedef enum
> {
> READ_WRITE
> } bar;
> typedef struct
> {
> struct
> {
> foo t1;
> } mp;
> } foobar;
> bar fn2 ();
> typedef struct
> {
> foobar tag_mem_config;
> } tag;
> static int
> fn3 (foobar * p1)
> {
> int valid;
> if (p1->mp.t1.hdr[0])
> valid = 0;
> else
> switch (fn2 ())
> case 0:
> valid = 1;
> return valid;
> }
> void
> fn4 ()
> {
> tag p_t1_rw_fsm_data;
> if (fn3 (_t1_rw_fsm_data.tag_mem_config))
> fn1 ();
> }
> 
> GCC says:
> test.c: In function 'fn4':
> test.c:38:8: warning: 'valid' may be used uninitialized in this function
> [-Wuninitialized]
> 
> 
> Again, line 38 is: if (fn3 (_t1_rw_fsm_data.tag_mem_config))
> In this case this looks like it's related to inlining.

gcc still gets this one wrong though:

$ /usr/local/bin/gcc -c -Os -S -Wall -Wextra 53917_a.c
53917_a.c: In function ‘fn4’:
53917_a.c:38:8: warning: ‘valid’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
 if (fn3 (_t1_rw_fsm_data.tag_mem_config))
^
$

So confirmed for the second testcase.

[Bug target/82092] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
I'll take the dup as confirmation.

[Bug target/82092] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #1 from Eric Gallager  ---
*** Bug 82315 has been marked as a duplicate of this bug. ***

[Bug bootstrap/82315] Bootstrap fails with Xcode 9.0 on MAC OS X

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Jürgen Reuter from comment #1)
> Not sure whether this related to #82300, at first glance it looks different.

Yup, it's different from bug 82300; the one this one is actually a dup of is
bug 82092 (they have the same linker error)

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

[Bug c++/82316] New: unexpected warning for using 'register' storage class in extern "C" declarations

[development at jordi dot vilar.cat]

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

Bug ID: 82316
   Summary: unexpected warning for using 'register' storage class
in extern "C" declarations
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: development at jordi dot vilar.cat
  Target Milestone: ---

C++ 17 removed the 'register' storage class, but it is still valid in C code.

In g++, a new warning has been included to cope with it:
warning: ISO C++1z does not allow 'register' storage class specifier
[-Wregister]
This warning is issued when compiling in C++ but not when compiling in C, as
expected.

But when including header files for C libraries from C++ code, typically C
declarations are introduced as extern "C". In this case, the warning should
also be supressed, as the 'register' storage refers to a valid C declaration,
but not a C++ declaration.

HOW TO REPRODUCE:

simply, compile the following line with -std=c++17:
extern "C" void test(register int);

[Bug bootstrap/82315] Bootstrap fails with Xcode 9.0 on MAC OS X

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

Version|unknown |8.0

--- Comment #1 from Jürgen Reuter  ---
Not sure whether this related to #82300, at first glance it looks different.

[Bug bootstrap/82315] New: Bootstrap fails with Xcode 9.0 on MAC OS X

[juergen.reuter at desy dot de]

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

Bug ID: 82315
   Summary: Bootstrap fails with Xcode 9.0 on MAC OS X
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

gcc trunk (r253118) fails to bootstrap with Xcode 9.0.
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.0.0 (clang-900.0.37)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
on MAC OS X Sierra 10.12.6. 

/usr/local/packages/gcc_trunk/_build/./gcc/xgcc
-B/usr/local/packages/gcc_trunk/_build/./gcc/
-B/usr/local/x86_64-apple-darwin16.7.0/bin/
-B/usr/local/x86_64-apple-darwin16.7.0/lib/ -isystem
/usr/local/x86_64-apple-darwin16.7.0/include -isystem
/usr/local/x86_64-apple-darwin16.7.0/sys-include-O2  -g -O2 -DIN_GCC-W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -mmacosx-version-min=10.5 -pipe -fno-common -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -dynamiclib -nodefaultlibs
-install_name /usr/local/lib/libgcc_s.1.dylib -single_module -o
./libgcc_s.dylib -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1
-current_version 1.0 -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o
_ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o
_trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o
_subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o
_ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o
_ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o
_paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o
_mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o
_divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o
_clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o
_fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o
_floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _fixsfti_s.o _fixdfti_s.o _fixxfti_s.o _fixtfti_s.o
_fixunssfti_s.o _fixunsdfti_s.o _fixunsxfti_s.o _fixunstfti_s.o _floattisf_s.o
_floattidf_s.o _floattixf_s.o _floattitf_s.o _floatuntisf_s.o _floatuntidf_s.o
_floatuntixf_s.o _floatuntitf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o
_udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o darwin-64_s.o
cpuinfo_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o
letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o
fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o
floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o
floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o
trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o
unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc
0  0x10dfccb1b  __assert_rtn + 129
0  0x10dfccb1b  __assert_rtn + 129
1  0x10dfe023a 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 3030
1  0x10dfe023a 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 3030
2  0x10dfd7bcc  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, ld::File::Ordinal,
mach_o::relocatable::ParserOptions const&) + 282
2  0x10dfd7bcc  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, ld::File::Ordinal,
mach_o::relocatable::ParserOptions const&) + 282
3  0x10e01cae4  ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool)
+ 830
3  0x10e01cae4  ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool)
+ 830
4  0x10e01f46d  ld::tool::InputFiles::parseWorkerThread() + 497
4  0x10e01f46d  ld::tool::InputFiles::parseWorkerThread() + 497
5  0x7fffdd55b93b  _pthread_body + 180
5  0x7fffdd55b93b  _pthread_body + 180
6  0x7fffdd55b887  _pthread_body + 0
6  0x7fffdd55b887  _pthread_body + 0
A linker snapshot was created at:
/tmp/libgcc_s.dylib-2017-08-24-013125.ld-snapshot
ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function
parse, file
/Library/Caches/com.apple.xbs/Sources/ld64/ld64-302.3/src/ld/parsers/macho_relocatable_file.cpp,
line 1898.
collect2: error: ld returned 1 exit status

[Bug fortran/57042] Strange typespec with -fdump-parse-tree

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
Is there still an issue left for this PR? I did not see anything wrong for the
tests with trunk (8.0) or 4.8.

[Bug fortran/55501] [F03] ICE using MERGE in constant expr

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #17 from Dominique d'Humieres  ---
From comment 15

>That issue was fixed for PR 56649 - which is the identical to the original
> test case.
> ...
> That program still gives an ICE with GCC 4.9:
> f951: internal compiler error: in is_illegal_recursion, at 
> fortran/resolve.c:1555

The ICE is now

internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:6972

and I have opened pr82314 for this remaining issue.

Closing this PR.

[Bug fortran/82314] New: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972

[dominiq at lps dot ens.fr]

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

Bug ID: 82314
   Summary: internal compiler error: in gfc_conv_expr_descriptor,
at fortran/trans-array.c:6972
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

Compiling the following test (coming from pr55501)

program testmerge3
  implicit none
  integer,parameter::iarray(merge(2,3,.true.)) = 1, i = size(iarray)
  print "(A,99I2)",'i,iarray =',i,iarray
end program testmerge3

gives the ICE

pr55501_3.f90:4:0:

   print "(A,99I2)",'i,iarray =',i,iarray

internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:6972

(gcc_assert (ss != gfc_ss_terminator);).

[Bug fortran/25071] dummy argument larger than actual argument

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dominiq at lps dot 
ens.fr

--- Comment #24 from Dominique d'Humieres  ---
Taking.

[Bug fortran/66328] Wrong initialization of derived-type DATA

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Thomas Koenig  ---
Test case committed to trunk, closing.

[Bug fortran/33056] [Meta-bug] Data - statement related bugs

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
Bug 33056 depends on bug 66328, which changed state.

Bug 66328 Summary: Wrong initialization of derived-type DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66328

   What|Removed |Added

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

[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834
Bug 32834 depends on bug 66328, which changed state.

Bug 66328 Summary: Wrong initialization of derived-type DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66328

   What|Removed |Added

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

[Bug fortran/66328] Wrong initialization of derived-type DATA

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Sep 24 14:26:55 2017
New Revision: 253126

URL: https://gcc.gnu.org/viewcvs?rev=253126=gcc=rev
Log:
2017-09-24  Thomas Koenig  
PR fortran/66328

* gfortran.dg/data_derived_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/data_derived_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/54613] [F03] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613
Bug 54613 depends on bug 54633, which changed state.

Bug 54633 Summary: ICEs and reject valid with MINLOC/MINVAL (MAXLOC/MAXVAL) due 
to lacking compile-time simplification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54633

   What|Removed |Added

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

[Bug fortran/54633] ICEs and reject valid with MINLOC/MINVAL (MAXLOC/MAXVAL) due to lacking compile-time simplification

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Koenig  ---
The remaining bug is now PR 82313.

[Bug libfortran/79612] missing space in diagnostic: Incorrect rank of return array in

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Dominique d'Humieres  ---
Closing.

[Bug fortran/82313] New: Rejects-valid for sum(minloc(...))) as array dimension

[tkoenig at gcc dot gnu.org]

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

Bug ID: 82313
   Summary: Rejects-valid for sum(minloc(...))) as array dimension
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

This is a spin-off from PR 54633.

integer y((sum(minloc((/1/
end

is rejected with the (IMHO misleading) error message

   integer y((sum(minloc((/1/
1
Error: Expected another dimension in array declaration at (1)

[Bug fortran/54633] ICEs and reject valid with MINLOC/MINVAL (MAXLOC/MAXVAL) due to lacking compile-time simplification

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Sep 24 13:51:39 2017
New Revision: 253125

URL: https://gcc.gnu.org/viewcvs?rev=253125=gcc=rev
Log:
2017-09-24  Thomas Koenig  

PR fortran/54633
* gfortran.dg/intrinsic_bounds_1.f90: New test.
* gfortran.dg/intrinsic_param_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_bounds_1.f90
trunk/gcc/testsuite/gfortran.dg/intrinsic_param_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/79612] missing space in diagnostic: Incorrect rank of return array in

[dominiq at gcc dot gnu.org]

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

--- Comment #6 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Sep 24 13:47:11 2017
New Revision: 253124

URL: https://gcc.gnu.org/viewcvs?rev=253124=gcc=rev
Log:
+2017-09-24  Dominique d'Humieres  

PR libgfortran/79612
* runtime/bounds.c: Use GFC_ASSERT.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/runtime/bounds.c

[Bug fortran/54633] ICEs and reject valid with MINLOC/MINVAL (MAXLOC/MAXVAL) due to lacking compile-time simplification

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> So, this PR is mostly fixed except for the sum(minloc(((1))) issue.

Why not opening a new PR for the remaining issue and closing this one as FIXED?

[Bug fortran/52622] ICE in gfortran 4.6.3, x86_64

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  ---
An instrumented compiler gives:

pr52622_red.f90:30:35:

   type, bind(c) :: Args_Basic_epv_t
   1
Warning: Derived type 'args_basic_epv_t' with BIND(C) attribute at (1) is
empty, and may be inaccessible by the C companion processor
pr52622_red.f90:98:2:

   function passeverywherefcomplex_impl(self, c1, c2, c3, exception) result(   
&
  1
Error: Unclassifiable statement at (1)
=
==2028==ERROR: AddressSanitizer: heap-use-after-free on address 0x6128091a
at pc 0x0001002ff02e bp 0x7fff5fbfe920 sp 0x7fff5fbfe918
READ of size 1 at 0x6128091a thread T0
#0 0x1002ff02d in resolve_symbol(gfc_symbol*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1002ff02d)
#1 0x10039b1b8 in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*),
void (*)(gfc_symbol*))
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x10039b1b8)
#2 0x1003b3773 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1003b3773)
#3 0x100345c3a in resolve_types(gfc_namespace*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x100345c3a)
#4 0x100345d66 in resolve_types(gfc_namespace*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x100345d66)
#5 0x1002f42cf in gfc_resolve(gfc_namespace*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1002f42cf)
#6 0x10029a2bf in gfc_parse_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x10029a2bf)
#7 0x1003f14f2 in gfc_be_parse_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1003f14f2)
#8 0x1045a4bac in compile_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1045a4bac)
#9 0x1045ad7fe in do_compile()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1045ad7fe)
#10 0x10651f30d in toplev::main(int, char**)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x10651f30d)
#11 0x1065249ce in main
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1065249ce)
#12 0x7fffbcb65234 in start (/usr/lib/system/libdyld.dylib+0x5234)

0x6128091a is located 90 bytes inside of 320-byte region
[0x612808c0,0x61280a00)
freed by thread T0 here:
#0 0x152cd4120 in wrap_free.part.0
(/opt/gcc/gcc8w/lib/libasan.4.dylib+0x67120)
#1 0x1003b3068 in gfc_free_symbol(gfc_symbol*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1003b3068)
#2 0x1003b3519 in gfc_release_symbol(gfc_symbol*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1003b3519)
#3 0x1003bf7ed in gfc_restore_last_undo_checkpoint()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1003bf7ed)
#4 0x1003bfea3 in gfc_undo_symbols()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1003bfea3)
#5 0x10027e8e5 in reject_statement()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x10027e8e5)
#6 0x100289e9c in decode_statement()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x100289e9c)
#7 0x10028c1dc in next_free()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x10028c1dc)
#8 0x10028caa6 in next_statement()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x10028caa6)
#9 0x1002991ab in parse_contained(int)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1002991ab)
#10 0x1002996e4 in parse_module()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1002996e4)
#11 0x10029a4e1 in gfc_parse_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x10029a4e1)
#12 0x1003f14f2 in gfc_be_parse_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1003f14f2)
#13 0x1045a4bac in compile_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1045a4bac)
#14 0x1045ad7fe in do_compile()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1045ad7fe)
#15 0x10651f30d in toplev::main(int, char**)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x10651f30d)
#16 0x1065249ce in main
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1065249ce)
#17 0x7fffbcb65234 in start (/usr/lib/system/libdyld.dylib+0x5234)

previously allocated by thread T0 here:
#0 0x152cd376c in wrap_calloc (/opt/gcc/gcc8w/lib/libasan.4.dylib+0x6676c)
#1 0x106366bd9 in xcalloc
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x106366bd9)
#2 0x1003aafd8 in gfc_new_symbol(char const*, gfc_namespace*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.7.0/8.0.0/f951+0x1003aafd8)
#3 0x1003ad6ea in gfc_get_sym_tree(char const*, 

[Bug fortran/68546] passing non-contiguous associated array section garbles results

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
   Severity|normal  |enhancement

--- Comment #3 from Thomas Koenig  ---
Actually, the problem is in the program. We should warn about
this, but not repack.

See https://gcc.gnu.org/ml/fortran/2017-08/msg00055.html
(but I didn't do the part with the arguments there).

[Bug fortran/52622] ICE in gfortran 4.6.3, x86_64

[tkoenig at gcc dot gnu.org]

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

--- Comment #11 from Thomas Koenig  ---
The first problem happens when resolving the symbol
passeverywherefcomplex_impl:

(gdb) p *sym
$5 = {name = 0x5e5c600 "passeverywherefcomplex_impl"

The offending line is

4866   if (formal->sym && formal->sym->attr.flavor == FL_NAMELIST)

and it appers to refer to formal->sym
(gdb) p *(formal->sym)
$13 = {name = 0x5e6f1d8 "self", 

So, there is probably a pointer that should have been zeroed
earlier.

[Bug fortran/52622] ICE in gfortran 4.6.3, x86_64

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2013-12-29 00:00:00 |2017-9-24

--- Comment #10 from Thomas Koenig  ---
Looks like a case of a pointer not being reset when
undoing something. Valgrind complains:

g.f90:30:35:

   type, bind(c) :: Args_Basic_epv_t
   1
Warnung: Abgeleiteter Typ »args_basic_epv_t« mit Attribut BIND(C) bei (1) ist
leer und könnte für entsprechenden C-Prozessor unzugreifbar sein
g.f90:130:2:

   function passeverywherefcomplex_impl(self, c1, c2, c3, exception) result(   
&
  1
Fehler: Nicht klassifizierbare Anweisung bei (1)
==5794== Invalid read of size 1
==5794==at 0x921D0D: resolve_symbol(gfc_symbol*) (resolve.c:14866)
==5794==by 0x93FF92: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) (symbol.c:4061)
==5794==by 0x91B87B: resolve_types(gfc_namespace*) (resolve.c:16156)
==5794==by 0x91B97C: resolve_types(gfc_namespace*) (resolve.c:16167)
==5794==by 0x91FF6C: gfc_resolve(gfc_namespace*) [clone .part.51]
(resolve.c:16269)
==5794==by 0x90EE44: gfc_parse_file() (parse.c:6217)
==5794==by 0x951C7F: gfc_be_parse_file() (f95-lang.c:204)
==5794==by 0xDD67BE: compile_file() (toplev.c:456)
==5794==by 0x883E1F: do_compile (toplev.c:2037)
==5794==by 0x883E1F: toplev::main(int, char**) (toplev.c:2172)
==5794==by 0x885E0A: main (main.c:39)
==5794==  Address 0x621422a is 90 bytes inside a block of size 336 free'd
==5794==at 0x4C2E2BB: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5794==by 0x9445D7: gfc_restore_last_undo_checkpoint() (symbol.c:3600)
==5794==by 0x905347: reject_statement() (parse.c:2546)
==5794==by 0x9080E4: decode_statement() (parse.c:347)
==5794==by 0x9096CC: next_free (parse.c:1225)
==5794==by 0x9096CC: next_statement() (parse.c:1457)
==5794==by 0x90D97C: parse_contained(int) (parse.c:5483)
==5794==by 0x90E715: parse_module() (parse.c:5895)
==5794==by 0x90EE29: gfc_parse_file() (parse.c:6198)
==5794==by 0x951C7F: gfc_be_parse_file() (f95-lang.c:204)
==5794==by 0xDD67BE: compile_file() (toplev.c:456)
==5794==by 0x883E1F: do_compile (toplev.c:2037)
==5794==by 0x883E1F: toplev::main(int, char**) (toplev.c:2172)
==5794==by 0x885E0A: main (main.c:39)
==5794==  Block was alloc'd at
==5794==at 0x4C2F0A5: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5794==by 0x156B940: xcalloc (xmalloc.c:162)
==5794==by 0x942FE8: gfc_new_symbol(char const*, gfc_namespace*)
(symbol.c:3003)
==5794==by 0x943467: gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) (symbol.c:3252)
==5794==by 0x9436D3: gfc_get_symbol(char const*, gfc_namespace*,
gfc_symbol**) (symbol.c:3305)
==5794==by 0x8A5B80: gfc_match_formal_arglist(gfc_symbol*, int, int, bool)
(decl.c:5953)
==5794==by 0x8AAFF8: gfc_match_function_decl() (decl.c:6773)
==5794==by 0x907C0A: decode_statement() (parse.c:343)
==5794==by 0x9096CC: next_free (parse.c:1225)
==5794==by 0x9096CC: next_statement() (parse.c:1457)
==5794==by 0x90D97C: parse_contained(int) (parse.c:5483)
==5794==by 0x90E715: parse_module() (parse.c:5895)
==5794==by 0x90EE29: gfc_parse_file() (parse.c:6198)

[Bug fortran/82143] add a -fdefault-real-16 flag

[sch...@linux-m68k.org]

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

--- Comment #21 from Andreas Schwab  ---
The promotion_4.f90 test fails due to bad assumptions:

(gdb) whatis d
type = real(kind=10)

[Bug fortran/82143] add a -fdefault-real-16 flag

[sch...@linux-m68k.org]

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

--- Comment #20 from Andreas Schwab  ---
On m68k there is a compilation failure for promotion_3.f90:

f951: Fatal Error: REAL(KIND=16) is not available for '-fdefault-real-16'
option

The promotion_4.f90 test fails during exection.

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #16 from Thomas Koenig  ---
This patch

> Draft patch - one probably needs to do something similar for derived types.
> 
> --- a/gcc/fortran/decl.c
> +++ b/gcc/fortran/decl.c
> @@ -1500,6 +1500,8 @@ add_init_expr_to_sym (const char *name, gfc_expr
> **initp, locus *var_locus)
>  >where);
> 
>   array->shape = gfc_get_shape (sym->as->rank);
> + if (init->ts.type == BT_CHARACTER)
> +   array->ts.u.cl = init->ts.u.cl;
>   for (n = 0; n < sym->as->rank; n++)
> spec_dimen_size (sym->as, n, >shape[n]);

fixes the test case, but regresses 

program p
   character(1), parameter :: x1(2) = 'a'
   character(*), parameter :: x2(2) = x1
end

which is a part of pr68154.f90 .

[Bug c++/82309] Compiled binary received SIGSEGV when -g

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Sergey Markelov from comment #6)
> Unfortunately -fsanitize=undefined does not catch this. Thank you for your
> help.

-fsanitize=address catchs it, specifically the use-after-return sanitizer, but
only since GCC 7.

[Bug fortran/82143] add a -fdefault-real-16 flag

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #19 from Rainer Orth  ---
The new gfortran.dg/promotion_4.f90 test FAILs on sparc-sun-solaris2.11:

+FAIL: gfortran.dg/promotion_4.f90   -O0  (test for excess errors)
+WARNING: gfortran.dg/promotion_4.f90   -O0  compilation failed to produce
executable

32 and 64-bit at all optimization levels:

Excess errors:
f951: Fatal Error: REAL(KIND=10) is not available for '-fdefault-real-10'
option
compilation terminated.

According to gcc-testresults, there are failures on aarch64-unknown-linux-gnu,
powerpc64le-unknown-linux-gnu, s390x-ibm-linux-gnu, and m68k-unknown-linux-gnu.

  Rainer

[Bug fortran/82312] [7/8 Regression] Pointer assignment to component of class variable results wrong vptr for the variable.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||5.4.0, 6.4.0
   Keywords||wrong-code
   Last reconfirmed||2017-09-24
 Ever confirmed|0   |1
Summary|Pointer assignment to   |[7/8 Regression] Pointer
   |component of class variable |assignment to component of
   |results wrong vptr for the  |class variable results
   |variable.   |wrong vptr for the
   ||variable.
  Known to fail||7.2.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
Regression which occurred between r241089 + 3 patches (2016-10-13, OK) and
r241140 + 4 patches (2016-10-13, wrong). I did not find any obvious candidate
in this range.

[Bug fortran/82312] New: Pointer assignment to component of class variable results wrong vptr for the variable.

[pault at gcc dot gnu.org]

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

Bug ID: 82312
   Summary: Pointer assignment to component of class variable
results wrong vptr for the variable.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

Posted on Stack Overflow:
https://stackoverflow.com/questions/46369744/gfortran-associates-wrong-type-bound-procedure/46388339#46388339

module minimalisticcase
implicit none

type, public :: DataStructure
integer :: i
contains
procedure, pass :: init => init_data_structure
procedure, pass :: a => beginning_of_alphabet
end type



type, public :: DataLogger
type(DataStructure), pointer :: data_structure
contains
procedure, pass :: init => init_data_logger
procedure, pass :: do_something => do_something
end type

contains
subroutine init_data_structure(self)
implicit none
class(DataStructure), intent(inout) :: self
write(*,*) 'init_data_structure'
end subroutine

subroutine beginning_of_alphabet(self)
implicit none
class(DataStructure), intent(inout) :: self

write(*,*) 'beginning_of_alphabet'
end subroutine

subroutine init_data_logger(self, data_structure)
implicit none
class(DataLogger), intent(inout) :: self
class(DataStructure), target :: data_structure
write(*,*) 'init_data_logger'

self%data_structure => data_structure
call self%do_something()
end subroutine

subroutine do_something(self)
implicit none
class(DataLogger), intent(inout) :: self

write(*,*) 'do_something'
end subroutine
end module

program main
use minimalisticcase
implicit none

type(DataStructure) :: data_structure
type(DataLogger) :: data_logger

call data_structure%init()
call data_logger%init(data_structure)
end program

produces

 init_data_structure
 init_data_logger
 beginning_of_alphabet

rather than

 init_data_structure
 init_data_logger
 do_something

The tree dump reveals that the vptr of 'self' is being set to the address of
the 'DataStructure' vtable.

Paul

[Bug fortran/54633] ICEs and reject valid with MINLOC/MINVAL (MAXLOC/MAXVAL) due to lacking compile-time simplification

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
integer x(minval((/1/))) is accepted now.

integer y((sum(minloc((/1/ is rejected with the
(IMHO misleading) error message

   integer y((sum(minloc((/1/
1
Error: Expected another dimension in array declaration at (1)

integer x(minval((/1/),mask=(/.TRUE./)))

is accepted.

  integer, parameter :: m = minval((/1/))

is now rejected with -std=f95 and accepted by default:

   integer, parameter :: m = minval((/1/))
   1
Error: Fortran 2003: Transformational function 'minval' at (1) is invalid in an
initialization expression

So, this PR is mostly fixed except for the sum(minloc(((1))) issue.

[Bug fortran/80118] [5/6/7/8 Regression] ICE with zero size parameter array

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Sep 24 08:39:00 2017
New Revision: 253123

URL: https://gcc.gnu.org/viewcvs?rev=253123=gcc=rev
Log:
2017-09-24  Thomas Koenig  
Steven G. Kargl  

PR fortran/80118
* expr.c (gfc_get_full_arrayspec_from_expr): If there is
no symtree, set array spec to NULL.

2017-09-24  Thomas Koenig  
Steven G. Kargl  

PR fortran/80118
* gfortran.dg/zero_sized_7.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/zero_sized_7.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/82309] Compiled binary received SIGSEGV when -g

[sergio_nsk at yahoo dot de]

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

--- Comment #6 from Sergey Markelov  ---
(In reply to Andrew Pinski from comment #5)
> The temp variable goes out if scope is the result of v0 + v1. And not the
> auto.  IIRC -fsanitize=undefined will catch this.

Yes, I agree, I understood it from your previous comment. Sorry, I was mistaken
with the extra minimized bug.cpp, so you can not see Vector constructor from
'VectorSum'.

'auto sum = v0 + v1 + v2' deduces the type VectorSum
Vector> with a reference to a temp variable of the type VectorSum.

'Vector sum = v0 + v1 + v2' sums and copies values during the temp scope is
valid.

Unfortunately -fsanitize=undefined does not catch this. Thank you for your
help.