--- Comment #2 from raeburn at raeburn dot org 2007-08-15 06:15 ---
Subject: Re: New: Warning when passing a pointer to a const array to a
function that expects a pointer to a non-cast one
On Aug 14, 2007, at 23:45, martin dot ferrari at gmail dot com wrote:
> Sorry if I'm misundersta
--- Comment #1 from raeburn at raeburn dot org 2007-08-15 06:13 ---
Subject: Re: New: Warning when passing a pointer to a const array to a
function that expects a pointer to a non-cast one
On Aug 14, 2007, at 23:45, martin dot ferrari at gmail dot com wrote:
> Sorry if I'm misundersta
--- Comment #3 from raeburn at raeburn dot org 2007-08-15 06:03 ---
Section 6.7.3 says: "If the specification of an array type includes any type
qualifiers, the element type is so-qualified, not the array type." The more I
think about it, the more I think the compiler is technically co
Sorry if I'm misunderstanding something or this is a FAQ, but I couldn't find
any reference, except for a unanswered mail with the same problem from 2000 at
http://gcc.gnu.org/ml/gcc-bugs/2000-10/msg00337.html (and I don't find it in
bugzilla either). The code looks semantically correct to me, the
On GCC-3.4.5 for mingw with Dwarf2-EH
Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,objc,f77 --disable-win32-registry --disable-shared
--disable-sjlj-exceptions -
--- Comment #10 from samuel dot thibault at ens-lyon dot org 2007-08-14
23:30 ---
This should have been fixed by svn commit 127290
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5212
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-14 23:28
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-14 23:26
---
Subject: Bug 33066
Author: fxcoudert
Date: Tue Aug 14 23:26:23 2007
New Revision: 127497
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127497
Log:
PR fortran/33066
* decl.c (gfc_get_type
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-14 23:02
---
Anyone calling DATE_AND_TIME without arguments probably actually *wants* to
have a no-op in their code, so I'd even be against fixing it ;-)
Well, Daniel, we have so many bugs to work on that I'll close this as W
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-14 22:43
---
Fixed, thanks for the bug report!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-14 22:40 ---
The iii bug is PR 27574.
So one problem was fixed for 4.1.0 and the other problem is already recorded as
a different PR number so I am going to close this as fixed.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-14 22:40
---
Subject: Bug 33073
Author: fxcoudert
Date: Tue Aug 14 22:40:00 2007
New Revision: 127494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127494
Log:
PR fortran/33073
* trans-intrinsic.c (bu
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
The following testcase ICEs on x64_64-linux with -m32 -O:
$ cat u.f90
subroutine scaleg(a, w)
real a(1), w(1)
a(1) = 2.0**int(w(1))
end
$ gfortran -m32 -c u.f90 -O1
u.f90: In function scaleg:
u.f90:3: internal compiler error: in copy_insn_1, at emit-rtl.c:4925
The regression happened somewh
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #2 from pcarlini at suse dot de 2007-08-14 22:32 ---
For some reason, I can't attach the patch, here it is, anyway:
Index: pt.c
===
*** pt.c(revision 127493)
--- pt.c(working copy)
***
--- Comment #1 from pcarlini at suse dot de 2007-08-14 22:29 ---
Yes, I can confirm this. The issue seems simple: at that line we are wrongly
calling TYPE_CONTEXT on a FUNCTION_DECL. In such circumstances the solution
normally adopted elsewhere is that in the draft, which in fact appear
--- Comment #9 from pcarlini at suse dot de 2007-08-14 22:16 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from paolo at gcc dot gnu dot org 2007-08-14 22:14 ---
Subject: Bug 27211
Author: paolo
Date: Tue Aug 14 22:13:45 2007
New Revision: 127493
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127493
Log:
/cp
2007-08-14 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #7 from paolo at gcc dot gnu dot org 2007-08-14 22:07 ---
Subject: Bug 27211
Author: paolo
Date: Tue Aug 14 22:07:31 2007
New Revision: 127492
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127492
Log:
/cp
2007-08-14 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.0
Known to work||4.2.1 4.1.3
--- Comment #1 from steven at gcc dot gnu dot org 2007-08-14 21:40 ---
No, the pointer comparison here is correct. Using rtx_equal_p here would result
in finding non-shared address rtx'en as false positives.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from steven at gcc dot gnu dot org 2007-08-14 21:34 ---
r127273 is this patch: http://gcc.gnu.org/ml/gcc-cvs/2007-08/msg00165.html
My initial reaction was, "What happens to the REG_RETVAL note, if the insn with
the REG_LIBCALL note?" I don't know what happens with the RE
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-14 21:33
---
Confirmed on x86_64-linux with -m32:
$ cat a.f90
real x(1)
call foo(nint(x))
end
$ gfortran a.f90 -m32
a.f90: In function MAIN__:
a.f90:1: internal compiler error: in gfc_add_modify, at fortran/trans.c:1
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-14 21:24 ---
Extended example (rejects-valid + accepts-invalid):
(Overlaps partially with PR31298)
module a
implicit none
interface operator(.op.)
module procedure sub
end interface
contains
function sub(i)
integer :: su
--- Comment #3 from andreast at gcc dot gnu dot org 2007-08-14 21:22
---
Created an attachment (id=14060)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14060&action=view)
preprocessed source
Added preprocessed source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33029
--- Comment #9 from burnus at gcc dot gnu dot org 2007-08-14 21:16 ---
(From update of attachment 13369)
> strcpy (new->local_name, name);
This does not make much sense for INTERFACE_INTRINSIC_OP.
The problem with being able to import an operator only once is related to PR
33072: operat
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Ke
subroutine PropagateGrid(wavl,grid,field)
parameter (KR=8); implicit real(KR) (a-h,o-z)
intent(in) wavl; intent(inout) grid; dimension grid(0:3,0:3)
complex(KR),intent(inout) :: field(*)
call PropagateField(wavl,nint(grid(0,1:)),field) !causes ICE
!call PropagateField(wavl,int(grid(0,
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-14 21:14
---
(In reply to comment #4)
> Your patch fixed my test cases.
>
> I do not have testresults on my HP workstation. I will try to find a copy of
> gfortran.dg/logical_3.f90 and test it.
OK, so I'm CCing the hppa main
Expected: An error that the user operator .sub. does not exist.
Actually: Compiles.
NAG f95:
Error: foo.f90, line 9: Cannot find symbol .SUB. in module A
module a
implicit none
contains
subroutine sub()
end subroutine sub
end module a
program test
use a, only: operator(.sub.)
end program
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-14 20:47 ---
Additional testcases:
(1) see loop in lines 23 and 32 in
http://gcc.gnu.org/ml/gcc-help/2007-08/msg00171.html
(2)
> SUBROUTINE SUSCEP(L,Iz)
> IMPLICIT NONE
> INTEGER L , Iz(L,L) , iznum, ix, iy
>
--- Comment #4 from mbo dot massimo at tiscali dot it 2007-08-14 20:37
---
ok I will try to generate gcc in a different build directory.
I read the gcc documentation a now known how to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33065
--- Comment #3 from seppo at totalviewtech dot com 2007-08-14 20:32 ---
Hi Andrew,
Thanks for the quick response. The static variable foofoo seems to be OK in
DWARF and the DW_AT_location is there. But for some reason I still do not see
the _non-static_ iii variable and its DW_AT_locati
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--- Comment #9 from dorit at gcc dot gnu dot org 2007-08-14 20:17 ---
PR32824 discusses a similar issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
--- Comment #4 from pcarlini at suse dot de 2007-08-14 19:25 ---
The issue in Comment #3 has long been fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
+===GNAT BUG DETECTED==+
| 4.1.2 (Ubuntu 4.1.2-0ubuntu4) (x86_64-pc-linux-gnu) Assert_Failure
sinfo.adb:351|
| Error detected at status_bar.ads:14:3|
| Please submit a bug report; see http://gcc.gnu.org/bugs.htm
While trying to build gcc 3.4.3 on a RHEL5/i386 system in a chroot we see
> Comparing stage2 and stage3 of the compiler
> gmake[1]: Entering directory `/opt/build/gcc-3.4.3-objdir3/gcc'
> [...]
> Bootstrap comparison failure!
> ./alloc-pool.o differs
> ./bb-reorder.o differs
> ./bt-load.o differs
--- Comment #12 from sje at gcc dot gnu dot org 2007-08-14 18:12 ---
Subject: Bug 32941
Author: sje
Date: Tue Aug 14 18:12:34 2007
New Revision: 127487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127487
Log:
PR tree-optimization/32941
* tree-eh.c (struct leh_t
--- Comment #3 from mbo dot massimo at tiscali dot it 2007-08-14 17:46
---
I don't know how to build in different directory.
Can you say me what I will do?
I did make command in the directory where I untared gcc
(/home/compiler/build/gcc/gcc-4.2.1)
--
http://gcc.gnu.org/bugzilla/s
--- Comment #6 from jigorou3 at mail dot goo dot ne dot jp 2007-08-14
17:46 ---
It looks like
zlib compiled w/ -O -msse -ftree-vectorize (built with fedora's rpm package
gcc-4.1.2-17)
has same problem.
In my environment, rpm-4.4.2.1-7.fc8 and seamonkey-1.1.3-6.fc8 segfault like
below
Function count_occurrences in rtlanal.c checks equalty of 2 rtx expressions by
comparing them instead of using rtx_equal_p:
if (x == find)
return 1;
should be:
if (rtx_equal_p (x, find))
return 1;
--
Summary: equalty of 2 rtx's are not checked with rtx_equal_p in
--- Comment #1 from Steve at Zook dot com 2007-08-14 17:28 ---
Created an attachment (id=14059)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14059&action=view)
Test C or C++ code fragment
For bad code compile: m68k-elf-gcc -c -save-temps -x c++ test.c
or: m68k-elf-g++ -c -save-te
When individual bit field members of a struct/class are declared as volatile,
the generated code may not treat them as volatile (code varies with -O and
-m choices). Non-bit field volatile members and bit field members of
volatile structs are always treated as volatile. The problem can be worked
ar
--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net 2007-08-14
17:19 ---
I know that, but that's irrelevant from a user interface perspective. The fact
remains that the error message is needlessly messy and would be far clearer and
less surprising to the user if it said 1.1 i
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-14 17:02 ---
Well 1.1 is not directly represented in double precission which is why you get
that "weird" number.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-14 17:01 ---
What happens if you don't build in the source directory?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33065
Consider:
struct T {} t;
bool b = 1.1 < t;
The code is invalid, but GCC's error message is peculiar:
"error: no match for 'operator<' in
'1.100088817841970012523233890533447265625e+0 < t'"
The long decimal expansion makes for a messy error that suggests the user typed
somethin
--- Comment #4 from pault at gcc dot gnu dot org 2007-08-14 16:44 ---
This fixes the problem. However there are some odd regressions that do not
seem to have anything to do with it but which must be investigated.
Paul
Index: gcc/fortran/expr.c
=
--- Comment #3 from pault at gcc dot gnu dot org 2007-08-14 16:36 ---
This fixes it but there are one or two regressions that I need to investigate.
Paul
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c
--- Comment #5 from michael dot a dot richmond at nasa dot gov 2007-08-14
16:16 ---
gfortran.dg/logical_3.f90 compiles without error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33062
--- Comment #4 from michael dot a dot richmond at nasa dot gov 2007-08-14
16:07 ---
Your patch fixed my test cases.
I do not have testresults on my HP workstation. I will try to find a copy of
gfortran.dg/logical_3.f90 and test it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33
--- Comment #1 from hjl at lucon dot org 2007-08-14 16:03 ---
isinfd32/isinfd64/isinfd128 are supposed to standard DFP functions.
They have the same names, independent of encodings.
--
hjl at lucon dot org changed:
What|Removed |Added
-
--- Comment #4 from drow at gcc dot gnu dot org 2007-08-14 16:02 ---
I encountered this as a build failure for powerpc-eabispe in libstdc++-v3.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-14 15:48 ---
Note: Instead of having the SEQUENCE property, the BIND(C) attribute ("type,
bind(c) :: t") suffices as well.
"Two data entities have the same type if they are declared with reference to
the same derived-type definit
R430 derived-type-stmt is TYPE [ [ , type-attr-spec-list ] :: ] type-name
[ ( type-param-name-list ) ]
Thus the :: is mandatory, however, gfortran does not give any diagnostic with
-std=f2003.
Expected: As with "type, private :: t" or "type, private, bind(c) t" give a
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-14 15:26
---
(In reply to comment #7)
> I suspect that '' is labels.0 (though it *has* a name!)
Well, that was wrong. If you look at the gimple tree (004t.gimple), it contains
the following:
print_sub (l, labels, _labels)
{
--- Comment #1 from mbo dot massimo at tiscali dot it 2007-08-14 15:20
---
Created an attachment (id=14058)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14058&action=view)
build log
the included file contains the log of the make process
--
http://gcc.gnu.org/bugzilla/show_
Error (I think) during generation of GCC 4.2.1:
Comparing stages 2 and 3
/bin/sh: line 9: cd: stage3-gcc: No such file or directory
Comparison successful.
gcc -v output:
Target: i686-pc-cygwin
Configured with: ./configure --with-gnu-as --with-gnu-ld
--enable-languages=c,c++,ada --with-gmp=/usr/loc
With current (today) trunk, building on x86-32bit host with
--enable-targets=all fails as follows. Just building 32bit (i.e. without
--enable-targets=all) works.
Host system is Debian (etch). Configure options are:
gcc/configure --prefix=/usr/local/gcc/head --enable-shared --with-system-zlib
--enab
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2007-08-14
14:48 ---
I have an HP MODEL 9000/778/B180L. It uses a PA-RISC 1.1 processor. The OS is
Debian Linux 3.1.
I will try your patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33062
--- Comment #10 from rask at gcc dot gnu dot org 2007-08-14 14:39 ---
Subject: Bug 30315
Author: rask
Date: Tue Aug 14 14:39:24 2007
New Revision: 127481
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127481
Log:
PR target/30315
* config/i386/i386.h (CANONICALIZE
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-14 14:28
---
I'll try to deal with that one, it looks nasty (although target-specific).
Thanks for the bug-report.
1. Can you report what HP-PA architecture this is happening on? And the OS?
(I have access to HP testdrive,
--
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 #7 from fxcoudert at gcc dot gnu dot org 2007-08-14 14:10
---
Reduced testcase:
subroutine print_sub(l, labels)
logical :: l
character (len=*), optional :: labels(1)
if (l) call foo
if (present(labels)) then
print *, labels(1)
end if
end
The logical and corre
--- Comment #8 from drow at gcc dot gnu dot org 2007-08-14 14:08 ---
I don't think there's anything useful we can do with it without a testcase,
unfortunately.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32955
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32977
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32987
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33054
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-14 13:42
---
(In reply to comment #3)
> One needs therefore to replace the current code by something which calls the
> library.
This was done, and the current error message was corrected.
--
fxcoudert at gcc dot gnu dot o
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-08-14 12:47
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-14 12:44
---
Subject: Bug 32594
Author: fxcoudert
Date: Tue Aug 14 12:44:19 2007
New Revision: 127478
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127478
Log:
PR fortran/32594
* trans-expr.c (gfc_co
--- Comment #10 from pcarlini at suse dot de 2007-08-14 10:04 ---
Apparently this is fixed in mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-14 09:25 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-14 09:25 ---
Subject: Bug 30428
Author: pinskia
Date: Tue Aug 14 09:24:26 2007
New Revision: 127477
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127477
Log:
2007-08-14 Andrew Pinski <[EMAIL PROTECTED]>
PR c/
--- Comment #5 from charlet at gcc dot gnu dot org 2007-08-14 09:20 ---
Closing as per latest changes.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-14 09:04
---
write(6,*) (/(s1(),i=1,3,-1)/)
!write(6,*) shape((/(s1(),i=1,3,-1)/))
contains
function s1()
character(len=1) :: s1
s1=" "
end function s1
end
Further reduced: no need for the substring in s1. You
--- Comment #6 from belyshev at depni dot sinp dot msu dot ru 2007-08-14
08:53 ---
Created an attachment (id=14057)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14057&action=view)
reduced a bit from bound_2.f90
Correction, you actually need "-O --param salias-max-array-elements=
--- Comment #5 from belyshev at depni dot sinp dot msu dot ru 2007-08-14
08:44 ---
gfortran.dg/bound_2.f90 and gfortran.dg/common_resize_1.f trigger this ICE with
"-O --param avg-aliased-vops=100"
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed
--- Comment #4 from charlet at gcc dot gnu dot org 2007-08-14 08:40 ---
Subject: Bug 19037
Author: charlet
Date: Tue Aug 14 08:40:11 2007
New Revision: 127422
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127422
Log:
2007-08-14 Olivier Hainque <[EMAIL PROTECTED]>
--- Comment #3 from fpbeekhof at gmail dot com 2007-08-14 08:11 ---
Subject: Re: std::tr1::tgamma produces wrong results [for
(x-1) in stead of for x]
OOPS!
Thank you! And sorry for wasting your time...
pcarlini at suse dot de wrote:
> --- Comment #2 from pcarlini at suse dot
88 matches
Mail list logo
