Fixing gcc git logs
In the following git log entry, I made a typo on the PR number in the libgfortran ChangeLog file. I noticed this right after the git commit, while editing the git log. So I quit the edit without saving and git reported that the commit was aborted. Then I edited the my local ChangeLog file, did git add . and git commit again. In this case the git log edit started as usual and I recopied the correct text into my editor (VI) and saved it. The commit proceeded as I expected. Then I did the git svn dcommit Well the git log ended up like this. How to fix? How to avoid? The 90274 should have been 90374. The actual committed files are OK. Regards, Jerry commit 86e1d9f75bae096922664755d037f2a9d85e2a24 (HEAD -> trunk, svn/trunk, origin/trunk, origin/master) Author: jvdelisle Date: Thu Jan 2 00:57:31 2020 + PR 90374 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d edit descriptors. PR libfortran/90274 * io/format.c (parse_format_list): Implement the E0 exponent width to provide smallest possible width for exponent fields. Refactor code for correct parsing and better readability of the code. * io/io.h (write_real_w0): Change interface to pass in pointer to fnode. * io/transfer.c: Update all calls to write_real_w0 to use the new interface. * io/write.c ((write_real_w0): Use the new interface with fnode to access both the decimal precision and exponent widths used in build_float_string. * io/write_float.def (build_float_string): Use the passed in exponent width to calculate the used width in the case of E0. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@279828 138bc75d-0d04-0410-961f-82ee72b054a4
Re: Call to arms: testsuite failures on various targets
FX Coudert wrote: wrt to the Subject of the mail, I'm not sure "Call to arms" means what I thought it meant, after all... I really wanted it to sound like "call for help" or "call for more arms". Sorry if there was any confusion in the tone. FX I thought it was great! Jerry
Typo in man page (atanh)
The following from man atanh has an error. Should not refer tp acosh() DESCRIPTION The atanh() function calculates the inverse hyperbolic tangent of x; that is the value whose hyperbolic tangent is x. If the absolute value of x is greater than 1.0, acosh() returns not-a-number (NaN) and errno is set. Does anyone know where this is created. Regards, Jerry
Re: Someone broke bootstrap with gfortran, again!
Steve Kargl wrote: Does this look familiar to anyone? I was having troubles doing a build after a cvs update. I had to delete everything in the build directory and rerun configure and then it would build ok. Not sure its the same problem you are seeing, but it happened today. I am running on i686-pc-linux-gnu. Jerry
Bootstrap breakage in Fortran
There was a breakage in Fortran that has now been fixed. In case anyone runs into it. Resolved by: M gcc/fortran/ChangeLog M gcc/fortran/iresolve.c M gcc/fortran/simplify.c r241000 = 7b8ebc39f2db57dcadd8b8f22b6b7561d187c279 (refs/remotes/svn/trunk) Related to a recent patch adding COTAN function. Regards, Jerry
I see this maybe related to PR71375 ?
After a build of trunk this morning: f951: internal compiler error: in altivec_init_builtins, at config/rs6000/rs6000.c:17547 0x10da4df3 altivec_init_builtins ../../trunk/gcc/config/rs6000/rs6000.c:17547 0x10da4df3 rs6000_init_builtins ../../trunk/gcc/config/rs6000/rs6000.c:16823 0x102c8797 gfc_init_builtin_functions ../../trunk/gcc/fortran/f95-lang.c:1244 0x102cb5f7 gfc_create_decls ../../trunk/gcc/fortran/f95-lang.c:181 0x102cb5f7 gfc_be_parse_file ../../trunk/gcc/fortran/f95-lang.c:197 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. On Using built-in specs. COLLECT_GCC=gfc COLLECT_LTO_WRAPPER=/home/jerryd/gcc/usr/libexec/gcc/powerpc64le-unknown-linux-gnu/7.0.0/lto-wrapper Target: powerpc64le-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/home/jerryd/gcc/usr --enable-languages=c,c++,fortran --disable-libmudflap --enable-libgomp --disable-bootstrap Thread model: posix gcc version 7.0.0 20161021 (experimental) (GCC) On gcc112 , compile farm, Fedora release 21 (Twenty One) Jerry
Breakage on trunk, a fix
I had to do this to get my build to work.
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5d96e5fd..140ff807 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2196,7 +2196,7 @@ continues.
@itemx --with-target-bdw-gc-lib=@var{list}
Specify search directories for the garbage collector header files and
libraries. @var{list} is a comma separated list of key value pairs of the
-form @samp{@var{multilibdir}@=@var{path}}, where the default multilib key
+form @samp{@var{multilibdir}=@var{path}}, where the default multilib key
is named as @samp{.} (dot), or is omitted (e.g.
@samp{--with-target-bdw-gc=/opt/bdw-gc,32=/opt-bdw-gc32}).
The error was:
../../trunk/gcc/doc/install.texi:2199: use braces to give a command as an
argument to @=
make[2]: *** [doc/gccinstall.info] Error 1
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2
I do not know who is to fix.
Regards
Jerry
Re: Removing an output file when test case has terminate
On 03/29/2015 04:50 AM, Janne Blomqvist wrote:
On Sun, Mar 29, 2015 at 2:28 PM, Thomas Koenig wrote:
I want to add a test case to the gfortran testsuite for PR 65563.
If all goes right, running the test case will
a) terminate the program with an error message (to be checked for)
b) create a file, which needs to be cleaned up after the test case
is run.
a) is clear, but how do I do b)? I haven't found anything in the
list of dg-final actions for this. (Due to the specifics of the test
case, I also cannot name my file "foo.mod" and let the automatic module
cleanup do the job for me :-)
Any ideas?
What I did for PR 64770, were the testcase created a file
"pr64770test.dat", was to add a line
! { dg-final { remote_file build delete "pr64770test.dat" } }
to the end of the testcase. See gfortran.dg/open_new_segv.f90 for the
whole testcase.
Don't know if this is the correct way to do it, but it seems to work.
You can also try:
open(10, status="scratch")
It will be deleted when closed. Also on failed test, instead of calling abort,
use STOP 500 or similar. STOP will close files.
Jerry
Is trunk now open for regular patches?
I see trunk is bumped to Version 6 now. Are we in Stage 1? Jerry
Re: RFC: Followup to PR91593
Copying gcc list for additional thoughts on a possible bogus warning.
On 9/29/19 9:02 AM, Jerry DeLisle wrote:
Hi all,
--- snip ---
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 4ef35561fdd..fc046efbe34 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1031,7 +1031,7 @@ btoa_big (const char *s, char *buffer, int len,
GFC_UINTEGER_LARGEST *n)
else
{
const char *p = s + len - 1;
- for (i = 0; i < len; i++)
+ for (i = 0; i < len - 1; i++)
{
char c = *p;
--- snip ---
The first attempt to fix (above) is completely off. I have tried various
combinations of code changes and I am beginning to think the warning is bogus:
In function ‘btoa_big’,
inlined from ‘write_b’ at ../../../trunk/libgfortran/io/write.c:1217:11:
../../../trunk/libgfortran/io/write.c:1052:6: warning: writing 1 byte into a
region of size 0 [-Wstringop-overflow=]
1052 | *q = '\0';
| ~~~^~
Using gdb I have watched the pointer address stored in q and the setting of the
string of bytes doing the binary to ascii conversion. I have also checked the
length of the buffer being used and its is what I would expect with length of 129.
However, the warning only goes away if I add an additional 8 bytes to the buffer
(suspicious).
So doing the following eliminates the warning:
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 4ef35561fdd..fd0e46851e4 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1204,7 +1204,7 @@ void
write_b (st_parameter_dt *dtp, const fnode *f, const char *source, int len)
{
const char *p;
- char itoa_buf[GFC_BTOA_BUF_SIZE];
+ char itoa_buf[GFC_BTOA_BUF_SIZE + 8];
GFC_UINTEGER_LARGEST n = 0;
if (len > (int) sizeof (GFC_UINTEGER_LARGEST))
Any suggestions? I am certainly not seeing it.
Regards,
Jerry
Re: RFC: Followup to PR91593
On 10/1/19 12:40 PM, Martin Sebor wrote: On 9/30/19 9:40 PM, Jerry DeLisle wrote: Copying gcc list for additional thoughts on a possible bogus warning. On 9/29/19 9:02 AM, Jerry DeLisle wrote: --- snip --- In case it helps, the warning is for the access: # .MEM_68 = VDEF <.MEM_71> MEM[(char *)_86] = 0; where _86 is set to _86 = &itoa_buf + _43; and _43 has the range [136, 17179869176]. (The warning needs to be enhanced a bit to mention the accessed object in this case.) itoa_buf's DECL_SIZE_UNIT evaluates to 129. The call to btoa_big in write_b: p = btoa_big (source, itoa_buf, len, &n); is made with len > 16. If len > sizeof itoa_buf / 8 then it does look like btoa_big would write past the end of itoa_buf because it writes len * 8 bytes into it. I don't know if the function can be called with len that large but if not, adding this just above the call suppresses the warning. if (len > sizeof itoa_buf / 8) __builtin_unreachable (); Martin Thanks Martin, this does help me understand why the warning. Yes, len cannot be greater than 16. I decided to just use memset in write_b where the buffer is created to avoid the assignment that triggers the warning. Your suggestion may likewise work. In my comments describing the warning as bogus, by bogus, I mean "not applicable" to the situation. I notice many warnings flying by when building gcc/gfortran. My preference would be to clear as many off as possible so that we can actually notice warnings when they are applicable and not miss them among a crowd of warnings. I don't know if this makes sense to anyone and I do appreciate your response. Jerry
[patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
The attached patch introduces an installation script and support structure to
build OpenCoarrays using mpich, allowing multi-image gfortran, (latest Fortran
standards).
This patch is preliminary and intended to allow testing and comments to start.
I would like to get this into gcc 7 release as a manually invoked script. Later,
in gcc 8, I would like to modify such that it is automatically invoked right
after gfortran and libgfortran are installed, ie end of make install. (assuming
this approach is acceptable to the community)
The manual script is invoked with libgfortran as the current working directory
and passing to it the location of the just installed gfortran installation
directory. This is done to ensure OpenCoarrays uses the just installed gfortran
and gcc for compilation. A typical invocation is:
mk-multi-image/mk-multi-image.sh --install-prefix /home/jerry/dev/usr
At least on Fedora 25, one must use 'module load mpi' before invoking the script
to set things up to find an existing mpich installation. The intent will be to
build mpich if it is not found by the script.
The script uses portions of Bash 3 Boilerplate which are under MIT license.
These are separated out into the use-case subdirectory.
The OpenCoarrays tarball is downloaded from the github repository, sha256sum
checked, unpacked, and built in a temporary folder. The boiler plate provides
quite a few options for setting installation parameters.
The build requires cmake/make and runs tests using ctest. There are currently 4
coarray test failures that are known issues being actively worked.
The installation places libcaf_mpi.a in the install-prefix lib directory and
executables, caf and cafrun, in the bin directory.
TODO:
1. Change name of 'use-case' directory to 'utilities' to clarify its function.
2. Set tracked versus untracked downloads before release of the script.
Currently this is set to false to avoid artificially inflating download
statistics on github during testing. Simplify the code for this
tracked/untracked feature.
3. Move the usage text file into the 'utility' directory.
4. Address both lib and lib64 versions of the library and where they are
installed.
5 Test and refine the finding and using/building mpich. We used mpich only as a
first implementation. Our intent will be to add other alternative communication
libraries in the future. (Will be testing on a Cray machine and others as made
available)
4. Resolve any issues/comments identified during this RFC phase.
Your comments are welcome. This is a first step in full integration of
multi-image coarrays into gfortran.
Regards,
Jerry
diff --git a/libgfortran/mk-multi-image/mk-multi-image.sh b/libgfortran/mk-multi-image/mk-multi-image.sh
new file mode 100755
index 000..def8032
--- /dev/null
+++ b/libgfortran/mk-multi-image/mk-multi-image.sh
@@ -0,0 +1,246 @@
+#!/usr/bin/env bash
+
+# Copyright (C) 2017 Free Software Foundation, Inc.
+# Contributed by Jerry DeLisle in collaboration with Damian Rousan.
+#
+# This file is part of the GNU Fortran runtime library (libgfortran).
+#
+# Libgfortran is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# Libgfortran is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# Under Section 7 of GPL version 3, you are granted additional
+# permissions described in the GCC Runtime Library Exception, version
+# 3.1, as published by the Free Software Foundation.
+
+# You should have received a copy of the GNU General Public License and
+# a copy of the GCC Runtime Library Exception along with this program;
+# see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
+# <http://www.gnu.org/licenses/>.
+
+# mk-multi-image.sh
+#
+# --- This script downloads and installs OpenCoarrays to directly support mult-image
+# execution in libgfortran. Execute this script the last step of the libgfortran
+# make install.
+
+# Portions of this script derive from or call sub-scripts of BASH3 Boilerplate. See
+# the B3B_USE_CASE subdirectory for the substantial portions of the Software and the
+# required permission notices of the MIT License (MIT).
+
+
+export LIBGFORTRAN_SRC_DIR="${LIBGFORTRAN_SRC_DIR:-${PWD%/}}"
+if [[ ! -d "${LIBGFORTRAN_SRC_DIR}/caf" ]]; then
+ echo "File not found: ${LIBGFORTRAN_SRC_DIR}/caf"
+ echo "Please run this script inside the libgfortran source directory or "
+ echo "set LIBGFORTRAN_SRC_DIR to the libgfortran source directory path."
+ exit 1
+fi
+export B3B_USE_CASE="${B3B_USE_CASE:-${LIBGFORTRAN_SRC_DIR}/mk-multi-image/use
Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
On 01/26/2017 05:25 AM, FX wrote: > Hi Jerry, > > A few questions: > > - why mpich? doesn’t opencoarrays support any MPI implementation? We picked it as one that I had available and only as a starting point, we plan to add support for other libraries as we go. (OpenCoarrays itself does support other libraries) > - I am a bit surprised by the complexity of the script… couldn’t we provide > a Makefile for opencoarrays, to be compatible with our other build > requirements? I agree, this script is using Boiler Plate which allows a lot of flexibility and provides some diagnostics and handling of script errors. It builds on things the OpenCoarrays team is familiar with and was the quickest way to go initially. My first draft script was about 50 lines with comments, but it had no error checks. I will be able to reduce what you see when I narrow down to one tracked release package. > - do we want to work towards seamless implementation of coarrays into > gfortran, or coexistence as a separate package (as is currently the case, for > example in Mac Homebrew, where it ships as a separate — but compatible — > package)? I think we do want to head toward seamless. I have explored even copying the source directly into the caf directory of libgfortran and merging the .h files, but this takes some time to do and would leave two sets of sources to maintain. Regarding things like Homebrew, or rpm packages, it will require us to learn how to do these packages which none of us know right now. Ultimately, since multi images is part of the Fortran language, it should just happen transparently with the gcc regular build process. Jerry
Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
On 01/28/2017 03:22 AM, FX wrote: > Hi Damian, > >> It would be difficult or impossible for several OpenCoarrays >> developers to contribute without OpenCoarrays remaining separate for >> several reasons. > > No, I understand that. What I meant is: do want to provide seamless > integration, so that libgfortran builds would automatically detect if an MPI > environment is available, and if so build opencoarrays. The only “hard" > dependency is whether we have an mpicc, it seems. > > However, the big issue is that of build-time requirements, which are not > compatible with GCC: opencoarrays depends on cmake and bash, so it is in that > respect very different from GMP and MPFR, which do not have stricter > requirement than GCC itself. > > I’ve started today to look at the OpenCoarrays source, and I admit I am quite > lost… it seems that the build machinery is much larger than the source > itself. Technically, it seems doable to OpenCoarrays a “Makefile.gfortran” > that would build OpenCoarrays, without the need for bash or cmake. Does this > sound right to you? > > >>> Ultimately, since multi images is part of the Fortran language, it should >>> just >>> happen transparently with the gcc regular build process. >> >> We’re all in agreement here so hopefully Jerry’s submission will be >> approved. > > Currently, I don’t think we can integrate it in this form, due to build > requirements. Maybe the threshold is lower for integrating it into GCC’s > contrib scripts directory? > > FX > The script could certainly be part of the contrib scripts which use bash. On Fedora as an example there are gcc-gfortrn packages and mpich packages, ideally the package maintainers of gcc/gfortran could easily include libcaf-mpi, caf, and cafrun in the package. Or, of course a separate package could be developed. Whoever does the package could simply use the script to generate the targets. I have not encountered a system without cmake yet, I did test the script with my cmake missing to confirm that it does actually build cmake if needed before it proceeds, and then uses make. We have bash scripts already in libgfortran that get invoked either during configuration or by build. I don't see any real strong argument to not invoke the script with our make install as a normal process, perhaps with a --enable-opencoarrays during configuration. I would see that as a next phase after gcc7, in gcc8. Also keep in mind we have target systems that do not use the common software packaging methods and must rely on the gcc/gfortran build method, so this script is a way to "integrate" with minimal effect on gfortran source. It is in its own subdirectory, isolated from everything else and for gcc7 only manually invoked. This gets it out there, gets exposure, and gets it further tested. Since my original post, I have significantly cleaned up the script and have been testing on several platforms. I will post the cleaned up script later today. Jerry
Fwd: [patch, contrib] Add support to install libcaf-mpi for multi-image coarray Fortran
I forgot to copy gcc list for this request for comments and approval to commit.
Regards,
Jerry
Forwarded Message
Subject: [patch, contrib] Add support to install libcaf-mpi for multi-image
coarray Fortran
Date: Wed, 15 Feb 2017 22:20:49 -0800
From: Jerry DeLisle
To: GCC Patches , fort...@gcc.gnu.org
The attached patch adds a new subdirectory called mk-libcaf-multi under contrib
which contains scripts which will download OpenCoarrays, build libcaf-mpi.a, and
install it in the user provided --install-prefix.
As given the script is only manually executed by a user interested in doing so.
Eventually we would like to fully integrate the build of libcaf-mpi into gcc to
provide full multi-image support for gfortran. These scripts provide an
intermediate means of doing so, bringing gfortran pretty close to full Fortran
2008 and 2015 standards.
Providing this will greatly expand user testing and development of gfortran
based CoArray Fortran (CAF) and simplify for users enabling this modern feature.
Tested on linux-x86-64 (Fedora 25) and MAC Darwin. Requires the user to
previously have installed mpich for the mpi library. The build uses cmake and
bash 3 scripts to enable a lot of useful argument checking and diagnostics.
For those not familiar with Coarrays in Fortran and want or need to explore
these advanced features, using this script is a very helful way to get started.
Others may chime in with comments or questions.
OK for trunk?
Regards,
Jerry
diff --git a/contrib/mk-libcaf-multi/mk-libcaf-multi.sh b/contrib/mk-libcaf-multi/mk-libcaf-multi.sh
new file mode 100755
index 000..753b035
--- /dev/null
+++ b/contrib/mk-libcaf-multi/mk-libcaf-multi.sh
@@ -0,0 +1,269 @@
+#!/usr/bin/env bash
+
+# Copyright (C) 2017 Free Software Foundation, Inc.
+# Contributed by Jerry DeLisle in collaboration with Damian Rousan.
+#
+# This file is part of the GNU Fortran runtime library (libgfortran).
+#
+# Libgfortran is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# Libgfortran is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# Under Section 7 of GPL version 3, you are granted additional
+# permissions described in the GCC Runtime Library Exception, version
+# 3.1, as published by the Free Software Foundation.
+
+# You should have received a copy of the GNU General Public License and
+# a copy of the GCC Runtime Library Exception along with this program;
+# see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
+# <http://www.gnu.org/licenses/>.
+
+# mk-multi-image.sh
+#
+# --- This script downloads and installs OpenCoarrays to directly support mult-image
+# execution in libgfortran. Execute this script the last step of the libgfortran
+# make install.
+
+# Portions of this script derive from or call sub-scripts of BASH3 Boilerplate. See
+# the B3B_USE_CASE subdirectory for the substantial portions of the Software and the
+# required permission notices of the MIT License (MIT).
+
+
+export LIBGFORTRAN_SRC_DIR="${LIBGFORTRAN_SRC_DIR:-${PWD%/}}"
+if [[ ! -d "${LIBGFORTRAN_SRC_DIR}/caf" ]]; then
+ echo "File not found: ${LIBGFORTRAN_SRC_DIR}/caf"
+ echo "Please run this script inside the libgfortran source directory or "
+ echo "set LIBGFORTRAN_SRC_DIR to the libgfortran source directory path."
+ exit 1
+fi
+export B3B_USE_CASE="${B3B_USE_CASE:-${LIBGFORTRAN_SRC_DIR}/../contrib/mk-libcaf-multi/utils}"
+if [[ ! -f "${B3B_USE_CASE:-}/bootstrap.sh" ]]; then
+ echo "Please set B3B_USE_CASE to the bash3boilerplate utils directory path."
+ exit 2
+else
+ source "${B3B_USE_CASE}/bootstrap.sh" "$@"
+fi
+
+# Set expected value of present flags that take no arguments
+export __flag_present=1
+
+if [[ "${arg_D}" == "${__flag_present}" || "${arg_L}" == "${__flag_present}" || "${arg_U}" == "${__flag_present}" || ${arg_V}"" == "${__flag_present}" ]]; then
+ print_debug_only=7
+ if [ "$(( LOG_LEVEL < print_debug_only ))" -ne 0 ]; then
+ debug "Supressing info and debug messages: -v present."
+ suppress_info_debug_messages
+#export LOG_LEVEL=5
+ fi
+fi
+
+# If one of the --print-* arguments is present (or its single-letter equivalanet), we
+# print its value and exit normally. Here we print with echo instead of a B3B function u
+# because the output might be used in an assignment to a variable in another script e.g.,
+# version=`mk-multi-image.sh -V`
+
+if [[ "${arg_L}" == &quo
Re: Warning annoyances in list_read.c
On 03/26/2017 11:45 AM, Steve Kargl wrote: > On Sun, Mar 26, 2017 at 11:27:59AM -0700, Jerry DeLisle wrote: >> >> +#pragma GCC diagnostic push >> +#pragma GCC diagnostic ignored "-Wimplicit-fallthrough" > > IMNSHO, the correct fix is to complain loudly to whomever > added -Wimplicit-fallthrough to compiler options. It should > be removed (especially if is has been added to -Wall). > > You can also probably add -Wno-implicit-fallthrough to > libgfortran/configure.ac at > > # Add -Wall -fno-repack-arrays -fno-underscoring if we are using GCC. > if test "x$GCC" = "xyes"; then > AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays > -fno-underscoring" > Problem I have is I don't know who to complain to. I think there is a bit of a glass wall going on here anyway, so what would be the point of complaining if the retrievers of the message all have the ON-OFF switch in the OFF position. (After all, I do not have a PHD, I am not a computer science graduate, why bother looking down ones nose at a low life such as myself, OMG its an engineer, what the hell does he know.) Maybe these warnings are being turned on as a matter of policy, but truth is, when I build 50 times a day, the warnings flying by are masking the errors or other warnings that may be important. For example, I inadvertently passed a ptr to a function rather than the *ptr. The warning that ensued flew by mixed in with all the other crap warnings and I did not see it. That cost me wasted cycle time (remember, I am not an expert and should not be expected to see such things. Hell, for that matter I should not even be doing any of this work. :) Cheers everybody, its been dark and gray all day. Jerry
New prerequisites to support multi image COARRAY in gfortran
Gerald, (or who does this) Since shared memory parallel programming with Fortran is now a Standard feature of the language, we would like to support full parallelism through the use of mpich and OpenCorrays. We choose mpich as a default only because it is very stable. We choose OpenCoarrays because it works well with gfortran and the developers have also supported significant portions of the gfortran frontend (not to mention that it is the only such library available). Choosing these as defaults for gfortran does not exclude any user from using any other libraries in the future since the final connection occurs at link time when a user compiles with -fcoarray=lib. In order to support testing of installation of the new packages we are requesting that the package tarballs be placed on the gcc.gnu.org along with the other gcc prerequisite packages here: ftp://gcc.gnu.org/pub/gcc/infrastructure/ There will be two stable released packages with appropriate shasum information to be added. I can provide the links to those packages for download or send them to you directly. Requesting approval for this first step. (Later steps (more than one) will provide patches for review of the contrib/download_prerequisites script. Another step will be modifying OpenCoarrays build structure to align with the Gnu/gcc build process. I believe mpich is already suitable, but will be testing.) Is this OK? Regards, Jerry
Re: New prerequisites to support multi image COARRAY in gfortran
On 04/04/2017 10:44 AM, FX wrote: >> We choose mpich as a default only because it is very stable. > > Why are why tying ourselves to one MPI implementation? > > FX > Not tying ourselves at all. This just gives users who install gcc manually with the ./configure process a default to use and only if they are using the download prerequisites script which is optional. Distributions can still provide multiple choices with package managers. The final tie is at link time where a user may specify any compatible library they choose. We do have a base of users who do not use package managers by the way. So the goal is a minimal installation of a fully functional Fortran. Jerry
Testing on Ryzen - Re: [patch, libfortran] AMD-specific versions of library matmul
GCC folks, if possible could someone install the dejagnu machinery on the Ryzen machines on the compile farm? Not sure who to ask. On 05/25/2017 07:29 AM, Thomas Koenig wrote: Hi Jerry, Yes, OK. Maybe test Ryzen first? Sure, I can wait for a bit :-) I just confirmed access to the Ryzen machines so I plan to get set up and test there. I have had access for some time now. I did not realize they had a few Ryzen machines now. I got right in. Of course they do not have all the prerequisites installed on the machine so I used contrib/download_prerequsites and the build completed fine. Next issue is they do not have the dejagnu machinery on the machine either so we need to get someone to install that unless there is a contrib script that will do the trick. (or maybe I am doing something wrong, make check did not work) In the meantime I will get the patch applied and test with our timing routines. Jerry
GCC server write access
Can I get the contact info for someone who has write access to: ftp://gcc.gnu.org/pub/gcc/infrastructure/ I would like to add two files there for testing of some patches to integrate OpenCoarrays into gfortran build. Help will be much appreciated. We need this to start testing. Regards, Jerry
Re: Strange commit from fortran-dev branch
On 06/05/2011 12:17 PM, H.J. Lu wrote: Hi, Your commit: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00145.html includes some bogus entries: trunk/gcc/go/gofrontend/expressions.cc.merge-left.r167407 trunk/gcc/go/gofrontend/expressions.cc.merge-right.r172891 trunk/gcc/go/gofrontend/expressions.cc.working trunk/gcc/go/gofrontend/go.cc.merge-left.r167407 trunk/gcc/go/gofrontend/go.cc.merge-right.r172891 trunk/gcc/go/gofrontend/go.cc.working trunk/gcc/go/gofrontend/gogo-tree.cc.merge-left.r167407 trunk/gcc/go/gofrontend/gogo-tree.cc.merge-right.r172891 trunk/gcc/go/gofrontend/gogo-tree.cc.working trunk/gcc/go/gofrontend/gogo.cc.merge-left.r167407 trunk/gcc/go/gofrontend/gogo.cc.merge-right.r172891 trunk/gcc/go/gofrontend/gogo.cc.working trunk/gcc/go/gofrontend/gogo.h.merge-left.r167407 trunk/gcc/go/gofrontend/gogo.h.merge-right.r172891 trunk/gcc/go/gofrontend/gogo.h.working trunk/gcc/go/gofrontend/parse.cc.merge-left.r167407 trunk/gcc/go/gofrontend/parse.cc.merge-right.r172891 trunk/gcc/go/gofrontend/parse.cc.working trunk/gcc/go/gofrontend/parse.h.merge-left.r167407 trunk/gcc/go/gofrontend/parse.h.merge-right.r172891 trunk/gcc/go/gofrontend/parse.h.working trunk/gcc/go/gofrontend/statements.cc.merge-left.r167407 trunk/gcc/go/gofrontend/statements.cc.merge-right.r172891 trunk/gcc/go/gofrontend/statements.cc.working trunk/gcc/go/gofrontend/statements.h.merge-left.r167407 trunk/gcc/go/gofrontend/statements.h.merge-right.r172891 trunk/gcc/go/gofrontend/statements.h.working trunk/gcc/go/gofrontend/types.cc.merge-left.r167407 trunk/gcc/go/gofrontend/types.cc.merge-right.r172891 trunk/gcc/go/gofrontend/types.cc.working trunk/gcc/go/gofrontend/unsafe.cc.merge-left.r167407 trunk/gcc/go/gofrontend/unsafe.cc.merge-right.r172891 trunk/gcc/go/gofrontend/unsafe.cc.working Can you fix it? Thanks. H.J. I am working on it. Both the gcc/go and libgo directories had numerous conflicts during merge even though we never touch those directories for gfortran. Why it would add those I have no idea. At the time of my commit there were no conflicts showing. Regardless, I will clean it up as I go here. The goal is to get gcc/fortran and libgfortran on the branch up to date with trunk. Jerry Jerry
Re: Strange commit from fortran-dev branch
On 06/05/2011 01:58 PM, H.J. Lu wrote: On Sun, Jun 5, 2011 at 12:17 PM, H.J. Lu wrote: Hi, Your commit: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00145.html includes some bogus entries: trunk/gcc/go/gofrontend/expressions.cc.merge-left.r167407 trunk/gcc/go/gofrontend/expressions.cc.merge-right.r172891 trunk/gcc/go/gofrontend/expressions.cc.working trunk/gcc/go/gofrontend/go.cc.merge-left.r167407 trunk/gcc/go/gofrontend/go.cc.merge-right.r172891 trunk/gcc/go/gofrontend/go.cc.working trunk/gcc/go/gofrontend/gogo-tree.cc.merge-left.r167407 trunk/gcc/go/gofrontend/gogo-tree.cc.merge-right.r172891 trunk/gcc/go/gofrontend/gogo-tree.cc.working trunk/gcc/go/gofrontend/gogo.cc.merge-left.r167407 trunk/gcc/go/gofrontend/gogo.cc.merge-right.r172891 trunk/gcc/go/gofrontend/gogo.cc.working trunk/gcc/go/gofrontend/gogo.h.merge-left.r167407 trunk/gcc/go/gofrontend/gogo.h.merge-right.r172891 trunk/gcc/go/gofrontend/gogo.h.working trunk/gcc/go/gofrontend/parse.cc.merge-left.r167407 trunk/gcc/go/gofrontend/parse.cc.merge-right.r172891 trunk/gcc/go/gofrontend/parse.cc.working trunk/gcc/go/gofrontend/parse.h.merge-left.r167407 trunk/gcc/go/gofrontend/parse.h.merge-right.r172891 trunk/gcc/go/gofrontend/parse.h.working trunk/gcc/go/gofrontend/statements.cc.merge-left.r167407 trunk/gcc/go/gofrontend/statements.cc.merge-right.r172891 trunk/gcc/go/gofrontend/statements.cc.working trunk/gcc/go/gofrontend/statements.h.merge-left.r167407 trunk/gcc/go/gofrontend/statements.h.merge-right.r172891 trunk/gcc/go/gofrontend/statements.h.working trunk/gcc/go/gofrontend/types.cc.merge-left.r167407 trunk/gcc/go/gofrontend/types.cc.merge-right.r172891 trunk/gcc/go/gofrontend/types.cc.working trunk/gcc/go/gofrontend/unsafe.cc.merge-left.r167407 trunk/gcc/go/gofrontend/unsafe.cc.merge-right.r172891 trunk/gcc/go/gofrontend/unsafe.cc.working Can you fix it? I checked in this patch: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00150.html to revert it. OK thanks, I still see some local conflicts on libstd++ so i am going to delete/clean the local tree and recheckout and see where we are. Thanks, Jerry
Re: Strange git commit on master branch in gcc git mirror
On 06/06/2011 04:40 AM, Richard Guenther wrote: On Mon, Jun 6, 2011 at 12:14 PM, Tobias Burnus wrote: On 06/06/2011 11:47 AM, Richard Guenther wrote: Looks like an accident, modifying both trunk and branches/fortran-dev. But the git mirror splits it between the trunk and fortran-dev branches. Jerry, can you fix it up please? This has been fixed else thread (cf. "Strange commit from fortran-dev branch") by HJ's commit: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00150.html (The question are: Why does "svn merge" produce merge errors for directories/files untouched in the branch? libgo was never modified in "fortran-dev" and should thus match the trunk to 100%. I also do not quite understand how a merge of the trunk into a branch via "svn merge; svn commit" can create files in the trunk.) You probably didn't branch the whole tree on fortran-dev? This way you have a partial branch/trunk checkout and I guess svn merge is just confused when you merge from trunk to trunk. So, don't branch in a way that a checkout produces a mix of branch/trunk. This whole thing has me puzzled. The branch was created before go and libgo existed on trunk. Then I did a plain vanilla merge and got a whole bunch of tree conflicts just for those two directories. Then I attempted to manually resolve those tree conflicts. So Tobias question remains open. Since yesterday after HJ fixed up, I deleted the whole local fortran-dev branch and did a clean checkout of fortran-dev. I have now done another plain vanilla merge of trunk into my local fortran-dev and again I get tree conflicts for go and libgo. I have proceeded to one by one resolve these by copying over the current trunk file. In some cases I have to do an svn add, other places I have to do svn resolve. I have never had to do this before, so I am sorry if I am messing up, The tree conflicts just "appeared" out of nowhere. I see also see about 4 files in libstd++ showing this now. After this cleanup I plan to commit to fortran-dev again and hope we are OK. I am open to suggestions. Jerry
[gcc-in-cxx] zlib?
Hi. I started looking at what it would take to convert zlib to build with c++. First off, it's not GPL. Are there any issues with modifying the code checked into the tree? Next, it uses automake, which seems to assume that a .c file should be compiled with CC, and not CXX. I get the impression we need to subvert automake to get this to happen. Any thoughts? Jerry
Re: [gcc-in-cxx] zlib?
On Wed, 2009-07-15 at 19:07 -0700, Ian Lance Taylor wrote: > Jerry Quinn writes: > > > Hi. I started looking at what it would take to convert zlib to build > > with c++. > > The zlib library in gcc is actually a copy of upstream sources, so I > don't think it would be a good idea to make this change. We should stay > as close to the upstream source as possible. I figured this was probably the case, hence asking before I did too much work :-) It does mean that we will always have to have c++ and c available to bootstrap. Was one of the goals to remove the need for a host C compiler? Meanwhile, I'm working on libdecnumber... Jerry
enable-build-with-cxx bootstrap compare broken by r149964
Hi, folks, Building with --enable-build-with-cxx fails to bootstrap as follows: Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_alloc.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/vec.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_globals.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/guard.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/mt_allocator.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/locale.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/pool_allocator.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/basic_file.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/system_error.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/locale_init.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/debug.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/mt_allocator.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/locale.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/pool_allocator.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/basic_file.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/system_error.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/locale_init.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/debug.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/atomic.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/atomic.o differs x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_alloc.o differs x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/vec.o differs x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_globals.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/mt_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/locale.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/pool_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/basic_file.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/system_error.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/locale_init.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/debug.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/mt_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/pool_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/basic_file.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/system_error.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale_init.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/debug.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/future.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/atomic.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/future.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/atomic.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/jlquinn/gcc/dev/build/trunk-cxx' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/jlquinn/gcc/dev/build/trunk-cxx' make: *** [all] Error 2 jlqu...@cerberus:~/gcc/dev/build/trunk-cxx$ After bisecting the svn repository, I tracked the problem down to r149964: XXX Try C++ bootstrap here FAIL r149964 | jason | 2009-07-22 19:03:22 -0400 (Wed, 22 Jul 2009) | 8 lines * mangle.c (mangle_type_string_for_rtti): Rename to be clearer. (needs_fake_anon): New. (write_name): Check it. (write_nested_name): Add a fake anonymous namespace scope if true. * name-lookup.c (get_anonymous_namespace_name): No longer static. * rtti.c, cp-tree.h: Adjust. * libsupc++/typeinfo (__GXX_MERGED_TYPEINFO_NAMES): Default to 0. XXX Try C++ bootstrap here SUCCESS r149962 | vmakarov | 2009-07-22 18:00:17 -0400 (Wed, 22 Jul 2009) | 22 lines 2009-07-22 Vladimir Makarov PR target/37488 * ira-lives.c (bb_has_abnormal_call_pred): New function. (process_bb_node_lives): Use it. Can someone take a look at this please? I came across this while trying to solve why enable-build-with-cxx didn't build on Fedora 11. (I have a patch, but I was waiting to track this down first). Having checked in some of the configure patches for it, I thought I should isolate the actual broken checkin to make sure it wasn't me :-) Thanks, Jerry
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Mon, 2009-08-17 at 16:16 -0400, Jason Merrill wrote: > On 08/15/2009 10:12 AM, Jerry Quinn wrote: > > Bootstrap comparison failure! > >[...] > > (write_nested_name): Add a fake anonymous namespace scope if > > true. > > What I assume is going on here is that use of anonymous namespaces can > break bitwise comparison, because get_file_function_name uses a random > number if it doesn't know a non-weak symbol to use in the name. > > One thing that would help would be to defer all mangling, or at least > all mangling that depends on the anonymous namespace name, until end of > file so that first_global_object_name is usually set. > > I'm not sure why GCC sources would need to mangle function-local > structs, though. I'm not sure if the following is relevant, but I found it in cp/mangle.c: /* Since we now use strcmp to compare typeinfos on all targets because of the RTLD_LOCAL problem, we need to munge the typeinfo name used for local classes of static functions to fix g++.dg/abi/local1.C. We do that by pretending that the function is in an anonymous namespace. */ static bool needs_fake_anon (const_tree decl) Jery
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Tue, 2009-08-18 at 08:43 -0700, Richard Henderson wrote:
> On 08/17/2009 07:40 PM, Jerry Quinn wrote:
> > On Mon, 2009-08-17 at 16:16 -0400, Jason Merrill wrote:
> >> I'm not sure why GCC sources would need to mangle function-local
> >> structs, though.
> >
> Would it be helpful to reserve a leading character (say, "*") that means
> that strcmp should not apply, but rather pointer identity? Thus a class
> foo that is intended to be local, as opposed to forced local via
> RTLD_LOCAL, can just use "*foo" and not have to bother with mangling?
I took a (very naive) swing at implementing this. I made the change in
my copy of r149964 to avoid the possibility of other issues interfering.
Apparently my change is too naive, because the assembler doesn't like a
name with '*' in it. Are there any chars that can pass muster with
assemblers but not be a valid namespace identifier?
The patch I tried is below.
Thanks,
Jerry
libtool: compile: /home/jlquinn/gcc/dev/build/trunk/./gcc/xgcc
-shared-libgcc -B/home/jlquinn/gcc/dev/build/trunk/./gcc -nostdinc++
-L/home/jlquinn/gcc/dev/build/trunk/x86_64-unknown-linux-gnu/libstdc
++-v3/src
-L/home/jlquinn/gcc/dev/build/trunk/x86_64-unknown-linux-gnu/libstdc
++-v3/src/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/
-isystem /usr/local/x86_64-unknown-linux-gnu/include
-isystem /usr/local/x86_64-unknown-linux-gnu/sys-include
-I/home/jlquinn/gcc/dev/gcc-in-cxx/libstdc++-v3/../gcc
-I/home/jlquinn/gcc/dev/build/trunk/x86_64-unknown-linux-gnu/libstdc
++-v3/include/x86_64-unknown-linux-gnu
-I/home/jlquinn/gcc/dev/build/trunk/x86_64-unknown-linux-gnu/libstdc
++-v3/include -I/home/jlquinn/gcc/dev/gcc-in-cxx/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g
-O2 -D_GNU_SOURCE -c ../../../../../gcc-in-cxx/libstdc++-v3/libsupc
++/eh_alloc.cc -fPIC -DPIC -o eh_alloc.o
/tmp/ccbRNQMb.s: Assembler messages:
/tmp/ccbRNQMb.s:1384: Error: unrecognized symbol type ""
/tmp/ccbRNQMb.s:1384: Error: junk at end of line, first unrecognized
character is `*'
/tmp/ccbRNQMb.s:1385: Error: expected comma after name `_ZN12' in .size
directive
/tmp/ccbRNQMb.s:1386: Error: invalid character '*' in mnemonic
make[5]: *** [eh_alloc.lo] Error 1
Index: gcc/cp/name-lookup.c
===
--- gcc/cp/name-lookup.c(revision 149964)
+++ gcc/cp/name-lookup.c(working copy)
@@ -69,7 +69,8 @@
{
/* The anonymous namespace has to have a unique name
if typeinfo objects are being compared by name. */
- anonymous_namespace_name = get_file_function_name ("N");
+ // anonymous_namespace_name = get_file_function_name ("N");
+ anonymous_namespace_name = get_identifier ("*cxx_anon_ns");
}
return anonymous_namespace_name;
}
Index: libstdc++-v3/libsupc++/tinfo2.cc
===
--- libstdc++-v3/libsupc++/tinfo2.cc(revision 149964)
+++ libstdc++-v3/libsupc++/tinfo2.cc(working copy)
@@ -37,7 +37,9 @@
#if __GXX_MERGED_TYPEINFO_NAMES
return name () < arg.name ();
#else
- return __builtin_strcmp (name (), arg.name ()) < 0;
+ return (name ()[0] == '*' && arg.name()[0] == '*')
+? name () < arg.name ()
+: __builtin_strcmp (name (), arg.name ()) < 0;
#endif
}
Index: libstdc++-v3/libsupc++/typeinfo
===
--- libstdc++-v3/libsupc++/typeinfo (revision 149964)
+++ libstdc++-v3/libsupc++/typeinfo (working copy)
@@ -110,12 +110,15 @@
// we can run into cases where type_info names aren't merged,
// so we still need to do string comparison.
bool before(const type_info& __arg) const
-{ return __builtin_strcmp (__name, __arg.__name) < 0; }
+{ return (__name[0] == '*' && __arg.__name[0] == '*')
+ ? __name < __arg.__name
+ : __builtin_strcmp (__name, __arg.__name) < 0; }
bool operator==(const type_info& __arg) const
{
return ((__name == __arg.__name)
- || __builtin_strcmp (__name, __arg.__name) == 0);
+ || (__name[0] != '*' && __arg.__name[0] != '*' &&
+ __builtin_strcmp (__name, __arg.__name) == 0));
}
#else
// On some targets we can rely on type_info's NTBS being unique,
Index: libstdc++-v3/libsupc++/tinfo.cc
===
--- libstdc++-v3/libsupc++/tinfo.cc (revision 149964)
+++ libstdc++-v3/libsupc++/tinfo.cc (working copy)
@@ -41,7 +41,9 @@
#if __GXX_MERGED_TYPEINFO_NAMES
return name () == arg.name ();
#else
- return (&arg == this) || (__builtin_strcmp (name (), arg.name ()) ==
0);
+ return (&arg == this)
+|| (name ()[0] != '*' && arg.name ()[0] != '*'
+ && (__builtin_strcmp (name (), arg.name ()) == 0));
#endif
}
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Thu, 2009-08-20 at 11:12 +0100, Dave Korn wrote: > Jerry Quinn wrote: > > On Tue, 2009-08-18 at 08:43 -0700, Richard Henderson wrote: > >> On 08/17/2009 07:40 PM, Jerry Quinn wrote: > >>> On Mon, 2009-08-17 at 16:16 -0400, Jason Merrill wrote: > >>>> I'm not sure why GCC sources would need to mangle function-local > >>>> structs, though. > >> Would it be helpful to reserve a leading character (say, "*") that means > >> that strcmp should not apply, but rather pointer identity? Thus a class > >> foo that is intended to be local, as opposed to forced local via > >> RTLD_LOCAL, can just use "*foo" and not have to bother with mangling? > > > > I took a (very naive) swing at implementing this. I made the change in > > my copy of r149964 to avoid the possibility of other issues interfering. > > Apparently my change is too naive, because the assembler doesn't like a > > name with '*' in it. Are there any chars that can pass muster with > > assemblers but not be a valid namespace identifier? > > Don't you just want to arrange things so that the asterisk ends up in the > typeinfo name string but not in the asm name? Well, it WAS a very naive attack on the problem :-) Where can I look to set the typeinfo name without setting the asm name? Thanks, Jerry
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Thu, 2009-08-20 at 14:05 +0100, Dave Korn wrote: > Jerry Quinn wrote: > > On Thu, 2009-08-20 at 11:12 +0100, Dave Korn wrote: > >> Jerry Quinn wrote: > > >>> Apparently my change is too naive, because the assembler doesn't like a > >>> name with '*' in it. Are there any chars that can pass muster with > >>> assemblers but not be a valid namespace identifier? > >> Don't you just want to arrange things so that the asterisk ends up in the > >> typeinfo name string but not in the asm name? > > > > Well, it WAS a very naive attack on the problem :-) > > > > Where can I look to set the typeinfo name without setting the asm name? > > I think you want to just modify the NTBS name, rather than the internal > identifier used to refer to it. Take a look at tinfo_base_init() in > gcc/cp/rtti.c, and how it calls tinfo_name. OK, I'm now confused. How does this dovetail with anonymous namespaces? Richard's suggestion was to avoid mangling the name at all and relying on pointers being different to distinguish between the anonymous namespaces in different translation units. If I understand correctly, the main thing we want is for libstdc++ to consider two typeinfos the same if they are the same type in the same file's anonymous namespace, but different if they have the same name but came from different files. I'm unclear how the symbols in the asm get turned into typeinfos, and thus how the transform needs to be done. Jerry
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Thu, 2009-08-20 at 15:22 +0100, Dave Korn wrote: > Your patch puts the asterisk into the namespace identifier decl, so it ends > up in both the rtti NTBS name string, and also in the generated asm name for > the objects. What I think you need to do is use an identifier for the > anonymous namespace without an asterisk, but prefix the asterisk when > generating the corresponding NTBS name string; then your changes to the name > comparison routines in libsupc++ should work, but the typeinfo name string > won't have any funny chars in it. OK, I've gotten almost this far and can bootstrap (the asterisk is actually not the very first char and I have to figure that out). However, in the referenced test case, both typeinfos are apparently merged, thus returning the same pointer for their name strings, so pointer comparison still wouldn't work. Therefore, I guess I'll need to do the following: > You might also need to take steps to ensure that the typeinfo gets emitted > as non-COMDAT with local symbols, so that each object does indeed end up with > its own separate copy. Where should I look to do this? Thanks, Jerry
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Fri, 2009-08-21 at 15:25 -0700, Richard Henderson wrote:
> On 08/21/2009 02:37 PM, Jerry Quinn wrote:
> > OK, I've gotten almost this far and can bootstrap (the asterisk is
> > actually not the very first char and I have to figure that out).
> > However, in the referenced test case, both typeinfos are apparently
> > merged, thus returning the same pointer for their name strings, so
> > pointer comparison still wouldn't work.
> >
> > Therefore, I guess I'll need to do the following:
> >
> >>You might also need to take steps to ensure that the typeinfo gets
> >> emitted
> >> as non-COMDAT with local symbols, so that each object does indeed end up
> >> with
> >> its own separate copy.
> >
> > Where should I look to do this?
>
> First thing you should do is make sure you're emitting a VAR_DECL
> with the string contents, rather than a STRING_CST constant. The
> later will be merged within an object file within the compiler.
>
> Second, make sure the VAR_DECL for the typeinfo is no DECL_ONE_ONLY.
> That flag sets up COMDAT sections, which will be merged by the linker.
It looks like I"ve got a working patch now. It bootstraps and has no
reqressions from make check, nor from make check in the libstdc++
directory.
Any thoughts?
Jerry
2009-08-22 Jerry Quinn
* name-lookup.c (get_anonymous_namespace_name): Use fixed
namespace "cxx_anon_ns".
* mangle.c (write_nested_name): Insert '*' to mark fake anonymous
namespace.
(get_mangled_string_length): New function.
(mangle_type_string_for_rtti): Put '*' at start of mangled namestring.
* rtti.c (tinfo_base_init): Disable DECL_COMDAT for fake
anonymous namespaces.
2009-08-22 Jerry Quinn
* libsupc++/tinfo.cc (typeinfo::operator==): Compare names
starting with '*' by pointer.
* libsupc++/tinfo2.cc (typeinfo::before): Same.
* libsupc++/typeinfo (typeinfo::operator==): Same.
* libsupc++/typeinfo (typeinfo::before): Same.
Index: gcc/cp/rtti.c
===
--- gcc/cp/rtti.c (revision 151008)
+++ gcc/cp/rtti.c (working copy)
@@ -862,9 +862,12 @@
DECL_TINFO_P (name_decl) = 1;
set_linkage_according_to_type (target, name_decl);
import_export_decl (name_decl);
+/* Disable DECL_COMDAT if we have an anonymous namspace here. */
+if (TREE_STRING_POINTER (name_string)[0] == '*')
+ DECL_COMDAT (name_decl) = 0;
DECL_INITIAL (name_decl) = name_string;
mark_used (name_decl);
pushdecl_top_level_and_finish (name_decl, name_string);
2009-08-21 Jakub Jelinek
PR c++/41131
Index: gcc/cp/mangle.c
===
--- gcc/cp/mangle.c (revision 151008)
+++ gcc/cp/mangle.c (working copy)
@@ -935,8 +935,14 @@
/* No, just use */
write_prefix (DECL_CONTEXT (decl));
if (needs_fake_anon (decl))
- /* Pretend this static function is in an anonymous namespace. */
- write_source_name (get_anonymous_namespace_name ());
+ {
+ /* Add a * to mark fake anonymous namespaces in typeinfos as
+compare-by-pointer. This * is used to put another one at the
+front when done building the string. */
+ write_char ('*');
+ /* Pretend this static function is in an anonymous namespace. */
+ write_source_name (get_anonymous_namespace_name ());
+ }
write_unqualified_name (decl);
}
write_char ('E');
@@ -2755,6 +2761,14 @@
name_base = obstack_alloc (&name_obstack, 0);
}
+/* Returns the length of the mangled string array. */
+
+static inline int
+get_mangled_string_length (void)
+{
+ return obstack_object_size (mangle_obstack);
+}
+
/* Done with mangling. If WARN is true, and the name of G.entity will
be mangled differently in a future version of the ABI, issue a
warning. */
@@ -2851,13 +2865,20 @@
mangle_type_string_for_rtti (const tree type)
{
const char *result;
+ int result_len;
start_mangling (type);
/* Mangle in a fake anonymous namespace if necessary. */
fake_anon_scope = true;
+ /* Place marker to be removed if not dealing with a nested name. */
+ write_char('*');
write_type (type);
fake_anon_scope = false;
+ result_len = get_mangled_string_length ();
result = finish_mangling (/*warn=*/false);
+ /* Remove the marker if not needed. */
+ if (!strchr(result + 1, '*'))
+result++;
if (DEBUG_MANGLE)
fprintf (stderr, "mangle_type_string = '%s'\n\n", result);
return result;
Index: gcc/cp/name-lookup.c
===
--- gc
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Thu, 2009-08-27 at 00:24 -0400, Jason Merrill wrote: > On 08/15/2009 10:12 AM, Jerry Quinn wrote: > > Building with --enable-build-with-cxx fails to bootstrap as follows: > > > > Comparing stages 2 and 3 > > warning: gcc/cc1plus-checksum.o differs > > warning: gcc/cc1-checksum.o differs > > Bootstrap comparison failure! > > x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_alloc.o differs > >... > > Do you know why r149964 makes a difference? The only objects that are > listed as differing here are from libstdc++, and changing > needs_fake_anon to abort rather than return true doesn't cause any > problems building libstdc++. We used anonymous namespaces in the > library before this... I don't know. I didn't try to debug, I only did the bootstraps narrowing down the offending patch. > I tried doing the bootstrap myself, but build-with-cxx doesn't currently > work with glibc 2.10. I guess I could try on a box with an older > install, but haven't yet. The following patch solved bootstrapping for Pedro on Fedora 11. It's got the new glibc. Tackling that issue is what got me onto this one to begin with. I was holding off on submitting it because I wouldn't be able to claim that the patch bootstrapped successfully against the head of the trunk. Jerry Index: gcc/configure === --- gcc/configure (revision 149964) +++ gcc/configure (working copy) @@ -10650,8 +10650,9 @@ + for ac_func in times clock kill getrlimit setrlimit atoll atoq \ - sysconf strsignal getrusage nl_langinfo \ + sysconf strsignal getrusage nl_langinfo basename \ gettimeofday mbstowcs wcswidth mmap mincore setlocale \ clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked do @@ -12673,11 +12674,10 @@ - for ac_func in getenv atol asprintf sbrk abort atof getcwd getwd \ strsignal strstr strverscmp \ errno snprintf vsnprintf vasprintf malloc realloc calloc \ - free basename getopt clock getpagesize clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked + free getopt clock getpagesize clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked do ac_tr_decl=`echo "HAVE_DECL_$ac_func" | $as_tr_cpp` echo "$as_me:$LINENO: checking whether $ac_func is declared" >&5 Index: gcc/config.in === --- gcc/config.in (revision 149964) +++ gcc/config.in (working copy) @@ -321,6 +321,12 @@ #endif +/* Define if your assembler supports LWSYNC instructions. */ +#ifndef USED_FOR_TARGET +#undef HAVE_AS_LWSYNC +#endif + + /* Define if your assembler supports mfcr field. */ #ifndef USED_FOR_TARGET #undef HAVE_AS_MFCRF @@ -351,23 +357,18 @@ #endif -/* Define if your assembler supports popcntb instruction. */ +/* Define if your assembler supports popcntb field. */ #ifndef USED_FOR_TARGET #undef HAVE_AS_POPCNTB #endif -/* Define if your assembler supports popcntd instruction. */ +/* Define if your assembler supports POPCNTD instructions. */ #ifndef USED_FOR_TARGET #undef HAVE_AS_POPCNTD #endif -/* Define if your assembler supports lwsync instruction. */ -#ifndef USED_FOR_TARGET -#undef HAVE_AS_LWSYNC -#endif - /* Define if your assembler supports .register. */ #ifndef USED_FOR_TARGET #undef HAVE_AS_REGISTER_PSEUDO_OP @@ -430,6 +431,12 @@ #endif +/* Define to 1 if you have the `basename' function. */ +#ifndef USED_FOR_TARGET +#undef HAVE_BASENAME +#endif + + /* Define to 1 if you have the `clearerr_unlocked' function. */ #ifndef USED_FOR_TARGET #undef HAVE_CLEARERR_UNLOCKED @@ -480,13 +487,6 @@ #endif -/* Define to 1 if we found a declaration for 'basename', otherwise define to - 0. */ -#ifndef USED_FOR_TARGET -#undef HAVE_DECL_BASENAME -#endif - - /* Define to 1 if we found a declaration for 'calloc', otherwise define to 0. */ #ifndef USED_FOR_TARGET Index: gcc/configure.ac === --- gcc/configure.ac(revision 149964) +++ gcc/configure.ac(working copy) @@ -1016,7 +1016,7 @@ fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked dnl putchar_unloc
Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx
Ralf Wildenhues wrote: > * Pedro LamarÃo wrote on Thu, Aug 27, 2009 at 12:24:07AM CEST: > > 2009/8/26 Ralf Wildenhues: > > > > >> The problem is that AC_CHECK_DECLS gets confused by overloaded > > >> functions, and glibc 2.10 has overloaded declarations of basename > > >> and some other string functions for const-correctness. > > > > > > Could you show the config.log snippet that shows the failed test? > > > Is this a new error due to the autotools upgrade, or new due to > > > glibc 2.10? > > > > I think this is new in glibc 2.10, for the reasons given by Jason Merrill > > above. > > I've discussed this problem with Jerry Quinn before, and he had a > > tentative patch that worked for me. > > As I understand things, this patch is on hold waiting for a solution > > to the bootstrap comparison problem being discussed in another thread. > > > > I am waiting for a solution to these problems to continue work on the > > std::sort gcc-in-cxx subproject; keeping all these patches up to date > > with trunk is too difficult for me right now. > > Currently, I have a patch to an old revision of the trunk. > Well, can you post the patch, or did I somehow miss it on the list? > I'd be particularly interested if it tries to fix the Autoconf test > in some sensible way. Here's the patch I sent Pedro: Index: gcc/configure === --- gcc/configure (revision 149964) +++ gcc/configure (working copy) @@ -10650,8 +10650,9 @@ + for ac_func in times clock kill getrlimit setrlimit atoll atoq \ - sysconf strsignal getrusage nl_langinfo \ + sysconf strsignal getrusage nl_langinfo basename \ gettimeofday mbstowcs wcswidth mmap mincore setlocale \ clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked do @@ -12673,11 +12674,10 @@ - for ac_func in getenv atol asprintf sbrk abort atof getcwd getwd \ strsignal strstr strverscmp \ errno snprintf vsnprintf vasprintf malloc realloc calloc \ - free basename getopt clock getpagesize clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked + free getopt clock getpagesize clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked do ac_tr_decl=`echo "HAVE_DECL_$ac_func" | $as_tr_cpp` echo "$as_me:$LINENO: checking whether $ac_func is declared" >&5 Index: gcc/config.in === --- gcc/config.in (revision 149964) +++ gcc/config.in (working copy) @@ -321,6 +321,12 @@ #endif +/* Define if your assembler supports LWSYNC instructions. */ +#ifndef USED_FOR_TARGET +#undef HAVE_AS_LWSYNC +#endif + + /* Define if your assembler supports mfcr field. */ #ifndef USED_FOR_TARGET #undef HAVE_AS_MFCRF @@ -351,23 +357,18 @@ #endif -/* Define if your assembler supports popcntb instruction. */ +/* Define if your assembler supports popcntb field. */ #ifndef USED_FOR_TARGET #undef HAVE_AS_POPCNTB #endif -/* Define if your assembler supports popcntd instruction. */ +/* Define if your assembler supports POPCNTD instructions. */ #ifndef USED_FOR_TARGET #undef HAVE_AS_POPCNTD #endif -/* Define if your assembler supports lwsync instruction. */ -#ifndef USED_FOR_TARGET -#undef HAVE_AS_LWSYNC -#endif - /* Define if your assembler supports .register. */ #ifndef USED_FOR_TARGET #undef HAVE_AS_REGISTER_PSEUDO_OP @@ -430,6 +431,12 @@ #endif +/* Define to 1 if you have the `basename' function. */ +#ifndef USED_FOR_TARGET +#undef HAVE_BASENAME +#endif + + /* Define to 1 if you have the `clearerr_unlocked' function. */ #ifndef USED_FOR_TARGET #undef HAVE_CLEARERR_UNLOCKED @@ -480,13 +487,6 @@ #endif -/* Define to 1 if we found a declaration for 'basename', otherwise define to - 0. */ -#ifndef USED_FOR_TARGET -#undef HAVE_DECL_BASENAME -#endif - - /* Define to 1 if we found a declaration for 'calloc', otherwise define to 0. */ #ifndef USED_FOR_TARGET Index: gcc/configure.ac === --- gcc/configure.ac(revision 149964) +++ gcc/configure.ac(working copy)
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote: > On 09/14/2009 11:54 AM, Jason Merrill wrote: > > I think the way to go with this is to revert the compiler bits of > > r149964, not mess with mangle.c at all, and insert the initial * if the > > typeinfo name won't have TREE_PUBLIC set, since that's precisely the > > property we want to mirror in comparison. > > Thoughts? Another concern I have is that adding an initial * breaks > simple demangling of type_info::name(), so I'd like to find another way > of marking it for pointer comparison. Sorry, it took me a while to get back to this. I started an implementation following the path you described above and am trying it now. Another approach could be to use 2 different names for anonymous namespaces that should and should not be compared by pointer. I don't like the speed implications, but it might work. Jerry
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote:
> On 09/14/2009 11:54 AM, Jason Merrill wrote:
> > I think the way to go with this is to revert the compiler bits of
> > r149964, not mess with mangle.c at all, and insert the initial * if the
> > typeinfo name won't have TREE_PUBLIC set, since that's precisely the
> > property we want to mirror in comparison.
>
> Thoughts? Another concern I have is that adding an initial * breaks
> simple demangling of type_info::name(), so I'd like to find another way
> of marking it for pointer comparison.
What if we have type_info::name() be smart? I.e.
const char* name() { return name[0] == '*' ? name + 1 : name; }
Then the * can still be a flag indicating compare by pointer.
Jerry
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Tue, 2009-09-22 at 09:40 -0400, Jason Merrill wrote:
> On 09/22/2009 07:04 AM, Jerry Quinn wrote:
> > On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote:
> >> On 09/14/2009 11:54 AM, Jason Merrill wrote:
> >>> I think the way to go with this is to revert the compiler bits of
> >>> r149964, not mess with mangle.c at all, and insert the initial * if the
> >>> typeinfo name won't have TREE_PUBLIC set, since that's precisely the
> >>> property we want to mirror in comparison.
> >>
> >> Thoughts? Another concern I have is that adding an initial * breaks
> >> simple demangling of type_info::name(), so I'd like to find another way
> >> of marking it for pointer comparison.
> >
> > What if we have type_info::name() be smart? I.e.
> >
> > const char* name() { return name[0] == '*' ? name + 1 : name; }
> >
> > Then the * can still be a flag indicating compare by pointer.
>
> I like it.
I'm trying the following in cp/rtti.c, but I get a segfault compiling
testsuite/g++.dg/debug/dwarf2/pr41063.C
Removing the TREE_PUBLIC code fixes the segfault, so it's definitely
related. I also tried using an arbitrary string for name_string, but I
get the same segfault. It seems like something is expecting the name to
be exactly in synch with the decl.
I'm not really sure how everything fits together here. Am I missing
something obvious?
tinfo_base_init (tinfo_s *ti, tree target)
{
tree init = NULL_TREE;
tree name_decl;
tree vtable_ptr;
{
tree name_name;
/* Generate the NTBS array variable. */
tree name_type = build_cplus_array_type
(build_qualified_type (char_type_node, TYPE_QUAL_CONST),
NULL_TREE);
tree name_string = tinfo_name (target);
/* Determine the name of the variable -- and remember with which
type it is associated. */
name_name = mangle_typeinfo_string_for_type (target);
TREE_TYPE (name_name) = target;
name_decl = build_lang_decl (VAR_DECL, name_name, name_type);
SET_DECL_ASSEMBLER_NAME (name_decl, name_name);
DECL_ARTIFICIAL (name_decl) = 1;
DECL_IGNORED_P (name_decl) = 1;
TREE_READONLY (name_decl) = 1;
TREE_STATIC (name_decl) = 1;
DECL_EXTERNAL (name_decl) = 0;
DECL_TINFO_P (name_decl) = 1;
set_linkage_according_to_type (target, name_decl);
import_export_decl (name_decl);
if (!TREE_PUBLIC (name_decl))
{
/* Inject '*' at start of name to force pointer comparison. */
int len = TREE_STRING_LENGTH (name_string);
char* buf = (char*) XNEWVEC (char, len + 1);
buf[0] = '*';
memcpy (buf + 1, TREE_STRING_POINTER (name_string), len);
name_string = build_string (len + 1, buf);
XDELETEVEC (buf);
}
DECL_INITIAL (name_decl) = name_string;
mark_used (name_decl);
pushdecl_top_level_and_finish (name_decl, name_string);
}
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Wed, 2009-09-23 at 11:05 -0400, Jason Merrill wrote:
> On 09/23/2009 09:22 AM, Jerry Quinn wrote:
> > I'm not really sure how everything fits together here. Am I missing
> > something obvious?
>
> I notice that you're missing the fix_string_type that tinfo_name does.
> But I'd rather not duplicate the code that creates the STRING_CST;
> better to delay the call to tinfo_name and add the * there.
>
> Jason
Hi, Jason,
Sorry, it took me a while to get back to this.
Here's the latest patch I have updated to today's tree. It fixes
bootstrap, but there are a number of testsuite failures. They all
appear to plugin test failures similar to below. I don't know if this
is related to my patch or is caused by some other issue when building
with --enable-build-with-cxx.
PR 40923 is about the bootstrap problem, and I've attached the patch
there as well.
Jerry
Executing on build: gcc -g
-O2 /home/jlquinn/gcc/dev/gcc-in-cxx/gcc/testsuite/g
++.dg/plugin/dumb_plugin.c -I.
-I/home/jlquinn/gcc/dev/gcc-in-cxx/gcc/testsuite
-I/home/jlquinn/gcc/dev/gcc-in-cxx/gcc/testsuite/../../gcc
-I/home/jlquinn/gcc/dev/build/trunk-cxx/gcc/testsuite/g++/../../../gcc
-I/home/jlquinn/gcc/dev/gcc-in-cxx/gcc/testsuite/../../include
-I/home/jlquinn/gcc/dev/gcc-in-cxx/gcc/testsuite/../../libcpp/include
-DIN_GCC -fPIC -shared -o dumb_plugin.so(timeout = 300)
set_ld_library_path_env_vars:
ld_library_path=.:/home/jlquinn/gcc/dev/build/trunk-cxx/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/jlquinn/gcc/dev/build/trunk-cxx/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/jlquinn/gcc/dev/build/trunk-cxx/gcc:/home/jlquinn/gcc/dev/build/trunk-cxx/gcc/32
Executing on host: /home/jlquinn/gcc/dev/build/trunk-cxx/gcc/testsuite/g
++/../../g++ -B/home/jlquinn/gcc/dev/build/trunk-cxx/gcc/testsuite/g
++/../../ /home/jlquinn/gcc/dev/gcc-in-cxx/gcc/testsuite/g
++.dg/plugin/dumb-plugin-test-1.C -nostdinc++
-I/home/jlquinn/gcc/dev/build/trunk-cxx/x86_64-unknown-linux-gnu/libstdc
++-v3/include/x86_64-unknown-linux-gnu
-I/home/jlquinn/gcc/dev/build/trunk-cxx/x86_64-unknown-linux-gnu/libstdc
++-v3/include -I/home/jlquinn/gcc/dev/gcc-in-cxx/libstdc++-v3/libsupc++
-I/home/jlquinn/gcc/dev/gcc-in-cxx/libstdc++-v3/include/backward
-I/home/jlquinn/gcc/dev/gcc-in-cxx/libstdc++-v3/testsuite/util
-fmessage-length=0 -fplugin=./dumb_plugin.so -O
-fplugin-arg-dumb_plugin-ref-pass-name=ccp
-fplugin-arg-dumb_plugin-ref-pass-instance-num=1 -S -o
dumb-plugin-test-1.s(timeout = 300)
cc1plus: error: Cannot load plugin ./dumb_plugin.so
./dumb_plugin.so: undefined symbol: tree_check_failed
compiler exited with status 1
output is:
cc1plus: error: Cannot load plugin ./dumb_plugin.so
./dumb_plugin.so: undefined symbol: tree_check_failed
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so
(test for warnings, line 10)
Patch below:
Index: gcc/cp/rtti.c
===
--- gcc/cp/rtti.c (revision 153489)
+++ gcc/cp/rtti.c (working copy)
@@ -102,7 +102,7 @@
static GTY (()) VEC(tinfo_s,gc) *tinfo_descs;
static tree ifnonnull (tree, tree);
-static tree tinfo_name (tree);
+static tree tinfo_name (tree, bool);
static tree build_dynamic_cast_1 (tree, tree, tsubst_flags_t);
static tree throw_bad_cast (void);
static tree throw_bad_typeid (void);
@@ -349,16 +349,31 @@
return exp;
}
-/* Generate the NTBS name of a type. */
+/* Generate the NTBS name of a type. If MARK_PRIVATE, put a '*' in
front so that
+ comparisons will be done by pointer rather than string comparison.
*/
static tree
-tinfo_name (tree type)
+tinfo_name (tree type, bool mark_private)
{
const char *name;
+ int length;
tree name_string;
- name = mangle_type_string_for_rtti (type);
- name_string = fix_string_type (build_string (strlen (name) + 1,
name));
- return name_string;
+ name = mangle_type_string (type);
+ length = strlen (name);
+
+ if (mark_private)
+{
+ /* Inject '*' at beginning of name to force pointer comparison.
*/
+ char* buf = (char*) XNEWVEC (char, length + 1);
+ buf[0] = '*';
+ memcpy (buf + 1, name, length);
+ name_string = build_string (length + 1, buf);
+ XDELETEVEC (buf);
+}
+ else
+name_string = build_string (length + 1, name);
+
+ return fix_string_type (name_string);
}
/* Return a VAR_DECL for the internal ABI defined type_info object for
@@ -839,13 +854,13 @@
tree vtable_ptr;
{
-tree name_name;
+tree name_name, name_string;
/* Generate the NTBS array variable. */
tree name_type = build_cplus_array_type
(build_qualified_type (char_type_node, TYPE_QUAL_CONST),
NULL_TREE);
-tree name_string = tinfo_name (target);
+//tree name_string = tinfo_name (target);
/* Determine the name of the variable -- and remember w
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Mon, 2009-10-26 at 09:53 -0400, Jason Merrill wrote:
> On 10/26/2009 07:14 AM, Jakub Jelinek wrote:
> >> -/* Generate the mangled representation of TYPE for the typeinfo name.
> >> */
> >> +/* Generate the mangled representation of TYPE. */
> >>
> >> const char *
> >> -mangle_type_string_for_rtti (const tree type)
> >> +mangle_type_string (const tree type)
> >
> > Why this change?
>
> This change is part of reverting my earlier fake namespace patch.
>
> I agree with Jakub's other comments, though.
>
> Jason
Here's the updated patch.
2009-10-28 Jerry Quinn
* mangle.c (mangle_type_string_for_rtti): Revert r149964.
(needs_fake_anon): Likewise.
(write_name): Likewise.
(write_nested_name): Likewise.
* cp-tree.h (mangle_type_string_for_rtti): Likewise.
(get_anonymous_namespace): Likewise.
* name-lookup.c (get_anonymous_namespace_name): Likewise.
* rtti.c (tinfo_name): Insert '*' in front of private names.
(tinfo_base_init): Use it.
2009-10-28 Jerry Quinn
* libsupc++/tinfo.cc (operator=(const type_info&)): Compare by
pointer if name begins with '*'.
* libsupc++/typeinfo (type_info::name()): Likewise.
* libsupc++/tinfo2.cc (before): Likewise.
Index: gcc/cp/rtti.c
===
--- gcc/cp/rtti.c (revision 153489)
+++ gcc/cp/rtti.c (working copy)
@@ -102,7 +102,7 @@
static GTY (()) VEC(tinfo_s,gc) *tinfo_descs;
static tree ifnonnull (tree, tree);
-static tree tinfo_name (tree);
+static tree tinfo_name (tree, bool);
static tree build_dynamic_cast_1 (tree, tree, tsubst_flags_t);
static tree throw_bad_cast (void);
static tree throw_bad_typeid (void);
@@ -349,16 +349,30 @@
return exp;
}
-/* Generate the NTBS name of a type. */
+/* Generate the NTBS name of a type. If MARK_PRIVATE, put a '*' in
front so that
+ comparisons will be done by pointer rather than string comparison.
*/
static tree
-tinfo_name (tree type)
+tinfo_name (tree type, bool mark_private)
{
const char *name;
+ int length;
tree name_string;
- name = mangle_type_string_for_rtti (type);
- name_string = fix_string_type (build_string (strlen (name) + 1,
name));
- return name_string;
+ name = mangle_type_string (type);
+ length = strlen (name);
+
+ if (mark_private)
+{
+ /* Inject '*' at beginning of name to force pointer comparison.
*/
+ char* buf = (char*) XALLOCAVEC (char, length + 1);
+ buf[0] = '*';
+ memcpy (buf + 1, name, length);
+ name_string = build_string (length + 1, buf);
+}
+ else
+name_string = build_string (length + 1, name);
+
+ return fix_string_type (name_string);
}
/* Return a VAR_DECL for the internal ABI defined type_info object for
@@ -839,13 +853,12 @@
tree vtable_ptr;
{
-tree name_name;
+tree name_name, name_string;
/* Generate the NTBS array variable. */
tree name_type = build_cplus_array_type
(build_qualified_type (char_type_node, TYPE_QUAL_CONST),
NULL_TREE);
-tree name_string = tinfo_name (target);
/* Determine the name of the variable -- and remember with which
type it is associated. */
@@ -862,6 +875,7 @@
DECL_TINFO_P (name_decl) = 1;
set_linkage_according_to_type (target, name_decl);
import_export_decl (name_decl);
+name_string = tinfo_name (target, !TREE_PUBLIC (name_decl));
DECL_INITIAL (name_decl) = name_string;
mark_used (name_decl);
pushdecl_top_level_and_finish (name_decl, name_string);
Index: gcc/cp/ChangeLog
=======
--- gcc/cp/ChangeLog(revision 153489)
+++ gcc/cp/ChangeLog(working copy)
@@ -1,3 +1,15 @@
+2009-10-28 Jerry Quinn
+
+ * mangle.c (mangle_type_string_for_rtti): Revert r149964.
+ (needs_fake_anon): Likewise.
+ (write_name): Likewise.
+ (write_nested_name): Likewise.
+ * cp-tree.h (mangle_type_string_for_rtti): Likewise.
+ (get_anonymous_namespace): Likewise.
+ * name-lookup.c (get_anonymous_namespace_name): Likewise.
+ * rtti.c (tinfo_name): Insert '*' in front of private names.
+ (tinfo_base_init): Use it.
+
2009-10-21 Jakub Jelinek
* mangle.c (finish_mangling_get_identifier): Use
Index: gcc/cp/mangle.c
===
--- gcc/cp/mangle.c (revision 153489)
+++ gcc/cp/mangle.c (working copy)
@@ -105,10 +105,6 @@
static GTY (()) globals G;
-/* Whether or not to pretend that a static function is in an anonymous
- namespace. */
-static bool fake_anon_scope;
-
/* The obstack on which we build mangled names. */
static struct obstack *mangle_obstack;
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Wed, 2009-10-28 at 11:35 -0400, Jason Merrill wrote:
> On 10/28/2009 07:29 AM, Jerry Quinn wrote:
> > + length = strlen (name);
> > + if (mark_private)
> > + name_string = build_string (length + 1, buf);
> > + else
> > +name_string = build_string (length + 1, name);
>
> These two calls shouldn't be using the same length. I think the +1 in
> the old code was unnecessary, so you can just remove it from the second
> call.
And here is the latest patch.
Index: gcc/cp/rtti.c
===
--- gcc/cp/rtti.c (revision 153489)
+++ gcc/cp/rtti.c (working copy)
@@ -102,7 +102,7 @@
static GTY (()) VEC(tinfo_s,gc) *tinfo_descs;
static tree ifnonnull (tree, tree);
-static tree tinfo_name (tree);
+static tree tinfo_name (tree, bool);
static tree build_dynamic_cast_1 (tree, tree, tsubst_flags_t);
static tree throw_bad_cast (void);
static tree throw_bad_typeid (void);
@@ -349,16 +349,30 @@
return exp;
}
-/* Generate the NTBS name of a type. */
+/* Generate the NTBS name of a type. If MARK_PRIVATE, put a '*' in
front so that
+ comparisons will be done by pointer rather than string comparison.
*/
static tree
-tinfo_name (tree type)
+tinfo_name (tree type, bool mark_private)
{
const char *name;
+ int length;
tree name_string;
- name = mangle_type_string_for_rtti (type);
- name_string = fix_string_type (build_string (strlen (name) + 1,
name));
- return name_string;
+ name = mangle_type_string (type);
+ length = strlen (name);
+
+ if (mark_private)
+{
+ /* Inject '*' at beginning of name to force pointer comparison.
*/
+ char* buf = (char*) XALLOCAVEC (char, length + 1);
+ buf[0] = '*';
+ memcpy (buf + 1, name, length);
+ name_string = build_string (length + 1, buf);
+}
+ else
+name_string = build_string (length, name);
+
+ return fix_string_type (name_string);
}
/* Return a VAR_DECL for the internal ABI defined type_info object for
@@ -839,13 +853,12 @@
tree vtable_ptr;
{
-tree name_name;
+tree name_name, name_string;
/* Generate the NTBS array variable. */
tree name_type = build_cplus_array_type
(build_qualified_type (char_type_node, TYPE_QUAL_CONST),
NULL_TREE);
-tree name_string = tinfo_name (target);
/* Determine the name of the variable -- and remember with which
type it is associated. */
@@ -862,6 +875,7 @@
DECL_TINFO_P (name_decl) = 1;
set_linkage_according_to_type (target, name_decl);
import_export_decl (name_decl);
+name_string = tinfo_name (target, !TREE_PUBLIC (name_decl));
DECL_INITIAL (name_decl) = name_string;
mark_used (name_decl);
pushdecl_top_level_and_finish (name_decl, name_string);
Index: gcc/cp/ChangeLog
===
--- gcc/cp/ChangeLog(revision 153489)
+++ gcc/cp/ChangeLog(working copy)
@@ -1,3 +1,15 @@
+2009-10-28 Jerry Quinn
+
+ * mangle.c (mangle_type_string_for_rtti): Revert r149964.
+ (needs_fake_anon): Likewise.
+ (write_name): Likewise.
+ (write_nested_name): Likewise.
+ * cp-tree.h (mangle_type_string_for_rtti): Likewise.
+ (get_anonymous_namespace): Likewise.
+ * name-lookup.c (get_anonymous_namespace_name): Likewise.
+ * rtti.c (tinfo_name): Insert '*' in front of private names.
+ (tinfo_base_init): Use it.
+
2009-10-21 Jakub Jelinek
* mangle.c (finish_mangling_get_identifier): Use
Index: gcc/cp/mangle.c
===
--- gcc/cp/mangle.c (revision 153489)
+++ gcc/cp/mangle.c (working copy)
@@ -105,10 +105,6 @@
static GTY (()) globals G;
-/* Whether or not to pretend that a static function is in an anonymous
- namespace. */
-static bool fake_anon_scope;
-
/* The obstack on which we build mangled names. */
static struct obstack *mangle_obstack;
@@ -734,20 +730,6 @@
}
}
-/* Since we now use strcmp to compare typeinfos on all targets because
of
- the RTLD_LOCAL problem, we need to munge the typeinfo name used for
- local classes of static functions to fix g++.dg/abi/local1.C. We do
- that by pretending that the function is in an anonymous namespace.
*/
-
-static bool
-needs_fake_anon (const_tree decl)
-{
- /* Pretend there's an anonymous namespace right around a static
- function if we're mangling for RTTI. */
- return (fake_anon_scope && !TREE_PUBLIC (decl)
- && TREE_CODE (decl) == FUNCTION_DECL);
-}
-
/* Lambdas can have a bit more context for mangling, specifically
VAR_DECL
or PARM_DECL context, which doesn't belong in DECL_CONTEXT. */
@@ -791,18 +773,13 @@
context = decl_mangling_context (decl);
- gcc_assert (context != NULL_TREE
Re: Library ABI seriously broken!!
On Fri, 2009-10-30 at 12:48 +0100, Paolo Carlini wrote: > Hi, > > sorry if the issue is already well known, but it's so serious that I > decided to post an heads up: today (not yesterday), the ABI is broken, > the size of many symbols exported by libstdc++ changed, see eg: > > http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02895.html > http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02903.html > http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02904.html > > I'm adding below some of the many error messages spilled by abi_check. > > I *strongly* suspect: > > 2009-10-28 Jerry Quinn > > * mangle.c (mangle_type_string_for_rtti): Revert r149964. > (needs_fake_anon): Likewise. > (write_name): Likewise. > (write_nested_name): Likewise. > * cp-tree.h (mangle_type_string_for_rtti): Likewise. > (get_anonymous_namespace): Likewise. > * name-lookup.c (get_anonymous_namespace_name): Likewise. > * rtti.c (tinfo_name): Insert '*' in front of private names. > (tinfo_base_init): Use it. Hi, Paolo, I've reverted the patch. This was intended to fix the broken bootstrap under --enable-build-with-cxx. Currently anonymous namespaces get random names so successive builds of the compiler have different binaries when built with C++. The patch marked anonymous namespaces so they could be compared by pointer instead of string allowing removal of the random naming. Obviously a different strategy is needed. I missed the ABI breakage when testing. Sorry for the aggravation. Jerry
ping^2 [rfc][patch] Document RETURN_EXPR better
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00690.html [cc'ing gcc since it might be the better forum for this]
Re: in asm: where does ".zero 2102063220" come from?
Daniel Franke wrote: Hi all. I'm in the process of revamping the fortran-frontend to use trees instead of linked lists in its array-constructor representation (initial patch at [1]). By now, I'm hunting down the last regressions. For one regression, I have no idea how to deal with it. The problem: for some reason the .o file for a small fortran program may be blown up to multiple GB. The diff below shows the differences in assembler of the testcase gfortran.dg/actual_array_substr_2.f90, once compiled with current trunk, once with my local tree. The only difference is the ".zero $bignumber" - it's not overly far fetched to link $bignumber with the object file size. It is to assume that I either dropped a required initialization or introduced one that should not be there. Simply reading the diff doesn't help me much as (a) it's rather big by now and (b) whenever I identified a candidate and put a breakpoint there, execution never actually stopped there ^^ Hints where these .zero lines are generated and why, where to put a breakpoint and what to look for -- or anything else that puts me on the right track -- would be appreciated. Try to get a look at the -fdump-tree-original output. This should happen long before any asm is generated. Post it here if you are still stuck. Regards, Jerry
Question about code licensing
Hi, folks, There is renewed interest in getting a D compiler into the GCC sources. The most direct route for this to happen is to use the existing Digital Mars DMD front end. The current DMD front end code is GPL licensed, and copyright is owned by Digital Mars. If they were to fork the source, and contribute that fork under the current license of GCC, do they still possess the freedom to continue to do what they wish with the original code? Thanks, Jerry Quinn
Re: Question about code licensing
On Fri, 2010-01-22 at 20:17 -0800, Joe Buck wrote: > On Fri, Jan 22, 2010 at 05:31:03PM -0800, Jerry Quinn wrote: > > There is renewed interest in getting a D compiler into the GCC sources. > > The most direct route for this to happen is to use the existing Digital > > Mars DMD front end. > > > > The current DMD front end code is GPL licensed, and copyright is owned > > by Digital Mars. If they were to fork the source, and contribute that > > fork under the current license of GCC, do they still possess the freedom > > to continue to do what they wish with the original code? > > The standard FSF contribution paperwork assigns copyright to the FSF and > then grants back a license to the contributor to do whatever they want > with the original code (continue to develop it, distribute under other > terms, embed in proprietary products -- not sure about any restrictions). > I'm not sure whether that would work for what they want to do or not. If > it would, it's easy. Otherwise they might be able to make some other > arrangement with the FSF. > > Ideally, something could be worked out so they wouldn't feel the need > to continue to maintain a fork. It's not very efficient. No, it's not efficient. I think the main reason is that DMD front end sources are dual licensed with GPL and Artistic License. The DMD backend is not under an open source license (personal use only), so the Artistic License is how the two are integrated. The fork is required to allow DMD to continue under its current license scheme. It also means that fixes to the GCC front end would not be copyable to the DMD front end going forward. Jerry
Question about reworking internals manual
Hi, folks. I'm looking at reworking the sections on trees in the internals manual and had a question about how to proceed. Right now, the information is spread between the GENERIC chapter and Trees chapter. The Trees chapter interleaves a lot of C and C++-specific info in with GENERIC info. What I'd like to do is the following: 1) Make GENERIC the chapter that talks about the front end representation. 2) Extract those portions of Trees that really talk about GENERIC (a large part of it) and integrate that into the GENERIC chapter 3) Make the remainder part of a section on language-dependent trees The problem I see is that doing the whole thing at once will make for a large hard-to-review patch. But to do it in steps will result in an inconsistent document until a good part of the work is done. Any suggestions about the best way to proceed? Thanks, Jerry
Re: Proposed gfortran development branch
NightStrike wrote: On Thu, Mar 19, 2009 at 3:06 PM, Steve Kargl wrote: On Thu, Mar 19, 2009 at 07:46:37PM +0100, Toon Moene wrote: I agree about the bisecting-in-case-of-bugs issue. However, what I see happening in practice is that all GCC developers keep on doing their development work on branches - only the gfortran developers are left out, because they do not have a branch. Of course we can create branches for all the subprojects that are pending on the creation of a 4.4 branch and freeing up trunk - it just doesn't seem very efficient to us. Of course I pleaded with the FSF (on the Steering Committee mailing list *and* the gcc list) for speed in the case of the 4.4 branch - in vain. We might be heading for a fork a la the EGCS fork - and I don't like it. It took a lot of effort (I was part of the EGCS cabal and I didn't even do a lot of that foot-work). "Those who do not learn from history are doomed to repeat it." George Santayana http://home.schmorp.de/egcs.html Why are we doing this? It's become increasingly clear in the course of hacking events that the FSF's needs for gcc2 are at odds with the objectives of many in the community who have done lots of hacking and improvment over the years. GCC is part of the FSF's publicity for the GNU project, as well as being the GNU system's compiler, so stability is paramount for them. On the other hand, Cygnus, the Linux folks, the pgcc folks, the Fortran folks and many others have done development work which has not yet gone into the GCC2 tree despite years of efforts to make it possible. This can be amended by replacing "so stability is paramount for them" with "so utopian philosophical pander is paramount for them" -- Steve http://gcc.gnu.org/ml/gcc/2009-03/msg00439.html I would agree that going back to stage 3 is really a good solution. I have also read several of the historical threads that are similar to this. First, a clarification. This proposed development branch is in no way intended to be a fork. That would be disrespectful of the gcc community and I could not support such a thing. Creating the branch allows us to continue joint effort much like other gcc developers do already. This is nearly an ideal time because we are talking significant changes that go beyond Fortran95 and move well into Fortran 2003/2008. That's what development branches ae for. If the 4.4 delay continues only a little while or a longer time, we are capable of managing the merging in an orderly manner. Therefore I believe the Yea's have it and I will attempt to create the branch hopefully this weekend. We will follow our usual practice of peer review before commits. Paul, do you have time to organize an IRC meeting to discuss order of commits and any other concerns? or Tobias? Regards, Jerry
[fortran-dev] Fortran development branch created.
The fortran development branch has been created. The purpose is to allow continuation of development of new Fortran 95 and Fortran 2003 features. A primary objective will be testing these features before committing over to mainline, when appropriate. A complete list of objectives can be found on the Fortran Wiki. URL: svn+ssh://jvdeli...@gcc.gnu.org/svn/gcc/branches/fortran-dev Repository Root: svn+ssh://jvdeli...@gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 144975 Regards, Jerry
[gcc-in-cxx] bootstrap fails
Hi, I just tried to bootstrap the gcc-in-cxx branch, but it fails in stage 2. If I expand the macros, the code looks OK to me. Any suggestions on how to go about tracking this down (if someone else doesn't get there first)? Thanks, Jerry Quinn /home/jlquinn/gcc/dev/gcc/host-x86_64-unknown-linux-gnu/prev-gcc/g++ -B/home/jlquinn/gcc/dev/gcc/host-x86_64-unknown-linux-gnu/prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -I/home/jlquinn/gcc/dev/gcc/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/jlquinn/gcc/dev/gcc/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/jlquinn/gcc/dev/gcc/./libstdc++-v3/libsupc++ -L/home/jlquinn/gcc/dev/gcc/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -c -g -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber \ ../.././gcc/config/i386/i386.c -o i386.o cc1plus: warnings being treated as errors ../.././gcc/config/i386/i386.c: In function ‘void ix86_function_specific_save(cl_target_option*)’: ../.././gcc/config/i386/i386.c:3282: error: comparison is always true due to limited range of data type ../.././gcc/config/i386/i386.c:3283: error: comparison is always true due to limited range of data type ../.././gcc/config/i386/i386.c:3284: error: comparison is always true due to limited range of data type ../.././gcc/config/i386/i386.c:3285: error: comparison is always true due to limited range of data type make[3]: *** [i386.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcj-dbtool.pod fsf-funding.pod jcf-dump.pod jv-convert.pod grmic.pod gcov.pod gcj.pod gc-analyze.pod gfdl.pod cpp.pod gij.pod gcc.pod gfortran.pod make[3]: Leaving directory `/home/jlquinn/gcc/dev/gcc/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/jlquinn/gcc/dev/gcc' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/jlquinn/gcc/dev/gcc' make: *** [all] Error 2
Re: [gcc-in-cxx] bootstrap fails
Joseph S. Myers wrote: On Sat, 21 Mar 2009, Ian Lance Taylor wrote: ../.././gcc/config/i386/i386.c:3282: error: comparison is always true due to limited range of data type #define IN_RANGE(VALUE, LOWER, UPPER) \ ((unsigned HOST_WIDE_INT) (VALUE) - (unsigned HOST_WIDE_INT) (LOWER) \ <= (unsigned HOST_WIDE_INT) (UPPER) - (unsigned HOST_WIDE_INT) (LOWER)) gcc_assert (IN_RANGE (ix86_arch, 0, 255)); It all looks fine to me. Sounds like enums in C++ having limited ranges meaning this is an assertion of something the compiler knows to be true. (This actually illustrates why these warnings can sometimes be problematic - you write a check for something that may or may not be always true depending on the sizes of types, the handling of enumerations, etc., and when it is always true the compiler complains. But in other cases they can be useful.) However, the stage 1 compilation succeeds, and that's being compiled with g++ 4.3.3. Wait, is it a warning in stage 1 and an error in stage 2? Jerry
Re: [gcc-in-cxx] bootstrap fails
Jerry Quinn wrote:
Joseph S. Myers wrote:
On Sat, 21 Mar 2009, Ian Lance Taylor wrote:
../.././gcc/config/i386/i386.c:3282: error: comparison is always true
due to limited range of data type
#define IN_RANGE(VALUE, LOWER, UPPER) \
((unsigned HOST_WIDE_INT) (VALUE) - (unsigned HOST_WIDE_INT)
(LOWER) \
<= (unsigned HOST_WIDE_INT) (UPPER) - (unsigned HOST_WIDE_INT)
(LOWER))
gcc_assert (IN_RANGE (ix86_arch, 0, 255));
It all looks fine to me.
Sounds like enums in C++ having limited ranges meaning this is an
assertion of something the compiler knows to be true. (This actually
illustrates why these warnings can sometimes be problematic - you
write a check for something that may or may not be always true
depending on the sizes of types, the handling of enumerations, etc.,
and when it is always true the compiler complains. But in other
cases they can be useful.)
However, the stage 1 compilation succeeds, and that's being compiled
with g++ 4.3.3. Wait, is it a warning in stage 1 and an error in
stage 2?
I just confirmed that it is a warning in stage 1. It would seem to me
that the thing to do here is to remove the gcc_assert. The fact that
ix86_arch is now an enum means it can't be assigned an invalid value
without an inappropriate cast somewhere. It seems like the compiler
should catch as many problems as the runtime check did, so I would think
we could ditch the runtime check. The patch below does that and fixes
bootstrap for me. Posted to gcc-patches as well.
Alternatively, the IN_RANGE macro could be modified to check that the
upper and lower bounds are within the limits of the checked value's
type. That seems like overkill to me, though.
Jerry
2009-03-21 Jerry Quinn
* config/i386/i386.c (ix86_function_specific_save): Don't check
range of enum values.
Index: i386.c
===
--- i386.c(revision 144950)
+++ i386.c(working copy)
@@ -3279,10 +3279,6 @@
static void
ix86_function_specific_save (struct cl_target_option *ptr)
{
- gcc_assert (IN_RANGE (ix86_arch, 0, 255));
- gcc_assert (IN_RANGE (ix86_schedule, 0, 255));
- gcc_assert (IN_RANGE (ix86_tune, 0, 255));
- gcc_assert (IN_RANGE (ix86_fpmath, 0, 255));
gcc_assert (IN_RANGE (ix86_branch_cost, 0, 255));
ptr->arch = ix86_arch;
Re: [gcc-in-cxx] bootstrap fails
Ian Lance Taylor wrote: Jerry Quinn writes: 2009-03-21 Jerry Quinn * config/i386/i386.c (ix86_function_specific_save): Don't check range of enum values. I still don't know why I don't see this, but this is OK for the gcc-in-cxx branch. Do I need to take any actions before I can commit into gcc's svn repository? I haven't written to gcc's svn repository before but I have an assignment in place. Thanks, Jerry
gfortran-dev branch bootstrap breakage
I just completed a sync to trunk that I have not committed back yet and I get the following error during bootstrap on the local branch. libbackend.a(plugin.o): In function `plugin_default_version_check': /home/jerry/gcc/objdev/gcc/../../gccdev/gcc/plugin.c:825: undefined reference to `plugin_gcc_version' There was a patch that went in about 3 days ago related to this. r146962. That patch is in place in my local gfortran-dev branch. local branch svn is at r147078 Suggestions anyone? Jerry
Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]
Tobias Burnus wrote:
Dave Korn wrote:
Dave Korn wrote:
Dave Korn wrote:
Tobias Burnus wrote:
I agree that for "main" the call to "__main()" should happend and thus
expand_main_function should be called. I'm not sure in about the exact
assumptions of the middle end. In principle, it would be OK if the
MAIN__ function would show up as MAIN__ in gimple/-fdump-tree-original.
The only potential inconvenience I see, is the mentioned reference to
MAIN__ instead of in middle-end warnings, which can
confuse users.
Is it legitimate to have a space in an IDENTIFIER_NODE? I have a cheeky idea:
- gfc_get_symbol (name, ns, &main_program);
+ identifier = gfc_get_string ("PROGRAM %s", name);
That should give reasonable warnings from the middle end, no? I don't know
what it might do to debugging though.
Currently one can use "b MAIN__" and "b helloworld" in the debugger:
(gdb) b helloworld
Breakpoint 1 at 0x400737: file test.f90, line 3.
(gdb) b MAIN__
Note: breakpoint 1 also set at pc 0x400737.
Breakpoint 2 at 0x400737: file test.f90, line 3.
(gdb) b main
Breakpoint 3 at 0x4007b9: file test.f90, line 9.
I have another idea: Just handle "PROGRAM main" specially by using the
name "MAIN__". It should be still quite readable in the middle-end
diagnostics. Furthermore, it matches the assembler name and using "b
main" one still get something useful - and it is less confusing for
everyone (middle end, users of -fdump-tree-original etc.) if there is
only a single "main".
Tobias
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(Revision 148004)
+++ gcc/fortran/trans-decl.c(Arbeitskopie)
@@ -289,7 +289,10 @@ gfc_get_label_decl (gfc_st_label * lp)
static tree
gfc_sym_identifier (gfc_symbol * sym)o commit
{
- return (get_identifier (sym->name));
+ if (sym->attr.is_main_program && strcmp (sym->name, "main") == 0)
+return (get_identifier ("MAIN__"));
+ else
+return (get_identifier (sym->name));
}
@@ -3874,6 +3877,8 @@ create_main_function (tree fndecl)
tmp = build_function_type_list (integer_type_node, integer_type_node,
build_pointer_type (pchar_type_node),
NULL_TREE);
+ main_identifier_node = get_identifier ("main");
+ ftn_main = build_decl (FUNCTION_DECL, main_identifier_node, tmp);
ftn_main = build_decl (FUNCTION_DECL, get_identifier ("main"), tmp);
DECL_EXTERNAL (ftn_main) = 0;
TREE_PUBLIC (ftn_main) = 1;
Tobias and Dave,
I tested the above on x86-64 Linux. OK to commit.
Jerry
Help with BLOCK vs BIND_EXPR trees?
Hi, all. I have a basic question about GENERIC trees. I'm playing with writing a front end, and find the distinction between BLOCK and BIND_EXPR to be somewhat confusing. In particular, I'm trying to get a handle on how to represent a function in GENERIC form. On the surface the texi docs and code comments don't seem to agree: Section on function trees say FUNCTION_DECL represents a function, and that DECL_INITIAL is not empty. But it doesn't say what should be contained there. It says DECL_SAVED_TREE should contain the body of the function. The comments in tree.h say that DECL_INITIAL holds the body of a function, with a BLOCK tree at the root. BLOCK nodes are described under TREE_SSA->GIMPLE, though these nodes are part of GENERIC if I understand correctly. In this section, it says that block scopes and variables are declared in BIND_EXPR nodes. Can someone please clarify how these things are supposed to relate in GENERIC form, assuming the default conversion to GIMPLE will be used? Thanks, Jerry Quinn
Help with BLOCK vs BIND_EXPR trees
(trying again) Hi, all. I have a basic question about GENERIC trees. I'm playing with writing a front end, and find the distinction between BLOCK and BIND_EXPR to be somewhat confusing. In particular, I'm trying to get a handle on how to represent a function in GENERIC form. On the surface the texi docs and code comments don't seem to agree: Section on function trees say FUNCTION_DECL represents a function, and that DECL_INITIAL is not empty. But it doesn't say what should be contained there. It says DECL_SAVED_TREE should contain the body of the function. The comments in tree.h say that DECL_INITIAL holds the body of a function, with a BLOCK tree at the root. BLOCK nodes are described under TREE_SSA->GIMPLE, though these nodes are part of GENERIC if I understand correctly. At least, the docs say that any tree code found in tree.def is part of GENERIC. In this section, it says that block scopes and variables are declared in BIND_EXPR nodes. Can someone please clarify how these things are supposed to fit together in GENERIC form, assuming the default conversion to GIMPLE will be used? Thanks, Jerry Quinn
Questions about VAR_DECL and DECL_EXPR
Hi, again, I am a little unclear on VAR_DECL and DECL_EXPR. The impression I get from reading the docs is that when a variable is first declared in a function, a VAR_DECL should be created, possibly with DECL_INITIAL() set. What's less clearly stated is what you use for variable references later in the code. I think you also use VAR_DECL for this purpose, but I'm not sure. Could someone clarify? If so, must it be the same tree node or does it just have to be another VAR_DECL with the same variable name? There is also DECL_EXPR representing local declarations, which appears to be related. How do these get used and would it even be used in a C-like language? Thanks, Jerry Quinn
Re: Help with BLOCK vs BIND_EXPR trees
On Tue, 2009-06-16 at 14:43 +0200, Richard Guenther wrote:
> BIND_EXPRs are containers for local variables in the GENERIC
> function body (they persist until GIMPLE is lowered). BLOCKs
> represent the scope tree of the function (which also refers to
> local variables). The BLOCK tree is kept live throughout the
> compilation and is used to generate proper debug information
> for example.
So let me see if I understand with an example from C. If we have the
following C function:
void foo() {
int a;
{ int b; }
{ int c; }
}
then starting with FUNCTION_DECL, we should have pseudocode for the
GENERIC something like the following?
tree foo = FUNCTION_DECL
tree int_a = VAR_DECL
tree int_b = VAR_DECL
tree int_c = VAR_DECL
tree scope_b = BIND_EXPR
BIND_EXPR_VARS(scope_b) = int_b
BIND_EXPR_BODY(scope_b) = int_b
tree scope_c = BIND_EXPR
BIND_EXPR_VARS(scope_c) = int_b
BIND_EXPR_BODY(scope_c) = int_b
tree foo_body = STATEMENT_LIST
// I know this is actually a tree-iterator
foo_body = { int_a, scope_b, scope_c }
tree scope_foo = BIND_EXPR
BIND_EXPR_VARS(scope_foo) = int_a
BIND_EXPR_BODY(scope_foo) = foo_body
DECL_SAVED_FUNCTION(foo) = scope_foo
tree block_foo = BLOCK
tree block_b = BLOCK
tree block_c = BLOCK
BLOCK_VARS(block_b) = int_b
BLOCK_SUPERCONTEXT(block_b) = block_foo
BLOCK_CHAIN(block_b) = block_c
BLOCK_VARS(block_c) = int_c
BLOCK_SUPERCONTEXT(block_c) = block_foo
BLOCK_CHAIN(block_c) = null
BLOCK_VARS(block_foo) = int_a
BLOCK_SUPERCONTEXT(block_foo) = foo
BLOCK_CHAIN(block_foo) = null
BLOCK_SUBBLOCKS(block_foo) = block_b, block_c
DECL_INITIAL(foo) = block_foo
Thanks for taking the time to clarify things for me,
Jerry
Basic frontend question about layout
Hi, folks, I'm having trouble seeing how layout is specified at the GENERIC level for RECORD_TYPEs. The docs and comments in tree.def say that you cannot rely on the order of fields of the type. In stor-layout.c, layout_types() seems to do the obvious thing, taking the fields in order, but the docs make it sound like there is no way to be sure what you'll get. Theoretically this would mean that you couldn't even reliably link a structure in two separate compilation units, which is bogus. Could someone please clear up my confusion? Thanks, Jerry Quinn
Re: Basic frontend question about layout
On Tue, 2009-06-23 at 20:52 -0700, Andrew Pinski wrote: > On Tue, Jun 23, 2009 at 8:48 PM, Jerry Quinn wrote: > > Hi, folks, > > > > I'm having trouble seeing how layout is specified at the GENERIC level > > for RECORD_TYPEs. The docs and comments in tree.def say that you cannot > > rely on the order of fields of the type. In stor-layout.c, > > layout_types() seems to do the obvious thing, taking the fields in > > order, but the docs make it sound like there is no way to be sure what > > you'll get. > > Could someone please clear up my confusion? > > The confusion here is that layout_types is separate from the rest of > the middle-end and the front-end could do the layout themselves and > the front-end calls layout_type if it does not do the layout itself. As I look at the code, it seems like a front end doesn't actually need to call layout_type at all. Is that correct? If so, is the layout C-compatible, assuming the field types being used are individually compatible? I'm gleaning this from a mix of code, comments, and gccint texinfo docs. Would it make sense to update them to indicate that layout is in order as long as the rest of the language-specific front end doesn't choose to lay things out differently? Thanks, Jerry
Exploring gcc-in-cxx compiler build requirements
Hi, all, I just tried to build gcc-in-cxx with some older gcc compilers on x86_64 linux. This is Debian testing, with 4.3.3 as the system compiler. Here's what I've gotten so far: 2.95.3 Doesn't support x86_64 3.0.4 Doesn't support x86_64 3.1.1 Fails to bootstrap 3.2.3 Fails to bootstrap Both 3.1.1 and 3.2.3 fail to bootstrap with the following error: make[1]: Entering directory `/home/jlquinn/gcc/dev/build/gcc323/gcc' gcc -c -DIN_GCC--std=gnu89 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DGENERATOR_FILE-I. -I. -I../../../gcc-3.2.3/gcc -I../../../gcc-3.2.3/gcc/. -I../../../gcc-3.2.3/gcc/config -I../../../gcc-3.2.3/gcc/../include ../../../gcc-3.2.3/gcc/read-rtl.c -o read-rtl.o In file included from ../../../gcc-3.2.3/gcc/read-rtl.c:24: ../../../gcc-3.2.3/gcc/rtl.h:125: warning: type of bit-field ‘code’ is a GCC extension ../../../gcc-3.2.3/gcc/rtl.h:128: warning: type of bit-field ‘mode’ is a GCC extension ../../../gcc-3.2.3/gcc/read-rtl.c: In function ‘fatal_with_file_and_line’: ../../../gcc-3.2.3/gcc/read-rtl.c:62: warning: traditional C rejects ISO C style function definitions ../../../gcc-3.2.3/gcc/read-rtl.c: In function ‘read_rtx’: ../../../gcc-3.2.3/gcc/read-rtl.c:662: error: lvalue required as increment operand make[1]: *** [read-rtl.o] Error 1 make[1]: Leaving directory `/home/jlquinn/gcc/dev/build/gcc323/gcc' make: *** [all-gcc] Error 2 3.3.6 old compiler builds. branch bootstrap fails with: make[3]: Entering directory `/home/jlquinn/gcc/dev/gcc-in-cxx/host-x86_64-unknown-linux-gnu/gcc' g++ -c -g -g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber../.././gcc/c-lang.c -o c-lang.o In file included from /home/jlquinn/gcc/dev/run/gcc336/include/c ++/3.3.6/iosfwd:46, from /usr/include/gmp-x86_64.h:24, from /usr/include/gmp.h:59, from ../../gcc/double-int.h:24, from ../../gcc/tree.h:30, from ../../gcc/c-lang.c:27: /home/jlquinn/gcc/dev/run/gcc336/include/c ++/3.3.6/x86_64-unknown-linux-gnu/bits/c++locale.h:61:40: attempt to use poisoned "malloc" make[3]: *** [c-lang.o] Error 1 make[3]: Leaving directory `/home/jlquinn/gcc/dev/gcc-in-cxx/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/jlquinn/gcc/dev/gcc-in-cxx' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/jlquinn/gcc/dev/gcc-in-cxx' make: *** [all] Error 2 I updated the system gmp to 4.2.3, so the C++ fix is present in the header. I'm configuring and bootstrapping with the 3.3.6 install at the head of the path. Maybe building with the CXX and CC explicitly specified would work better here. I didn't run the test suite on the 3.3.6 build, so it's possible it didn't build correctly. gcc 3.4.6 successfully bootstraps the branch with all default languages. Jerry
Unable to build --enable-build-with-cxx --enable-languages=c,c++ --with-gold
This is on Debian testing. I have a clean tree r164966. I configure as follows: ../../gcc-in-cxx/configure --enable-build-with-cxx --enable-languages=c,c++ --with-gold I just run make and it fails as below. Any ideas what might be wrong? Thanks, Jerry Configuring stage 1 in ./libcpp configure: creating cache ./config.cache checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c checking for x86_64-unknown-linux-gnu-gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for x86_64-unknown-linux-gnu-ranlib... ranlib checking for aclocal... aclocal checking for autoconf... autoconf checking for autoheader... autoheader checking whether gcc supports -W... yes checking whether gcc supports -Wall... yes checking whether gcc supports -Wwrite-strings... yes checking whether gcc supports -Wmissing-format-attribute... yes checking whether gcc supports -Wstrict-prototypes... yes checking whether gcc supports -Wmissing-prototypes... yes checking whether gcc supports -Wold-style-definition... yes checking whether gcc supports -Wc++-compat... yes checking whether gcc supports -pedantic -Wno-long-long... yes checking dependency style of g++... gcc3 checking whether time.h and sys/time.h may both be included... yes checking whether string.h and strings.h may both be included... yes checking how to run the C++ preprocessor... g++ -E checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking stdlib.h usability... yes checking stdlib.h presence... yes checking for stdlib.h... yes checking strings.h usability... yes checking strings.h presence... yes checking for strings.h... yes checking string.h usability... yes checking string.h presence... yes checking for string.h... yes checking sys/stat.h usability... yes checking sys/stat.h presence... yes checking for sys/stat.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking unistd.h usability... yes checking unistd.h presence... yes checking for unistd.h... yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for inline... inline checking for obstacks... yes checking for off_t... yes checking for size_t... yes checking for ssize_t... yes checking for uintptr_t... no checking for ptrdiff_t... no checking whether struct tm is in sys/time.h or time.h... time.h checking size of int... 4 checking size of long... 8 checking for clearerr_unlocked... yes checking for feof_unlocked... yes checking for ferror_unlocked... yes checking for fflush_unlocked... yes checking for fgetc_unlocked... yes checking for fgets_unlocked... yes checking for fileno_unlocked... yes checking for fprintf_unlocked... no checking for fputc_unlocked... yes checking for fputs_unlocked... yes checking for fread_unlocked... yes checking for fwrite_unlocked... yes checking for getchar_unlocked... yes checking for getc_unlocked... yes checking for putchar_unlocked... yes checking for putc_unlocked... yes checking whether abort is declared... yes checking whether asprintf is declared... yes checking whether basename is declared... yes checking whether errno is declared... no checking whether getopt is declared... yes checking whether vasprintf is declared... yes checking whether clearerr_unlocked is declared... yes checking whether feof_unlocked is declared... yes checking whether ferror_unlocked is declared... yes checking whether fflush_unlocked is declared... yes checking whether fgetc_unlocked is declared... yes checking whether fgets_unlocked is declared... yes checking whether fileno_unlocked is declared... yes checking whether fprintf_unlocked is declared... no checking whether fputc_unlocked is declared... yes checking whether fputs_unlocked is declared... yes checking whether fread_unlocked is declared... yes checking whether fwrite_unlocked is declared... yes checking whether getchar_unlocked is declared... yes checking whether getc_unlocked is declared... yes checking whether putchar_unlocked is
Regular LAPACK testing
I would like to get regular LAPACK regression testing and automatic reporting set up. Is there a gcc.gnu server somewhere that I can get access to to set this up and have it run once daily? This is mostly to catch gfortran regressions as well as an occasional back-end or middle-end bug. After setting this up I would like to close PR5900 Regards, Jerry
BFD Error a regression?
With latest svn trunk and Bud's splay patch. I don't think this is related to Bud's patch because regression testing and NIST testing passed fine. While compiling LAPACK with -O3 -funroll-loops -march=nocona I got the following error message: I am not sure I can reduce the case. But I can try if this is something new. Look familiar? Regards, Jerry BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at ../../bfd/elfcode.h line 190 in bfd_elf32_swap_symbol_in BFD: Please report this bug. make[1]: *** [complex16] Error 1 make[1]: *** Waiting for unfinished jobs BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at ../../bfd/elfcode.h line 190 in bfd_elf32_swap_symbol_in BFD: Please report this bug. make[1]: *** [double] Error 1 make[1]: Leaving directory `/home/jerry/fortran/lapack/SRC' make: *** [lapacklib] Error 2
Re: BFD Error a regression?
Nick Clifton wrote: Hi Jerry, While compiling LAPACK with -O3 -funroll-loops -march=nocona I got the following error message: BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at ../../bfd/elfcode.h line 190 in bfd_elf32_swap_symbol_in If you are able to reproduce this bug, then please try using the latest version of the binutils from the mainline of the CVS repository. If the bug still exists there please submit a binutils bug report (at: http://sourceware.org/bugzilla/) and we will be happy to investigate. (If you can include a simple test case that reproduces the problem, preferably without needing to build a special compiler, that will help immensely). Cheers Nick I observed that ar and ranlib are invoked by make to build the LAPACK libraries. I was using make -j3 to do this. When I do not use the -j option the build proceeds normally, so I am OK here. There are several hundred object files being pulled together here. I don't think I can reproduce the problem with a smaller set. I will just avoid the option. Thanks, Jerry
Memory leaks in compiler
With the Fortran test case I am using for PR34722. I did a valgrind check with the following command: valgrind --leak-check=full f951 inquire_12.f90 The possible problem in mpfr has been around a while. The other two problems look like middle-end or back-end problems. Does this warrant a PR? Against what component? Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc43/configure --prefix=/home/jerry/gcc/usr --enable-languages=c,fortran --disable-libmudflap --enable-libgomp --with-mpfr-lib=/home/jerry/gcc/usr/lib --with-mpfr-include=/home/jerry/gcc/usr/include --disable-bootstrap Thread model: posix gcc version 4.3.0 20080111 (experimental) [trunk revision 131004] (GCC) I get the following: ==14240== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1) ==14240== malloc/free: in use at exit: 310,961 bytes in 1,036 blocks. ==14240== malloc/free: 2,207 allocs, 1,171 frees, 1,296,169 bytes allocated. ==14240== For counts of detected errors, rerun with: -v ==14240== searching for pointers to 1,036 not-freed blocks. ==14240== checked 2,346,928 bytes. ==14240== ==14240== 64 bytes in 2 blocks are possibly lost in loss record 1 of 8 ==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149) ==14240==by 0xB2F778: __gmp_default_allocate (in /mnt/sdb2/obj43/gcc/f951) ==14240==by 0x4C2B62D: mpfr_init2 (init2.c:53) ==14240==by 0x4C34424: mpfr_cache (cache.c:57) ==14240==by 0x4C18E48: mpfr_log (log.c:133) ==14240==by 0x4C2A4D1: mpfr_log10 (log10.c:111) ==14240==by 0x40A29F: gfc_arith_init_1 (arith.c:165) ==14240==by 0x443BC2: gfc_init_1 (misc.c:259) ==14240==by 0x47684D: gfc_init (f95-lang.c:288) ==14240==by 0x6D74F4: toplev_main (toplev.c:2128) ==14240==by 0x3B7EC1E073: (below main) (in /lib64/libc-2.7.so) ==14240== ==14240== ==14240== 408 bytes in 3 blocks are definitely lost in loss record 2 of 8 ==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149) ==14240==by 0xB1B4DB: xrealloc (xmalloc.c:177) ==14240==by 0x8B1265: vec_heap_o_reserve_1 (vec.c:176) ==14240==by 0x4FC09D: insn_locators_alloc (vecprim.h:27) ==14240==by 0xA759F8: tree_expand_cfg (cfgexpand.c:1862) ==14240==by 0x65C925: execute_one_pass (passes.c:1118) ==14240==by 0x65CAEB: execute_pass_list (passes.c:1171) ==14240==by 0x735345: tree_rest_of_compilation (tree-optimize.c:404) ==14240==by 0x8E55E1: cgraph_expand_function (cgraphunit.c:1152) ==14240==by 0x8E73C3: cgraph_assemble_pending_functions (cgraphunit.c:523) ==14240==by 0x8E6894: cgraph_finalize_function (cgraphunit.c:640) ==14240==by 0x49368B: gfc_generate_function_code (trans-decl.c:3403) ==14240== ==14240== ==14240== 5,672 (5,224 direct, 448 indirect) bytes in 71 blocks are definitely lost in loss record 4 of 8 ==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149) ==14240==by 0xB1B567: xmalloc (xmalloc.c:147) ==14240==by 0x51E842: df_install_refs (df-scan.c:2425) ==14240==by 0x51EADA: df_refs_add_to_chains (df-scan.c:2551) ==14240==by 0x52029F: df_record_exit_block_uses (df-scan.c:3808) ==14240==by 0x5218D0: df_scan_blocks (df-scan.c:597) ==14240==by 0x51499D: rest_of_handle_df_initialize (df-core.c:742) ==14240==by 0x65C925: execute_one_pass (passes.c:1118) ==14240==by 0x65CAEB: execute_pass_list (passes.c:1171) ==14240==by 0x65CAFD: execute_pass_list (passes.c:1172) ==14240==by 0x735345: tree_rest_of_compilation (tree-optimize.c:404) ==14240==by 0x8E55E1: cgraph_expand_function (cgraphunit.c:1152) ==14240== ==14240== LEAK SUMMARY: ==14240==definitely lost: 5,632 bytes in 74 blocks. ==14240==indirectly lost: 448 bytes in 2 blocks. ==14240== possibly lost: 64 bytes in 2 blocks. ==14240==still reachable: 304,817 bytes in 958 blocks. ==14240== suppressed: 0 bytes in 0 blocks. ==14240== Reachable blocks (those to which a pointer was found) are not shown. ==14240== To see them, rerun with: --leak-check=full --show-reachable=yes
Re: Memory leaks in compiler
Jerry DeLisle wrote: With the Fortran test case I am using for PR34722. I did a valgrind check with the following command: valgrind --leak-check=full f951 inquire_12.f90 Here is a reduced test case. I will submit a PR. It has nothing to do with my iostat patch for pr34722. program gamsanal end Jerry
Re: Memory leaks in compiler
Bernhard Fischer wrote: On Fri, Jan 11, 2008 at 11:30:12AM -0800, Jerry DeLisle wrote: With the Fortran test case I am using for PR34722. I did a valgrind check with the following command: valgrind --leak-check=full f951 inquire_12.f90 The possible problem in mpfr has been around a while. The other two problems look like middle-end or back-end problems. Does this warrant a PR? Against what component? Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc43/configure --prefix=/home/jerry/gcc/usr --enable-languages=c,fortran --disable-libmudflap --enable-libgomp --with-mpfr-lib=/home/jerry/gcc/usr/lib --with-mpfr-include=/home/jerry/gcc/usr/include --disable-bootstrap Thread model: posix gcc version 4.3.0 20080111 (experimental) [trunk revision 131004] (GCC) I get the following: ==14240== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1) ==14240== malloc/free: in use at exit: 310,961 bytes in 1,036 blocks. ==14240== malloc/free: 2,207 allocs, 1,171 frees, 1,296,169 bytes allocated. ==14240== For counts of detected errors, rerun with: -v ==14240== searching for pointers to 1,036 not-freed blocks. ==14240== checked 2,346,928 bytes. ==14240== ==14240== 64 bytes in 2 blocks are possibly lost in loss record 1 of 8 ==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149) ==14240==by 0xB2F778: __gmp_default_allocate (in /mnt/sdb2/obj43/gcc/f951) ==14240==by 0x4C2B62D: mpfr_init2 (init2.c:53) ==14240==by 0x4C34424: mpfr_cache (cache.c:57) ==14240==by 0x4C18E48: mpfr_log (log.c:133) ==14240==by 0x4C2A4D1: mpfr_log10 (log10.c:111) ==14240==by 0x40A29F: gfc_arith_init_1 (arith.c:165) ==14240==by 0x443BC2: gfc_init_1 (misc.c:259) ==14240==by 0x47684D: gfc_init (f95-lang.c:288) ==14240==by 0x6D74F4: toplev_main (toplev.c:2128) ==14240==by 0x3B7EC1E073: (below main) (in /lib64/libc-2.7.so) ==14240== ==14240== ==14240== 408 bytes in 3 blocks are definitely lost in loss record 2 of 8 ==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149) ==14240==by 0xB1B4DB: xrealloc (xmalloc.c:177) ==14240==by 0x8B1265: vec_heap_o_reserve_1 (vec.c:176) ==14240==by 0x4FC09D: insn_locators_alloc (vecprim.h:27) ==14240==by 0xA759F8: tree_expand_cfg (cfgexpand.c:1862) ==14240==by 0x65C925: execute_one_pass (passes.c:1118) ==14240==by 0x65CAEB: execute_pass_list (passes.c:1171) ==14240==by 0x735345: tree_rest_of_compilation (tree-optimize.c:404) ==14240==by 0x8E55E1: cgraph_expand_function (cgraphunit.c:1152) ==14240==by 0x8E73C3: cgraph_assemble_pending_functions (cgraphunit.c:523) ==14240==by 0x8E6894: cgraph_finalize_function (cgraphunit.c:640) ==14240==by 0x49368B: gfc_generate_function_code (trans-decl.c:3403) Didn't look, but perhaps something like this? I don't see where locations_locators_locs and locations_locators_vals are freed either, but they seem to still be in use after locators_finalize... Index: gcc-4.3/gcc/cfglayout.c === --- gcc-4.3/gcc/cfglayout.c (revision 131470) +++ gcc-4.3/gcc/cfglayout.c (working copy) @@ -274,6 +274,9 @@ insn_locators_finalize (void) if (curr_rtl_loc >= 0) epilogue_locator = curr_insn_locator (); curr_rtl_loc = -1; + + VEC_free (int, heap, block_locators_locs); + VEC_free (tree, gc, block_locators_blocks); } /* Set current location. */ No, this does not fix it. Jerry
Re: Memory leaks in compiler
Kaveh R. GHAZI wrote: On Fri, 11 Jan 2008, Vincent Lefevre wrote: ==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149) ==14240==by 0xB2F778: __gmp_default_allocate (in /mnt/sdb2/obj43/gcc/f951) ==14240==by 0x4C2B62D: mpfr_init2 (init2.c:53) ==14240==by 0x4C34424: mpfr_cache (cache.c:57) ==14240==by 0x4C18E48: mpfr_log (log.c:133) ==14240==by 0x4C2A4D1: mpfr_log10 (log10.c:111) ==14240==by 0x40A29F: gfc_arith_init_1 (arith.c:165) ==14240==by 0x443BC2: gfc_init_1 (misc.c:259) ==14240==by 0x47684D: gfc_init (f95-lang.c:288) ==14240==by 0x6D74F4: toplev_main (toplev.c:2128) ==14240==by 0x3B7EC1E073: (below main) (in /lib64/libc-2.7.so) I'd say that this is a "bug" in GCC, that doesn't call mpfr_free_cache() before exiting. Now, this isn't really necessary in practice since the memory will be freed anyway. Jerry - does this fix it? --Kaveh 2008-01-16 Kaveh R. Ghazi <[EMAIL PROTECTED]> * toplev.c (toplev_main): Call mpfr_free_cache(). diff -rup orig/egcc-SVN20080116/gcc/toplev.c egcc-SVN20080116/gcc/toplev.c --- orig/egcc-SVN20080116/gcc/toplev.c 2008-01-03 23:37:34.0 +0100 +++ egcc-SVN20080116/gcc/toplev.c 2008-01-16 06:13:24.0 +0100 @@ -2276,6 +2276,8 @@ toplev_main (unsigned int argc, const ch if (!exit_after_options) do_compile (); + mpfr_free_cache (); + if (errorcount || sorrycount) return (FATAL_EXIT_CODE); Hi Kaveh, Yes this fixes the mpfr related memory leak. The cgraph related leaks are still in trunk. Jerry
Current failures on Cygwin
Here are gfortran failures I am seeing on Cygwin as of a few hours ago. I noticed some of these are at -O3, implying some optimization passes at fault. IIRC nint_2.f90 and default_format_denormal_1.f90 are not new. The rest of these are fairly recent. Maybe we need a meta-bug to track these. Regards, Jerry Running /home/Jerry/gcc/gcc44/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/array_constructor_24.f execution test FAIL: gfortran.dg/array_constructor_24.f execution test FAIL: gfortran.dg/array_constructor_24.f execution test FAIL: gfortran.dg/array_constructor_24.f execution test FAIL: gfortran.dg/default_format_denormal_1.f90 execution test FAIL: gfortran.dg/default_format_denormal_1.f90 execution test FAIL: gfortran.dg/default_format_denormal_1.f90 execution test FAIL: gfortran.dg/default_format_denormal_1.f90 execution test FAIL: gfortran.dg/default_format_denormal_1.f90 execution test FAIL: gfortran.dg/default_format_denormal_1.f90 execution test FAIL: gfortran.dg/default_format_denormal_1.f90 execution test FAIL: gfortran.dg/default_format_denormal_1.f90 execution test FAIL: gfortran.dg/nint_2.f90 execution test FAIL: gfortran.dg/use_only_1.f90 (internal compiler error) FAIL: gfortran.dg/use_only_1.f90 (test for excess errors) WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable FAIL: gfortran.dg/use_only_1.f90 (internal compiler error) FAIL: gfortran.dg/use_only_1.f90 (test for excess errors) WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable FAIL: gfortran.dg/use_only_1.f90 (internal compiler error) FAIL: gfortran.dg/use_only_1.f90 (test for excess errors) WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable FAIL: gfortran.dg/use_only_1.f90 (internal compiler error) FAIL: gfortran.dg/use_only_1.f90 (test for excess errors) WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable FAIL: gfortran.dg/use_only_1.f90 (internal compiler error) FAIL: gfortran.dg/use_only_1.f90 (test for excess errors) WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable FAIL: gfortran.dg/use_only_1.f90 (internal compiler error) FAIL: gfortran.dg/use_only_1.f90 (test for excess errors) WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable FAIL: gfortran.dg/use_only_1.f90 (internal compiler error) FAIL: gfortran.dg/use_only_1.f90 (test for excess errors) WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable FAIL: gfortran.dg/use_only_1.f90 (internal compiler error) FAIL: gfortran.dg/use_only_1.f90 (test for excess errors) WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable FAIL: gfortran.dg/g77/970915-0.f (internal compiler error) FAIL: gfortran.dg/g77/970915-0.f (test for excess errors) Running /home/Jerry/gcc/gcc44/gcc/testsuite/gfortran.dg/gomp/gomp.exp ... Running /home/Jerry/gcc/gcc44/gcc/testsuite/gfortran.dg/vect/vect.exp ... Running /home/Jerry/gcc/gcc44/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp ... Running /home/Jerry/gcc/gcc44/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp ... FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution, -O0 FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution, -O1 FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution, -O2 FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution, -Os
Re: Current failures on Cygwin
Tim Prince wrote: I verified your report of 2 new problems (new since 2 weeks ago, the last time I could bootstrap on cygwin): use_only_1.f90 segfaults the compiler at all optimization levels. array_constructor_24.f seems to get into a non-terminating loop at run-time, which segfaults eventually, with the problem showing up only at -O3. g77/970915-0.f is also segfaulting on compilation with no optimization. Jerry
Re: Current failures on Cygwin
Janus Weil wrote: Jerry DeLisle wrote: Tim Prince wrote: I verified your report of 2 new problems (new since 2 weeks ago, the last time I could bootstrap on cygwin): use_only_1.f90 segfaults the compiler at all optimization levels. array_constructor_24.f seems to get into a non-terminating loop at run-time, which segfaults eventually, with the problem showing up only at -O3. g77/970915-0.f is also segfaulting on compilation with no optimization. I'm afraid use_only_1.f90 and g77/970915-0.f are actually my fault (caused by rev. 134867). Will fix them soon. Cheers, Janus The patch for the use_only_1.f90 and gcc/970915-0.f has been committed and I confirm these two are fixed on Cygwin. The array_constructor_24.f is a different issue and still hangs. Jerry
Re: Failure building GFortran (Cygwin)
Ian Lance Taylor wrote: CC'ed to Eric. This may require some configury patches somewhere. Ian Angelo Graziosi <[EMAIL PROTECTED]> writes: The point isn't that to find workarounds. The point is, so as stand the things, unless a new Cygwin 1.5.25-16 (or 1.5.26-1 ?), the build of GFortran-trunk and friends is *officially* broken for cygwin-users. Thanks, Angelo. Dave Korn ha scritto: Angelo Graziosi wrote on 29 June 2008 11:38: Oops, I have discovered this, in libiberty/ChangeLog 2008-06-19 Eric Blake <[EMAIL PROTECTED]> Adjust strsignal to POSIX 200x prototype. * strsignal.c (strsignal): Remove const. You may need to build and install cygwin from CVS[*] to get the corresponding newlib fix and install it into your system headers in /usr/include. Or you could patch your /usr/include/string.h locally. See http://sourceware.org/ml/newlib/2008/msg00342.html for the other half of Eric's patch. cheers, DaveK [*] - You may not want to do that because of the 1.5 -> 1.7 WIP, in which case you could rebuild your current DLL from its source package and backport the patch linked above. A PR should be opened for this. Has that been done? Is it marked as a regression and as a blocker? Who has responsibility to fix this? Regards, Jerry
Re: Is that OK to borrow code from coreutils?
Steven Bosscher wrote: On Wed, Jul 9, 2008 at 11:48 PM, H.J. Lu <[EMAIL PROTECTED]> wrote: In that chmod() is not defined by the Fortran Standard, how can you infer that libgfortran's implementation is incorrect? Please read a decent UNIX system book or look how system () is implemented in glibc. Well, there's a helpful answer! You obviously want to change libgfortran for some reason. It seems only normal to me that you make an effort to explain why you think this is necessary. AFAIK the chmod in libgfortran, and in libg2c before that, has never been a problem for anyone. And with the basic rule "If it ain't broke, don't fix it" in mind, there is no reason to change the implementation to something more sophisticated. So what problem are you trying to solve? Got a test case? Please don't point back to the PR again, you're not explaining the problem there either, only the symptom. Surely, you didn't wonder off into libgfortran land if you didn't have a piece of real world code that has issues with the current libgfortran chmod? ;-) I vote that the PR be closed as invalid and drop this whole subject. I have reviewed the PR and this thread. Ripples in the pond and butterfly wings. Jerry
Re: REAL(16) ...on x86/x86-64
Steve Kargl wrote: On Mon, Aug 25, 2008 at 03:15:42PM -0700, Steve Kargl wrote: On Mon, Aug 25, 2008 at 11:50:16PM +0200, Dominique Dhumieres wrote: REAL(16) needs to be done in software -- on x86, x86-64 -- as it is not supported in hardware; if you want to use more than REAL(8) on x86, x86-64 you can use REAL(10). Or you use a system such as PowerPC which supports REAL(16) in silicon. As far as I can tell, the ifc implementation is a "real" one where the full 128 bits are used to code the real number. So far i did not have the time to play with it. Now concerning gfortran and since gcc requires gmp and mpfr, how difficult (efficient) would it be to use these libraries to implement REAL(xxx)? Getting +, -, *, and / working is almost trivial. The hard part is getting REAL(16) working in all the fun corners of the standard as well as getting IO working. Here's a start where one may need to distinguish between hardware FP and software emulation. With the patch I sent earlier with an off-by-1 fix in exponents, I get Kind: 4 8 10 16 Precision: 6 15 18 33 Digits: 24 53 64 113 Radix: 2 2 2 2 Min. exp.: -125 -1021 -16381 -16381 Max. exp.: 128 1024 16384 16384 on x86_64-*-freebsd. program probe real(4) a real(8) b real(10) c real(16) d print '(A,4(I0,x))', ' Kind: ', kind(a), kind(b), kind(c), kind(d) print '(A,4(I0,x))', 'Precision: ', precision(a), precision(b), & & precision(c), precision(d) print '(A,4(I0,x))', ' Digits: ', digits(a), digits(b), digits(c), & & digits(d) print '(A,4(I0,x))', 'Radix: ', radix(a), radix(b), radix(c), radix(d) print '(A,4(I0,x))', 'Min. exp.: ', minexponent(a), minexponent(b), & & minexponent(c), minexponent(d) print '(A,4(I0,x))', 'Max. exp.: ', maxexponent(a), maxexponent(b), & & maxexponent(c), maxexponent(d) end program probe This looks like a nice start. We already have support for real(16) I/O working so that will be a minor piece. There exists float-128 routines within the gcc libraries now. We need to figure out how to adapt/configure and use these. Steve, will you carry this patch forward to get +,-,*, and / working? In the meantime, is there someone knowledgeable of the flt-128 library that can guide us in this area. Maybe between Steve and I we can get it working with some mentoring on the configuration stuff. (target gcc 4.5) Jerry
Regressions on latest trunk
The following are failing: Running /mnt/sdb2/gcc43/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/interface_12.f90 -O2 execution test FAIL: gfortran.dg/interface_12.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/interface_12.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/interface_12.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/interface_12.f90 -O3 -g execution test FAIL: gfortran.dg/result_in_spec_1.f90 -O2 execution test FAIL: gfortran.dg/result_in_spec_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/result_in_spec_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/result_in_spec_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/result_in_spec_1.f90 -O3 -g execution test Seem to pass with no optimization. I was having no problems yesterday, so I suspect this is within the last 24 hours or so. This is on x86-64-linux-gnu, clean bootstrap, clean trunk. Updated a few hours ago. Jerry
[Fwd: Re: Problem compiling NONMEM with mingw gfortran 4.3.0 builds]
Forwarding to gcc list since there seems to be a C related problem here as well.
Example code below.
Original Message
Subject: Re: Problem compiling NONMEM with mingw gfortran 4.3.0 builds
Date: Sat, 21 Jul 2007 10:13:32 -0700
From: Jerry DeLisle <[EMAIL PROTECTED]>
To: Danny Smith <[EMAIL PROTECTED]>, Fortran List <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Danny,
I experimented with your simple Hello World in C running on Cygwin, writing to
CONOUT$. It does not error out, but does nothing.
On the gfortran side it creates a file named CONOUT$.
I would like to intercept this file name on mingw and cygwin systems and attempt
to map it to stdio in the gfortran runtime library. (band aid fix)
A couple of questions:
1) Is there a #define somewhere that I can use to conditionally compile this
"band aid" just for mingw and cygwin? I have looked in config.h and did not
find anything useful.
2) At least on cygwin, since the example does not work for the C version (I have
not tried mingw, but presume it works there) is there a "system" level fix for
this problem that would be more appropriate?
Best regards,
Jerry
Examples:
$ cat test.c
#include
#include
#include
int main()
{
int fd= _open ("CONOUT$", _O_RDWR);
if (fd >= 0)
_write (fd, "Hello world", sizeof ("Hello world"));
return 0;
}
$ cat test.f
open(unit=29,file="CONOUT$")
write(29,100)
100format('Hello, world!')
end
Re: GCC GSoC 2022: Call for project ideas and mentors
Perhaps someone could work on completing and merging the shared memory (native) fortran coarrays branch. Regards, Jerry On 3/9/22 6:39 AM, Martin Jambor wrote: Hello, I am pleased that I can announce that GCC has been accepted as a mentoring organization of Google Summer of Code 2022. Contributors(*) will be applying from April 4th to April 19th but have already seen some announcing their intention to apply and asking for guidance when selecting a project and preparing their applications. Please continue helping them figure stuff out about GCC like you always do. If anyone still wants to add a project to our idea list (and sign up to be a potential mentor), now is the time to do it. I'm looking forward to another year of interesting projects, Martin (*) Contributors no longer have to be students - they should however be "new or beginner" contributors to our project with the exception that participants of GSoC 2020 or GSoC 2021 can apply. More on changes this year is in my original call for projects: https://gcc.gnu.org/pipermail/gcc/2022-January/238006.html
Re: testsuite under wine
On 1/4/23 6:50 PM, NightStrike via Fortran wrote:
On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer wrote:
NightStrike wrote:
On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer wrote:
NightStrike wrote:
[...]
Second, the problems with extra \r's still remain, but I think we've
generally come to think that that part isn't Wine and is instead
either the testsuite or deja. So I'll keep those replies to Jacob's
previous message.
Most likely, it is a combination of the MinGW libc (which emits "\r\n"
for end-of-line in accordance with Windows convention) and the kernel
terminal driver (which passes "\r" and translates "\n" to "\r\n" in
accordance with POSIX convention). Wine, short of trying to translate
"\r\n" back to "\n" in accordance with POSIX conventions (and likely
making an even bigger mess---does Wine know if a handle is supposed to
be text or binary?) cannot really fix this, so the testsuite needs to
handle non-POSIX-standard line endings. (The Rust tests probably have
an outright bug if the newlines are being duplicated.)
You may be onto something here. I ran wine under script as `script -c
"wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r
prepended to the \r\n. I was making the mistake previously of running
wine manually and capturing it to a file as `wine64 ./a.exe > out`,
which as several have pointed out in this thread, that would disable
the quirk, so of course it didn't reveal any problems. I'm behind,
but I'll catch up to you guys eventually :)
So close, and yet so far... script(1) /also/ uses a pty, so it is
getting the same translations as Expect and therefore DejaGnu.
So at least we know for sure that this particular instance of extra
characters is coming from Wine. Maybe Wine can be smart enough to
only translate \n into \r\n instead of translating \r\n into \r\r\n.
Jacek / Eric, comments here? I'm happy to try another patch, the
first one was great.
I doubt that Wine is doing that translation. MinGW libc produces output
conformant to Windows conventions, so printf("\n") on a text handle
emits "\r\n", which Wine passes along. POSIX convention is that "\n" is
translated to "\r\n" in the kernel terminal driver upon output, so the
kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
"\r\r\n" at the pty master end. This is why DejaGnu testsuites must be
prepared to discard excess carriage returns. The first CR came from
MinGW libc; the second CR came from the kernel terminal driver; the LF
was ultimately passed through.
Jacek and I have been digging into this on IRC, and he's been very
helpful in trying to get further, but we're still stuck. We tried to
be more introspective, inserting strace both as "strace script wine"
and as "script strace wine". We tried running just "wine a.exe"
without any extra glue, and logging the raw SSH packets from putty.
After many iterations on these and other tests, Jacek finally had the
idea to try removing Windows entirely from the equation, and we ran
with a purely unix program / compiler combination:
#include
int main()
{
write(1, "test\r\n", 6);
return 0;
}
(and also as "test\n", 5)
In both versions, the following was observed:
case 1) ./a.out | xxd
case 2) script -c ./a.out out; xxd out
case 3) enable putting logging, ./a.out
In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an
extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
So, is it possible after all of this back and forth regarding mingw,
wine, and others, that it's down to the write() system call that's
inserting extra \r's? Is this expected?
I have reproduced this test with C. I suspect that the 'write' function
was written to accommodate non standard behavior of windows which
expects a CR-LF. This means that POSIX compliant code is adjusted by
the C or gfortran libraries to emit a extra CR so that on Windows it
will just work ok. So the test is doing exactly what you are telling it
to do. An LF causes the run times to add a CR in front.
With libgfortran I remember implementing some of this code myself and
this is the reason, to keep applications happy on Windows.
So the gfortran tests we wrote to accept either a CR or a CR-LF, and in
the test code to only issue a normal line ending which on UNIX will be
an LF and Windows an CR-LF.
I lose track of details in between looking ta the test cases. let me
know one of them to study that is gfortran side and will see what it is
doing.
Jerry
Re: testsuite under wine
On 1/5/23 7:33 PM, Jacob Bachmeyer via Fortran wrote:
NightStrike wrote:
On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer
wrote:
NightStrike wrote:
On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer
wrote:
[...]
So at least we know for sure that this particular instance of extra
characters is coming from Wine. Maybe Wine can be smart enough to
only translate \n into \r\n instead of translating \r\n into \r\r\n.
Jacek / Eric, comments here? I'm happy to try another patch, the
first one was great.
I doubt that Wine is doing that translation. MinGW libc produces output
conformant to Windows conventions, so printf("\n") on a text handle
emits "\r\n", which Wine passes along. POSIX convention is that "\n" is
translated to "\r\n" in the kernel terminal driver upon output, so the
kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
"\r\r\n" at the pty master end. This is why DejaGnu testsuites must be
prepared to discard excess carriage returns. The first CR came from
MinGW libc; the second CR came from the kernel terminal driver; the LF
was ultimately passed through.
Jacek and I have been digging into this on IRC, and he's been very
helpful in trying to get further, but we're still stuck. We tried to
be more introspective, inserting strace both as "strace script wine"
and as "script strace wine". We tried running just "wine a.exe"
without any extra glue, and logging the raw SSH packets from putty.
After many iterations on these and other tests, Jacek finally had the
idea to try removing Windows entirely from the equation, and we ran
with a purely unix program / compiler combination:
#include
int main()
{
write(1, "test\r\n", 6);
return 0;
}
(and also as "test\n", 5)
In both versions, the following was observed:
case 1) ./a.out | xxd
case 2) script -c ./a.out out; xxd out
case 3) enable putting logging, ./a.out
In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an
extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
So, is it possible after all of this back and forth regarding mingw,
wine, and others, that it's down to the write() system call that's
inserting extra \r's? Is this expected?
"This is why DejaGnu testsuites must be prepared to discard excess
carriage returns."
The write(2) system call inserts nothing and simply hands off the buffer
to the relevant part of the kernel I/O subsystem. (The kernel in POSIX
is *not* a monolithic black box.) When stdout for your test program is
a pty slave, that relevant part is the kernel terminal driver. The
kernel terminal driver is converting "\n" to "\r\n" upon output to the
associated port, since hardware terminals typically *do* require CRLF.
The associated port in this case is virtual and part of the kernel pty
subsystem, which presents octets written to that port to its associated
pty master device. The user-visible pty slave device acts just like a
serial terminal, including all translations normally done for handling
serial terminals.
A pty is conceptually a null-modem cable connected between two
infinitely-fast serial ports on the same machine, although the slave
will still report an actual baud rate if queried. (Run "stty" with no
arguments under script(1), an ssh session, or an X11 terminal emulator
to see what a pty slave looks like on your machine.)
In your case 1, the pty subsystem is not used and output is collected
over a pipe. Using "./a.out > out; xxd out" would produce the same
results. In cases 2 and 3, there is a pty involved, either set up by
script(1) or by sshd (assuming you meant "enable putty logging" in case
3) that performs the standard terminal translations. In all cases,
strace(1) will show the exact string written to the pty slave device,
which will not include any extra CRs because *those* *are* *inserted*
*by* *the* *kernel* *terminal* *driver* as the data is transferred to
the pty master device's read queue.
This insertion of carriage returns is expected and standardized behavior
in POSIX and is the reason Unix could use bare LF as end-of-line even
though hardware terminals always needed CRLF. CP/M (and therefore
MS-DOS which began its existence as a cheap CP/M knockoff) did not have
this translation layer and instead dumped the complexity of a two-octet
end-of-line sequence on user programs, leading to much confusion even
today. This is not a Wine issue, although the terminal escape sequences
in your original issue *were* from Wine. Note that the number of excess
carriage returns that a DejaGnu testsuite must be prepared to discard is
unspecified because running tests on remote targets may result in *any*
*number* of CRs preceding each LF by the time the results reach the test
driver machine in more complex testing lab environments.
-- Jacob
Agree
Fwd: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
I had this show up today. I have no idea what this is about. Please advise. Jerry Forwarded Message Subject: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master) Date: Sun, 29 Jan 2023 19:31:23 + From: buil...@sourceware.org To: Jerry DeLisle A new failure has been detected on builder gcc-gentoo-sparc while building gcc. Full details are available at: https://builder.sourceware.org/buildbot/#builders/231/builds/210 Build state: failed configure (failure) Revision: 8011fbba7baa46947341ca8069b5a327163a68d5 Worker: gentoo-sparc-big Build Reason: (unknown) Blamelist: Jerry DeLisle Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/1/logs/stdio - 2: rm -rf gcc-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/2/logs/stdio - 3: configure ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/3/logs/stdio
Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
On 1/30/23 5:46 AM, Sam James wrote: On 30 Jan 2023, at 06:27, Steve Kargl via Gcc wrote: Hi Steve, Please remove the skull and cross bones in the subject line. This is a sourceware project so I've CC'd the buildbot mailing list where we discuss these matters. Does the emoji bother you, or is it the skull and crossbones specifically (which is a recognised symbol for a hazard)? Note that this is the default upstream from the Buildbot project (we use their software) too. We haven't chosen it ourselves. Thanks, sam As long as your asking it just looks stupid, childish to think anyone needs an emoji in what we try think is a professional product. ( Too informal? ) If that's not enough, how about corny, or something for 12 year olds. Yep, it's just stupid. I don't have an issue with bots, I just don't need emojis outside of my personal chats on my phone. If it is suppose to be a notification, how about just the word "Alert" or "Notice" Regards, Jerry Jerry
Hosting our gfortran MatterMost workspace
Hello all and gcc overseers, I received a notice that the MasterMost server providers decided to drop their free service. Unfortunate and understandable. I plan to contact the Open Software Lab folks at Oregon State University to see if they can host for us. If anyone else has any suggestions of possible places we can host an instance, please let me know. The software for the platform is open source many folks self host, so we can do this. I am not sure where gcc.gnu.org is hosted, but that might be a logical place. Best regards, Jerry
Fwd: Hosting our gfortran MatterMost workspace
Forgot to copy the list on this. Forwarded Message Subject: Re: Hosting our gfortran MatterMost workspace Date: Fri, 5 May 2023 10:24:11 -0700 From: Jerry D To: Mark Wielaard On 4/29/23 5:36 AM, Mark Wielaard wrote: Hi, On Fri, Apr 28, 2023 at 08:55:44PM +0200, Bernhard Reutner-Fischer wrote: On 28 April 2023 18:46:07 CEST, Mark Wielaard wrote: OSUOSL already provides some machines for sourceware/gcc. If you could put a bit more technical details into that bugzilla issue, with expected usage (how many people, groups, moderation?) then we can coordinate and put it on the overseers agenda. Or you just ask Lance folks over there, but they'll need a ticket anyway. As long as there is a sensible IRC adapter I'm sure nobody would mind it. I'm not sure if anything ever happened to hosting these here, i only remember a quick poll some time ago locally. Just let us know what works best for you. If you feel it could be useful to the rest of the gcc/sourceware community we can coordinate through the overseers infrastructure ticket: https://sourceware.org/bugzilla/show_bug.cgi?id=29853 And we'll arrange a machine through Conservancy & OSUOSL. But if you are more comfortable setting something up just for the gfortran hackers and wanting to maintain it fully yourself then going directly to OSUOSL might be easier for you. Cheers, Mark I have sent an email to Lance at osuosl.org and Mark to see if we can get started on this. I am wondering how to migrate what we have now over to a new host. I will have to query the MatterMost web pages. Regards, Jerry
Build breakage
I am getting this failure to build from clean trunk.
In file included from ../../../../trunk/libgomp/config/linux/allocator.c:31:
../../../../trunk/libgomp/config/linux/allocator.c: In function
‘linux_memspace_alloc’:
../../../../trunk/libgomp/config/linux/allocator.c:70:26: error: format
‘%ld’ expects argument of type ‘long int’, but argument 3 has type
‘size_t’ {aka ‘unsigned int’} [-Werror=format=]
70 | gomp_debug (0, "libgomp: failed to pin %ld bytes of"
| ^
71 | " memory (ulimit too low?)\n", size);
|
| |
| size_t
{aka unsigned int}
../../../../trunk/libgomp/libgomp.h:186:29: note: in definition of macro
‘gomp_debug’
186 | (gomp_debug) ((KIND), __VA_ARGS__); \
| ^~~
../../../../trunk/libgomp/config/linux/allocator.c:70:52: note: format
string is defined here
70 | gomp_debug (0, "libgomp: failed to pin %ld bytes of"
| ~~^
||
|long int
| %d
RE: gcc on SCO
Dave Korn wrote: > But consider also > http://gcc.gnu.org/svn/gcc/trunk/README.SCO Which calls them "not a serious threat." I hadn't been closely following this, but that sure seems to be the case given last week's ruling. http://arstechnica.com/news.ars/post/20070812-sco-never-owned-unix-copyr ights-owes-novell-95-percent-of-unix-royalties.html http://en.wikipedia.org/wiki/Sco_group#SCO-Linux_lawsuits_and_controvers ies gsw
git gcc-verify question
Does anyone know what this is about? $ git gcc-verify Checking 918fcaf0cbf833063c45805ef893cfa2c9ebc875: OK Exception ignored in: Traceback (most recent call last): File "/usr/lib/python3.13/site-packages/git/cmd.py", line 563, in __del__ File "/usr/lib/python3.13/site-packages/git/cmd.py", line 544, in _terminate File "/usr/lib64/python3.13/subprocess.py", line 2227, in terminate ImportError: sys.meta_path is None, Python is likely shutting down I am on Fedora 41 just updated. Jerry
Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not
On 2/9/25 1:07 AM, Thomas Koenig wrote: Hello world, looking at a few Fortran bug reports, I found some cases where it was not clear if the program in question was standard-conforming or not. I would propose to add a keyword for that, tentatively called "interp". Comments? Suggestions for a different name? Should I just go ahead and create it? Best regards Thomas Your suggestion is reasonable and it happens often enough to be useful. It does not have to be an official interpretation needed necessarily. Sometimes we resolve these via discussion and comparison to other compilers. -- Jerry
Build appears to be broken.
I am getting this tonight. Jerry In file included from /home/jerry/dev/usr/include/c++/16.0.0/x86_64-pc-linux-gnu/bits/gthr-default.h:35, from /home/jerry/dev/usr/include/c++/16.0.0/x86_64-pc-linux-gnu/bits/gthr.h:157, from /home/jerry/dev/usr/include/c++/16.0.0/ext/atomicity.h:37, from /home/jerry/dev/usr/include/c++/16.0.0/bits/shared_ptr_base.h:61, from /home/jerry/dev/usr/include/c++/16.0.0/bits/shared_ptr.h:53, from /home/jerry/dev/usr/include/c++/16.0.0/memory:82, from ../../trunk/libcody/cody.hh:24, from ../../trunk/libcody/internal.hh:5, from ../../trunk/libcody/buffer.cc:6: /home/jerry/dev/usr/include/c++/16.0.0/ext/concurrence.h:257:32: error: cannot convert ‘’ to ‘unsigned int’ in initialization 257 | __gthread_cond_t _M_cond = __GTHREAD_COND_INIT; |^~~
