Hi,
On 2013-11-24 22:38, N.M. Maclaren wrote:
The main problem is that integer constant expressions in C are limited to
the built-in operators, of which the only tricky ones are division and
remainder (and, occasionally, multiplication) - see C11 6.6#3. Fortran
is not so limited, and there
Dear gfortraners,
On 2012-10-14 23:35, Janne Blomqvist wrote:
- I'd be vary wrt backporting, in my experience the module.c code is
somewhat fragile and easily causes regressions. In any case, AFAICS PR
51727 is not a regression.
Can this be reconsidered, as the benefits for users seem to be
/msg02515.html
On 2012-10-28 16:28, Tobias Schlüter wrote:
Ping. This issue stands in the way of a very simple solution of PR
fortran/51727. I've re-attached the patch for your convenience.
On 15 Oct 2012 at 22:51:05 +0200 Tobias Schlüter wrote:
The attached patch adds out-of-memory
Hi Thomas,
there are already lots of places that check for do variables,
gfc_check_do_variable() does the hard work. Couldn't the same result be
achieved in a much simpler way during resolution?
Cheers,
- Tobi
On 2012-11-01 13:58, Thomas Koenig wrote:
Hello world,
after the dicsussion
Ping. This issue stands in the way of a very simple solution of PR
fortran/51727. I've re-attached the patch for your convenience.
On 15 Oct 2012 at 22:51:05 +0200 Tobias Schlüter wrote:
The attached patch adds out-of-memory diagnostics for code using STL
containers by using
On 2012-10-14 23:44, Jakub Jelinek wrote:
On Mon, Oct 15, 2012 at 12:35:27AM +0300, Janne Blomqvist wrote:
On Sat, Oct 13, 2012 at 4:26 PM, Tobias Schlüter
I'm putting forward two patches. One uses a C++ map to very concisely build
up and handle the ordered list of symbols. This has three
Hi Janne,
thanks for the review.
On 2012-10-14 23:35, Janne Blomqvist wrote:
- Personally, I'd prefer the C++ version; The C++ standard library is
widely used and documented and using it in favour of rolling our own
is IMHO a good idea.
- I'd be vary wrt backporting, in my experience the
On 2012-10-14 23:44, Jakub Jelinek wrote:
On Mon, Oct 15, 2012 at 12:35:27AM +0300, Janne Blomqvist wrote:
On Sat, Oct 13, 2012 at 4:26 PM, Tobias Schlüter
I'm putting forward two patches. One uses a C++ map to very concisely build
up and handle the ordered list of symbols. This has three
Hi,
On 2012-10-14 23:44, Jakub Jelinek wrote:
On Mon, Oct 15, 2012 at 12:35:27AM +0300, Janne Blomqvist wrote:
On Sat, Oct 13, 2012 at 4:26 PM, Tobias Schlüter
I'm putting forward two patches. One uses a C++ map to very concisely build
up and handle the ordered list of symbols. This has
with a few examples that they both
produce identical .mod files as they should.
Is the C++ patch, modified to do the #include correctly, ok for the
trunk? If not, the C-only patch? Can I put the C-only patch on the
release branches? And which?
Cheers,
- Tobi
2012-10-13 Tobias Schlüter t
ps I forgot to mention that I also changed write_generic to traverse the
tree in defined order, this is the same in the C++ and the C-only patch.
Cheers,
- Tobi
On 2012-10-13 15:26, Tobias Schlüter wrote:
Hi,
first a question also to non-gfortraners: if I want to use std::map,
where do I
On 2012-10-13 20:00, Diego Novillo wrote:
On 2012-10-13 09:26 , Tobias Schlüter wrote:
first a question also to non-gfortraners: if I want to use std::map,
where do I #include map? In system.h?
No. Ada includes system.h in pure C code. Why not include it exactly
where you need it?
Ok, I
Hi Mikael,
On 2012-08-19 19:57, Mikael Morin wrote:
My main concern is this: the increased type safety by changing the
(void*) - (gfc_bbt*) change is balanced by the reduced type safety for
all the types inherited from gfc_bbt as the left and right pointer have
now gfc_bbt type instead of the
Dear Mikael,
On 2012-08-18 13:41, Mikael Morin wrote:
On 17/08/2012 23:32, Tobias Schlüter wrote:
The problem is that the initialization of format_asterisk is not allowed
in the C++ standard
So it's not valid ;-)
Sure, that's why I tried to work around it. My question
Following up on myself:
On 2012-08-16 14:59, Tobias Schlüter wrote:
A place where C++ inheritance is a trivial improvement is the red-black
tree used for storing various objects (gfc_symtree, gfc_gsymbol,
gfc_st_label, I think). This is currently implemented with macro-based
inheritance
on 30 November 2009).
Cheers,
- Tobi
Thus, the earlier patch is ok.
Thanks,
Richard.
2012-05-06 Janne Blomqvist j...@gcc.gnu.org
* configure.ac: Bump minimum MPFR version to 2.4.2.
* configure: Regenerated.
--
Janne Blomqvist
--
Tobias Schlüter
Am Coulombwall 1
Dear Tobias,
On 2011-11-01 22:33, Tobias Burnus wrote:
Regarding the tree-walking issue: I think it is a general issue which
could also affect other things. I really wonder why we haven't been
bitten by it before. However, it might be that we hit those problems and
fixed them by re-resolving
Hi Christopher,
On 2011-06-18 14:39, C. Bergström wrote:
On 06/18/11 05:16 PM, Toon Moene wrote:
On 06/18/2011 12:12 PM, Toon Moene wrote:
On 06/18/2011 05:05 AM, Christopher Bergström wrote:
Hi
We're in the process of considering contributing to gfortran for a
special project, but when
Hi all,
I'm sorry if I made this turn into a discussion of the benefits of Free
Software, just two short points ...
On 2011-06-19 18:58, Steve Kargl wrote:
On Sun, Jun 19, 2011 at 11:04:09PM +0700, C. Bergstr?m wrote:
Andy started the project and at the time of the fork still was the
--- Comment #33 from =?ISO-8859-1?Q?Tobias_Schl=FCter?=
tobias dot schlueter at physik dot uni-muenchen dot de 2009-08-15 10:17
---
Subject: Re: Invariant DO loop variables and subroutines
jv244 at cam dot ac dot uk wrote:
--- Comment #32 from jv244 at cam dot ac dot uk
--- Comment #35 from =?ISO-8859-1?Q?Tobias_Schl=FCter?=
tobias dot schlueter at physik dot uni-muenchen dot de 2009-08-15 10:58
---
Subject: Re: Invariant DO loop variables and subroutines
tkoenig at gcc dot gnu dot org wrote:
--- Comment #34 from tkoenig at gcc dot gnu dot org
--- Comment #14 from =?ISO-8859-1?Q?Tobias_Schl=FCter?=
tobias dot schlueter at physik dot uni-muenchen dot de 2009-08-13 23:33
---
Subject: Re: Invariant DO loop variables and subroutines
tkoenig at gcc dot gnu dot org wrote:
--- Comment #13 from tkoenig at gcc dot gnu dot org
--- Comment #7 from =?ISO-8859-1?Q?Tobias_Schl=FCter?=
tobias dot schlueter at physik dot uni-muenchen dot de 2009-08-12 18:11
---
Subject: Re: Invariant DO loop variables and subroutines
tkoenig at gcc dot gnu dot org wrote:
--- Comment #6 from tkoenig at gcc dot gnu dot org
Hi,
I'm seeing this error:
/Users/tobi/src/hggcc/build/./prev-gcc/xgcc
-B/Users/tobi/src/hggcc/build/./prev-gcc/
-B/usr/local/i386-apple-darwin8.11.1/bin/
-B/usr/local/i386-apple-darwin8.11.1/bin/
-B/usr/local/i386-apple-darwin8.11.1/lib/ -isystem
Joseph S. Myers wrote:
On Mon, 1 Jun 2009, Tobias Schlüter wrote:
The complaint is about:
ICONV_CONST char *inbuf = CONST_CAST (char *, ident);
[...snip...]
iconv_ret = iconv (cd, inbuf, inbytesleft,
outbuf
Hi Jack,
Jack Howarth wrote:
You didn't show the configure options you used to build gcc trunk
against the fink libraries. You need at least...
--with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
Note that we don't set
Geoff Keating wrote:
It seems like mostly, anyone using the compiler farm has to use
--with-mpfr, and otherwise people avoid it.
A random data point: if you use --with-gmp (as I have to), configure
finds an mpfr in the same subdirectory, so you might want to look for
that as well.
Cheers,
Gerald Pfeifer wrote:
On Tue, 14 Oct 2008, Tobias Schlüter wrote:
I'll take care of this, provided Gerald approves the change. Gerald, if
you think that copyright is a problem, I'll gladly rephrase it.
Thanks for the change, it looks like a good one. You may want to make
one or the other
Markus Milleder wrote:
Adrian Bunk schrieb am 13.10.2008 17:41:15:
E.g. the next stable release of Debian will likely ship with 2.3.1 .
So in this specific case fulfilling a 2.3.1 requirement would be easy,
while a 2.3.2 requirement would make it much harder to build gcc 4.4 .
Much harder ?
Hi,
the Mercurial repository has not been updated since svn revision 133268
which happened yesterday morning GMT. With all this talk about git
recently, I'm wondering if the Mercurial repository is still alive?
Cheers,
- Tobi
the f77 frontend I think */
/* copied from c-convert.c without significant modification*/
I don't think this file has ever been modified in any non-mechanical
way. So I'd assume that its contents are historical / accidental.
Cheers,
- Tobi
--
Tobias Schlüter
Am Coulombwall 1, Zi. 326
85748
Jan Hubicka wrote:
Thanks, I sent the patch for testing and lets see if it solves the
problem.
If the testsuite passes, and you intend to commit this, please add a FIXME.
Cheers,
- Tobi
Honza
Index: trans-decl.c
===
---
H.J. Lu wrote:
It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
return an address which can alias something else. But it isn't true
for realloc. Now, the qestions are
1. Can gcc make such an assumption?
2. Can realloc be marked as DECL_IS_MALLOC.
BTW, glibc also marks
FX Coudert [EMAIL PROTECTED] wrote on Mon, 16 Oct 2006:
For Fortran 2003 standard conformance, the Fortran front-end has to
know at compile-time what integer mode corresponds to some C99 types,
like intmax_t, intN_t, int_leastN_t, int_fastN_t.
For intN_t and int_leastN_t, I can see how to get
Dominique Dhumieres wrote:
On an AMD, the 20060105 build gives
tree SSA verifier : 9.55 (50%) usr 0.09 (23%) sys 9.62 (48%) wall
19 kB ( 0%) ggc
tree STMT verifier: 1.56 ( 8%) usr 0.00 ( 0%) sys 1.61 ( 8%) wall
0 kB ( 0%) ggc
TOTAL : 19.26
In looking at compiles times, I missed looking at memory usage:
Dominique Dhumieres wrote:
On an AMD, the 20060105 build gives
tree SSA rewrite : 0.45 ( 2%) usr 0.02 ( 5%) sys 0.36 ( 2%) wall
35265 kB (27%) ggc
tree SSA incremental : 0.71 ( 4%) usr 0.02 ( 5%) sys
Richard Guenther wrote:
I guess the fix for PR tree-optimization/22555 could make some difference
if fortran uses a lot of structures with embedded arrays. Basically this
enables decomposing these structures for aliasing purposes and should
generate better code.
It is perhaps noteworthy that
[ forwarding to gcc@gcc.gnu.org ]
Jerry DeLisle wrote:
I just did a fresh build testing a patch here and then I try make bubblestrap
and no target 'bubblestrap'
I'm curious myself. Was this an intentional result of the toplevel bootstrap
stuff?
- Tobi
Giovanni Bajo wrote:
The section is unneeded and duplicates the first paragraph of SvnBasic.
Please,
make sure to not insert duplicate information in the Wiki, prefer to link. I
have removed the duplicate.
Sorry, I had missed that section when I looked for it.
Thanks,
- Tobi
http://gcc.gnu.org/wiki/SvnSetup has the following example for
checking out the GCC sources under Checking out a tree
svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
but this doesn't work for me. Rather, I'm getting:
% svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
Permission denied
Paul Thomas wrote:
I spent nearly 5 hours yesterday reading the svn FAQ, mailing list
archives, and the docs. I never came across this solution.
Could somebody please distill the wisdom from this thread onto the
Wiki? I can understand why Steve might send 5 hours on it. It's bad
[ I've added gcc@ to the CC list and reproduced the message in full, FX
already got the buy a bigger harddisk answer there, I think it makes sense
to show that other people care about this, too ]
Steve Kargl wrote:
I fear the impending switch to subversion will have a negative impact on
the
Steve Kargl wrote:
On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote:
694Msvn40 -- svn 4.0 branch 694Msvn41 -- svn 4.1 branch 694M
trunk -- svn mainline
Now add one or two additional svn directories for large change sets and
this becomes intolerable. (Before anyone
Ingo Krabbe wrote:
Am Mittwoch, 14. September 2005 08:39 schrieb Gaurav Gautam, Noida:
I have a function written in fortran say fun(x, y), with x and y as integer
(scalars) . Function returns integer.
I need to call this function from a C program. How do I do it.
Can some one help me.
Does
Paul Thomas wrote:
Andrew,
This is PR 21766. Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02543.html.
You will have to explain this to me very slowly, preferably in baby talk
Heh, I thought the same when I read the desription of what happens :-)
- Tobi
(added [EMAIL PROTECTED] to the CC list, as that is the appropriate list for
this dicussion)
Gerald Pfeifer wrote:
To add a concrete example, unlike g77 in earlier versions of GCC, gfortran
is not and will not be part of the standard gcc40 port in FreeBSD.
Do you have a pointer to where this
Gerald Pfeifer wrote:
On Mon, 21 Feb 2005, Tobias Schlüter wrote:
To add a concrete example, unlike g77 in earlier versions of GCC, gfortran
is not and will not be part of the standard gcc40 port in FreeBSD.
Do you have a pointer to where this decision is explained?
That took place
Thomas Koenig wrote:
On Wed, Feb 16, 2005 at 10:59:00PM -0500, Jason Merrill wrote:
I suspect that the problem is that the transformations fold_indirect_ref_1
is doing on arrays don't mix well with how fortran handles arrays.
I have been trying to look at the problem in the BLAS sources,
48 matches
Mail list logo
