--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-26 22:43 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
I found that libgomp installs $PREFIX/include/omp_lib.f90, even in case
the Fortran frontend has not been configured nor built, for example when
configuring with --enable-languages=c,c++,objc,java --disable-libgcj.
include/omp_lib.mod and include/omp_lib_kinds.mod are not installed in
this case,
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-26 23:09 ---
It is unsigned int on Solaris too. Seems like glibc/Linux is the out man out
really as this was developed by the BSD folks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25914
gcc version 4.2.0 20060121
With optimzation the following code skips the last loop iteration:
#include stdio.h
int main(void)
{
int bits = 25;
while (bits) {
printf(bits=%d\n,bits);
if (bits = 8) {
bits -= 8;
--- Comment #1 from gdr at cs dot tamu dot edu 2006-01-26 23:16 ---
Subject: Re: New: libgomp installs include/omp_lib.f90 even if Fortran is not
built
gerald at pfeifer dot com [EMAIL PROTECTED] writes:
| I found that libgomp installs $PREFIX/include/omp_lib.f90, even in case
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-26 23:21 ---
(In reply to comment #1)
should not this be versioned as other components do (e.g. C++ header
files)?
That is a different bug which was already filed, PR 25938.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-26 23:28 ---
Confirmed, quickly looking at this DOM gets it wrong.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following code is meaningless therefore should produce the WARNING.
At least would be useful to have some pedantic warning mode when this should
produce warning.
Yuri
---testcase--
void a() { }
void f() {
return a();
}
--
Summary: return from funcrtion of void
--- Comment #15 from rakdver at gcc dot gnu dot org 2006-01-26 23:52
---
The patch fixes the problem by making gimplification of cleanups much more
robust, and able to handle nested statements, at the expense of producing a bit
worse code.
--
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-01-26 23:51
---
Created an attachment (id=10738)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10738action=view)
Possible patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
--- Comment #1 from gdr at cs dot tamu dot edu 2006-01-26 23:53 ---
Subject: Re: New: return from funcrtion of void value allowed
yuri at tsoft dot com [EMAIL PROTECTED] writes:
| The following code is meaningless
says you.
| therefore should produce the WARNING.
I'm unconvinced.
--- Comment #2 from yuri at tsoft dot com 2006-01-27 00:02 ---
This functionality was *added* on
purpose to allow generic codes to be written seamlessly
Sure!
Then code void f() { void x; retrun (x); } should work. But it produces:
t.C: In function `void f()':
t.C:2: variable or field
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-27 00:07 ---
http://www.glenmccl.com/ansi_023.htm
I don't know how old that page is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25986
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-27
00:12 ---
Subject: Re: strsignal.c:558: warning: comparison between signed and unsigned
It is unsigned int on Solaris too. Seems like glibc/Linux is the out man out
really as this was developed by the BSD folks.
/opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/bin/ -c -O2 -g -mpa-risc-2-0
-DIN
_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-pedant
ic -Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissing-format-a
ttribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-27 00:39 ---
Which revision is this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25987
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-27 00:40 ---
Is it before or after rev. 110274?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25987
--- Comment #4 from yuri at tsoft dot com 2006-01-27 00:44 ---
For templates it's sufficient to treat void as type in template
specializations.
No need to further change language.
Especially because generic programming doesn't really scale much beyond it's
'local' use like in STL.
--
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-27
00:53 ---
Subject: Re: insn-automata.c:2433: warning: implicit declaration of function
'hppa_fpstore_bypass_p'
Is it before or after rev. 110274?
Before (revision 110267M).
Dave
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-27 00:54 ---
Rev 110274 is where the fix went in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25987
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-27
00:55 ---
Subject: Re: insn-automata.c:2433: warning: implicit declaration of function
'hppa_fpstore_bypass_p'
Rev 110274 is where the fix went in.
Trying again.
Dave
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-27 01:01 ---
(In reply to comment #4)
No need to further change language.
Change what language? C++?
Well it is part of the C++ standard.
6.6.3/2:
A return statement with an expression of type cv void can be used only in
--- Comment #7 from gdr at cs dot tamu dot edu 2006-01-27 02:43 ---
Subject: Re: return from funcrtion of void value allowed
yuri at tsoft dot com [EMAIL PROTECTED] writes:
| For templates it's sufficient to treat void as type in template
| specializations.
| No need to further
--- Comment #8 from yuri at tsoft dot com 2006-01-27 03:09 ---
Let's close this PR as we do not have place for trolls.
I am basing my opinion on the very practical experience w/out any intent of
trolling.
You either provide an example of wide-range successful GP use or take back your
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-27 03:12 ---
(In reply to comment #8)
Let's close this PR as we do not have place for trolls.
I am basing my opinion on the very practical experience w/out any intent of
trolling.
Please at least know that the C++ standard
--- Comment #10 from yuri at tsoft dot com 2006-01-27 03:19 ---
I never advocated C. I only noted that language was unreasonably changed to
simplify few GP tricks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25986
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-27 03:22
---
(In reply to comment #10)
I never advocated C. I only noted that language was unreasonably changed to
simplify few GP tricks.
Changed when, before 1998 Almost 8 years now. I cannot remember what ARM
Compiling test.adb results in
test.adb:7:04: instantiation error at foo.adb:10
test.adb:7:04: S_Two is not visible
test.adb:7:04: instantiation error at foo.adb:10
test.adb:7:04: non-visible declaration at xy-z.ads:4
test.adb:7:04: instantiation error at foo.adb:10
test.adb:7:04:
I am getting the following on Trunk:
At line 1162 of file schkee.f
Fortran runtime error: Bad integer for item 1 in list input
With -O3 -march=pentium4 -funroll-loops
I think we reported this before but I am not finding the PR.
IIRC StevenB was going to delve into this optimization bug.
Can
-threads=posix
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.0 20060126 (experimental)
/home/perrin/gcc_HEAD/INSTALL/110282/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1
-E -quiet -v -iprefix
/home/perrin/gcc_HEAD/INSTALL/110282/bin/../lib/gcc/x86_64-unknown-linux-gnu
--- Comment #1 from perrin at msli dot com 2006-01-27 07:18 ---
Created an attachment (id=10739)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10739action=view)
code fails when compiled with -O2 -fopenmp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25989
built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/perrin/GOMP/gomp-20050608-branch/configure
--prefix=/home/perrin/GOMP/INSTALL/110296/ --enable-threads=posix
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.0-gomp-20050608-branch 20060126 (experimental) (merged
--- Comment #1 from perrin at msli dot com 2006-01-27 07:35 ---
Created an attachment (id=10740)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10740action=view)
fails with -fopenmp and -O2
contains two
#pragama omp parallel for
loops
--
101 - 133 of 133 matches
Mail list logo
