public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
[not found] <bug-42568-4@http.gcc.gnu.org/bugzilla/>
@ 2014-01-13 13:40 ` dominiq at lps dot ens.fr
2015-09-05 10:42 ` dominiq at lps dot ens.fr
` (3 subsequent siblings)
4 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-01-13 13:40 UTC (permalink / raw)
To: gcc-bugs
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)?
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
[not found] <bug-42568-4@http.gcc.gnu.org/bugzilla/>
2014-01-13 13:40 ` [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library dominiq at lps dot ens.fr
@ 2015-09-05 10:42 ` dominiq at lps dot ens.fr
2015-09-15 5:31 ` urbanjost at comcast dot net
` (2 subsequent siblings)
4 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-09-05 10:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
[not found] <bug-42568-4@http.gcc.gnu.org/bugzilla/>
2014-01-13 13:40 ` [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library dominiq at lps dot ens.fr
2015-09-05 10:42 ` dominiq at lps dot ens.fr
@ 2015-09-15 5:31 ` urbanjost at comcast dot net
2015-09-18 16:57 ` jvdelisle at gcc dot gnu.org
2017-08-15 14:29 ` urbanjost at comcast dot net
4 siblings, 0 replies; 20+ messages in thread
From: urbanjost at comcast dot net @ 2015-09-15 5:31 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
[not found] <bug-42568-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2015-09-15 5:31 ` urbanjost at comcast dot net
@ 2015-09-18 16:57 ` jvdelisle at gcc dot gnu.org
2017-08-15 14:29 ` urbanjost at comcast dot net
4 siblings, 0 replies; 20+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-09-18 16:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
[not found] <bug-42568-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2015-09-18 16:57 ` jvdelisle at gcc dot gnu.org
@ 2017-08-15 14:29 ` urbanjost at comcast dot net
4 siblings, 0 replies; 20+ messages in thread
From: urbanjost at comcast dot net @ 2017-08-15 14:29 UTC (permalink / raw)
To: gcc-bugs
[-- 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?id846
similarly there are two bugs on the bug mailing list
for 81845 and later bugs are missing.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
` (13 preceding siblings ...)
2010-01-16 23:18 ` kargl at gcc dot gnu dot org
@ 2010-01-16 23:47 ` kargl at gcc dot gnu dot org
14 siblings, 0 replies; 20+ messages in thread
From: kargl at gcc dot gnu dot org @ 2010-01-16 23:47 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
` (12 preceding siblings ...)
2010-01-05 18:13 ` dominiq at lps dot ens dot fr
@ 2010-01-16 23:18 ` kargl at gcc dot gnu dot org
2010-01-16 23:47 ` kargl at gcc dot gnu dot org
14 siblings, 0 replies; 20+ messages in thread
From: kargl at gcc dot gnu dot org @ 2010-01-16 23:18 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
` (11 preceding siblings ...)
2010-01-05 16:10 ` ian at airs dot com
@ 2010-01-05 18:13 ` dominiq at lps dot ens dot fr
2010-01-16 23:18 ` kargl at gcc dot gnu dot org
2010-01-16 23:47 ` kargl at gcc dot gnu dot org
14 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens dot fr @ 2010-01-05 18:13 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
` (10 preceding siblings ...)
2010-01-05 14:46 ` burnus at gcc dot gnu dot org
@ 2010-01-05 16:10 ` ian at airs dot com
2010-01-05 18:13 ` dominiq at lps dot ens dot fr
` (2 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: ian at airs dot com @ 2010-01-05 16:10 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
` (9 preceding siblings ...)
2010-01-05 3:01 ` jvdelisle at gcc dot gnu dot org
@ 2010-01-05 14:46 ` burnus at gcc dot gnu dot org
2010-01-05 16:10 ` ian at airs dot com
` (3 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-01-05 14:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
` (8 preceding siblings ...)
2010-01-04 18:57 ` kargl at gcc dot gnu dot org
@ 2010-01-05 3:01 ` jvdelisle at gcc dot gnu dot org
2010-01-05 14:46 ` burnus at gcc dot gnu dot org
` (4 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2010-01-05 3:01 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
` (7 preceding siblings ...)
2010-01-04 18:06 ` davek at gcc dot gnu dot org
@ 2010-01-04 18:57 ` kargl at gcc dot gnu dot org
2010-01-05 3:01 ` jvdelisle at gcc dot gnu dot org
` (5 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: kargl at gcc dot gnu dot org @ 2010-01-04 18:57 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
` (6 preceding siblings ...)
2010-01-04 18:05 ` davek at gcc dot gnu dot org
@ 2010-01-04 18:06 ` davek at gcc dot gnu dot org
2010-01-04 18:57 ` kargl at gcc dot gnu dot org
` (6 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-04 18:06 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
` (5 preceding siblings ...)
2010-01-04 17:14 ` kargl at gcc dot gnu dot org
@ 2010-01-04 18:05 ` davek at gcc dot gnu dot org
2010-01-04 18:06 ` davek at gcc dot gnu dot org
` (7 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-04 18:05 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
` (4 preceding siblings ...)
2010-01-04 16:36 ` davek at gcc dot gnu dot org
@ 2010-01-04 17:14 ` kargl at gcc dot gnu dot org
2010-01-04 18:05 ` davek at gcc dot gnu dot org
` (8 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: kargl at gcc dot gnu dot org @ 2010-01-04 17:14 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
` (3 preceding siblings ...)
2010-01-04 16:13 ` kargl at gcc dot gnu dot org
@ 2010-01-04 16:36 ` davek at gcc dot gnu dot org
2010-01-04 17:14 ` kargl at gcc dot gnu dot org
` (9 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-04 16:36 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
` (2 preceding siblings ...)
2010-01-04 16:06 ` dominiq at lps dot ens dot fr
@ 2010-01-04 16:13 ` kargl at gcc dot gnu dot org
2010-01-04 16:36 ` davek at gcc dot gnu dot org
` (10 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: kargl at gcc dot gnu dot org @ 2010-01-04 16:13 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
2010-01-04 9:44 ` [Bug fortran/42568] [Cygwin] " burnus at gcc dot gnu dot org
2010-01-04 15:43 ` davek at gcc dot gnu dot org
@ 2010-01-04 16:06 ` dominiq at lps dot ens dot fr
2010-01-04 16:13 ` kargl at gcc dot gnu dot org
` (11 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens dot fr @ 2010-01-04 16:06 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
2010-01-04 9:44 ` [Bug fortran/42568] [Cygwin] " burnus at gcc dot gnu dot org
@ 2010-01-04 15:43 ` davek at gcc dot gnu dot org
2010-01-04 16:06 ` dominiq at lps dot ens dot fr
` (12 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-04 15:43 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
@ 2010-01-04 9:44 ` burnus at gcc dot gnu dot org
2010-01-04 15:43 ` davek at gcc dot gnu dot org
` (13 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-01-04 9:44 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2017-08-15 13:33 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-42568-4@http.gcc.gnu.org/bugzilla/>
2014-01-13 13:40 ` [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library dominiq at lps dot ens.fr
2015-09-05 10:42 ` dominiq at lps dot ens.fr
2015-09-15 5:31 ` urbanjost at comcast dot net
2015-09-18 16:57 ` jvdelisle at gcc dot gnu.org
2017-08-15 14:29 ` urbanjost at comcast dot net
2009-12-31 23:06 [Bug fortran/42568] New: " urbanjost at comcast dot net
2010-01-04 9:44 ` [Bug fortran/42568] [Cygwin] " burnus at gcc dot gnu dot org
2010-01-04 15:43 ` davek at gcc dot gnu dot org
2010-01-04 16:06 ` dominiq at lps dot ens dot fr
2010-01-04 16:13 ` kargl at gcc dot gnu dot org
2010-01-04 16:36 ` davek at gcc dot gnu dot org
2010-01-04 17:14 ` kargl at gcc dot gnu dot org
2010-01-04 18:05 ` davek at gcc dot gnu dot org
2010-01-04 18:06 ` davek at gcc dot gnu dot org
2010-01-04 18:57 ` kargl at gcc dot gnu dot org
2010-01-05 3:01 ` jvdelisle at gcc dot gnu dot org
2010-01-05 14:46 ` burnus at gcc dot gnu dot org
2010-01-05 16:10 ` ian at airs dot com
2010-01-05 18:13 ` dominiq at lps dot ens dot fr
2010-01-16 23:18 ` kargl at gcc dot gnu dot org
2010-01-16 23:47 ` kargl at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).