--- Comment #1 from ludovic at ludovic-brenta dot org 2009-05-19 06:30
---
There was a typo in the original program that I mistakenly corrected. This
typo is the trigger for the bug:
with Ada.Unchecked_Conversion;
package Essai is
type Attributed_Chararcter is record -- line 3
--- Comment #3 from jb at gcc dot gnu dot org 2009-05-19 06:42 ---
Assigning to myself.
HJL is right, we should use the _r functions if available, if not we must
protect the calls with a mutex.
--
jb at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-19 07:31 ---
Created an attachment (id=17891)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17891action=view)
gcc45-pr40174.patch
thr-release is owned by thread, not team, and is initialized by the thread, so
it should be
--- Comment #5 from mikpe at it dot uu dot se 2009-05-19 08:24 ---
(In reply to comment #1)
I've been bootstrapping trunk pretty regularly for arm-linux-gnueabi on the
compile farm (though not building with latest libc) and haven't seen such a
problem .
Note that the bug report is
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-05-19 09:11 ---
(In reply to comment #3)
HJL is right, we should use the _r functions if available, if not we must
protect the calls with a mutex.
Janne, if mutexes are added, could you also add a note to the docs of that
these
The return value of this function is known at compile time, but from looking at
dump-tree-optimized this seems not to be optimized as such.
INTEGER FUNCTION F1()
INTEGER :: I1
INTEGER, TARGET :: I2
INTEGER, POINTER :: IP
INTERFACE
SUBROUTINE S(I1,I2)
INTEGER,INTENT(IN) :: I1
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-19 10:01 ---
OK, updated testcase, while the argument still holds for the previous code,
this was the intended code, and the generated code is even worse:
INTEGER FUNCTION F1()
INTEGER :: I1
INTEGER, TARGET :: I2
INTEGER,
--- Comment #2 from to dot my dot trociny at gmail dot com 2009-05-19
10:06 ---
The patch works for me.
Actually, calling mutex_destroy in gomp_thread_start() before return was the
first my solution and it solved my problem too. But I am not very familiar with
libgomp so I was not
--- Comment #2 from jv244 at cam dot ac dot uk 2009-05-19 10:14 ---
the context of the report is
http://gcc.gnu.org/ml/gcc/2009-05/msg00465.html
in particular, fortran variables are often not 'addressable' in the sense that
seems to be important of the gcc optimizers
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-19 10:20 ---
Does
SUBROUTINE S(I1,IP)
INTEGER,INTENT(IN) :: I1
INTEGER, POINTER :: IP
END SUBROUTINE S
allow that S stores the pointer to I1 to global memory?
I think that the easiest way to improve
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-19 10:39 ---
Hmm, DECL_BY_REFERENCE is set too often. Maybe in addition set/check
TREE_READONLY.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40194
--- Comment #8 from arjen dot verweij at tass-safe dot com 2009-05-19
10:59 ---
We use xlf 10.1.0.0 5724-M1300 on AIX and there is no problem there. The V10
manual[x] also prohibits it, but I don't see the V12 manual stating they broke
backwards compatability, so I will assume that it
D:\test\bingfortran -c ..\source\t2.f90
Fatal Error: Can't delete module file 'm.mod': Permission denied
gfortran: Internal error: Aborted (program f951)
Please submit a full bug report.
See http://gcc.gnu.org.bugs.html for instructions.
File ..\source\t2.f90 :
MODULE m
END MODULE
--
--- Comment #5 from eightdot at hotmail dot com 2009-05-19 11:23 ---
i agree but could find in which release they are first included..
but already fixed in what i now use (4.3.3)...
--
eightdot at hotmail dot com changed:
What|Removed |Added
Type parameter inquiry:
str%len is equivalent to len(str)
a%kind is equivalent to kind(a)
The real fun part starts with user-defined kinds, e.g.
type tp(dim)
integer, KIND :: dim
real :: dist(dim)
end type tp
type(tp) :: t(5)
print *, t%dist%dim
Quote from F2008 but F2003 should
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-19 11:36 ---
Another related item are complex parts; contrary to the type parameter inquiry
above, those are lvalues and can be assigned to. (Again a F2003 feature, quote
is however from F2008.)
R615 complex-part-designator is
--- Comment #5 from jv244 at cam dot ac dot uk 2009-05-19 11:54 ---
(In reply to comment #3)
Does
SUBROUTINE S(I1,IP)
INTEGER,INTENT(IN) :: I1
INTEGER, POINTER :: IP
END SUBROUTINE S
allow that S stores the pointer to I1 to global memory?
this is not a
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-19 12:04 ---
The intel compiler passes I1 by value:
..___tag_value_f1_.1: #1.18
subq $24, %rsp #1.18
..___tag_value_f1_.3:
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-19 12:10 ---
Hm, no. It doesn't pass it by value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40194
Spu.h needs to define PTRDIFF_TYPE, since fortran now uses this in compiling
trans-types. SIZE_TYPE probably should also be defined.
gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-19
12:35 ---
Created an attachment (id=17892)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17892action=view)
Define PTRDIFF_TYPE, SIZE_TYPE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40197
Compiling GCC-4.5.0:trunk or 20090514 fails on my System
Gentoo
Intel Atom N270
With following log message:
tmp-mlib.h; \
fi
echo '#include tree.def' tmp-all-tree.def
echo timestamp s-gtyp-input
lsf=; for f in $lsf; do \
echo #include \$f\; \
done |
Compiling the following program causes gcc to crash when using the -std=gnu99
option, but there is no crash without this option. I need to use this option
because the program uses language features such as loop initial declarations
which require passing -std=c99 or -std=gnu99 option.
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-19 14:36 ---
Actually http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01181.html is a better
patch since PTRDIFF_TYPE and SIZE_TYPE are documented to have defaults.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #11 from theresa dot adelt at greselius dot net 2009-05-19
15:45 ---
Hello!
I need help, too.
I want to compile with g95 the following easy program:
program prim
! Testet, ob eine gegebene Zahl prim
integer :: kandidat, teiler, rest
kandidat = 7099
do teiler = 2,
--- Comment #12 from tobi at gcc dot gnu dot org 2009-05-19 15:55 ---
Add an ampersand ()
(In reply to comment #11)
write(*,*)kandidat, ' ist nicht Teiler'
here ^^
and be sure to read the section on continuation lines in your
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-19 16:09 ---
I have no problems with 4.5 revision 147705 on Linux/ia32. If you
still have problems, please post the English version of the error
messages.
--
hjl dot tools at gmail dot com changed:
What
--- Comment #2 from joseph at codesourcery dot com 2009-05-19 16:15 ---
Subject: Re: No rule to make target `proto', needed by
`native'. Stop.
protoize and unprotoize were removed in 4.5 having been deprecated in 4.4
- either some reference did not get removed, or an old build
--- Comment #5 from jeff at schwabcenter dot com 2009-05-19 16:36 ---
Whoa whoa whoa... The behavior seemed correct before. vectorfloat[4]
shouldn't even be legal. Shouldn't the compiler to catch such a mistake?
--
jeff at schwabcenter dot com changed:
What
--- Comment #6 from paolo dot carlini at oracle dot com 2009-05-19 16:42
---
I think that, in any case, we cannot do anything wrong here: we are simply
restoring an implementation detail of the previous implementations, which, as a
side effect, allows to compile this specific kind of
Command
gcc file.cpp -o file.cpp
leads to overwriting of the code by the compiled version
I propose error or backup of the overwritten file if it is equal to the sourse
file.
This happened just now. I was in deep debug.
While it didn't compile - no problem.
As soon as I finished with all
--- Comment #7 from jeff at schwabcenter dot com 2009-05-19 17:09 ---
I understand the desire for backward compatibility, but are the semantics
actually the same? Are the vector values arrays, or do they decay to pointers?
Section 23.1 says standard container elements have to be
--- Comment #8 from paolo dot carlini at oracle dot com 2009-05-19 17:12
---
This is not going to change again. We had this behaviour forever until 4.3.x
and all the major implementations outside GCC behave the same as GCC now (and
before the change of behavior).
--
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-05-19 17:14 ---
Created an attachment (id=17893)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17893action=view)
Failing test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40187
--- Comment #4 from tkoenig at gcc dot gnu dot org 2009-05-19 17:17 ---
Created an attachment (id=17894)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17894action=view)
Driver for failing test case (identical to c_f_pointer_shape_tests_2_driver.c)
$ gfortran
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-05-19 17:18 ---
Since I'm working in this area anyway, I might as well take this.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jeff at schwabcenter dot com 2009-05-19 17:32 ---
OK. Thanks for the explanation. Are the semantics documented somewhere?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
Test case:
program testhour
use omp_lib
integer :: h(1000), h1(1000), bins(0:23), v(8)
call omp_set_num_threads(4)
print *, Running on,omp_get_max_threads(),threads
and,omp_get_num_procs(),procs.
!$omp parallel do schedule(STATIC,250)
do i=1,1000
call date_and_time(values=v)
h(i) = v(5)
--- Comment #10 from paolo dot carlini at oracle dot com 2009-05-19 17:38
---
Look closely at the patch I committed, I changed *nothing* of the actual
behavior of the containers. Thus the semantics is exactly the same as before,
only, the destructor in not called explicitly anymore on
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-19 17:47 ---
*** This bug has been marked as a duplicate of 40190 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-19 17:47 ---
*** Bug 40201 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40190
--- Comment #11 from coleb at eyesopen dot com 2009-05-19 17:57 ---
(In reply to comment #10)
Look closely at the patch I committed, I changed *nothing* of the actual
behavior of the containers. Thus the semantics is exactly the same as before,
only, the destructor in not called
--- Comment #12 from jeff at schwabcenter dot com 2009-05-19 18:07 ---
What he said. I'm perusing your patch, and I appreciate that you removed an
artificial restriction. The right place to catch this is up front, in a
concept check, rather than in _Destroy; since I'm not about to add
--- Comment #13 from paolo dot carlini at oracle dot com 2009-05-19 18:19
---
It's life, you know ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
--- Comment #4 from paolo at gcc dot gnu dot org 2009-05-19 18:20 ---
Subject: Bug 40184
Author: paolo
Date: Tue May 19 18:20:47 2009
New Revision: 147714
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147714
Log:
2009-05-19 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #5 from paolo dot carlini at oracle dot com 2009-05-19 18:24
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #25 from manu at gcc dot gnu dot org 2009-05-19 19:29 ---
Subject: Bug 40172
Author: manu
Date: Tue May 19 19:29:27 2009
New Revision: 147717
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147717
Log:
2009-05-19 Manuel López-Ibáñez m...@gcc.gnu.org
PR
--- Comment #26 from manu at gcc dot gnu dot org 2009-05-19 20:29 ---
The case in toplev.c cannot be fixed without tracking macro expansions somehow,
but I wonder why it warns (multiple times!) for this case:
../../trunk/gcc/config/mips/sb1.md:159: error: logical �or� of
void f(...);
struct X {
X();
};
void g() {
X x;
f(x);
}
nonpod.cpp: In function void g():
nonpod.cpp:9: warning: cannot pass objects of non-POD type struct X through
...; call will abort at runtime
Someone I know is currently trying to fix this warning in a very large
Hi. After several tries and a modicum of googling, I found that
CFLAGS=-m64 ../gcc-4.4.0/configure --disable-multilib
was the magic incantation to get gcc to get into the second stage of
the boostrap. This is on a Fedora Core 10 system.
This seems to be an old issue; google turns
--- Comment #27 from ddaney at caviumnetworks dot com 2009-05-19 20:58
---
Subject: Re: [4.5 Regression] Revision 147596 breaks bootstrap
manu at gcc dot gnu dot org wrote:
--- Comment #26 from manu at gcc dot gnu dot org 2009-05-19 20:29 ---
The case in toplev.c cannot
The asprintf() and vasprintf() prototypes are declared in stdio.h header
file.
The cstdio should be the adapted version of the same file for C++ language.
Nonetheless those two prototypes are missing.
Quoting from the cstdio:
/** @file include/cstdio
* This is a Standard C++ Library file. You
--- Comment #28 from hjl at gcc dot gnu dot org 2009-05-19 21:17 ---
Subject: Bug 40172
Author: hjl
Date: Tue May 19 21:17:00 2009
New Revision: 147719
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147719
Log:
2009-05-19 H.J. Lu hongjiu...@intel.com
PR c/40172
--- Comment #29 from hjl at gcc dot gnu dot org 2009-05-19 21:24 ---
Subject: Bug 40172
Author: hjl
Date: Tue May 19 21:24:23 2009
New Revision: 147720
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147720
Log:
2009-05-19 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #3 from wuddja at yahoo dot de 2009-05-19 21:28 ---
ok lets take a look at my config flags
/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.5.0-pre
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-19 22:02 ---
Both asprintf and vasprintf are extensions to the C (and the C++) standard so
...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-19 22:04 ---
So are you asking to print out 'x' here?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Compiling the following (nonsense but valid) code triggers an internal
compiler error.
Environment:
System: Linux thanatos 2.6.26-2-686-bigmem #1 SMP Thu Mar 26 02:03:34 UTC 2009
i686 GNU/Linux
How-To-Repeat:
Compile the following:
-- snip --
struct s {
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #2 from paolo dot carlini at oracle dot com 2009-05-19 22:25
---
Indeed, these are extensions and certainly the C++ standard doesn't say must be
made available in namespace std:: via cstdio. Actually, I think this PR is a
duplicate...
--
paolo dot carlini at oracle dot
--- Comment #3 from paolo dot carlini at oracle dot com 2009-05-19 22:27
---
Indeed...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-05-19 22:27
---
*** This bug has been marked as a duplicate of 39542 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-05-19 22:27
---
*** Bug 40203 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Aharon Robbins wrote:
Hi. After several tries and a modicum of googling, I found that
CFLAGS=-m64 ../gcc-4.4.0/configure --disable-multilib
was the magic incantation to get gcc to get into the second stage of
the boostrap. This is on a Fedora Core 10 system.
This seems to be an old
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-05-20 00:16
---
Subject: Bug 37754
Author: jvdelisle
Date: Wed May 20 00:16:38 2009
New Revision: 147725
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147725
Log:
2009-05-19 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #9 from rakdver at gcc dot gnu dot org 2009-05-20 00:34 ---
Subject: Bug 40087
Author: rakdver
Date: Wed May 20 00:33:54 2009
New Revision: 147727
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147727
Log:
PR tree-optimization/40087
*
--- Comment #56 from dave dot korn dot cygwin at gmail dot com 2009-05-20
04:25 ---
Created an attachment (id=17895)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17895action=view)
Target option and autoconf test to enable aligned common support.
Currently putting the attached
67 matches
Mail list logo
