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 are
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 f
Hi all,
On 2012-10-14 23:35, Janne Blomqvist wrote:
On Sat, Oct 13, 2012 at 4:26 PM, Tobias Schlüter
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.
After receivi
://gcc.gnu.org/ml/gcc-patches/2012-10/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 wro
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 on
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
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. Thi
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
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 modu
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
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 "? In system.h?
No. Ada includes system.h in pure C code. Why not include it exactly
where you need i
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
problem with CP2K. I also verified 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?
Ch
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 w
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. It
t library search path, the --with-mpfr configure option
should be used. See also --with-mpfr-lib and --with-mpfr-include.
=
(for reference: mpfr 2.4.2 was released on 30 November 2009).
Cheers,
- Tobi
>
> Thus, the earlier patch is ok.
>
> Thanks,
> Richard.
>
>
>
>> 2012-05-06 Janne Blomqvist
>>
>>* configure.ac: Bump minimum MPFR version to 2.4.2.
>>* configure: Regenerated.
>>
>>
>>
>> --
>> Janne Blomqvist
--
Tobias Schlüter
Am Coulombwall 1, Zi. 317
85748 Garching b. München
Tel.: +49/89/289-14157
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
18 matches
Mail list logo
