[Bug fortran/37336] [F03] Finish derived-type finalization

2019-07-01 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336

--- Comment #30 from Jürgen Reuter  ---
Are there any plans on finishing the finalization implementation? To me it
looks that the missing cases are the last open issues (besides some minor known
bug) to claim complete F2003 implementation.

[Bug bootstrap/90808] gcc fails to build/bootstrap with XCode 10.2.1

2019-06-10 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90808

--- Comment #7 from Jürgen Reuter  ---
Yes, there two things. The missing library comes from the fact that I didn't
install the system header and libraries under /usr/. I copied the files, now I
get these warnings (but everything works):
ld: warning: text-based stub file /usr/lib/system/libsystem_notify.tbd and
library file /usr/lib/system/libsystem_notify.dylib are out of sync. Falling
back to library file for linking.
ld: warning: text-based stub file /usr/lib/system/libsystem_sandbox.tbd and
library file /usr/lib/system/libsystem_sandbox.dylib are out of sync. Falling
back to library file for linking.
...
etc.

[Bug bootstrap/90808] gcc fails to build/bootstrap with XCode 10.2.1

2019-06-10 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90808

--- Comment #2 from Jürgen Reuter  ---
So that means this is something that can be solved by editing the gcc code?

[Bug bootstrap/90808] New: gcc fails to build/bootstrap with XCode 10.2

2019-06-10 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90808

Bug ID: 90808
   Summary: gcc fails to build/bootstrap with XCode 10.2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

There is a new bootstrap problem, I don't know whether this is a regression, or
something new due to the new command line tools of Apple.
In file included from ../../../libgcc/libgcov-interface.c:26:
../../../libgcc/libgcov.h: In function 'gcov_get_counter_ignore_scaling':
../../../libgcc/libgcov.h:331:44: warning: unused parameter 'ignore_scaling'
[-Wunused-parameter]
  331 | gcov_get_counter_ignore_scaling (gcov_type ignore_scaling)
  |  ~~^~
/usr/local/packages/gcc_10.0/_build/./gcc/xgcc
-B/usr/local/packages/gcc_10.0/_build/./gcc/
-B/usr/local/x86_64-apple-darwin18.5.0/bin/
-B/usr/local/x86_64-apple-darwin18.5.0/lib/ -isystem
/usr/local/x86_64-apple-darwin18.5.0/include -isystem
/usr/local/x86_64-apple-darwin18.5.0/sys-include   -fno-checking -g -O2 -O2  -g
-O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  
-mmacosx-version-min=10.5 -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -mmacosx-version-min=10.5 -pipe -fno-common -I. -I.
-I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc
-I../../../libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o _gcov.o -MT _gcov.o
-MD -MP -MF _gcov.dep -DL_gcov -c ../../../libgcc/libgcov-driver.c
ld: library not found for -ldylib1.10.5.o
collect2: error: ld returned 1 exit status
make[5]: *** [libgcc_s.dylib] Error 1
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[3]: *** Waiting for unfinished jobs
In file included from ../../../libgcc/libgcov-interface.c:26:
../../../libgcc/libgcov.h: In function 'gcov_get_counter_ignore_scaling':
../../../libgcc/libgcov.h:331:44: warning: unused parameter 'ignore_scaling'
[-Wunused-parameter]
  331 | gcov_get_counter_ignore_scaling (gcov_type ignore_scaling)
  |  ~~^~
In file included from ../../../libgcc/libgcov-interface.c:26:
../../../libgcc/libgcov.h: In function 'gcov_get_counter_ignore_scaling':
../../../libgcc/libgcov.h:331:44: warning: unused parameter 'ignore_scaling'
[-Wunused-parameter]
  331 | gcov_get_counter_ignore_scaling (gcov_type ignore_scaling)
  |  ~~^~
In file included from ../../../libgcc/libgcov-driver.c:26:
../../../libgcc/libgcov.h: In function 'gcov_get_counter_ignore_scaling':
../../../libgcc/libgcov.h:331:44: warning: unused parameter 'ignore_scaling'
[-Wunused-parameter]
  331 | gcov_get_counter_ignore_scaling (gcov_type ignore_scaling)
  |  ~~^~
make[2]: *** [all-stage1-target-libgcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

This is r272113. r271437 was still working, but I think, I did a command lines
update before. MAC OS X is 10.14.5, XCode is 10.2.1. It seems that ca. 4-5
weeks ago I installed the command line tools beta 1, though I haven't any beta
update channel checkboxed!? Any confirmation?

[Bug fortran/90506] New: rejects-valid: function with polymorphic return type

2019-05-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90506

Bug ID: 90506
   Summary: rejects-valid: function with polymorphic return type
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

I don't know whether this already has been reported, it was discussed today
(May 16, 2019) on c.l.f. The following valid code is rejected by gfortran:

   13 |   call do_stuff(g_maker)
  |1
Error: Actual argument for 'f_maker' must be ALLOCATABLE at (1)

This is the code:
program test_poly

  implicit none

  type f_t
 real :: a
  end type f_t

  type, extends (f_t) :: g_t
 real :: b
  end type g_t

  call do_stuff(g_maker)

contains

  subroutine do_stuff (f_maker)

interface
   function f_maker () result (f)
 import f_t
 class(f_t), allocatable :: f
   end function f_maker
end interface

class(f_t), allocatable :: f

f = f_maker()

  end subroutine do_stuff

  function g_maker () result (g)

class(f_t), allocatable :: g

g = g_t(a=1.,b=1.)

  end function g_maker

end program test_poly

[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file

2019-05-08 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90379

--- Comment #5 from Jürgen Reuter  ---
I am seeing the same issue on Darwin 18.5.0 (macOSX 10.4.4) with XCode 10.2.

[Bug fortran/65381] [7/8/9/10 Regression] ICE during array result, assignment

2019-05-02 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65381

--- Comment #6 from Jürgen Reuter  ---
I do not get an ICE with the abridged versions from #5, only for the original
code.

[Bug fortran/64120] [F03] Wrong handling of allocatable character string

2019-05-02 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120

--- Comment #12 from Jürgen Reuter  ---
Paul, getting back to this one? At first glance seems not overly much work left
for the remaining case.

[Bug fortran/60560] Problem allocating character array with assumed length

2019-05-02 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60560

--- Comment #2 from Jürgen Reuter  ---
This is still present in the 10.0 trunk. How difficult is that to fix?

[Bug fortran/55735] ICE with deferred-length strings in COMMON

2019-05-02 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735

--- Comment #11 from Jürgen Reuter  ---
(In reply to Jürgen Reuter from comment #10)
> Interestingly, nagfor rejects this code with the message "Inconsistent
> definitions of COMMON block FOO in program-units $block and BAR". Both ifort
> and pgfortran compile the code, and the program issues 'ABCDEF' upon
> execution. 
> ifort warns however: warning #5436: Overlapping storage initializations
> encountered with STR.

Replying to myself :( ...
I asked on c.l.f. whether the code is conformant at all. I think, fixing the
ICE is probably not too hard (?).

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-04-17 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #81 from Jürgen Reuter  ---
LLVM worked, so I think there are enough green lights now for committing this
fix.

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-04-17 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #80 from Jürgen Reuter  ---

> A little late to the party, but this revised patch worked for me on
> 10.4.4/Xcode10.2 with gcc8.3.0, gcc7.4.0, and gcc6.5.0.  fftw3-3.3.8 built
> and passed all tests against the patched gcc8 and gcc7.  cernlib built
> against the patched gcc6.

Never too late for an important confirmation.^^
LLVM now builds (after solving unrelated PR90124, its tests are running
(45%done). Looks good.

[Bug c++/90124] [9 Regression] Compilation of llvm PDBContext.cpp fails.

2019-04-17 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #2 from Jürgen Reuter  ---
This happens not only for the git repo of LLVM, but also with their latest
release LLVM 8.0.

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-04-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #75 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #74)

> Thanks, does that include a test suite run and/or building something
> substantial (e.g. LLVM)? .. sorry to pass this on, but right now as noted,
> very limited access to Darwin test resources.

Well, our own code compiles and tests correctly, but that is Fortran2018 with
some C++ interfaces to external libraries. LLVM does not compile, but I guess
this is unrelated to the problem here:
[ 38%] Building CXX object
lib/DebugInfo/PDB/CMakeFiles/LLVMDebugInfoPDB.dir/PDBContext.cpp.o
In file included from
/Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/IPDBSession.h:12,
 from
/Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/PDBContext.h:13,
 from
/Users/reuter/local/packages/llvm-project/llvm/lib/DebugInfo/PDB/PDBContext.cpp:9:
/Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/PDBSymbol.h:20:37:
error: invalid use of incomplete type 'const class llvm::pdb::PDBSymbolData'
   20 |   auto MethodName() const->decltype(RawSymbol->MethodName()) { 
   \
  | ^
/Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/PDBSymbolData.h:27:3:
note: in expansion of macro 'FORWARD_SYMBOL_METHOD'
   27 |   FORWARD_SYMBOL_METHOD(getAccess)
  |   ^

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-04-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #73 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #68)
> Created attachment 46176 [details]
> revised fixincludes patch.

> 
> The patch attached include the generated files, and I'd be grateful if folks
> would test it (right now I have limited access to Darwin test boxen, but it
> seems to DTRT for me) - I will post to @patches, but leave commit until it's
> confirmed that it's working.

This fix works for me on Darwin 10.14.4, XCode 10.2, with r270377.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #72 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #71)
> (In reply to Iain Sandoe from comment #70)
> > (In reply to Jürgen Reuter from comment #69)
> > > (In reply to Iain Sandoe from comment #68)
> 
> > Does this mean, "when building LLVM on OSX 10.14.2 using GCC as the
> > bootstrap compiler"?
> > 
> > (I'm not sure what's wrong here - if the compiler bootstrap succeeds, then
> > the compiler should be able to process the headers - if the code is C11,
> > then _Atomic should be accepted, if it's C++ then _Atomic should be mapped
> > to volatile).
> 
> I guess that means for some other piece of (C++) code there's some use of
> _Atomic that's being messed up by including  or some other header
> that includes ucred.h.
> 
> ... will try to repeat ...

This issue was with the fixincludes from comment #45, not yet with the new one.
I have to compile/bootstrap with the new fix tonight.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #69 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #68)
> Created attachment 46176 [details]
> revised fixincludes patch.
> 
> The patch attached include the generated files, and I'd be grateful if folks
> would test it (right now I have limited access to Darwin test boxen, but it
> seems to DTRT for me) - I will post to @patches, but leave commit until it's
> confirmed that it's working.

I will test this fix tonight when I have access to enough electricity again. 

It looks like this really affects things, as my try to compile LLVM failed:
$ make
[  0%] Built target LLVMDemangle
[  0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Host.cpp.o
In file included from /usr/include/sys/sysctl.h:83,
 from
/Users/reuter/local/packages/llvm-project/llvm/lib/Support/Host.cpp:1224:
/usr/include/sys/ucred.h:94:2: error: '_Atomic' does not name a type
   94 |  _Atomic u_long  cr_ref;  /* reference count */
  |  ^~~
make[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/Host.cpp.o] Error 1

[Bug fortran/78640] [F2018] gfortran accepts invalid allocatable polymorphic result in pure function

2019-04-12 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78640

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #4 from Jürgen Reuter  ---
In the meanwhile (F2018) this is C1584, and it says: "The function result of a
pure function shall not be both polymorphic and allocatable, or have a
polymorphic allocatable ultimate component."
So this is still not allowed. Funnily, also ifort does not veto this code,
nagfor however does:
Error: pr78640.f90, line 9: Result variable of pure function F is polymorphic
allocatable

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-11 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #65 from Jürgen Reuter  ---
(In reply to Jakub Jelinek from comment #64)
> Why is this a [9 Regression] BTW?  If the failure is while compiling
> darwin-driver.c and caused by system headers using _Atomic even in C++, when
> gcc/config/darwin-driver.c is identical between 8.x and 9.x (except for
> copyright year in a comment), I don't understand how gcc 9 could fail to
> build with XCode 10.2 while gcc 8.3 would succeed.

Sorry, Jakub, when I first stumbled over the problem I thought that this was
triggered by a change in the gcc trunk, until I realized it was a change in the
XCode/system code. Indeed, it is not a regression.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-10 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #63 from Jürgen Reuter  ---
I confirm that the fix in comment #48 works also with MACOSX 10.14.4, XCode
10.2 on gcc trunk, as of r270245.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-10 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #59 from Jürgen Reuter  ---
Yes, to me this looks also like an independent problem, and it appears to me
like a sort of race condition. I also just restarted the bootstrap (without a
parallel make). Now I have to do some theoretical physics, will know more
tonight.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-10 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #56 from Jürgen Reuter  ---
I tried the fix, but now I get another error:
/libstdc++-v3/../libgcc
-I/usr/local/packages/gcc_9.0_fixincl/_build/x86_64-apple-darwin18.5.0/i386/libstdc++-v3/include/x86_64-apple-darwin18.5.0
-I/usr/local/packages/gcc_9.0_fixincl/_build/x86_64-apple-darwin18.5.0/i386/libstdc++-v3/include
-I/usr/local/packages/gcc_9.0_fixincl/libstdc++-v3/libsupc++ -std=gnu++17
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=fs_dir.lo -fimplicit-templates -g -O2 -m32 -c
../../../../../../libstdc++-v3/src/c++17/fs_dir.cc  -fno-common -DPIC
-D_GLIBCXX_SHARED -o fs_dir.o
../../../../../../libstdc++-v3/src/c++17/fs_ops.cc:31:10: fatal error:
filesystem: No such file or directory
   31 | #include 
  |  ^~~~
compilation terminated.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-10 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #54 from Jürgen Reuter  ---
Ok, after running genfixes there are still only two modified files in the whole
tree of code, namely fixincludes/inclhack.def and fixincludes/fixincl.x.
Is that as intended?

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-10 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #53 from Jürgen Reuter  ---
(In reply to Erik Schnetter from comment #46)
> The patch does not include the generated files. You need to run "genfixes"
> in the "fixincludes" directory after applying the patch.

This I don't understand: ./genfixes did nothing, just producing the message
# ./genfixes 
AutoGen-ing fixincl.x

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-09 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #50 from Jürgen Reuter  ---
(In reply to Jakub Jelinek from comment #48)
> Perhaps that redefinition of _Atomic should be guarded with
> #if (__STDC_VERSION__ < 201112L) || defined(__cplusplus)
> or so, so that for C -std=c11 you still get _Atomic?

So shall I wait for this to test the fix?

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-09 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #44 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #43)
> Created attachment 46110 [details]
> Proof-of-principle path
> 
> Does this work for you?
>  - my local testing says it generates the right wrapped include file.
> 
> (perhaps the constraint on darwin version was too tight in Erik's case)

Sorry for my ignorance, but how do I apply this? Do I just patch, and then
configure and compile/bootstrap as a normal svn checkout, or do I have to do
anything special regarding the fixincludes? And if so, is there a link to some
documentation?

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-09 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #42 from Jürgen Reuter  ---
I filed an APPLE bug report:
https://bugreport.apple.com/web/?problemID=49727047

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-08 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #40 from Jürgen Reuter  ---
Are there any news on this?

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-04 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #35 from Jürgen Reuter  ---
The latest fix doesn't work. It fails at the darwin-driver.c. So yes, all the
files mentioned before have to be modified, asan_mac.cc, sanitizer_mac.cc,
sanitizer_platform_limits_posix.cc, darwin-driver.c

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-04 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #32 from Jürgen Reuter  ---
(In reply to Erik Schnetter from comment #31)
> Here is an updated version of the patch that fixincludes both
>  and , and does not need to touch any sources
> files in GCC any more:
> 


What about the changes in the libsanitizer? Are they still necessary?

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-04 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #30 from Jürgen Reuter  ---
In addition to Erik's changes I have to do as well:
--- asan_mac.cc 2019-04-04 15:02:48.0 +0200
+++ asan_mac.cc.orig2019-04-04 16:44:32.0 +0200
@@ -32,13 +32,7 @@
 #include   // for free()
 #include 
 #include 
-#if defined(__cplusplus) && __cplusplus >= 201103L
-#  define _Atomic volatile
-#endif
 #include 
-#if defined(__cplusplus) && __cplusplus >= 201103L
-#  undef _Atomic
-#endif
 #include 
 #include 

--- sanitizer_platform_limits_posix.cc  2019-04-04 15:02:24.0 +0200
+++ sanitizer_platform_limits_posix.cc.orig 2019-04-04 16:45:00.0
+0200
@@ -52,14 +52,7 @@
 #endif

 #if !SANITIZER_ANDROID
-
-#if defined(__cplusplus) && __cplusplus >= 201103L
-#  define _Atomic volatile
-#endif
 #include 
-#if defined(__cplusplus) && __cplusplus >= 201103L
-#  undef _Atomic
-#endif  
 #include 
 #include 
 #endif
@@ -77,13 +70,7 @@
 #include 
 #include 
 #include 
-#if defined(__cplusplus) && __cplusplus >= 201103L
-#  define _Atomic volatile
-#endif
 #include 
-#if defined(__cplusplus) && __cplusplus >= 201103L
-#  undef _Atomic
-#endif  
 #include 
 #include 
 #include 

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-04 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #27 from Jürgen Reuter  ---
In order to proceed bootstrapping I had also to fix 
libsanitize/sanitizer_common/sanitizer_platform_limits_posix.cc
and
libsanitize/asan/asan_mac.cc
by correspondingly wrapping include statements.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-04 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #23 from Jürgen Reuter  ---
This patch still doesn't work for me:
libtool: compile:  /usr/local/packages/gcc_9.0/_build/./gcc/xgcc -shared-libgcc
-B/usr/local/packages/gcc_9.0/_build/./gcc -nostdinc++
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.5.0/libstdc++-v3/src
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.5.0/libstdc++-v3/src/.libs
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.5.0/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-apple-darwin18.5.0/bin/
-B/usr/local/x86_64-apple-darwin18.5.0/lib/ -isystem
/usr/local/x86_64-apple-darwin18.5.0/include -isystem
/usr/local/x86_64-apple-darwin18.5.0/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../libsanitizer/sanitizer_common -I.. -I
../../../../libsanitizer/include -isystem
../../../../libsanitizer/include/system -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-apple-darwin18.5.0
-I../../../../libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g -O2 -MT
sanitizer_platform_limits_posix.lo -MD -MP -MF
.deps/sanitizer_platform_limits_posix.Tpo -c
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc 
-fno-common -DPIC -o .libs/sanitizer_platform_limits_posix.o
In file included from /usr/include/sys/attr.h:42,
 from /usr/include/sys/mount.h:76,
 from
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:55:
/usr/include/sys/ucred.h:94:2: error: '_Atomic' does not name a type
   94 |  _Atomic u_long  cr_ref;  /* reference count */
  |  ^~~
make[4]: *** [sanitizer_platform_limits_posix.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libsanitizer] Error 2
make: *** [all] Error 2

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-02 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #18 from Jürgen Reuter  ---
Do you think it would be possible to get this fix before the 9.1 release (see
the announcement by Richard B. yesterday/today)?

[Bug fortran/87127] External function not recognised from within an associate block

2019-03-29 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127

--- Comment #5 from Jürgen Reuter  ---
Paul, would be cool to get back to this one! ;)

[Bug fortran/85686] [8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385

2019-03-29 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85686

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #4 from Jürgen Reuter  ---
Any update on this one, that should possibly be not so hard to fix I'd guess.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-03-29 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #17 from Jürgen Reuter  ---
(In reply to Erik Schnetter from comment #16)
> The proper way to fix this via fixinclude is to replace declarations such as
> 
> _Atomic u_long
> 
> with
> 
> _Atomic(u_long)
> 
> which is still legal in C. In C++, one can then add
> 
> #include 
> #ifndef _Atomic
> #define _Atomic(T) std::atomic< T >
> #endif
> 
> to create proper C++ code.

It would be really great if you could provide a proper fix for gcc.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-03-29 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #15 from Jürgen Reuter  ---
Sorry for the spam, now I got it, there was something old (i.e. new) lingering
around still. Now, back to XCode 10.1 and command line tools from October 2018
with a different include/sys. Started compilation/bootstrapping of gcc again,
hopefully it is working now.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-03-29 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #14 from Jürgen Reuter  ---
Unfortunately, the downgrade to XCode 10.1 didn't work, I still get the
buggy/problematic headers. That is really annoying, because now I am stuck with
my development.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-03-29 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #13 from Jürgen Reuter  ---
I see. For the moment, I will be downgrading to XCode 10.1 with its command
line tools, but I really hope that either you or them will be able to fix it.
If you were following the progress from Apple, maybe you could also note in
this PR in case the issue is fixed by Apple?

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-03-29 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #11 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #10)

> In the short-term, I'd suggest picking up the previous version of Xcode
> command line tools [e.g.10.1] (from developer.apple.com) and using the SDK
> from that?  While this gets fixed.

with "while this gets fixed" you mean waiting for an update from the Apple side
(like an XCode 10.2.1 update or so), or a 'proper' fix from the gcc side?
And if it is a fix from the Apple side, how will I know that an update contains
the desired fix?

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-03-29 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #9 from Jürgen Reuter  ---
Trying to continue that fix I get loads and loads of other error in the
libsanitizer :(

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-03-29 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #8 from Jürgen Reuter  ---
Hi Erik,
your patch works beyond the point where the problem occurs first, but then the
sanitizer still fails bootstrapping:
In file included from /usr/include/sys/sysctl.h:83,
 from
../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:70:
/usr/local/packages/gcc_9.0/_build/gcc/include-fixed/sys/ucred.h:106:2: error:
'_Atomic' does not name a type
  106 |  _Atomic u_long  cr_ref;  /* reference count */
  |  ^~~
In file included from
../../../../libsanitizer/sanitizer_common/sanitizer_flags.h:15,
 from
../../../../libsanitizer/sanitizer_common/sanitizer_common.h:17,
 from
../../../../libsanitizer/sanitizer_common/sanitizer_mac.h:14,
 from
../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:14:
../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc: In member function
'void __sanitizer::BlockingMutex::CheckLocked()':
../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:406:13: warning:
dereferencing type-punned pointer will break strict-aliasing rules
[-Wstrict-aliasing]
  406 |   CHECK_NE(*(OSSpinLock*)_storage_, 0);
  | ^
../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:292:46:
note: in definition of macro 'CHECK_IMPL'
  292 | __sanitizer::u64 v1 = (__sanitizer::u64)(c1); \
  |  ^~
../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:406:3: note: in
expansion of macro 'CHECK_NE'
  406 |   CHECK_NE(*(OSSpinLock*)_storage_, 0);
  |   ^~~~
../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc: In function 'void*
__sanitizer::internal_start_thread(void (*)(void*), void*)':
../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:578:47: warning:
cast between incompatible function types from 'void (*)(void*)' to 'void*
(*)(void*)' [-Wcast-function-type]
  578 |   pthread_create(, 0, (void*(*)(void *arg))func, arg);
  |   ^~~~
make[4]: *** [sanitizer_mac.lo] Error 1

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-03-28 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #5 from Jürgen Reuter  ---
My hunch is that it takes Apple too long to fix that issue, so a fix inside gcc
would be very much appreciated.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-03-28 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #4 from Jürgen Reuter  ---
Created attachment 46043
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46043=edit
Darwin header file ucred.h

As this seems to be of interest, I posted the Darwin XCode 10.2 header file
ucred.h

[Bug bootstrap/89864] New: [9.0 regression] gcc fails to build/bootstrap with XCode 10.2

2019-03-28 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

Bug ID: 89864
   Summary: [9.0 regression] gcc fails to build/bootstrap with
XCode 10.2
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Using the svn revision r269983 under MACOSX 10.14.4/Darwin 18.5.0 with XCode
10.2 bootstrapping gcc 9.0 fails with the following error:
/usr/local/packages/gcc_9.0/_build/./prev-gcc/xg++
-B/usr/local/packages/gcc_9.0/_build/./prev-gcc/
-B/usr/local/x86_64-apple-darwin18.5.0/bin/ -nostdinc++
-B/usr/local/packages/gcc_9.0/_build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/src/.libs
-B/usr/local/packages/gcc_9.0/_build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/libsupc++/.libs

-I/usr/local/packages/gcc_9.0/_build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/include/x86_64-apple-darwin18.5.0

-I/usr/local/packages/gcc_9.0/_build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/include
 -I/usr/local/packages/gcc_9.0/libstdc++-v3/libsupc++
-L/usr/local/packages/gcc_9.0/_build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/src/.libs
-L/usr/local/packages/gcc_9.0/_build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2  -fno-checking  -gtoggle -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I./../intl -I../../gcc/../libcpp/include -I/usr/local//include
-I/usr/local//include -I/usr/local//include  -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace  
-o darwin-driver.o -MT darwin-driver.o -MMD -MP -MF ./.deps/darwin-driver.TPo
../../gcc/config/darwin-driver.c
In file included from /usr/include/sys/sysctl.h:83,
 from ../../gcc/config/darwin-driver.c:30:
/usr/include/sys/ucred.h:94:2: error: '_Atomic' does not name a type
   94 |  _Atomic u_long  cr_ref;  /* reference count */
  |  ^~~
make[3]: *** [darwin-driver.o] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

I guess that this was not triggered by a recent change in the gcc code but by
changes in XCode 10.2 (or Darwin 18.5.0/MACOSX 10.14.4). Darwin 10.14.3 or
XCode 10.1 has been working with r269670.

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-03-17 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #37 from Jürgen Reuter  ---
I'm inclined to advice to close this PR. In principle, it would be good to
follow up on this and see which change around Christmas 2018 triggered this,
but I fear we don't have the personpower atm.

[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure

2019-03-11 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695

--- Comment #9 from Jürgen Reuter  ---
Sorry if that maybe a stupid question but is it wise that close before the new
release to start such a bigger coding?

[Bug bootstrap/89539] [9 Regression] gcc fails to build/bootstrap on MACOSX

2019-03-01 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89539

--- Comment #6 from Jürgen Reuter  ---
Yep, fixed, thanks for the overnight reaction^^. (and next time I think I have
the guts to mark it as 'bootstrap' right from the beginning)

[Bug c/89539] New: [9.0 regression] gcc fails to build/bootstrap on MACOSX

2019-02-28 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89539

Bug ID: 89539
   Summary: [9.0 regression] gcc fails to build/bootstrap on
MACOSX
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

gcc fails to compile/bootstrap on MAC OS X Darwin 10.14.3, 64bit, 
Darwin Finarfin.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53
PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64 i386 MacBookPro11,5
Darwin

Seems to be a very recent commit, r269230 was still working, r269284 is
failing. 
My configure line was ../configure --prefix=/usr/local/ --with-gmp=/usr/local/
--with-mpfr=/usr/local/ --with-mpc=/usr/local/ --enable-checking=release
--enable-languages=c,c++,fortran,lto
The compiler is being built with 
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Do you need more information? 




/usr/local/packages/gcc_9.0/_build/./prev-gcc/xg++
-B/usr/local/packages/gcc_9.0/_build/./prev-gcc/
-B/usr/local/x86_64-apple-darwin18.2.0/bin/ -nostdinc++
-B/usr/local/packages/gcc_9.0/_build/prev-x86_64-apple-darwin18.2.0/libstdc++-v3/src/.libs
-B/usr/local/packages/gcc_9.0/_build/prev-x86_64-apple-darwin18.2.0/libstdc++-v3/libsupc++/.libs

-I/usr/local/packages/gcc_9.0/_build/prev-x86_64-apple-darwin18.2.0/libstdc++-v3/include/x86_64-apple-darwin18.2.0

-I/usr/local/packages/gcc_9.0/_build/prev-x86_64-apple-darwin18.2.0/libstdc++-v3/include
 -I/usr/local/packages/gcc_9.0/libstdc++-v3/libsupc++
-L/usr/local/packages/gcc_9.0/_build/prev-x86_64-apple-darwin18.2.0/libstdc++-v3/src/.libs
-L/usr/local/packages/gcc_9.0/_build/prev-x86_64-apple-darwin18.2.0/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2  -fno-checking  -gtoggle -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I./../intl -I../../gcc/../libcpp/include -I/usr/local//include
-I/usr/local//include -I/usr/local//include  -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace  
-o dwarf2out.o -MT dwarf2out.o -MMD -MP -MF ./.deps/dwarf2out.TPo
../../gcc/dwarf2out.c
../../gcc/dwarf2out.c: In function 'void
output_comdat_type_unit(comdat_type_node*, bool)':
../../gcc/dwarf2out.c:11237:55: error: unused parameter 'early_lto_debug'
[-Werror=unused-parameter]
11237 | output_comdat_type_unit (comdat_type_node *node, bool early_lto_debug)
  |  ~^~~
cc1plus: all warnings being treated as errors
make[3]: *** [dwarf2out.o] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

[Bug fortran/89374] gfortran does not respect privacy of types

2019-02-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89374

--- Comment #2 from Jürgen Reuter  ---
(In reply to Dominique d'Humieres from comment #1)
> Related to/duplicate of pr36383?

Related to most likely yes, could have the same origin. Probably the fortran DT
is cast into an internal C representation. I don't know whether this is the
same (or a related) object in the gfortran C code.

[Bug fortran/89374] New: gfortran does not respect privacy of types

2019-02-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89374

Bug ID: 89374
   Summary: gfortran does not respect privacy of types
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The following example is from the Intel Forum, cf. 
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/583935
The NAG compiler and now also the Intel compiler report:
Error: abstract.f90, line 69: Cannot extend abstract type ABSTRACT_BUGGY
because it has a private deferred type-bound procedure BUGGY_MULTIPLY_SCALAR
   detected at ::@BUGGY
Error: abstract.f90, line 69: Cannot extend abstract type ABSTRACT_BUGGY
because it has a private deferred type-bound procedure SCALAR_MULTIPLY_BUGGY
   detected at ::@BUGGY
Error: abstract.f90, line 69: Cannot extend abstract type ABSTRACT_BUGGY
because it has a private deferred type-bound procedure BUGGY_ASSIGN_BUGGY
   detected at ::@BUGGY
[NAG Fortran Compiler pass 1 error termination, 3 errors]
If I  undestand this correctly, the abstract types cannot be extended because
they are private, and not public. gfortran doesn't seem to recognize this. 


The code is below 

module type_abstract_buggy
implicit none
private
public :: abstract_buggy

type, abstract :: abstract_buggy
  contains
! public methods
procedure(abstract_printf), public, deferred :: printf
generic,public   :: operator(*) =>
buggy_multiply_scalar, scalar_multiply_buggy
generic,public   :: assignment(=) =>
buggy_assign_buggy
! private methods
procedure(abstract_buggy_multiply_scalar),   pass(lhs), private,
deferred :: buggy_multiply_scalar
procedure(scalar_multiply_abstract_buggy),   pass(rhs), private,
deferred :: scalar_multiply_buggy
procedure(abstract_buggy_assign_abstract_buggy), pass(lhs), private,
deferred :: buggy_assign_buggy
endtype abstract_buggy
abstract interface
  subroutine abstract_printf(self)
  import :: abstract_buggy
  class(abstract_buggy), intent(IN) :: self
  endsubroutine abstract_printf

  function abstract_buggy_multiply_scalar(lhs, rhs) result(multy)
  import :: abstract_buggy
  class(abstract_buggy), intent(IN)  :: lhs
  integer,   intent(IN)  :: rhs
  class(abstract_buggy), allocatable :: multy
  endfunction abstract_buggy_multiply_scalar

  function scalar_multiply_abstract_buggy(lhs, rhs) result(multy)
  import :: abstract_buggy
  integer,   intent(IN)  :: lhs
  class(abstract_buggy), intent(IN)  :: rhs
  class(abstract_buggy), allocatable :: multy
  endfunction scalar_multiply_abstract_buggy

  pure subroutine abstract_buggy_assign_abstract_buggy(lhs, rhs)
  import :: abstract_buggy
  class(abstract_buggy), intent(INOUT) :: lhs
  class(abstract_buggy), intent(IN):: rhs
  endsubroutine abstract_buggy_assign_abstract_buggy
endinterface
endmodule type_abstract_buggy

module lib_abstract_buggy
use type_abstract_buggy, only : abstract_buggy
implicit none
private
public :: raise_bug
contains
  subroutine raise_bug(bug, scalar)
  class(abstract_buggy), intent(INOUT) :: bug
  integer,   intent(IN):: scalar

  call bug%printf()
  bug = bug * scalar
  call bug%printf()
  bug = scalar * bug
  call bug%printf()
  endsubroutine raise_bug
endmodule lib_abstract_buggy

module type_buggy
use type_abstract_buggy, only : abstract_buggy
implicit none
private
public :: buggy

type, extends(abstract_buggy) :: buggy
  private
  real, dimension(:), allocatable :: array
  integer :: scalar=0
  contains
! public methods
procedure, pass(self), public :: printf
! private methods
procedure, pass(lhs), private :: buggy_multiply_scalar
procedure, pass(rhs), private :: scalar_multiply_buggy
procedure, pass(lhs), private :: buggy_assign_buggy
endtype buggy
interface buggy
  procedure create_buggy
endinterface
contains
  pure function create_buggy(array, scalar) result(bug)
  real, dimension(:), intent(IN) :: array
  integer,intent(IN) :: scalar
  type(buggy):: bug

  bug%array = array
  bug%scalar = scalar
  return
  endfunction create_buggy

  subroutine printf(self)
  class(buggy), intent(IN) :: self
  integer  :: i

  print "(A)", "Array:"
  do i=1, size(self%array)
print*, self%array(i)
  enddo
  print "(A,I5)", "Scalar: ", self%scalar
  endsubroutine printf

  function buggy_multiply_scalar(lhs, rhs) result(multy)
  class(buggy), intent(IN)   :: lhs
  integer,  intent(IN)   :: rhs
  class(abstract_buggy), allocatable :: multy
  type(buggy),   allocatable :: multy_tmp

  allocate(buggy :: multy_tmp)
  multy_tmp%array = lhs%arra

[Bug fortran/88438] [F08] A pointer function reference can denote a variable in any variable definition context.

2019-02-05 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88438

--- Comment #2 from Jürgen Reuter  ---
(In reply to Dominique d'Humieres from comment #1)
> At https://gcc.gnu.org/wiki/Fortran2008Status I see
> 
> Unimplemented features -- based on the list in the "Introduction" of the
> F2008 standard
> ...
> A pointer function reference can denote a variable in any variable
> definition context.
> ...

Yes, but one confuses me is that this is not as a red box in the list on the
top of the page.

[Bug fortran/89030] New: gfortran accepts invalid code

2019-01-23 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89030

Bug ID: 89030
   Summary: gfortran accepts invalid code
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The following issue was discussed on the Intel forum:
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/803316
The assignment is accepted by gfortran, but it should be rejected as invalid
code:
x = t(5)

1. The RHS is evaluated as structure constructor for t
2. Then defined assignment sets in, so it is translated into set (x, t(5)),
and here either both x and t must be unlimited polymorphic, or both
have to have the same type.
(if I understand the standard correctly, but Steve Lionel seems to support
this)
Cheers,
JRR



Short reproducer:


module mod

  implicit none
  private

  type, public :: t
 integer :: i = 3
   contains
 generic, public :: assignment(=) => set
 procedure, private :: set
  end type t

contains

  subroutine set(x, y)
class(t), intent(out) :: x
type(t), intent(in) :: y
print *, "foo"
  end subroutine set

end module mod



program alloc_assign

  use mod
  implicit none
  class(*), allocatable :: x

  x = t(5)

end program alloc_assign

[Bug fortran/41178] Ambiguity checks for type-bound and interface operator calls

2019-01-23 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41178

--- Comment #3 from Jürgen Reuter  ---
Nothing has been done here for a decade, and the functions mentioned below
(gfc_expand_expr and gfc_expand_assign) do not exist any longer in the code.

[Bug fortran/41023] Inconsistent error locations for wrong interfaces with overloaded operators

2019-01-23 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41023

--- Comment #7 from Jürgen Reuter  ---
Has this patch ever been applied and/or reg-tested?

[Bug fortran/40598] Some missed optimizations in array assignment

2019-01-22 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #13 from Jürgen Reuter  ---
This seems to have been forgotten, it is still assigned. Is there any progress
on this one?

[Bug fortran/38113] on warning/error: skip whitespaces, move position marker to actual variable name

2019-01-22 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38113

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #9 from Jürgen Reuter  ---
Here there are some problems that have been fixed, and some new have been
revealed!? To me it is not clear what the exact context is now. Maybe closing
as WORKSFORME, and waiting for someone to open an actual issue with the
alignment of markers?

[Bug fortran/37398] Statement functions mask missing PURE procedures.

2019-01-22 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37398

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #3 from Jürgen Reuter  ---
This correctly gives the expected error messages since at least gfortran 5.4.
Closing as FIXED?

[Bug fortran/37222] [OOP] Checks when overriding type-bound procedures are incomplete

2019-01-22 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37222

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #4 from Jürgen Reuter  ---
As Janus commented there is just one left-over (already fixed in the past six
years?). So what is really left to do here?

[Bug fortran/35718] deallocating non-allocated pointer target does not fail

2019-01-22 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35718

--- Comment #6 from Jürgen Reuter  ---
Still present in trunk.

[Bug fortran/35779] error pointer wrong in PARAMETER

2019-01-22 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #13 from Jürgen Reuter  ---
Still present in trunk.

[Bug fortran/35476] Accepts invalid: USE/host association of generics with same specifics

2019-01-22 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #9 from Jürgen Reuter  ---
This is still present and not caught by gfortran, according to the interp from
J3 the code is invalid.

[Bug fortran/35276] Doc should described how to compile mixed-language programs

2019-01-21 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #4 from Jürgen Reuter  ---
It seems that at least Thomas and Dominique believe that this can be closed.

[Bug fortran/34663] Specification expression is defined by dummy variables of different entry points

2019-01-20 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34663

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #3 from Jürgen Reuter  ---
Entry is now a F2008 obsolescent feature. Neither nagfor nor PGI catch this.

[Bug fortran/34528] Document internal structure of arrays

2019-01-20 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34528

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #2 from Jürgen Reuter  ---
Is this still the same interface nowadays then it was back then? And is a
possible new one now maybe documented?

[Bug fortran/34392] BOZ diagnost invalid Fortran 2003 use with -std=f2003 warnings

2019-01-20 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34392

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #3 from Jürgen Reuter  ---
Looks like one needs to come up with a list of possible cases to find one that
is not yet covered.

[Bug fortran/33097] Function decl trees without proper argument list

2019-01-20 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #20 from Jürgen Reuter  ---
Dominique, you announced almost 10 months ago that you would close this one in
case of no feedback. Closing?

[Bug fortran/32986] Improve diagnostic message for COMMON with automatic object

2019-01-20 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32986

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #3 from Jürgen Reuter  ---
Indeed, ifort is more informative, though nagfor also just tells em
"N is not permitted in a constant expression".

[Bug fortran/32515] [F03] Reject COMMON block names if local symbol already exists

2019-01-20 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32515

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #4 from Jürgen Reuter  ---
I think Mikael Morin is incorrect here. nagfor and ifort reject the test case,
e.g. 
ifort:
A name that identifies a global entity is used to identify another global
entity in the same program.
nagfor:
Error: pr_32515.f90, line 31: COMMON block BAR is also a global procedure
So I think this should be closed.

[Bug fortran/32512] efficiency of RESHAPE and SPREAD

2019-01-20 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32512

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #8 from Jürgen Reuter  ---
Is this still an actual feature request? or have things changed in the past 7
years?

[Bug fortran/34740] -fbounds-check with TRANSFER misses out of bounds in array assignment

2019-01-20 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34740

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #2 from Jürgen Reuter  ---
Still not caught in trunk. nagfor and ifort do catch this one.

[Bug fortran/31009] Generate conditional code to assign arrays, depending on their stride

2019-01-20 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31009

--- Comment #7 from Jürgen Reuter  ---
Seems also to me that this should be reconsidered whether there is still need
for optimization for the case of arrays not declared as contiguous.

[Bug fortran/30733] VOLATILE: Missed optimization - attribute not restricted to scope

2019-01-20 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30733

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #3 from Jürgen Reuter  ---
There were some changes with the optimization and the volatile attribute with
release 7.0. Maybe check if this issue is still present?

[Bug fortran/30438] Set but never used variable should raise warning

2019-01-20 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30438

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #10 from Jürgen Reuter  ---
nagfor does this warning, ifort and PGI fortran doesn't.

[Bug fortran/30123] Document INQUIRE, especially UNFORMATTED and FORMATTED

2019-01-20 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30123

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #4 from Jürgen Reuter  ---
This seems like one of these documentation tasks which is in principle very
easy to do but nobody is motivated to do.^^

[Bug fortran/25714] concat of strings create an extra temporary variable

2019-01-19 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25714

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #7 from Jürgen Reuter  ---
This seems to be now
   _gfortran_concat_string (2, , 1, , 1, );
__builtin_memmove (, , 2);
so it still has a temporary AFAIC tell.

[Bug fortran/25095] Disallowed intrinsic in initialization statement

2019-01-19 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25095

--- Comment #7 from Jürgen Reuter  ---
Indeed, ifort and PGI fortran flag this as an error in the implied DO
expression. Nagfor flags it just as an extension.

[Bug fortran/24878] subroutine getting called illegally as a function

2019-01-19 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24878

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #5 from Jürgen Reuter  ---
This is not caught by ifort or PGI fortran either. Nagfor, however, gets it.

[Bug fortran/88871] [9 regression] ICE segmentation fault in f951

2019-01-18 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871

--- Comment #13 from Jürgen Reuter  ---
Is this ready to be submitted?

[Bug fortran/88871] [9 regression] ICE segmentation fault in f951

2019-01-17 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871

--- Comment #12 from Jürgen Reuter  ---
I can also confirm that with the provided patch our code completely compiles,
and all tests work.

[Bug fortran/81849] Size of automatic array argument specified by host-associated variable.

2019-01-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81849

--- Comment #10 from Jürgen Reuter  ---
Actually, it was Thomas Koenig in r267953, so not your commits, but very
close.^^ The report is PR88871.

[Bug fortran/88871] [9 regression] ICE segmentation fault in f951

2019-01-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871

--- Comment #7 from Jürgen Reuter  ---
(In reply to Thomas Koenig from comment #6)
> Could be a result of my recent commit, r267953.  I'll take a look tonight.

That would be my guess, too,
I think it has to do with the array
descriptor together with implicit
typing and maybe together the common
block.

[Bug fortran/88871] [9 regression] ICE segmentation fault in f951

2019-01-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871

--- Comment #4 from Jürgen Reuter  ---
(In reply to Richard Biener from comment #3)
> Seems to work on the branches but I can't reproduce on trunk either.

That is strange. Did you try to compile several
times? Sometimes it comes, sometimes it doesn’t.
I did svn up and compiled the gcc,
maybe I have to recompile all?

[Bug fortran/88871] [9.0 regression] ICE segmentation fault in f951

2019-01-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871

--- Comment #2 from Jürgen Reuter  ---
Here is a more minimal example:
  SUBROUTINE MNREAD(IFLGIN,IFLGUT)
  IMPLICIT DOUBLE PRECISION (A-H,O-Z)
  PARAMETER (MNE=100 , MNI=50)
  PARAMETER (MNIHL=MNI*(MNI+1)/2)
  CHARACTER*10 CPNAM  
  COMMON
 1/MN7NAM/ CPNAM(MNE)
 2/MN7EXT/ U(MNE)

  CHARACTER  CRDBUF*80, CUPBUF*10
  CUPBUF(1:10) = CRDBUF(1:10)
  RETURN
  END

or also to completely implicit typing
 SUBROUTINE MNREAD(IFLGIN,IFLGUT)
  PARAMETER (MNE=100 , MNI=50)
  PARAMETER (MNIHL=MNI*(MNI+1)/2)
  CHARACTER*10 CPNAM  
  COMMON
 1/MN7NAM/ CPNAM(MNE)
 2/MN7EXT/ U(MNE)
  CHARACTER  CRDBUF*80, CUPBUF*10
  CUPBUF(1:10) = CRDBUF(1:10)
  RETURN
  END

[Bug fortran/88871] [9.0 regression] ICE segmentation fault in f951

2019-01-15 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871

--- Comment #1 from Jürgen Reuter  ---
My suspicion goes toward the fix for PR81849, so maybe also the gcc-7 and gcc-8
branches are affected.

[Bug fortran/88871] New: [9.0 regression] ICE segmentation fault in f951

2019-01-15 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871

Bug ID: 88871
   Summary: [9.0 regression] ICE segmentation fault in f951
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Created attachment 45436
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45436=edit
File that triggers the ICE.

The following (legacy) code included in our software package fails compilation
with an ICE in f951 with r267961, while r267903 was still working. 
$ gfortran -g -O2 mnread.f 
f951: internal compiler error: Segmentation fault: 11
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug fortran/81849] Size of automatic array argument specified by host-associated variable.

2019-01-15 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81849

--- Comment #8 from Jürgen Reuter  ---
I think this fix or something very near by causes an ICE in our code, I will
provide a bug report soon.

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-01-09 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #33 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #32)
> (In reply to Jürgen Reuter from comment #31)
> > Then I get tons of duplicate symbol lines.
> 
> ah well, not so simple then,
> 
> then I think the next step is for you to identify the last working revision
> of  the compiler - we can then analyse what the change was that caused the
> difference and determine if that's a real regression or just exposing a
> build system issue.

I fear I don't have the capacities to do that right now.

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-01-09 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #31 from Jürgen Reuter  ---
Then I get tons of duplicate symbol lines.

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-01-09 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #29 from Jürgen Reuter  ---
-rdynamic doesn't change anything, and ld doesn't understand -export-dynamic.
I am a bit confused what to do now, as we have a workaround, i.e. using -static
instead of -static-libtool-libs as libtool flag. But in general, the attempt
for a completely static binary (at least on MACOSX) doesn't work, so maybe we
should retire that feature.

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-01-09 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #25 from Jürgen Reuter  ---
(In reply to Richard Biener from comment #24)
> (In reply to Iain Sandoe from comment #23)
> > (In reply to Jürgen Reuter from comment #22)

> 
> Indeed - somehow you didn't get a statically linked executable.  Quoting the
> full final link command would be interesting.

The full link commands can be found here, I believe: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750#c14

Our code generates code for particle physics simulations in the form of dynamic
libraries that get linked and loaded. For batch clusters, we attempted to
provide static binaries for these simulations, however, we have order 10-15
external libraries that can be linked to our code (which are partially
mandatory). There are some of them which only exist as dynamic libraries, so
there our approach cannot result in a purely static binary. The static stdc++
library is sucked in via the libtool link mode/flag -static-libtool-libs while
the dynamic ones are sucked in via the external C++ libraries that are
available only dynamically.

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-01-09 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #22 from Jürgen Reuter  ---
This is the output from the lldb command (but this was not a debug build of gcc
yet):
$ lldb ./static_1.exe
(lldb) target create "./static_1.exe"
Current executable set to './static_1.exe' (x86_64).
(lldb) run
Process 36799 launched: './static_1.exe' (x86_64)
static_1.exe(36799,0x1048f75c0) malloc: *** error for object 0x105c5eee0:
pointer being freed was not allocated
static_1.exe(36799,0x1048f75c0) malloc: *** set a breakpoint in
malloc_error_break to debug
Process 36799 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x7fff5a2d023e libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff5a2d023e <+10>: jae0x7fff5a2d0248; <+20>
0x7fff5a2d0240 <+12>: movq   %rax, %rdi
0x7fff5a2d0243 <+15>: jmp0x7fff5a2ca3b7; cerror_nocancel
0x7fff5a2d0248 <+20>: retq   
Target 0: (static_1.exe) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x7fff5a2d023e libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff5a386c1c libsystem_pthread.dylib`pthread_kill + 285
frame #2: 0x7fff5a2391c9 libsystem_c.dylib`abort + 127
frame #3: 0x7fff5a3486e2 libsystem_malloc.dylib`malloc_vreport + 545
frame #4: 0x7fff5a3484a3 libsystem_malloc.dylib`malloc_report + 152
frame #5: 0x000100929c84
static_1.exe`std::locale::_Impl::~_Impl(this=0x000105c5f0a0) at
locale.cc:243
frame #6: 0x000100929d8e
static_1.exe`std::locale::operator=(this=0x000105c611c0,
__other=0x7ffeefbfdad8) at locale_classes.h:568
frame #7: 0x000100927aec
static_1.exe`std::ios_base::_M_init(this=0x000105c610f0) at
ios_locale.cc:44
frame #8: 0x00010096cef1 static_1.exe`std::basic_ios >::init(this=0x000105c610f0,
__sb=0x000105c60840) at basic_ios.tcc:129
frame #9: 0x000105afcdf9 libstdc++.6.dylib`std::ios_base::Init::Init()
+ 681
frame #10: 0x000105ad30a0
libsio.2.12.dylib`_GLOBAL__sub_I_SIO_blockManager.cc + 16
frame #11: 0x000104859cc8
dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) +
518
frame #12: 0x000104859ec6
dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
frame #13: 0x0001048550da
dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
unsigned int, char const*, ImageLoader::InitializerTimingList&,
ImageLoader::UninitedUpwards&) + 358
frame #14: 0x00010485506d
dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
unsigned int, char const*, ImageLoader::InitializerTimingList&,
ImageLoader::UninitedUpwards&) + 249
frame #15: 0x00010485506d
dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
unsigned int, char const*, ImageLoader::InitializerTimingList&,
ImageLoader::UninitedUpwards&) + 249
frame #16: 0x000104854254
dyld`ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned
int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 134
frame #17: 0x0001048542e8
dyld`ImageLoader::runInitializers(ImageLoader::LinkContext const&,
ImageLoader::InitializerTimingList&) + 74
frame #18: 0x000104843774 dyld`dyld::initializeMainExecutable() + 199
frame #19: 0x00010484878f dyld`dyld::_main(macho_header const*,
unsigned long, int, char const**, char const**, char const**, unsigned long*) +
6237
frame #20: 0x0001048424f6 dyld`dyldbootstrap::start(macho_header
const*, int, char const**, long, macho_header const*, unsigned long*) + 1154
frame #21: 0x000104842036 dyld`_dyld_start + 54

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-01-09 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #21 from Jürgen Reuter  ---
Created attachment 45388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45388=edit
DYLD_PRINT output working example

DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 ./static_1.exe > working_output
2>&1

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-01-09 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #20 from Jürgen Reuter  ---
Created attachment 45387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45387=edit
DYLD_PRINT output non-working example

DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 ./static_1.exe >
non_working_output 2>&1

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-01-09 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #19 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #18)
> (In reply to Jürgen Reuter from comment #14)
> 
> does the application use exceptions?

No exceptions, only a poor man's C signal catcher. 

> 
> > /usr/local/lib/libstdc++.a
> 
> ^^^ please confirm that this is from the "current compiler build".
> 

Yes, they are the same. Unfortunately, there is no uninstall target for gcc,
but all stdc++ libraries in /usr/local/lib are from my Jan 8 clean building. 


> 
> ^^^ this looks like the build process in this case is adding libs that
> the compiler driver normally adds ( they are not present in the case above ).
> 

Yes, that is for a different reason, a different build with a tutorial C and
C++ wrapper for our code, but they don't hurt here.


> * If you can extract these two fortran link lines - and then execute them
> separately in the build dir with "-v" so that we can see the output of the
> compiler-driver's internal link line and what its search paths are.

This is the output for the non-working linking:
$ gfortran -g -O2 -Wl,-rpath -Wl,/usr/local/packages/OpenLoops/lib -o
static_1.exe .libs/static_1.exe_prclib_dispatcher.o 
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/whizard-core
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/hepmc
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/lcio
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/hoppet
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/looptools
-L/usr/local/packages/OpenLoops/lib -L/usr/local/lib -L../src
./.libs/static_1_lib.a
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/models
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/whizard-core/.libs/libwhizard_main.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/.libs/libomega.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/omega/src/.libs/libomega_core.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/.libs/libwhizard.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/vamp/src/.libs/libvamp.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/circe1/src/.libs/libcirce1.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/circe2/src/.libs/libcirce2.a
-lcuttools -lopenloops -loneloop -lolcommon -lrambo /usr/local/lib/libLHAPDF.a
/usr/local//lib/libHepMC.a -llcio /usr/local/lib/libstdc++.a
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/src
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/src/.libs
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/libsupc++/.libs
-lm -v
Driving: gfortran -g -O2 -Wl,-rpath -Wl,/usr/local/packages/OpenLoops/lib -o
static_1.exe .libs/static_1.exe_prclib_dispatcher.o
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/whizard-core
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/hepmc
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/lcio
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/hoppet
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/looptools
-L/usr/local/packages/OpenLoops/lib -L/usr/local/lib -L../src
./.libs/static_1_lib.a
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/models
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/whizard-core/.libs/libwhizard_main.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/.libs/libomega.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/omega/src/.libs/libomega_core.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/.libs/libwhizard.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/vamp/src/.libs/libvamp.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/circe1/src/.libs/libcirce1.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/circe2/src/.libs/libcirce2.a
-lcuttools -lopenloops -loneloop -lolcommon -lrambo /usr/local/lib/libLHAPDF.a
/usr/local//lib/libHepMC.a -llcio /usr/local/lib/libstdc++.a
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/src
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/src/.libs
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/libsupc++/.libs
-lm -v -mmacosx-version-min=10.14.0 -asm_macosx_version_min=10.14 -l gfortran
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin18.2.0/9.0.0/lto-wrapper
Target: x86_64-apple-darwin18.2.0
Configured with: ../configure --prefix=/usr/local/ --with-gmp=/usr/local/
--with-mpfr=/usr/local/ --with-mpc=/usr/local/ --enable-checking=release
--enable-languages=c,c++,fortran,lto
Thread model: posix
gcc version 9.0.0 20190107 (experimental) (GCC) 
Reading specs from

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-01-08 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #16 from Jürgen Reuter  ---
Yes, after the problem occurred, I did a completely clean new build of gmp,
mpfr, mpc, gcc (configured with ../configure --prefix=/usr/local/
--with-gmp=/usr/local/ --with-mpfr=/usr/local/ --with-mpc=/usr/local/
--enable-checking=release --enable-languages=c,c++,fortran,lto),
all the tools our software depends, and our software. It turns out that
external C++ libraries linked into our (Fortran) project via bind(C) are not a
problem if they have been built via libtool, such that a .dylib, a .a and a .la
file are present. The two projects that have problem either exist as .dylib and
.a produced by hand-written configure and makefiles (i.e. not using autotools),
or only as dynamic libraries produced via cmake and make.

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-01-08 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #14 from Jürgen Reuter  ---
Well, it seems that r267488 from Dec 31 was still working, on the other hand, I
saw a problem on the other MACbook definitely around at latest Dec 26 or so.
Probably before Christmas. It might be that small updates did not trigger a
complete recompilation of the trunk? 
This one is failing:
gfortran -g -O2 -Wl,-rpath -Wl,/usr/local/packages/OpenLoops/lib -o
static_1.exe .libs/static_1.exe_prclib_dispatcher.o 
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/whizard-core
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/hepmc
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/lcio
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/hoppet
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/looptools
-L/usr/local/packages/OpenLoops/lib -L/usr/local/lib -L../src
./.libs/static_1_lib.a
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/models
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/whizard-core/.libs/libwhizard_main.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/.libs/libomega.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/omega/src/.libs/libomega_core.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/.libs/libwhizard.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/vamp/src/.libs/libvamp.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/circe1/src/.libs/libcirce1.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/circe2/src/.libs/libcirce2.a
-lcuttools -lopenloops -loneloop -lolcommon -lrambo /usr/local/lib/libLHAPDF.a
/usr/local//lib/libHepMC.a -llcio /usr/local/lib/libstdc++.a
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/src
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/src/.libs
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/libsupc++/.libs
-lm 

while that one is working:

gfortran -g -O2 -Wl,-rpath -Wl,/usr/local/packages/OpenLoops/lib -o
static_1.exe .libs/static_1.exe_prclib_dispatcher.o 
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/whizard-core
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/hepmc
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/lcio
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/hoppet
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/looptools
-L/usr/local/packages/OpenLoops/lib -L/usr/local/lib -L../src
./.libs/static_1_lib.a
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/models
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/whizard-core/.libs/libwhizard_main.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/.libs/libomega.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/omega/src/.libs/libomega_core.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/.libs/libwhizard.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/vamp/src/.libs/libvamp.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/circe1/src/.libs/libcirce1.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/circe2/src/.libs/libcirce2.a
-lcuttools -lopenloops -loneloop -lolcommon -lrambo /usr/local/lib/libLHAPDF.a
-L/usr/local/lib/gcc/x86_64-apple-darwin18.2.0/9.0.0
-L/usr/local/lib/gcc/x86_64-apple-darwin18.2.0/9.0.0/../../..
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/src
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/src/.libs
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/libsupc++/.libs
-lSystem -lgcc_ext.10.5 /usr/local//lib/libHepMC.a -lstdc++ -llcio -lm

But that's probably not very helpful for you.

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-01-08 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #12 from Jürgen Reuter  ---
No, unfortunately a working svn # is difficult, I first observed it by doing
svn up on another Macbook around Christmas. What do you mean by transcripts?

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

2019-01-08 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750

--- Comment #10 from Jürgen Reuter  ---
The trunk, svn 267657, all newest versions of gmp, mpfr, mpc. It seems that the
problem is also solved when I use the libtool flag -static instead of
-static-libtool-libs for libtool to build these executables.

  1   2   3   4   5   >