headers
Dominique Dhumieres | 1 Oct 14:18
Picon
Picon
Favicon

Re: [Patch, Fortran] PR fortran/35723: Some fixes to restricted-expression handling

Daniel,

> and commit in addition Dominique's test to prevent regressing in the future.

First the test I have sent has been extracted from pr36192 in order to show 
the lost errors.

Second, I don't think this test is needed if you remove the error "suppressors" 
from your patch. I think it would be more appropriate in the patch fixing the 
duplicate errors.

Dominique
Permalink | Reply | 4 comments |
headers
Daniel Kraft | 1 Oct 14:33
Picon

Re: [Patch, Fortran] PR fortran/35723: Some fixes to restricted-expression handling

Dominique Dhumieres wrote:
> Daniel,
> 
>> and commit in addition Dominique's test to prevent regressing in the future.
> 
> First the test I have sent has been extracted from pr36192 in order to show 
> the lost errors.
> 
> Second, I don't think this test is needed if you remove the error "suppressors" 
> from your patch. I think it would be more appropriate in the patch fixing the 
> duplicate errors.

Hi Dominique,

my point was to ensure these regressions don't occur at any point in the 
future, as (see my reasoning else-thread for that) I believe 
is_non_constant_shape_array is not really "right" in reporting errors 
and we may come across other problems with those; just speculating, though.

However, I don't think your test would be more appropriate with the 
patch for fixing the duplicate errors than it is now; my understanding 
is that the lost errors are more or less a bug uncovered (or at least 
something I would consider bad design) and neither related to either of 
the two patches...

But I'll do whatever you believe is best here.

Daniel

--

--
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dominique Dhumieres | 1 Oct 14:39
Picon
Picon
Favicon

Re: [Patch, Fortran] PR fortran/35723: Some fixes to restricted-expression handling

Daniel,

> But I'll do whatever you believe is best here.

I don't have a strong opinion on adding or not the test case.

I have had another look at pr36192 anf found that the number od duplicated errors is
related (proportional?) to the number of arrays in real, dimension(n,d) :: x, v ... .

I have a reduced test case for it, but I wonder if it is better to add it to pr36192
or to open a new pr (if you did not aleady open one)?

Dominique
Permalink | Reply | 2 comments |
headers
Daniel Kraft | 1 Oct 14:47
Picon

Re: [Patch, Fortran] PR fortran/35723: Some fixes to restricted-expression handling

Dominique Dhumieres wrote:
> Daniel,
> 
>> But I'll do whatever you believe is best here.
> 
> I don't have a strong opinion on adding or not the test case.
> 
> I have had another look at pr36192 anf found that the number od duplicated errors is
> related (proportional?) to the number of arrays in real, dimension(n,d) :: x, v ... .
> 
> I have a reduced test case for it, but I wonder if it is better to add it to pr36192
> or to open a new pr (if you did not aleady open one)?

No, I didn't and you're very welcome to do so!  If you mention the test 
with the lost errors there and ensure those errors should in any case be 
present, I'm also fine without this additional test here; I just don't 
want this gets forgotten and some time in the future maybe some other 
patch again removes the errors and then nobody finds it.

Daniel

--

-- 
Done:  Arc-Bar-Cav-Rog-Sam-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran-Tou
Permalink | Reply | 1 comment |
headers
Dominique Dhumieres | 1 Oct 15:03
Picon
Picon
Favicon

Re: [Patch, Fortran] PR fortran/35723: Some fixes to restricted-expression handling

> No, I didn't and you're very welcome to do so!

This is now pr37691. 

BTW I don't know what dg-expession should be used to distinguish between
single or multiple error messages produced by a single statement.

Dominique
Permalink | Reply | 0 comments |
headers
Michael Margitus | 1 Oct 20:37
Picon

gFortran and the /usr/local/bin directory

Hi,

I've just installed gFortran onto two different Mac OSX computers.   
When I look in the /usr/local/bin directories for each one, my desktop  
computer lists these files:

Magick++-config		fondu			identify			msginit		ps2pdf14
Magick-config		font2c			import			msgmerge	ps2pdfwr
Wand-config			fontforge		libwmf-config	msgunfmt	ps2ps
animate				freetype-config	lprsetup.sh		msguniq		ps2ps2
autopoint			frombin			lumper			ngettext		pv.sh
bdftops				gettext			mogrify			pdf2dsc		setfondname
compare			gettext.sh		montage		pdf2ps		showfond
composite			gettextize		msgattrib		pdfopt		stream
conjure				gs				msgcat			pf2afm		texdist
convert				gs-X11			msgcmp			pfaedit		tobin
dfont2res			gs-noX11		msgcomm		pfbtopfa		ufond
display				gsbj				msgconv		printafm		unix-lpr.sh
dumphint			gsdj				msgen			ps2ascii		wftopfa
dvipdf				gsdj500			msgexec		ps2epsi		xgettext
envsubst			gslj				msgfilter			ps2pdf
eps2eps				gslp				msgfmt			ps2pdf12
fixmswrd.pl			gsnd			msggrep		ps2pdf13

And my laptop has these files:

gfortran

I've never looked in this directory before, but I was wondering if all  
of those other files on my desktop computer were installed by
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bud Davis | 1 Oct 20:46
Picon
Favicon

Re: gFortran and the /usr/local/bin directory


> I've just installed gFortran onto two different Mac OSX
> computers.   
> When I look in the /usr/local/bin directories for each one,
> my desktop  
> computer lists these files:

/usr/local/bin is the traditional unix place for users to
install software. don't worry about that stuff. 

 
> 
> Fatal Error:  Can't open module file
> 'msgfmt.mod' for reading at (1):   
> No such file or directory
> 

you need a fortran module file called msgfmt.mod   you will probably need
to get it from wherever you received the fortran source.

HTH,
bud
Permalink | Reply | 0 comments |
headers
Steven Bosscher | 2 Oct 10:39
Picon

Re: [patch] Implement LEADZ and TRAILZ (Fortran 2008 intrinsics)

On Sun, Sep 28, 2008 at 8:04 PM, Paul Richard Thomas
<paul.richard.thomas <at> gmail.com> wrote:
> Tobias,
>
>> implement this as vendor extension shows its usefulness. Thus I would
>> not mind to have it still in 4.4, but deferring it to 4.5 is also
>> reasonable.
>
> Then let's go with it now - as you say, it is quite orthogonal, since
> it adds a new intrinsic.

OK, I take it no-one objects if I commit this tonight, then?

Gr.
Steven
Permalink | Reply | 1 comment |
headers
Paul Richard Thomas | 2 Oct 13:51
Picon

Re: [patch] Implement LEADZ and TRAILZ (Fortran 2008 intrinsics)

OK for me.

Many thanks for a very quick response to the correspondence on this.

Paul

On Thu, Oct 2, 2008 at 10:39 AM, Steven Bosscher <stevenb.gcc <at> gmail.com> wrote:
> On Sun, Sep 28, 2008 at 8:04 PM, Paul Richard Thomas
> <paul.richard.thomas <at> gmail.com> wrote:
>> Tobias,
>>
>>> implement this as vendor extension shows its usefulness. Thus I would
>>> not mind to have it still in 4.4, but deferring it to 4.5 is also
>>> reasonable.
>>
>> Then let's go with it now - as you say, it is quite orthogonal, since
>> it adds a new intrinsic.
>
> OK, I take it no-one objects if I commit this tonight, then?
>
> Gr.
> Steven
>

--

-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy
Permalink | Reply | 0 comments |
headers
Arjen Markus | 2 Oct 15:33
Picon
Favicon

Using chmod fails under MinGW

Hello,

I am experimenting with the GNU extensions for gfortran
under Windows (MinGW, gfortran 4.3.2-tdm-1 to be more precise)
to see how these functions and subroutines behave. I ran into
the following problem with chmod:

C:\DOCUME~1\HP_EIG~1\LOCALS~1\TempccONaqaG.o:chk_windows.f90:(.text+0x200):
undefined reference to `__gfortran_chmod_i4_sub'
collect2: ld returned 1 exit status

Apparently the chmod subroutine is recognised as an intrinsic,
but there is no suitable implementation.

Here is the relevant source code:

  call chmod( 'chk.dat', 'u+r', status )
  write(*,*) 'Changing status: ', merge('success', 'failure', status == 0 )

Using the function form gives a similar error message, this time
on __gfortran_chmod_func

Regards,

Arjen
Permalink | Reply | 9 comments |

Gmane