[Bug fortran/42568] New: BLOCKDATA referenced in EXTERNAL not loading from library

[Bug fortran/42568] New: BLOCKDATA referenced in EXTERNAL not loading from library

[urbanjost at comcast dot net]

Even though the BLOCKDATA is referenced with an EXTERNAL statement, it is
not initializing the COMMON; this worked in previous versions of gfortran,
and g95, g77, ifort, and vendor compilers (Cray, HP-UX, IRIX64, SunOS, Solaris,
...) as long as the EXTERNAL statement was present.


#!/bin/sh
echo trouble loading a blockdata from a library
set -x
cat >missingBlockData.f <<\EOF
      program missingBlockData
      external juinit2
      character chars(5)*(20)
      common /qindex2/chars 
      save /qindex2/
      write(*,*)'chars=',chars
      if(chars(5).ne.'abcdefghijklmnopqrst')then
         write(*,*)'*missingBlockData* E-R-R-O-R: bad load'
      else
         write(*,*)'*missingBlockData* loaded common block'
      endif
      end
EOF
cat >juinit2.f <<\EOF
!______________________________________________________________________-
      blockdata juinit2
      character chars(5)*(20)
      common /qindex2/chars 
      save /qindex2/
      data chars/5*'abcdefghijklmnopqrst'/
      end
!______________________________________________________________________-
EOF
(
exec 2>&1
set -x
: __________________________________________________________
export F90
F90='gfortran -Wall'
: "compile with $F90"
: __________________________________________________________
: Make libex.a library
$F90  -c  juinit2.f 
nm juinit2.o
: I thought JUINIT2 would be a T, not a B ??
ar rv libex.a juinit2.o
rm juinit2.o
: __________________________________________________________
: run loading from library
rm -f missingBlockData
$F90 missingBlockData.f -L. -lex -o missingBlockData
./missingBlockData
: __________________________________________________________
: run not loading from library
rm -f missingBlockData
$F90 missingBlockData.f juinit2.f -o missingBlockData
./missingBlockData
: __________________________________________________________
: version
date
uname -a
$F90 -v missingBlockData.f juinit2.f -o missingBlockData
: __________________________________________________________
: cleanup
rm -f missingBlockData libex.a juinit2.f missingBlockData.f
) >> $0
exit 


***************
***************
RESULTS OF RUN:
***************
***************

+ set -x
+ : __________________________________________________________
+ export F90
+ F90=gfortran -Wall
+ : compile with gfortran -Wall
+ : __________________________________________________________
+ : Make libex.a library
+ gfortran -Wall -c juinit2.f
+ nm juinit2.o
00000000 b .bss
00000000 d .data
00000000 t .text
00000000 B _juinit2_
00000000 D _qindex2_
+ : I thought JUINIT2 would be a T, not a B ??
+ ar rv libex.a juinit2.o
ar: creating libex.a
a - juinit2.o
+ rm juinit2.o
+ : __________________________________________________________
+ : run loading from library
+ rm -f missingBlockData
+ gfortran -Wall missingBlockData.f -L. -lex -o missingBlockData
+ ./missingBlockData
 chars=
missingBlockData* E-R-R-O-R: bad load
+ : __________________________________________________________
+ : run not loading from library
+ rm -f missingBlockData
+ gfortran -Wall missingBlockData.f juinit2.f -o missingBlockData
+ ./missingBlockData

chars=abcdefghijklmnopqrstabcdefghijklmnopqrstabcdefghijklmnopqrstabcdefghijklmnopqrstabcdefghijklmnopqrst
 *missingBlockData* loaded common block
+ : __________________________________________________________
+ : version
+ date
Thu Dec 31 17:39:18 EST 2009
+ uname -a
CYGWIN_NT-6.0 urbanjs-PC 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin
+ gfortran -Wall -v missingBlockData.f juinit2.f -o missingBlockData
Driving: gfortran -Wall -v missingBlockData.f juinit2.f -o missingBlockData
-lgfortran
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ../trunk/configure --prefix=/usr/local/gfortran
--enable-languages=c,c++,fortran --disable-bootstrap --enable-threads=posix
--enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls
--disable-libmudflap --disable-shared --disable-win32-registry
--with-system-zlib --enable-checking=release --enable-werror
--without-included-gettext --without-x --enable-libgomp
Thread model: posix
gcc version 4.5.0 20091119 (experimental) [trunk revision 152402] (GCC) 
COLLECT_GCC_OPTIONS='-Wall' '-v' '-o' 'missingBlockData.exe' '-mtune=generic'

/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.5.0/f951.exe
missingBlockData.f -ffixed-form -quiet -dumpbase missingBlockData.f
-mtune=generic -auxbase missingBlockData -Wall -version
-fintrinsic-modules-path
/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/finclude
-o /cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccWoGlsE.s
GNU Fortran (GCC) version 4.5.0 20091119 (experimental) [trunk revision 152402]
(i686-pc-cygwin)
        compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.8
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.5.0 20091119 (experimental) [trunk revision 152402]
(i686-pc-cygwin)
        compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.8
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-Wall' '-v' '-o' 'missingBlockData.exe' '-mtune=generic'
 as -o /cygdrive/c/Users/urbanjs/AppData/Local/Temp/cc83xpoo.o
/cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccWoGlsE.s
COLLECT_GCC_OPTIONS='-Wall' '-v' '-o' 'missingBlockData.exe' '-mtune=generic'

/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.5.0/f951.exe
juinit2.f -ffixed-form -quiet -dumpbase juinit2.f -mtune=generic -auxbase
juinit2 -Wall -version -fintrinsic-modules-path
/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/finclude
-o /cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccWoGlsE.s
GNU Fortran (GCC) version 4.5.0 20091119 (experimental) [trunk revision 152402]
(i686-pc-cygwin)
        compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.8
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.5.0 20091119 (experimental) [trunk revision 152402]
(i686-pc-cygwin)
        compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.8
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-Wall' '-v' '-o' 'missingBlockData.exe' '-mtune=generic'
 as -o /cygdrive/c/Users/urbanjs/AppData/Local/Temp/cc06kxQY.o
/cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccWoGlsE.s
COMPILER_PATH=/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.5.0/:/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/
LIBRARY_PATH=/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/:/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/:/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-Wall' '-v' '-o' 'missingBlockData.exe' '-mtune=generic'

/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.5.0/collect2.exe
-Bdynamic --dll-search-prefix=cyg -tsaware -o missingBlockData.exe /lib/crt0.o
/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/crtbegin.o
-L/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0
-L/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc
-L/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/../../..
/cygdrive/c/Users/urbanjs/AppData/Local/Temp/cc83xpoo.o
/cygdrive/c/Users/urbanjs/AppData/Local/Temp/cc06kxQY.o -lgfortran -lgcc
-lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc
/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/crtend.o
+ : __________________________________________________________
+ : cleanup
+ rm -f missingBlockData libex.a juinit2.f missingBlockData.f


-- 
           Summary: BLOCKDATA referenced in EXTERNAL not loading from
                    library
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: urbanjost at comcast dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #1 from kargl at gcc dot gnu dot org  2010-01-01 00:46 -------
Can you please read how to submit a bug report?  I can't
find anywhere were it states that a Bourne shell script
should be submitted.  It simply makes it almost impossible
to read the actual bug report.  In fact, all the crap with 
nm and ar is just unneeded cluttered.

% gfc4x -c a2.f90
% ar -cur libex.a a2.o
% gfc4x -o z a1.f90 -L. -lex
% ./z
 chars=abcdefghijklmnopqrst<remainder deleted>
 *missingBlockData* loaded common block
% gfc4x -c a2.f90 a1.f90
% ./z
 chars=abcdefghijklmnopqrst<remainder deleted>
 *missingBlockData* loaded common block
% gfortran44 -c a2.f90
% ar -cur libex.a a2.o
% gfortran44 -o z a1.f90 -L. -lex
% ./z
 chars=abcdefghijklmnopqrst<remainder deleted>
 *missingBlockData* loaded common block
% gfortran44 -o z a1.f90 a2.f90
% ./z
 chars=abcdefghijklmnopqrst<remainder deleted>
 *missingBlockData* loaded common block

Appears to work for me.  Where did you get your copy of 
gfortran?


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[urbanjost at comcast dot net]

------- Comment #2 from urbanjost at comcast dot net  2010-01-01 01:57 -------
Subject: Re:  BLOCKDATA referenced in EXTERNAL not loading from library

I just got it from the gfortran Wiki because of problems with the previous 
version I had:
http://gcc.gnu.org/wiki/GFortranBinaries
 then the "CygWin" version, which appears to point to
http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.5-Cygwin-i686.tar.bz2
today, anyway.

 I guess tastes vary.
We preferred shell scripts when I worked at Cray, HP, SGI, Compaq, and 
Digital;
as you otherwise don't know which compiler switches, system level, and so on 
were
used..

It works for me on several Linux boxes as well, just not CygWin. What 
platform are you on? I'm curious
if you do a nm on your libex.a file if juinit2 is type T or B;  I haven't 
used a non-Unix/GNU
machine for so many years (except for CygWin) I guess it didn't occur to me 
a shell script
would be harder, not easier, to use. Some examples in the Wiki of "ideal" 
bug reports would
be useful.

Note I just upgraded my CygWin a few days ago, to version 1.7; as X11 
windows were not working.
I have built the program I extracted the problem from many times in the past 
with older GFORTRAN
versions
(and G77 and G95) on CygWin; but a recent Vista upgrade broke CygWin (the 
X11 windows
were a bit fragile on Vista anyway). It still builds with G95, and an older 
version still builds with G77.

PS: I found it surprising that if I just compiled the main program I didn't 
get a warning about
unsatisified external JUINIT2; I did with every other compiler I tried.  It 
was also odd that
if I put a no-op subroutine in the same file as the BLOCKDATA file and then 
called it from the main
program that the BLOCKDATA was then initialized properly.

----- Original Message ----- 
From: "kargl at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: <urbanjost@comcast.net>
Sent: Thursday, December 31, 2009 7:46 PM
Subject: [Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading 
from library


>
>
> ------- Comment #1 from kargl at gcc dot gnu dot org  2010-01-01 
> 00:46 -------
> Can you please read how to submit a bug report?  I can't
> find anywhere were it states that a Bourne shell script
> should be submitted.  It simply makes it almost impossible
> to read the actual bug report.  In fact, all the crap with
> nm and ar is just unneeded cluttered.
>
> % gfc4x -c a2.f90
> % ar -cur libex.a a2.o
> % gfc4x -o z a1.f90 -L. -lex
> % ./z
> chars=abcdefghijklmnopqrst<remainder deleted>
> *missingBlockData* loaded common block
> % gfc4x -c a2.f90 a1.f90
> % ./z
> chars=abcdefghijklmnopqrst<remainder deleted>
> *missingBlockData* loaded common block
> % gfortran44 -c a2.f90
> % ar -cur libex.a a2.o
> % gfortran44 -o z a1.f90 -L. -lex
> % ./z
> chars=abcdefghijklmnopqrst<remainder deleted>
> *missingBlockData* loaded common block
> % gfortran44 -o z a1.f90 a2.f90
> % ./z
> chars=abcdefghijklmnopqrst<remainder deleted>
> *missingBlockData* loaded common block
>
> Appears to work for me.  Where did you get your copy of
> gfortran?
>
>
> -- 
>
> kargl at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|UNCONFIRMED                 |WAITING
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #3 from kargl at gcc dot gnu dot org  2010-01-01 02:49 -------
(In reply to comment #2)
> Subject: Re:  BLOCKDATA referenced in EXTERNAL not loading from library
> 
> I just got it from the gfortran Wiki because of problems with the previous 
> version I had:
> http://gcc.gnu.org/wiki/GFortranBinaries
>  then the "CygWin" version, which appears to point to
> http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.5-Cygwin-i686.tar.bz2
> today, anyway.
> 
>  I guess tastes vary.
> We preferred shell scripts when I worked at Cray, HP, SGI, Compaq, and 
> Digital;
> as you otherwise don't know which compiler switches, system level, and so on 
> were used..

Then please attach the script to the bug report.  The web interface
to bugzilla and cut-n-paste plays havoc with whitespace, long lines,
etc.

> It works for me on several Linux boxes as well, just not CygWin. What 
> platform are you on?

FreeBSD on i686 and x86_64.

> I'm curious
> if you do a nm on your libex.a file if juinit2 is type T or B;

% nm libex.a

a2.o:
00000000 B juinit2_
00000000 D qindex2_

> I haven't  used a non-Unix/GNU
> machine for so many years (except for CygWin) I guess it didn't occur to me 
> a shell script
> would be harder, not easier, to use. Some examples in the Wiki of "ideal" 
> bug reports would
> be useful.

The ideal bug report is the shortest source code example that 
exhibits the problem, which you gave us.

The simplest command line used to compile the code that 
exhibits the problem.

If a data file or input is needed, the shortest such data
is desirable.

If the problem is an internal compiler error or segfault of
the compiler, include the last several lines that appear
on the terminal.

If it's a runtime problem, either give the abort message
or error message, or tell us what the expected output
should have been.

> Note I just upgraded my CygWin a few days ago, to version 1.7;

This is my suspicion.  There's a problem with the new cygwin.

> (and G77 and G95) on CygWin; but a recent Vista upgrade broke CygWin (the 
> X11 windows
> were a bit fragile on Vista anyway). It still builds with G95, and an older 
> version still builds with G77.
> 
> PS: I found it surprising that if I just compiled the main program I didn't 
> get a warning about >unsatisified external JUINIT2; I did with every other
> compiler I tried.

I don't know much about how BLOCK DATA and COMMON are implemented.
But, it looks like the compiler is simply eliminating the symbol
as dead code.

% gfc4x -o z a1.f
% nm z | grep -i juin
% nm a1.o
00000000 t MAIN__
         U _gfortran_compare_string
         U _gfortran_set_args
         U _gfortran_set_options
         U _gfortran_st_write
         U _gfortran_st_write_done
         U _gfortran_transfer_array
         U _gfortran_transfer_character
00000197 T main
00000060 r options.4.1509
00000019 C qindex2_

AFAIK, there is no constraint in the Standard that something
marked by EXTERNAL must be referenced.

> It was also odd that
> if I put a no-op subroutine in the same file as the BLOCKDATA file and then 
> called it from the main
> program that the BLOCKDATA was then initialized properly.

That is strange.  It seems to be a linker problem.  I suspect that
you may need to ping the cygwin guys.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2010-01-01 06:22 -------
I tried the test case with Cygwin running on WinNT-4.0 and it works fine with
both 4.3.4 and 4.5.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu dot org]

------- Comment #5 from jvdelisle at gcc dot gnu dot org  2010-01-01 06:35 -------
I forgot to mention I am using Cygwin 1.7, so this is beginning to look like
some sort of installation issue.  The gfortran version 4.5 I downloaded and
installed per the gfortran wiki.

The other possibility to consider is what version of Windows you are using.  I
notice some reports on the Cygwin list of Vista and Windows 7 bugs.  However,
these bugs are being actively worked.

Try using Cygwin setup.exe and select the reinstall option for gcc core and
gfortran.  Also install all updates that are coming in daily almost on cygwin
as the bugs are getting cleared.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[urbanjost at comcast dot net]

------- Comment #6 from urbanjost at comcast dot net  2010-01-02 07:50 -------
Subject: Re:  BLOCKDATA referenced in EXTERNAL not loading from library

I am using Vista. I reinstalled. No luck.

 I updated CygWin 1.7 again and did a reinstall on the developer package
and the base package; got the same result, so I used the "dummy procedure" 
kludge as a stop-gap so I  could test the rest of the code. It's about 
70,000
lines, mixes C and Fortran, uses the X11 library, has an interpreter built 
into it  ... so it's not trivial and it seems to be running fine otherwise 
(there is
a basic four-hour suite of tests and it passed).  I was pleasantly surprised 
by this.  By the way, I found several mentions of similar problems on Mac OS 
and
other places dating mostly around 2007 on the Web. Since no one else can 
reproduce this so far, and it works fine on Linux platforms and there are
many work-arounds possible I can understand this being dropped for now if 
you see fit to do so.

If anyone else can reproduce this or has any tests they want me to run on my 
platform let me know. I attached something very similar to the original
test code. If I add a dummy routine in the "blockdata" file; and a "call 
dummy()" everything loads properly. Otherwise, it runs with g77 and g95, but
fails with 4.5.0 and 4.4.3 (which it used to work with) so it seems more and 
more like something is wrong with the loader, not gfortran per-se.

Does anyone know off the bat why G77 and G95 would work and GFORTRAN would 
not?

----- Original Message ----- 
From: "jvdelisle at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: <urbanjost@comcast.net>
Sent: Friday, January 01, 2010 1:35 AM
Subject: [Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading 
from library


>
>
> ------- Comment #5 from jvdelisle at gcc dot gnu dot org  2010-01-01 
> 06:35 -------
> I forgot to mention I am using Cygwin 1.7, so this is beginning to look 
> like
> some sort of installation issue.  The gfortran version 4.5 I downloaded 
> and
> installed per the gfortran wiki.
>
> The other possibility to consider is what version of Windows you are 
> using.  I
> notice some reports on the Cygwin list of Vista and Windows 7 bugs. 
> However,
> these bugs are being actively worked.
>
> Try using Cygwin setup.exe and select the reinstall option for gcc core 
> and
> gfortran.  Also install all updates that are coming in daily almost on 
> cygwin
> as the bugs are getting cleared.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter. 


------- Comment #7 from urbanjost at comcast dot net  2010-01-02 07:50 -------
Created an attachment (id=19444)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19444&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu dot org]

------- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-01-04 03:25 -------
OK, I could not get the script to run for some reason.

However, I manually performed the steps in the script:

   gfortran-4 -c juinit2.f 
   ar -r libex.a juinit2.o
   gfortran-4 bug.f -L. -lex -o bug
   ./bug

and I get the bad result.  Doing this with g77 works fine.  The issue seems
related to trying to use juinit2.o from the created library libex.a

Sorry this took me a while to see what this was about.  I resproduced this
problem on Cygwin.  I have not tried on Linux yet.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|0000-00-00 00:00:00         |2010-01-04 03:25:21
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu dot org]

------- Comment #9 from jvdelisle at gcc dot gnu dot org  2010-01-04 03:40 -------
With Linux:

$ ./bug1.sh 
ar: creating libex.a
COMPILER g77
 GOOD LOAD ix2(4)=abcdefghijklmnopqrst
ar: creating libex.a
COMPILER g95
 GOOD LOAD ix2(4)=abcdefghijklmnopqrst
ar: creating libex.a
COMPILER gfortran
 GOOD LOAD ix2(4)=abcdefghijklmnopqrst
ar: creating libex.a
COMPILER gfc
 GOOD LOAD ix2(4)=abcdefghijklmnopqrst

gfc is gfortran-4.5.0 experimental
gfortran is gfortran-4.4.1

The problem appears to be target specific, Cygwin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu dot org]

------- Comment #10 from jvdelisle at gcc dot gnu dot org  2010-01-04 03:52 -------
Fixed the script on Cygwin:

$ ./bug1.sh
ar: creating libex.a
COMPILER gfortran-4
 BAD LOAD ix2(4)=
ar: creating libex.a
COMPILER gfc
 BAD LOAD ix2(4)=
ar: creating libex.a
COMPILER g77
 GOOD LOAD ix2(4)=abcdefghijklmnopqrst


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[burnus at gcc dot gnu dot org]

------- Comment #11 from burnus at gcc dot gnu dot org  2010-01-04 09:44 -------
Mark as new as Jerry has confirmed it. Jerry, do you see whether this is a
regression? From comment 0: "this worked in previous versions of gfortran"

It would be useful to know in which version it still worked. Does MinGW work?

Christopher, Dave: Do you have an idea what goes wrong?


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davek at gcc dot gnu dot
                   |                            |org, cgf at gcc dot gnu dot
                   |                            |org
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|2010-01-04 03:25:21         |2010-01-04 09:44:03
               date|                            |
            Summary|BLOCKDATA referenced in     |[Cygwin] BLOCKDATA
                   |EXTERNAL not loading from   |referenced in EXTERNAL not
                   |library                     |loading from library


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[davek at gcc dot gnu dot org]

------- Comment #12 from davek at gcc dot gnu dot org  2010-01-04 15:42 -------
COMMON symbols don't cause members to be pulled in from library archives.  You
can omit "-L. -lex" from the final link altogether and get the same result:
it's unused.  So the reference from bug.o to _jindx2 doesn't cause the library
archive member to be drawn into the final link.

With g77, there's this additional undefined symbol _juinit2_ in bug.o, which is
not common, and hence causes the libex.a(juinit2.o) member to be drawn into the
final link, at which time the explicit definition of _jindx2 overrides the
common definition.  gfortran doesn't generate any reference to _juinit2_ when
it is used to compile bug.f, so there is nothing left to pull the archive
member into the final link.

The reference to _juinit2_ that g77 generates while compiling bug.f but
gfortran does not generate has a label associated with it that suggests very
strongly that g77 was aware of the problem that common symbols don't pull in
lib archive members and uses this reference to an associated non-common symbol
deliberately to solve the problem:

        .file   "bug.f"
        .data
        .align 4
___g77_forceload_0.0:
        .long   _juinit2_

The "forceload" bit seems highly suggestive.  Does gfortran need to adopt this
part of g77's mechanism?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[dominiq at lps dot ens dot fr]

------- Comment #13 from dominiq at lps dot ens dot fr  2010-01-04 16:05 -------
The test fails also on *-apple-darwin9, but not on x86_64-apple-darwin10.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #14 from kargl at gcc dot gnu dot org  2010-01-04 16:13 -------
(In reply to comment #12)
> COMMON symbols don't cause members to be pulled in from library archives.  You
> can omit "-L. -lex" from the final link altogether and get the same result:
> it's unused.  So the reference from bug.o to _jindx2 doesn't cause the library
> archive member to be drawn into the final link.
> 

Comment #1 seems to contradict your assertion here.  To repeat, 

laptop:kargl[207] gfc4x -c a2.f
laptop:kargl[208] ar -cru libex.a a2.o
laptop:kargl[209] gfc4x -o z a1.f -L. -lex
laptop:kargl[210] ./z
 chars=abcdeabcdeabcdeabcdeabcde
 *missingBlockData* loaded common block


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[davek at gcc dot gnu dot org]

------- Comment #15 from davek at gcc dot gnu dot org  2010-01-04 16:36 -------
(In reply to comment #14)
> (In reply to comment #12)
> > COMMON symbols don't cause members to be pulled in from library archives.  You
> > can omit "-L. -lex" from the final link altogether and get the same result:
> > it's unused.  So the reference from bug.o to _jindx2 doesn't cause the library
> > archive member to be drawn into the final link.
> > 
> 
> Comment #1 seems to contradict your assertion here.  To repeat, 
> 
> laptop:kargl[207] gfc4x -c a2.f
> laptop:kargl[208] ar -cru libex.a a2.o
> laptop:kargl[209] gfc4x -o z a1.f -L. -lex
> laptop:kargl[210] ./z
>  chars=abcdeabcdeabcdeabcdeabcde
>  *missingBlockData* loaded common block

I can't tell anything from that.  What is gfc4x, and what are a1.f and a2.f?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #16 from kargl at gcc dot gnu dot org  2010-01-04 17:13 -------
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #12)
> > > COMMON symbols don't cause members to be pulled in from library archives.  You
> > > can omit "-L. -lex" from the final link altogether and get the same result:
> > > it's unused.  So the reference from bug.o to _jindx2 doesn't cause the library
> > > archive member to be drawn into the final link.
> > > 
> > 
> > Comment #1 seems to contradict your assertion here.  To repeat, 
> > 
> > laptop:kargl[207] gfc4x -c a2.f
> > laptop:kargl[208] ar -cru libex.a a2.o
> > laptop:kargl[209] gfc4x -o z a1.f -L. -lex
> > laptop:kargl[210] ./z
> >  chars=abcdeabcdeabcdeabcdeabcde
> >  *missingBlockData* loaded common block
> 
> I can't tell anything from that.  What is gfc4x, and what are a1.f and a2.f?

gfc4x is gfortran 4.5.

a1.f is OP's main program with the character(len=20)
replaced by character(len=5) to prevent screen wrap
on output.

a2.f is OP's block data file.

laptop:kargl[205] cat a1.f a2.f
      !
      ! File a1.f
      !
      program missingBlockData
      external juinit2
      character chars(5)*(5)
      common /qindex2/chars 
      save /qindex2/
      write(*,*)'chars=',chars
      if(chars(5).ne.'abcde')then
         write(*,*)'*missingBlockData* E-R-R-O-R: bad load'
      else
         write(*,*)'*missingBlockData* loaded common block'
      endif
      end
      !
      ! File a2.f
      !
      block data juinit2
      character chars(5)*(5)
      common /qindex2/chars 
      save /qindex2/
      data chars/5*'abcde'/
      end

You made an unmerited assertion that "COMMON symbols don't cause
members to be pulled in from library archives."  I've shown the 
counter example.  This appears to be linker issue on cygwin.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[davek at gcc dot gnu dot org]

------- Comment #17 from davek at gcc dot gnu dot org  2010-01-04 18:05 -------
(In reply to comment #16)

> You made an unmerited assertion that "COMMON symbols don't cause
> members to be pulled in from library archives."  I've shown the 
> counter example.  

  On what platform?

> This appears to be linker issue on cygwin.

It appears to be the entirely correct behaviour of the linker on PE-COFF
platforms; I don't know about ELF platforms, which may well behave differently.
 Why do you supposed the "forceload" mechanism existed in g77 if not to allow
the compiler to generate code that worked regardless of the target object
format?

See here: http://www.airs.com/blog/archives/48 

>"In general the linker will not include archives if they provide a definition for a common symbol."

Isn't that what's going on here?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[davek at gcc dot gnu dot org]

------- Comment #18 from davek at gcc dot gnu dot org  2010-01-04 18:06 -------
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1811 also looks pertinent.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #19 from kargl at gcc dot gnu dot org  2010-01-04 18:56 -------
(In reply to comment #17)
> (In reply to comment #16)
> 
> > You made an unmerited assertion that "COMMON symbols don't cause
> > members to be pulled in from library archives."  I've shown the 
> > counter example.  
> 
>   On what platform?

FreeBSD.  Yes, it's an ELF platform.  For the record, the behavior
as I've shown occurs with GNU ld.

% ld --version
GNU ld version 2.15 [FreeBSD] 2004-05-23


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu dot org]

------- Comment #20 from jvdelisle at gcc dot gnu dot org  2010-01-05 03:01 -------
I have read through the links given by Dave.  My take is that we have some
implementation dependent, non portable, behaviour in linkers.  Now that we know
we have this inconsistency, the question is do we want to fix this with a work
around in gfortran?

>From my read, there are situations where this is not desired behaviour. 
Obviously linux/Gnu is doing it. If so, exactly how is this done?  Should it be
handled by Cygwin? (by the linker?)

Dave, do you know how to emit the forceload and just exactly what is this?

What to do? and who?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[burnus at gcc dot gnu dot org]

------- Comment #21 from burnus at gcc dot gnu dot org  2010-01-05 14:46 -------
(In reply to comment #20)
> Dave, do you know how to emit the forceload and just exactly what is this?

g77 does it as shown in
http://gcc.gnu.org/viewcvs/branches/gcc-3_4-branch/gcc/f/com.c?view=markup


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[ian at airs dot com]

------- Comment #22 from ian at airs dot com  2010-01-05 16:09 -------
For ELF, when the GNU linker has seen a common symbol, and then sees that
symbol in the archive map, it will look in the object to see whether the object
defines the symbol (rather than simply providing another common definition). 
If the object does define the symbol, then it is pulled into the link.  See
http://sourceware.org/ml/binutils/1999-12/msg00015.html .  This was done for
compatibility with the SunOS and HP/UX linkers, but in retrospect I think it
may have been a mistake.

For the PE target used on cygwin, the GNU linker does not do this.  It follows
the simpler rule.  For that matter, the gold linker also does not do this.

So, yes, the linkers behave differently.  If you need to provide a common
definition, and you also need to force that common definition to pull in a
definition from an archive, then the compiler should arrange for that to
happen.  The easy way is: whenever you have a definition, also define some
other symbol.  Whenever you have a common symbol, also include an undefined
reference to that definition.


-- 

ian at airs dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[dominiq at lps dot ens dot fr]

------- Comment #23 from dominiq at lps dot ens dot fr  2010-01-05 18:12 -------
This looks like a duplicate of pr34136.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #24 from kargl at gcc dot gnu dot org  2010-01-16 23:18 -------
Fixed in trunk.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #25 from kargl at gcc dot gnu dot org  2010-01-16 23:47 -------
Re-open.  Sorry guys, wrong PR.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[urbanjost at comcast dot net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 39850 bytes --]

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

--- Comment #34 from urbanjost at comcast dot net ---
It still occurs with Cygwin 2.8.2, which comes with gfortran 5.4.0, which is
the latest version of CygWin, if that is of any help.

-----Original Message-----
From: dominiq at lps dot ens.fr [mailto:gcc-bugzilla@gcc.gnu.org] 
Sent: Sunday, August 13, 2017 6:00 AM
To: urbanjost@comcast.net
Subject: [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not
loading from library

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

--- Comment #34 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> So... what should we do with this bug then? I'm trying to move it out 
> of the WAITING queue. Change to SUSPENDED?

I am afraid that SUSPENDED is some kind of black hole for problems waiting
committee clarification. Here we are still waiting an answer from CygWin users
if it is still present with recent releases.

--
You are receiving this mail because:
You reported the bug.
>From gcc-bugs-return-572147-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 15 13:39:24 2017
Return-Path: <gcc-bugs-return-572147-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 39635 invoked by alias); 15 Aug 2017 13:39:22 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 39412 invoked by uid 48); 15 Aug 2017 13:39:01 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/81820] -Os may remove debug info
Date: Tue, 15 Aug 2017 14:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 8.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-81820-4-ek5Xo1o01V@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-81820-4@http.gcc.gnu.org/bugzilla/>
References: <bug-81820-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-08/txt/msg01706.txt.bz2
Content-length: 566

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |8.0

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed by

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ac36c55f2dac2b54a657d242646d84dfd522eb55
>From gcc-bugs-return-572148-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 15 13:41:13 2017
Return-Path: <gcc-bugs-return-572148-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 43317 invoked by alias); 15 Aug 2017 13:41:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 43100 invoked by uid 48); 15 Aug 2017 13:41:02 -0000
From: "webrown.cpp at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/81836] New: ill-formed qualified name not diagnosed
Date: Tue, 15 Aug 2017 15:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: webrown.cpp at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone
Message-ID: <bug-81836-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-08/txt/msg01707.txt.bz2
Content-length: 1239

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

            Bug ID: 81836
           Summary: ill-formed qualified name not diagnosed
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc@arne-mertz.de
                CC: webrown.cpp at gmail dot com
  Target Milestone: ---
                CC: webrown.cpp at gmail dot com

Consider the following code:

    typedef int foo;
    namespace Foo {
        int f();
        foo g();
    }

    int ::Foo::f() { return 0; }
    foo ::Foo::g() { return 1; }

This compiles in gcc 7.2.0 and 8.0.0 20170814, but should give an error in the
last line:

[expr.prim.id.qual] states, that `foo :: Foo` is a qualified ID. (`foo` is a
type-name). [basic.lookup.qual] then requires `foo` to denote a class,
enumeration or namespace. 

Clang, MSVC (and IAR) give diagnostics for this, see
https://godbolt.org/g/vhW9si

(`int :: Foo` is not a qualified ID because `int` is only a
simple-type-specifier, [dcl.type.simple])

But also consider open issue
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1828
>From gcc-bugs-return-572149-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 15 14:11:46 2017
Return-Path: <gcc-bugs-return-572149-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 90964 invoked by alias); 15 Aug 2017 14:11:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 90835 invoked by uid 48); 15 Aug 2017 14:11:30 -0000
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/38592] Optimize memmove / memcmp combination
Date: Tue, 15 Aug 2017 15:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.4.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: msebor at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc see_also
Message-ID: <bug-38592-4-sw4wwy8uk7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-38592-4@http.gcc.gnu.org/bugzilla/>
References: <bug-38592-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-08/txt/msg01708.txt.bz2
Content-length: 1251

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=81703

--- Comment #9 from Martin Sebor <msebor at gcc dot gnu.org> ---
The optimization should be easily doable in tree-ssa-strlen.c.  What makes it
less than straightforward is that gimple-fold.c folds constant size
memcpy/memmove into a MEM_REF which the strlen pass doesn't know how to handle.
 I think the best way is to defer the folding until after the strlen pass has
run.  That will not only make the optimization easily implementable but also
make it possible to detect past the end reads/writes in calls to the functions
because only the strlen pass knows the sizes of the source sequences.  (Bug
81703 tracks another instance of missing strlen optimization due to early
folding.  As an aside, deferring the folding is complementary to handling
MEM_REF in the strlen pass.)
>From gcc-bugs-return-572150-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 15 14:13:18 2017
Return-Path: <gcc-bugs-return-572150-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 104176 invoked by alias); 15 Aug 2017 14:13:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 103215 invoked by uid 48); 15 Aug 2017 14:13:08 -0000
From: "alenuke at yandex dot ru" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/81845] New: const union's field doesn't interpret as const in switch/case
Date: Tue, 15 Aug 2017 15:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 7.1.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: alenuke at yandex dot ru
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-81845-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-08/txt/msg01709.txt.bz2
Content-length: 1119

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

            Bug ID: 81845
           Summary: const union's field doesn't interpret as const in
                    switch/case
           Product: gcc
           Version: 7.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alenuke at yandex dot ru
  Target Milestone: ---

Here's the code that compiles ok:

#include  <stdio.h>

    const union {
        char c[4];
        int i;
    } buzaka = { { 1, 2, 3, 4 } };


int main(int argc, char ** argv)
{

    const int z = buzaka.i;


    switch (argc)
    {
        default:
     // case z:
        printf("Hello, world!\n");
        break;

    }

    return z;
}



If we uncomment "case z", it will not compile.


What's funny is that I didn't find any compiler, that could compile it.
(
you can see interactive compilers here:
https://godbolt.org/g/CoseVn
)

Some people say that's a C standard issue of "const != constexpr", but I really
can't get it (why/where).

Thanks.
>From gcc-bugs-return-572151-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 15 14:30:08 2017
Return-Path: <gcc-bugs-return-572151-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 74326 invoked by alias); 15 Aug 2017 14:29:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 73859 invoked by uid 48); 15 Aug 2017 14:29:17 -0000
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/81811] missing -Wreturn-local-addr returning strcpy result
Date: Tue, 15 Aug 2017 16:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 8.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: msebor at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-81811-4-7Wxrpb7diJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-81811-4@http.gcc.gnu.org/bugzilla/>
References: <bug-81811-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-08/txt/msg01710.txt.bz2
Content-length: 761

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

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> Wonder whether the memcpy case is because we fold the memcpy away as both
> memcpy and strcpy are marked RET1 (returns arg1).

The memcpy is eliminated in DSE and turned into a plain 'return a' statement
that  the find_explicit_erroneous_behavior() in tree-ssa-isolate-paths.c that
implements the warning knows how to handle.

DSE doesn't handle strcpy or strncpy so the calls are not eliminated and
because find_explicit_erroneous_behavior() doesn't handle calls, the 'return
strcpy(a, s)' statement isn't detected.

This suggests an opportunity to improve not just the warning but also DSE.
>From gcc-bugs-return-572152-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 15 14:34:15 2017
Return-Path: <gcc-bugs-return-572152-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 62455 invoked by alias); 15 Aug 2017 14:34:02 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 57604 invoked by uid 48); 15 Aug 2017 14:33:53 -0000
From: "sezeroz at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug web/81846] New: ViewVC Exception
Date: Tue, 15 Aug 2017 16:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: web
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sezeroz at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-81846-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-08/txt/msg01711.txt.bz2
Content-length: 1602

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

            Bug ID: 81846
           Summary: ViewVC Exception
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: web
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sezeroz at gmail dot com
  Target Milestone: ---

http://gcc.gnu.org/viewcvs/gcc/branches/?sortby=date
is failing with the following:

An Exception Has Occurred
Python Traceback

Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/viewvc/lib/viewvc.py", line 4855, in
main
    request.run_viewvc()
  File "/usr/lib/python2.6/site-packages/viewvc/lib/viewvc.py", line 408, in
run_viewvc
    self.view_func(self)
  File "/usr/lib/python2.6/site-packages/viewvc/lib/viewvc.py", line 2296, in
view_directory
    file_data, options)
  File "/usr/lib/python2.6/site-packages/viewvc/lib/vclib/svn/svn_repos.py",
line 458, in dirlogs
    date, author, msg, revprops, changes = self._revinfo(entry_rev)
  File "/usr/lib/python2.6/site-packages/viewvc/lib/vclib/svn/svn_repos.py",
line 788, in _revinfo
    cached_info = _revinfo_helper(rev, include_changed_paths)
  File "/usr/lib/python2.6/site-packages/viewvc/lib/vclib/svn/svn_repos.py",
line 750, in _revinfo_helper
    revprops = fs.revision_proplist(self.fs_ptr, rev)
  File "/usr/lib64/python2.6/site-packages/libsvn/fs.py", line 736, in
svn_fs_revision_proplist
    return apply(_fs.svn_fs_revision_proplist, args)
SubversionException: ('No such revision 206916', 160006)
>From gcc-bugs-return-572153-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 15 14:52:48 2017
Return-Path: <gcc-bugs-return-572153-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 126958 invoked by alias); 15 Aug 2017 14:52:43 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 126502 invoked by uid 48); 15 Aug 2017 14:52:10 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/81844] New: -finstrument-control-flow -mcet is incompatible with makecontext family functions
Date: Tue, 15 Aug 2017 16:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter blocked target_milestone cf_gcctarget resolution
Message-ID: <bug-81844-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-08/txt/msg01712.txt.bz2
Content-length: 1988

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

            Bug ID: 81844
           Summary: -finstrument-control-flow -mcet is incompatible with
                    makecontext family functions
           Product: gcc
           Version: 8.0
            Status: RESOLVED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
            Blocks: 81652
  Target Milestone: ---
            Target: x86
            Status: RESOLVED
        Resolution: DUPLICATE

-finstrument-control-flow -mcet enables shadow stack which is incompatible
with makecontext family functions:

/* Get user context and store it in variable pointed to by UCP.  */
extern int getcontext (ucontext_t *__ucp) __THROWNL;

/* Set user context from information of variable pointed to by UCP.  */
extern int setcontext (const ucontext_t *__ucp) __THROWNL;

/* Save current context in context variable pointed to by OUCP and set
   context from variable pointed to by UCP.  */
extern int swapcontext (ucontext_t *__restrict __oucp,
                        const ucontext_t *__restrict __ucp) __THROWNL;

/* Manipulate user context UCP to continue with calling functions FUNC
   and the ARGC-1 parameters following ARGC when the context is used
   the next time in `setcontext' or `swapcontext'.

   We cannot say anything about the parameters FUNC takes; `void'
   is as good as any other choice.  */
extern void makecontext (ucontext_t *__ucp, void (*__func) (void),
                         int __argc, ...) __THROW;


At minimum, compiler shouldn't set the GNU_PROPERTY_X86_FEATURE_1_SHSTK bit
if one of these functions is used.

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
Dup.

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -finstrument-control-flow -mcet bugs
>From gcc-bugs-return-572154-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 15 14:52:51 2017
Return-Path: <gcc-bugs-return-572154-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 127004 invoked by alias); 15 Aug 2017 14:52:47 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 126735 invoked by uid 48); 15 Aug 2017 14:52:25 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/81842] New: -finstrument-control-flow -mcet is incompatible with makecontext family functions
Date: Tue, 15 Aug 2017 16:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc blocked target_milestone cf_gcctarget
Message-ID: <bug-81842-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-08/txt/msg01713.txt.bz2
Content-length: 1982

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

            Bug ID: 81842
           Summary: -finstrument-control-flow -mcet is incompatible with
                    makecontext family functions
           Product: gcc
           Version: 8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: igor.v.tsimbalist at intel dot com
            Blocks: 81652
  Target Milestone: ---
            Target: x86

-finstrument-control-flow -mcet enables shadow stack which is incompatible
with makecontext family functions:

/* Get user context and store it in variable pointed to by UCP.  */
extern int getcontext (ucontext_t *__ucp) __THROWNL;

/* Set user context from information of variable pointed to by UCP.  */
extern int setcontext (const ucontext_t *__ucp) __THROWNL;

/* Save current context in context variable pointed to by OUCP and set
   context from variable pointed to by UCP.  */
extern int swapcontext (ucontext_t *__restrict __oucp,
                        const ucontext_t *__restrict __ucp) __THROWNL;

/* Manipulate user context UCP to continue with calling functions FUNC
   and the ARGC-1 parameters following ARGC when the context is used
   the next time in `setcontext' or `swapcontext'.

   We cannot say anything about the parameters FUNC takes; `void'
   is as good as any other choice.  */
extern void makecontext (ucontext_t *__ucp, void (*__func) (void),
                         int __argc, ...) __THROW;


At minimum, compiler shouldn't set the GNU_PROPERTY_X86_FEATURE_1_SHSTK bit
if one of these functions is used.

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
*** Bug 81844 has been marked as a duplicate of this bug. ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -finstrument-control-flow -mcet bugs
>From gcc-bugs-return-572155-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 15 14:52:59 2017
Return-Path: <gcc-bugs-return-572155-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 127631 invoked by alias); 15 Aug 2017 14:52:57 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 126978 invoked by uid 48); 15 Aug 2017 14:52:43 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/81652] [meta-bug] -finstrument-control-flow -mcet bugs
Date: Tue, 15 Aug 2017 17:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: dep_changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-81652-4-TRxKmhJ7xN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-81652-4@http.gcc.gnu.org/bugzilla/>
References: <bug-81652-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-08/txt/msg01714.txt.bz2
Content-length: 513

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

Bug 81844 Summary: -finstrument-control-flow -mcet is incompatible with makecontext family functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81844

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE
>From gcc-bugs-return-572156-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 15 15:12:54 2017
Return-Path: <gcc-bugs-return-572156-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 33679 invoked by alias); 15 Aug 2017 15:12:52 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 33634 invoked by uid 89); 15 Aug 2017 15:12:47 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:67267f8, H*i:sk:67267f8, HX-HELO:sk:EUR03-D, H*RU:sk:EUR03-D
X-Spam-User: qpsmtpd, 2 recipients
X-HELO: EUR03-DB5-obe.outbound.protection.outlook.com
Received: from mail-eopbgr40061.outbound.protection.outlook.com (HELO EUR03-DB5-obe.outbound.protection.outlook.com) (40.107.4.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Aug 2017 15:12:45 +0000
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs.Nagy@arm.com;
Received: from [10.2.206.69] (217.140.96.140) by DB6PR0802MB2486.eurprd08.prod.outlook.com (2603:10a6:4:a0::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1341.17; Tue, 15 Aug 2017 15:12:41 +0000
Message-ID: <59930F66.50805@arm.com>
Date: Tue, 15 Aug 2017 17:06:00 -0000
From: Szabolcs Nagy <szabolcs.nagy@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Martin Sebor <msebor@gmail.com>, Eric Gallager <egall@gwmail.gwu.edu>
CC: nd@arm.com, gcc-bugs@gcc.gnu.org, GCC Mailing List <gcc@gcc.gnu.org>
Subject: Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.
References: <CAMfHzOsXnceTY=YHFfC_qDPYYgkyer=dm5ESABuO_KjuQ60MXw@mail.gmail.com> <67267f8d-030b-e5ac-21b1-8d5c6911045d@gmail.com>
In-Reply-To: <67267f8d-030b-e5ac-21b1-8d5c6911045d@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DB6PR07CA0129.eurprd07.prod.outlook.com (2603:10a6:6:16::22) To DB6PR0802MB2486.eurprd08.prod.outlook.com (2603:10a6:4:a0::21)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 8a15fec7-0942-48d2-60f2-08d4e3f01311
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam:	UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:DB6PR0802MB2486;
X-Microsoft-Exchange-Diagnostics:	1;DB6PR0802MB2486;3:W9vwKY0q6m3f2pr3IvMOlD5wxY9ZU5rP+9CfK83CHMRkMvIeJG/VE4hJD+2dDou6LUmw2lZAfAoqnRkvCGpQwcXkDsVkqwuGkT4jM4fEGAp/SELnz1YWzxzDrJZAcpBCuMCELecPtAf9TDmvm6eRkFtUn0omEiTEwqqyjvnX87v21WMhFG48Bn3/rmBCvBEimNDZR0jCpFr48evY77uZOEnyqJiP+/O63Wn2t7yD4M7SRMWyHz2+xIAUXv1uu/Cw;25:ttizKH1AgqQQGu7WzBHSte+xAc732Mp5WMt3D//7S4esGakLwGvcGRS4tve98DDYDkIS+A3eeERw/mf8AnNiXDCipL5sOI/8BXSniaYE2vyoQWkp8VQgBnPL6xhp9kXEkaoAXuA/6/eCy4HRz1iQSpyq5/xiHwJau/nGuHvAipKcLlFAHF5Jg89JMuFCwdiv61fEmwgzkS7grekEy+4odzFKYW+F72Prmokh1zKjCWEZAcNmX9IrYE+KLL1uoTJRc1BCwmOi1wUefKxuJ8i7D9JGTtnceM3wrud1vlp8NzxVHmVh3Jt1o41eu9yP/o7YV1PnUwFgLluDv3K6p9LkHw==;31:IuLthkN4yBKCBXvgHeHVaNhWV8SzK02Wg6C/qQUyqt7d7jVJwf+u6pvF4lmqznItdm93TCsJj8h9Q9/8a83iwqR2TT9pGINtIVDK9y/n6NRek7xZNDYQpmP809V+zsVNDrYr/XH5hv7Hxc9rQwFq2gRFbRY9O1tmPGFPDrNEU9zzcLIbCKgviODD033c2A1x/0AkBe7hwz65PZc3CZsgsHrvvs9cDXMaVxLMTlABVCEX-MS-TrafficTypeDiagnostic: DB6PR0802MB2486:
NoDisclaimer: True
X-Microsoft-Exchange-Diagnostics:	1;DB6PR0802MB2486;20:xDoWrD8ze96ZTgOVmn5QQSM58m1rt9ytyjGcjMijGjKPxXRG3Rat20sFnGTspzYVXUs+RN18AoEGphQsqc+LVfEJ5ZiWDFYC/B0aFtwy5wu863YmexTCcjmNr33icygshs4RDUX/5jNjZ9dmHoeywf++JqK7Qw1naw0InIqwC1M=;4:yrQJXtlkVcBMCYwyCTkg3OJc8XWLNASO+zAyhuFqWqY5vK9FRIk9kZzr5q/dnY/WY6/c40FxCLf3HK4uWjMw91J3abvH9Ob1ujHtYD3R/NBukGjuCmORSLgcsJCAIlNxyprnFavep2wH58CxW19UKafUVLnHj0+v1QNg3Mf8OZnmYn351tetXggGV+wzVjptaiM1oshv/F6CIykfWiufwcjdzhP31+ayhvb211/RSb+x2bea9/RCcXmepyCfVK8KLC2Q0+6o1kEilZhEyI1Mk78SzgHYGM9s5QQkruG0ALoK9w1IBnJJE+i7lO7niWjwDfKycKOOSVX/oAzfD8fP4Q=X-Exchange-Antispam-Report-Test: UriScan:(22074186197030)(183786458502308);
X-Microsoft-Antispam-PRVS:	<DB6PR0802MB248655347EE59589E277FDD0ED8D0@DB6PR0802MB2486.eurprd08.prod.outlook.com>
X-Exchange-Antispam-Report-CFA-Test:	BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DB6PR0802MB2486;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DB6PR0802MB2486;
X-Forefront-PRVS: 04004D94E2
X-Forefront-Antispam-Report:	SFV:NSPM;SFS:(10009020)(4630300001)(7370300001)(6009001)(6049001)(39860400002)(24454002)(377454003)(189002)(199003)(33656002)(47776003)(230700001)(5660300001)(6116002)(2950100002)(3846002)(65956001)(42186005)(36756003)(66066001)(4001350100001)(101416001)(54356999)(6306002)(8676002)(6666003)(65806001)(53546010)(81156014)(53936002)(7736002)(81166006)(6246003)(305945005)(2171002)(50986999)(65816999)(76176999)(189998001)(478600001)(2906002)(105586002)(106356001)(83506001)(72206003)(4326008)(7350300001)(68736007)(966005)(64126003)(25786009)(86362001)(97736004)(15650500001)(23676002)(50466002)(229853002)(6486002)(77096006);DIR:OUT;SFP:1101;SCL:1;SRVR:DB6PR0802MB2486;H:[10.2.206.69];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en;
Received-SPF: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics:	=?utf-8?B?MTtEQjZQUjA4MDJNQjI0ODY7MjM6cTNmSWNiNXhLRkp5d05hWmJiRXFoWWVq?= =?utf-8?B?cGs0Ni8ydWRaMmswaHEwNVN6VVZhQUN0cms3M1Y3aVZZdEY0Q1o3enFQWHdY?= =?utf-8?B?eUVLMlRSaXFxZTNuSHdsa0VJNmVZYXFOMGMxTTYzOWNJSzZUQkI4TlhXVjNo?= =?utf-8?B?T0tWV2lyWGRrQldKOXFkc2VVVXNjblkvT0lrWTJ6NkxNSzNnd0U0T3N1NTRp?= =?utf-8?B?Z2JxZFRIaEk2Qm5RblpSdlRGSkZKVlZBblMwbVgwa2tyMWsxZDBLc0RrUzZn?= =?utf-8?B?WDVkMTFkMGRYeURFdm9ERUdwNEd1Z3JwQmpBQ2RWQ2IwYUlvNWFoay9lMVQ2?= =?utf-8?B?ZGRDQjdidCt4TG5HV3VzR3ora2g1NDVDZlpBM1l2L1ZSUVZneDV5UHhuTlFp?= =?utf-8?B?Y1kwYmpYZktVUTZQSkVmT0NKVHVZSG92T29XbUZmQnBocHFXR25YZkd2em1S?= =?utf-8?B?ejY0RXdGdXM4VG5XdmcwOGVnRUlXMXhrdnVsY3dmenRVL0JYQUszbjlBYmNt?= =?utf-8?B?NTFoSnFrS2srRVJoMTRCOFNHNUNpZXAzM1V5cVVZMUVxdWw2WCtmK2ZvWWM3?= =?utf-8?B?WFVUY3M4VXYzZ2w3Q0x0UUZIZ1hVY3dXWWtoQlUxVVh6emM5YjkxUG5tZ3h0?= =?utf-8?B?S1BhSkdCT3NkMHMzYjNPZVU5dlJyVGlZYzBiMEZEL2NRcmhJUjJ6dkoya0lJ?= =?utf-8?B?SU1JaGpwMWNVbzJvYU9KM3hyRXc0YzdXcnhJU21Sd3B3NjJOdkRJN3FVR2RV?= =?utf-8?B?SjQxSWdtZGtZM0U3ZzYvRHk5VVNoMGZINmdTY0loTmQvZUYxYmFldzlnY2Iy?= =?utf-8?B?T2paQzRjV2xaZnRaUE1ZSnI1aHY4bDhTVndlL0RBWGtaclJIZzJTQXM1N1FV?= =?utf-8?B?bVU3VW5oMGZRbzZybmN3WkYxeE5xSklsYVJTMXBoU3dDNzZyaHFZQlZWL05k?= =?utf-8?B?djZrVnpZK0d1T1MrSms0ZFBHVm51aXB3aXhjRkhPMWNnSDcybnF1M1FIT3ZZ?= =?utf-8?B?TFRxcHh4TVNlVkxGMDVIZ2VsOE0zU2grZkk1dUsvTkdHR0wxZzhUKzNuYUJR?= =?utf-8?B?ZzFrbnhkSE8xWFhlOEtHZmlWL3BycnpHL2pKMXNlaHVoNm43K1lFZ1RxT0Nz?= =?utf-8?B?Q0RncHBQQ0h2ZE9tRkhZNFAzUTY5bDFqbExCQkFMSndpbkl6VkVQRThCd29r?= =?utf-8?B?N0dQNlk3N0xBdkZzUGp5ajZRTW8vQUxkbzVhVlZCQUoydk15aG5mbjFaNnF2?= =?utf-8?B?aDkrdWVGU0hDNkIwUlN1eGlZcXhGRWtKeEw2UnJFMGhZNTZFTkxWN2lXNHp6?= =?utf-8?B?Y0FPSElVUlN6aG52NW9JR3YxbG01YWpacXpzMkw2ZVJ0OGg3aHREYjQ0djRL?= =?utf-8?B?MWpCdHZ2czNITExkeEIySTlGaHFzaTEzQjBGWlYrcXN3OFpHUTFRQmtPTzI0?= =?utf-8?B?d2dKaWIwY3pXbHpmemN3M3FBd3AwTDd5S2N6bFAzOUFBWWxySUd5NmFrQ29m?= =?utf-8?B?L09HNDJGWXRBZXQ4cUU4cFJzMGEyV1pMdUJIY0dyTFVTNHQwbm42ak0zRERH?= =?utf-8?B?WHIreVFjLzhRMThTQTBJYTJFZzFJaHRmQjAxWXQyalVUQnIwemFoNlNRS3NR?= =?utf-8?B?aHpFZDV1OXk3UWtleTlIemlHdmdtU1FnWk5VQXpSb2d5OUdPa3VtMTRNOGNW?= =?utf-8?B?SDl0TnpoZllmS29SYVlJTnVGcU5PS0V0ZE1ERWtCazIwb012SDhqZXdjcGti?= =?utf-8?B?ZXNHK3oyVnpZbisyTnhPRHJiaWo0djl5bXB2SFpvSnd5eDNQRzFEeXRqbVlj?= =?utf-8?B?RWR3VWxMYjZwQTMwbkFCbFh5T055TmJXQ1RxL21ZY2MzSVRpYjhlWWJkOC91?= =?utf-8?B?QitFczZaRWFySFJubUVabm9mU0NYVHQweDlSbTZuOURHYVhWMXB5NEhjWjk0?= =?utf-8?B?RFplSTVpRG1SRlE9PQ==?X-Microsoft-Exchange-Diagnostics:	1;DB6PR0802MB2486;6:+Q6IQQPySgOA8MLmwW3xIWngVlXfcoEg7ToFKCvLEdZyUMt5SLSB26745xOv6Lc2usY5djiRTc2grEj2TTueYbhVVB8ydoquDI2SR+u37CCzlD84GqJkbxXh5OF8pzWG1XzSDzmYyMDa7F5aCthoFKj8SYYwwYqJUNKZ3QYuWkrU45369hWZf7b/Zbsa2wr9r/k1vAlmPRmN4f5LWcY1qSKIdj3JsqLMfMrx3svPuUKFsMIh2KjLDxkkhkvYNGrSJIprzcz23bkaPvb/5qLGruICDkuDipK+T2QLbcbc/OdJEVv/Pr4GwfgIiiYq2cfJOkDEqUwWMfTsBnpCssVnHw==;5:l+KVaSBb+XqIPiqJ1+TSx/Z1lR5aMlD1j/wvEGCJmhY5cINU8wlXAsV7PwUxSa56yOV5bFxR7xN5Fgemlw0nm6rTPxyigA2DCRTKku34hLVnFyHSrxuYUGzBTzNJBDyO542dIboNBAXq2/tB7e/GCg==;24:2bRRyEH5UV7J+5quQoovPYexHg0VLsJUaXXweY7UpfuNIs/7dN9i5HdtiC94bx0l39FWgKrpOUmLsPAEClZ8TaR+ZtliY0m7V54w0ABtcFw=;7:/3P4ho/A0XywRlnXTgJyUOywWjIdaTQMcYbM1mnhWR8S4UzH/812nJqCfCV9pl1hmDuD8v+087UGeCRWFXWNbeLy/v/fpgw9G2qGLlihiCCwX3A4TJAYZ7hzSYwZXZTOOzsGHsdcjT2GS0Gfk2rgHIJI4t3kcz53POpxjpFYm9O2egVwLswl4t5qMVV7Z/fUssI/sNpaxQ9rytn9jX+2Q48tDHqkfhgwreby/soxK38SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Aug 2017 15:12:41.1238 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2486
X-IsSubscribed: yes
X-SW-Source: 2017-08/txt/msg01715.txt.bz2
Content-length: 1062

On 15/08/17 04:10, Martin Sebor wrote:
> On 08/14/2017 04:22 PM, Eric Gallager wrote:
>> I'm emailing this manually to the list because Bugzilla is down and I
>> can't file a bug on Bugzilla about Bugzilla being down. The error
>> message looks like this:
>
> Bugzilla and the rest of gcc.gnu.org have been down much of
> the afternoon/evening due to a hard drive upgrade (the old disk
> apparently failed).  You're not the only one who found out about
> it the hard way.  I (and I suspect most others) also discovered
> it when things like Git and SVN (and Bugzilla) stopped working.
>
> I've CC'd the gcc list to let others know (not sure what list
> to subscribe to in order to get a heads up on these kinds of
> maintenance issues).
>

i seems the database got corrupted.

at least one of my bugs was overwritten by another:

original 81846:
https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01574.html
current 81846:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id846

similarly there are two bugs on the bug mailing list
for 81845 and later bugs are missing.

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |WAITING
                 CC|                            |jvdelisle at gcc dot gnu.org
         Resolution|FIXED                       |---

--- Comment #29 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I happened to just get Cygwin installed and running on my Windows box.  Let me
run some tests and see if I can understand this.

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[urbanjost at comcast dot net]

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

--- Comment #28 from urbanjost at comcast dot net ---
This is still a problem with Cygwin 2.2.1 and gfortran 4.9.3 

  $ cygcheck --version
cygcheck (cygwin) 2.2.1
System Checker for Cygwie
$ gfortran --version
GNU Fortran (GCC) 4.9.3

$ bash bug1.sh
ar: creating libex.a
COMPILER gfortran
 BAD LOAD ix2(4)=


-----Original Message-----
From: fxcoudert at gcc dot gnu.org [mailto:gcc-bugzilla@gcc.gnu.org] 
Sent: Saturday, September 12, 2015 7:20 AM
To: urbanjost@comcast.net
Subject: [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not
loading from library

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |fxcoudert at gcc dot gnu.org
         Resolution|---                         |FIXED

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[dominiq at lps dot ens.fr]

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

--- Comment #27 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Is it still true on recent versions of Cygwin (it has been fixed on darwin
> since darwin10, see pr34136)?

Ping! Without answer I'll close this PR as FIXED.

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |WAITING

--- Comment #26 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Is it still true on recent versions of Cygwin (it has been fixed on darwin
since darwin10, see pr34136)?