from Jerome Huck
Good morning.
I did use Gfortran GCC 9.0 on Windows 7 64 bits on an old Fortran77. I
attached both the source code and the GCC outputs.
I have warning with COMMON. The COMMONS are the same along the code...
When compiled I have warnings with different sizes !!!
I do not know if i
Hi:
Is there any possibility to parallel the compilation in a single file scope?
For large application the compilation time is long, although we
can parallel the process at the level of files, we still try to find a way to
accelerate the compilation in a single file. Can we change some serial
On 2014.07.29 at 08:07 +, Gengyulei (Gengyl) wrote:
> Hi:
>
> Is there any possibility to parallel the compilation in a single file
> scope? For large application the compilation time is long, although
> we can parallel the process at the level of files, we still try to
> find a way to acc
Good morning Jerome,
Jerome Huck wrote:
> I have warning with COMMON. The COMMONS are the same along the code...
> When compiled I have warnings with different sizes !!!
Well, neither /NO1/ nor /NO4/ are not the same size throughout the code.
> There were some bugs/issues in the past see :
Thos
Thank you for your answer. I find the most time consuming process in compiling
a file is the optimization of the cgraph nodes (execute all_passes),
This process is sequence, one node by one node. If we divide the cgraph nodes
into unrelated forest, we can parallel it, is this way feasible?
Tha
On 07/29/2014 10:27 AM, Gengyulei (Gengyl) wrote:
> Thank you for your answer. I find the most time consuming process in
> compiling a file is the optimization of the cgraph nodes (execute
> all_passes),
> This process is sequence, one node by one node. If we divide the cgraph nodes
> into unre
> Thank you for your answer. I find the most time consuming process in
> compiling a file is the optimization of the cgraph nodes (execute
> all_passes),
> This process is sequence, one node by one node. If we divide the cgraph nodes
> into unrelated forest, we can parallel it, is this way feas
On Mon, Jul 28, 2014 at 10:02 PM, Prathamesh Kulkarni
wrote:
> I am having few issues replacing op in c_expr.
> I thought of following possibilities:
>
> a) create a new vec vector new_code.
> for each token in code
> {
> if token.type is not CPP_NAME
> new_code.safe_push (token);
>
On Mon, Jul 28, 2014 at 11:49 AM, Richard Biener
wrote:
> On Sun, Jul 27, 2014 at 9:13 AM, Thomas Mertes wrote:
> > On Fri, Jul 25, 2014 at 12:35, Richard Biener
> > wrote:
> >> On Fri, Jul 25, 2014 at 10:43 AM, Thomas Mertes
> >> wrote:
> >> > On Thu, Jul 24 at 10:36 PM, Richard Biener
>
On Tue, Jul 29, 2014 at 1:17 PM, Thomas Mertes wrote:
> On Mon, Jul 28, 2014 at 11:49 AM, Richard Biener
> wrote:
>> On Sun, Jul 27, 2014 at 9:13 AM, Thomas Mertes wrote:
>> > On Fri, Jul 25, 2014 at 12:35, Richard Biener
>> > wrote:
>> >> On Fri, Jul 25, 2014 at 10:43 AM, Thomas Mertes
>>
Jeff Law writes:
> On 07/22/14 06:56, Richard Sandiford wrote:
> > I'll need to step down as MIPS maintainer this weekend in order to
> avoid
> > a possible conflict of interest with a new job. SC: please could you
> > appoint some new maintainers to take over?
> We'll get the process started.
>
> I think that if anybody has strong objections, now is the time to make
> them. Otherwise I think we should go with this plan.
IMHO the cure is worse than the disease.
> Given that there is no clear reason to ever change the major version
> number, making that change will not convey any useful
Eric Botcazou writes:
> Here we seem to be leaning towards a weird scheme where we retain the
> major version number but change its meaning, which will be even more
> confusing than the current scheme.
How does it change meaning? It's still the major number, just
incremented more often.
Andrea
On July 29, 2014 6:45:13 PM CEST, Eric Botcazou
wrote:
>> I think that if anybody has strong objections, now is the time to
>make
>> them. Otherwise I think we should go with this plan.
>
>IMHO the cure is worse than the disease.
>
>> Given that there is no clear reason to ever change the major
On 29 July 2014 18:14, Richard Biener wrote:
> On July 29, 2014 6:45:13 PM CEST, Eric Botcazou
> wrote:
>>> I think that if anybody has strong objections, now is the time to
>>make
>>> them. Otherwise I think we should go with this plan.
>>
>>IMHO the cure is worse than the disease.
>>
>>> Give
On 2014.07.29 at 19:14 +0200, Richard Biener wrote:
> On July 29, 2014 6:45:13 PM CEST, Eric Botcazou
> wrote:
> >> I think that if anybody has strong objections, now is the time to
> >make
> >> them. Otherwise I think we should go with this plan.
> >
> >IMHO the cure is worse than the disease.
On 29 July 2014 18:30, Markus Trippelsdorf wrote:
> Since gcc is released annually, why not tie the version to the year of
> the release, instead of choosing an arbitrary number?
>
> 15.o
What did the Romans every do for us? Release GCC XV, obviously...
Unfortunately, they couldn't release *.0 v
At Cauldron on the Sunday morning there was a Release Management BoF
session, replacing the specRTL talk (does anyone know what happened to
the latter?)
One of the topics was bug triage, and how many bug reports lacked basic
metadata on e.g. host/build/target, reproducer etc.
I suggested we could
On 29 July 2014 19:29, Joern Rennecke wrote:
> E.g. A GCC release on the 1st April 2015 at 09:00 UTC is made
> 90 days and 9 hours after the start of the year, and should thus carry
> the version number 2015.24760274
P.S.: a patchlevel release in a subsequent year can be marked by increasing
th
> How does it change meaning? It's still the major number, just
> incremented more often.
Reread Ian's post, the original idea is to drop the major version number.
--
Eric Botcazou
On 29 July 2014 21:58, Eric Botcazou wrote:
>> How does it change meaning? It's still the major number, just
>> incremented more often.
>
> Reread Ian's post, the original idea is to drop the major version number.
I think you're confusing the topic now.
What are you objecting to, calling the nex
On Tue, Jul 29, 2014 at 5:58 AM, Matthew Fortune
wrote:
> Jeff Law writes:
>> On 07/22/14 06:56, Richard Sandiford wrote:
>> > I'll need to step down as MIPS maintainer this weekend in order to
>> avoid
>> > a possible conflict of interest with a new job. SC: please could you
>> > appoint some n
22 matches
Mail list logo
