--- Comment #1 from martin at mpa-garching dot mpg dot de 2005-10-25 06:09
---
Would it be possible to add "gomp-branch" or something similar to the
"reported against" field in bugzilla?
--
martin at mpa-garching dot mpg dot de changed:
What|Removed
The current head of the gomp-branch fails to compile the following code:
class foo
{
void f(int *p)
{
#pragma omp parallel for
for (int i=0; i<1000; ++i)
p[i]=0;
}
};
[EMAIL PROTECTED]:~/tmp> g++ -v -c -fopenmp test.cc
Using built-in specs.
Target: x86_64-unknown-linux-gn
--- Comment #10 from fengwang at gcc dot gnu dot org 2005-10-25 05:31
---
This will improve 168.wupwise at lease 1%. And I have partially fixed. Patches
are coming soon.
--
fengwang at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from cvs-commit at gcc dot gnu dot org 2005-10-25 01:45
---
Subject: Bug 24224
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-25 01:45:03
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/gfortran.dg: arr
--- Comment #2 from cvs-commit at gcc dot gnu dot org 2005-10-25 01:32
---
Subject: Bug 24224
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-25 01:32:33
Modified files:
libgfortran: ChangeLog
libgfortran/io : io.h list_rea
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 01:00 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
The following valid code snippet is rejected when compiled with -fopenmp:
=
template void foo()
{
#pragma omp for
for (int i=0; i<10; i++) ;
#pragma omp for
for (int i=0; i<10; i++) ;
}
void bar()
{
foo<0>();
}
=
The program below fails to link with gcc 4.0.2. See also the closely related
bug 22263 (fixed in 4.0.2).
$ cat a.cpp && g++ -c a.cpp && g++ -DMAIN a.cpp a.o
template struct S { T foo (); T bar (); };
template T S::foo () { return T (); };
#ifndef MAIN
template struct S;
#else
extern template st
--- Comment #5 from amodra at bigpond dot net dot au 2005-10-24 23:26
---
I can't reproduce this problem. It seems likely that you have unusual values
for __GNUC__ and/or __GNUC_MINOR__, possibly due to local patches. You can see
what they are by running
./xgcc -B./ -E -dD - < /dev/n
--- Comment #8 from dalej at gcc dot gnu dot org 2005-10-24 21:41 ---
Incidentally, this bug started getting tickled (more, at least) on darwin due
to the fix for 15813. I'm not aware of any problems before that. However, the
15813 fix is correct and necessary.
--
http://gcc.gnu.o
--- Comment #1 from dje at gcc dot gnu dot org 2005-10-24 21:36 ---
fill_window() includes a loop whose count is based on WSIZE. The profile
prediction pass calculates an accurate count estimate of 0x8000. Other loops
have unknown loop bounds, which are estimated with a count of 3-10.
--- Comment #20 from laurent at guerby dot net 2005-10-24 21:31 ---
Jan Hubicka told me on IRC that Jakub Jelinek is working on PR23775 which might
be related (or the same issue) as this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-24 21:21 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-24 21:20 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from steven at gcc dot gnu dot org 2005-10-24 21:19 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24416
--- Comment #9 from pault at gcc dot gnu dot org 2005-10-24 21:13 ---
Fixed on mainline and 4.03.
The problem turned out to be that saved_string was not being freed after
character reads. This is done within read_ for every type other than
character, which is why it was missed. Have ad
--- Comment #8 from cvs-commit at gcc dot gnu dot org 2005-10-24 21:10
---
Subject: Bug 24416
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-24 21:10:14
Modified files:
libgfortran: ChangeLog
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2005-10-24 21:05
---
> I have some patches from Richard Kenner in my tree though. Eric, did you
> manage
> to reproduce the problem at all?
Nein. :-) But I'll try a bit harder tomorrow and on various machines.
--
ebotcazou at
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-24 20:20
---
Subject: Bug 24416
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-24 20:20:40
Modified files:
libgfortran: ChangeLog
libgfortran/io : list_read
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Nested derived type pointer |[4.0 only] Nested derived
|component not initialize
--- Comment #2 from jakub at gcc dot gnu dot org 2005-10-24 20:09 ---
Fixed in CVS.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #2 from jakub at gcc dot gnu dot org 2005-10-24 20:09 ---
Oops, sorry, I have messed up 2 checkins together.
Part of the fix is in
http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00991.html
as well.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-24 20:08 ---
The problem is that we don't record the rank of the lbound for some reason,
looking into it little more.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18003
--- Comment #1 from cvs-commit at gcc dot gnu dot org 2005-10-24 19:47
---
Subject: Bug 24502
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gomp-20050608-branch
Changes by: [EMAIL PROTECTED] 2005-10-24 19:47:18
Modified files:
gcc/cp : ChangeLo
--- Comment #18 from laurent at guerby dot net 2005-10-24 19:37 ---
Still seeing the failures on SuSE 9.3 i686 machine with
"-enable-languages=ada,c --enable-__cxa_atexit --disable-nls
--enable-threads=posix --disable-multilib" --enable-checking as of:
LAST_UPDATED: Mon Oct 24 17:22:09
--- Comment #2 from tromey at gcc dot gnu dot org 2005-10-24 19:31 ---
FWIW, I tried this with jamvm+classpath cvs, and got the expected result.
So it does appear to be gcj-specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24461
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-24 19:28
---
Subject: Bug 22282
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-24 19:28:18
Modified files:
gcc/fortran: ChangeLog check.c decl.c expr.c gfortran.h
--- Comment #8 from cvs-commit at gcc dot gnu dot org 2005-10-24 19:28
---
Subject: Bug 17031
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-24 19:28:18
Modified files:
gcc/fortran: ChangeLog check.c decl.c expr.c gfortran.h
--- Comment #11 from cvs-commit at gcc dot gnu dot org 2005-10-24 19:21
---
Subject: Bug 24225
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-24 19:20:38
Modified files:
gcc/testsuite : ChangeLog
gcc: ChangeLog
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-24 19:05 ---
Fixed. Thanks Mike.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
St
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #5 from mrs at apple dot com 2005-10-24 19:02 ---
Subject: Re: remaking existing build after cvs update gives configure recheck
problems
I think this problem can be marked as fixed. It was fixed by:
2005-05-04 Mike Stump <[EMAIL PROTECTED]>
* configure.in: Alw
--- Comment #7 from dalej at gcc dot gnu dot org 2005-10-24 18:55 ---
Indeed, the failing case I saw was C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
--- Comment #3 from tromey at gcc dot gnu dot org 2005-10-24 18:47 ---
I'm still not clear on exactly why we see the same data here.
However, I suspect this can be fixed by adding 'seeded = true' to
SHA1PRNG.engineSetSeed().
--
tromey at gcc dot gnu dot org changed:
What
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-24 18:43
---
I have a patch now which I am testing now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from eedelman at gcc dot gnu dot org 2005-10-24 18:43
---
(In reply to comment #10)
> Fixed on 4.1, on 4.0 there still seems to be some kind of bug.
The remaining problem on 4.0 seems to be fixed by the patch Richard Henderson
posted here: http://gcc.gnu.org/ml/fortran/
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-24 18:16
---
Here is the full problem, we get a loop.temp_ss but we don't build a reference
off from that to var.
Though, really we should get a REAL type loop.temp_ss instead of a user defined
type. Looking how to get the c
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-24 18:05 ---
Marking this as a 4.1 regression and moving to the target milestone as 4.1 as
it could most likely show up in C++ code too. For some analysis see PR 15023.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-24 18:03
---
(In reply to comment #9)
>Don't know how widespread this would be; other rs6000 targets for sure.
Yes this shows up as PR 23392 with the GNU runtime and objc exceptions.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #9 from dalej at gcc dot gnu dot org 2005-10-24 17:58 ---
Another bug in renaming just showed up on darwin rs6000. When renaming changes
a register in the RTL, it does not make the corresponding change in attached
FRAME_RELATED notes. This leads to inaccurate Dwarf exceptio
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-24 17:22
---
Subject: Bug 23617
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-24 17:22:41
Modified files:
gcc/java : ChangeLog zextr
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-24 17:19 ---
With -Wall, I get:
t.c: In function main:
t.c:6: warning: format %d expects type int *, but argument 2 has type
short int *
t.c:8: warning: format %d expects type int *, but argument 2 has type
short int
This bug is in all versions of gcc I tested: 3.2.3, 3.3.4, and 3.3.6. I am
using Slackware Linux version 10.2 on a Pentium 4 based PC, and the gcc it came
with, version 3.3.6. When the following program is compiled without
optimization, it runs correctly. When compiled with any optimization, th
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
I get an error message for the following code snippet:
void foo()
{
long n = 10;
int i;
#pragma omp for
for (i = 0; i < n; ++i) ;
}
bug.c: In function 'foo':
bug.c:6: error: invalid controlling predicate
This happens w
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-24 17:03 ---
At trans-expr.c:2756:
2756 tmp = gfc_trans_scalar_assign (&lse, &rse, expr1->ts.type);
lse is wrong. looking more into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18157
--- Comment #10 from eedelman at gcc dot gnu dot org 2005-10-24 16:56
---
Fixed on 4.1, on 4.0 there still seems to be some kind of bug. While the
testcase from PR 23924 now works, the testcase by Salvatore Filippone still
fails, but with a different error message:
erik:~$ gfortran
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-24 16:53 ---
The fold_convert bug is also PR 20244.
*** This bug has been marked as a duplicate of 20244 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-24 16:53 ---
*** Bug 24504 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-10-24 16:47 ---
We are trying to fold_convert
c12D.574[NON_LVALUE_EXPR + -1]
to struct une_classe (which is the main variant).
(the type is already une_classe - if the name does mean anything here)
Just fortran doesn't recognize
--- Comment #9 from cvs-commit at gcc dot gnu dot org 2005-10-24 16:41
---
Subject: Bug 21625
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-24 16:41:07
Modified files:
gcc/fortran: ChangeLog resolve
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2005-10-24 16:33
---
Ouch! I cannot reproduce with a i586-suse-linux compiler configured with full
checking and gccflags="-O2 -march=i686".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
--- Comment #4 from eedelman at gcc dot gnu dot org 2005-10-24 16:31
---
(In reply to comment #3)
> (In reply to comment #2)
> > I think I've seen this bug reported somewhere, but couldn't find it in a
> > quick
> > search.
> Looks to be PR 23675.
Yes, they seem to be the same, except
--- Comment #6 from pault at gcc dot gnu dot org 2005-10-24 15:58 ---
Thanks FX. Jerry DeLisle is having a stab at this so I have put him on the cc
list.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pcarlini at suse dot de 2005-10-24 15:58 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #9 from cvs-commit at gcc dot gnu dot org 2005-10-24 15:34
---
Subject: Bug 24450
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-24 15:33:58
Modified files:
libstdc++-v3/config/locale/gene
--- Comment #8 from cvs-commit at gcc dot gnu dot org 2005-10-24 15:31
---
Subject: Bug 24450
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-24 15:31:40
Modified files:
libstdc++-v3 : ChangeLog
Lo
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-24 15:22 ---
The left hand side is not getting the correct tree, we only have array[tmp]
instead of array[tmp].field.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18157
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-24 15:09 ---
Fixed for 4.1 by:
fortran/
* decl.c (gfc_match_save): Changed duplicate SAVE errors to
warnings in the absence of strict standard conformance
* symbol.c (gfc_add_save): Same.
--
pi
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24351
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-24 14:06 ---
Hmm, looks like the front-end is not using the correct expression, I might look
at this one soon.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-24 13:56 ---
(In reply to comment #2)
> I think I've seen this bug reported somewhere, but couldn't find it in a quick
> search.
Looks to be PR 23675.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24503
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24107
--- Comment #5 from pbrook at gcc dot gnu dot org 2005-10-24 13:02 ---
Fixed
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from dberlin at gcc dot gnu dot org 2005-10-24 12:55 ---
Subject: Re: [4.1 Regression] ICE in
do_simple_structure_copy with some C++ code
On Mon, 2005-10-24 at 11:55 +, rguenth at gcc dot gnu dot org wrote:
>
> --- Comment #7 from rguenth at gcc dot gnu
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-24 12:55
---
Subject: Bug 24107
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-24 12:55:37
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/gcc.dg: 20050
--- Comment #2 from erik dot edelmann at iki dot fi 2005-10-24 12:53
---
(In reply to comment #1)
> Here is what I get with the mainline of GCC:
> In file t.f90:12
>
> PUBLIC :: s_to_c
>1
> Error: 'string' is a PRIVATE type and cannot be a dummy argument of 's_to_c',
>
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2005-10-24 12:53
---
Here is another example of this problem (or so I think), reported today on the
list:
# cat bug.f90
program bugged
character*80 mc_sample
namelist /BUG/ mc_sample
! Sequence without read of Namelis
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-24 12:20 ---
On the mainline, we get a different ICE:
t.f90: In function 'nuees':
t.f90:36: internal compiler error: in fold_convert, at fold-const.c:2028
Please submit a full bug report,
with preprocessed source if appropriate.
Utilisation des specs internes.
Target: i386-redhat-linux
Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-li
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-24 12:16 ---
Here is what I get with the mainline of GCC:
In file t.f90:12
PUBLIC :: s_to_c
1
Error: 'string' is a PRIVATE type and cannot be a dummy argument of 's_to_c',
which is PUBLIC at (1)
--
http://gc
* the exact version of GCC;
> gfortran -v
Utilisation des specs internes.
Target: i386-redhat-linux
Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-10-24 11:55 ---
All of the fixes are wrong. The only safe thing papering over the problem is
disallowing this case with
Index: tree-ssa-structalias.c
===
RCS file: /c
The following valid code snippet is rejected by the C++ frontend when
compiled with -fopenmp:
=
template void foo()
{
int i;
#pragma omp for
for (i = 0; i < 10; i++) ;
}
=
bug.cc: In function 'void foo()':
bug.cc:5: error: ex
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-10-24 11:01 ---
Also, while we have the same types for lhs and rhs in do_structure_copy, namely
(gdb) call debug_tree(lhstype)
constant invariant 16>
unit size constant invariant 2>
align 8 symtab 0 alias set -1
fiel
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-10-24 10:46 ---
We are trying to copy 16 bits of
$5 = {id = 8, name = 0x896d7d0 "D.1877", decl = 0x4019ae18, offset = 8,
size = 8, fullsize = 16, next = 0x0, node = 8, address_taken = 0,
indirect_target = 0, is_artificial_var
--- Comment #8 from irar at gcc dot gnu dot org 2005-10-24 09:38 ---
Subject: Bug 24262
Author: irar
Date: Mon Oct 24 09:38:20 2005
New Revision: 105376
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105376
Log:
Bring over from mainline:
2005-10-12 Sebastian Po
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2005-10-24 09:33
---
(In reply to comment #7)
> I would guess a GNU make bug. What version of GNU make are you using? Try a
> newer release.
I had GNU Make version 3.78.1, which seems too old. 3.80 works fine. But...
later I have t
--- Comment #73 from pcarlini at suse dot de 2005-10-24 09:14 ---
(In reply to comment #72)
> why is it pointless? just because it doesn't work on some target architectures
> doesn't mean it doesn't work on most main archs.
Are you really, really, sure that without patching the middle-
--- Comment #10 from cvs-commit at gcc dot gnu dot org 2005-10-24 09:11
---
Subject: Bug 15586
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-24 09:11:52
Modified files:
gcc/fortran: ChangeLog arith.c check.c decl.c parse.c
--- Comment #1 from cvs-commit at gcc dot gnu dot org 2005-10-24 09:11
---
Subject: Bug 24493
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gomp-20050608-branch
Changes by: [EMAIL PROTECTED] 2005-10-24 09:11:47
Modified files:
gcc/fortran: ChangeLo
--- Comment #2 from bonzini at gcc dot gnu dot org 2005-10-24 07:01 ---
It should work by now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17269
84 matches
Mail list logo