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’
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
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
sonal chats on my phone.
If it is suppose to be a notification, how about just the word "Alert"
or "Notice"
Regards,
Jerry
Jerry
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
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 i
ests 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
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
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 e
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
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
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
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
e package managers by the
way. So the goal is a minimal installation of a fully functional Fortran.
Jerry
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
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 wh
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
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
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. (OpenCoarr
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
fix.
Regards
Jerry
ty One)
Jerry
)
Related to a recent patch adding COTAN function.
Regards,
Jerry
I see trunk is bumped to Version 6 now. Are we in Stage 1?
Jerry
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
.
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 untou
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
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
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
n 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
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
> &g
, 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
d.
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
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00690.html
[cc'ing gcc since it might be the better forum for this]
>
> 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_typ
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 (
PE. */
> >>
> >> 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
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_n
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
nter 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
ter 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
> 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 s
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
> > wa
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
erefore, 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
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
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:
> >>>&g
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.
> &
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
tches for
it, I thought I should isolate the actual broken checkin to make sure it
wasn't me :-)
Thanks,
Jerry
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 w
t the impression we need to subvert
automake to get this to happen.
Any thoughts?
Jerry
aybe 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
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
t 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
RCONTEXT(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
ears
to be related. How do these get used and would it even be used in a
C-like language?
Thanks,
Jerry Quinn
C. 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
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
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
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 referen
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 t
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
ful.)
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
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-x
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
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
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
ject. I
have reviewed the PR and this thread. Ripples in the pond and butterfly
wings.
Jerry
d for this. Has that been done? Is it marked as a
regression and as a blocker?
Who has responsibility to fix this?
Regards,
Jerry
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
eventually, with the problem showing up only
at -O3.
g77/970915-0.f is also segfaulting on compilation with no optimization.
Jerry
.
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
: 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.
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
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
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
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
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:
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
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
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
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 jo
.
After setting this up I would like to close PR5900
Regards,
Jerry
on i686-pc-linux-gnu.
Jerry
not-a-number
(NaN) and
errno is set.
Does anyone know where this is created.
Regards,
Jerry
86 matches
Mail list logo
