[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-11-09 08:20 --- This a target bug (stdcall symbol name decorati0on on windows targets) -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-11-09 08:24 --- Patch at: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00321.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #4 from d dot g dot gorbachev at gmail dot com 2008-11-09 11:30 --- (In reply to comment #3) Ok, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug middle-end/37323] [4.4 Regression] __builtin_apply failures
--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-09 10:57 --- Created an attachment (id=16639) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16639action=view) gcc44-pr37323.patch I guess the following patch should fix it. The question is if it doesn't break other targets... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37323
[Bug fortran/38065] New: bug5
Hello, Thank you for fixing the last bug I reported, number 37445. I am attempting to build my lens design program. I encounter the following errors when I compile file geomotfM.f90: /home/norm/design/source/geomotfM.f90:836.4: function CreateLine ( RayData, MaxFreq, NoOfGoodRays, ChromaticWeights, Err 1 Error: PUBLIC function 'createline' at (1) cannot be of PRIVATE type 'tline' This is incorrect. Both the type TLine and the function CreateLine are private to the module. The NAG, Intel and g95 compilers all compile this. I tried to reproduce this problem with a small example, but I did not succeed. As soon as I am assigned a bug number, I will upload a tar file, bug5.tgz to the following address: [EMAIL PROTECTED] Unpack the file and invoke the shell script bug5.sh to reproduce the problem. I'll indicate the bug number in the subject line. I am running Open SuSE 10.1 on a dual core Athlon chip. I'm using the gcc-trunk build: [EMAIL PROTECTED]:~/design/gfortran/production gfortran --version GNU Fortran (GCC) 4.4.0 20081109 (experimental) [trunk revision 141714] Copyright (C) 2008 Free Software Foundation, Inc. Thank you for your attention. Norm Clerman -- Summary: bug5 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: clerman at fuse dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug fortran/38065] bug5
--- Comment #1 from clerman at fuse dot net 2008-11-09 14:57 --- Subject: bug 38065 (my bug5) Attached is the file you will need to reproduce the problem. Thanks again for your assistance. Norm Clerman --- Comment #2 from clerman at fuse dot net 2008-11-09 14:57 --- Created an attachment (id=16640) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16640action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug fortran/38066] New: bug6 ambiguous reference
Hello everyone, I have created a small example to reproduce another bug I have found when I attempt to build my lens design program. I will upload a file to you, bug6M.tgz, as soon as I am assigned a bug number. The bug occurs in file bug6M.f90: bug6M.f90:17.21: CALL GetNullSet (search_set) 1 Error: Name 'getnullset' at (1) is an ambiguous reference to 'getnullset' from module 'pbit4set' This is not correct. The reference is not ambiguous. See file errepsetM.f90 and the statement. use PBit4Set, TErrorBitSet = TPBit4Set The NAG, Intel and g95 compilers all compile this code. Thank you for your attention. Norm Clerman -- Summary: bug6 ambiguous reference Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: clerman at fuse dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066
[Bug fortran/38066] bug6 ambiguous reference
--- Comment #1 from clerman at fuse dot net 2008-11-09 15:04 --- Created an attachment (id=16641) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16641action=view) see bug explanation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066
[Bug middle-end/37323] [4.4 Regression] __builtin_apply failures
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-09 16:28 --- Subject: Re: [4.4 Regression] __builtin_apply failures I guess the following patch should fix it. The question is if it doesn't break other targets... I'll give it a try. If this fixes the problem, the preceding comment needs adjustment. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37323
[Bug fortran/38065] bug5
--- Comment #3 from jv244 at cam dot ac dot uk 2008-11-09 17:22 --- (In reply to comment #2) Created an attachment (id=16640) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16640action=view) [edit] the shell script seems to have a few lines referring to your home, but it looks like most files are there. One missing file is: treetypeT.f90 please check that all files needed to reproduce the error are in the tarball, and that the procedure how to reproduce the error is clear enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug testsuite/38008] gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c unportable
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-09 17:28 --- Patch posted to gcc-patches... http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00328.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38008
[Bug fortran/37832] System_Clock
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-11-09 18:18 --- After doing some more testing and comparing g77 vs gfortran, gfortran actually provides higher resolution 1000 ticks/sec then g77 100 ticks/second on at least my platform (x86-64-linux) On Cygwin, results are identical except gfortran does allow integer(kind=8) where g77 does not. Therefore, I am closing this as not a bug. If greater timing precision is needed, then Steve's suggestion of binding to a custom C routine is the wy to go. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37832
[Bug tree-optimization/37950] failure in polyhedron benchmark when ftree-parallelize-loops is enabled
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-09 19:25:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37950
[Bug fortran/38065] bug5
--- Comment #4 from clerman at fuse dot net 2008-11-09 21:54 --- Subject: Re: bug5 Thank you for your prompt reply. I have reassembled all the files to reproduce the problem and they are in the attached file bug5a.tgz. My apologies for any problem this has caused. Norm Clerman jv244 at cam dot ac dot uk [EMAIL PROTECTED] wrote: --- Comment #3 from jv244 at cam dot ac dot uk 2008-11-09 17:22 --- (In reply to comment #2) Created an attachment (id=16640) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16640action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16640action=view) [edit] the shell script seems to have a few lines referring to your home, but it looks like most files are there. One missing file is: treetypeT.f90 please check that all files needed to reproduce the error are in the tarball, and that the procedure how to reproduce the error is clear enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. --- Comment #5 from clerman at fuse dot net 2008-11-09 21:54 --- Created an attachment (id=16642) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16642action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
GCC 4.3 picks non-const operator
Hello,
I am a bit surprised that GCC (Ubuntu 4.3.2-1ubuntu11) 4.3.2 picks the
char* operator rather than the const char* one in the code attached...
I thought I'd report it in case someone case explain it to me, or in
case it might be a bug.
Thanks an regards,
Hervé
#include iostream
#include cstring
class Test {
public:
operator const char* () const {
return abcdef;
}
operator char* () {
return strdup(ghijkl);
}
#ifdef AMBIGUOUS
char operator[](unsigned int) const {
return 'a';
}
#endif
};
int main() {
Test t;
if (t[0] == 'g') {
std::cout wrong one std::endl;
}
if (t[0] == 'a') {
std::cout right one std::endl;
}
return 0;
}
[Bug fortran/37159] RANDOM_SEED: PUT= check array size at compile time
--- Comment #7 from michael dot a dot richmond at nasa dot gov 2008-11-10 00:09 --- I get a compile-time error: [EMAIL PROTECTED]:~$ cat sort1.f90 PROGRAM sort1 INTEGER Count(1) !Current value of system clock CALL Random_Seed(Put=Count) END PROGRAM sort1 [EMAIL PROTECTED]:~$ gfortran sort1.f90 sort1.f90:3.23: CALL Random_Seed(Put=Count) 1 Error: Array PUT of intrinsic random_seed is too small (1/8) at (1) -- michael dot a dot richmond at nasa dot gov changed: What|Removed |Added CC||michael dot a dot richmond ||at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37159
[Bug driver/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c
--- Comment #7 from samuel dot thibault at ens-lyon dot org 2008-11-09 23:50 --- libiberty actually already has its own powerful getpwd () Attaching patches currently fails, I'll try to submit later if I remember (else remind me). -- samuel dot thibault at ens-lyon dot org changed: What|Removed |Added CC||samuel dot thibault at ens- ||lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21706
[Bug driver/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c
--- Comment #8 from samuel dot thibault at ens-lyon dot org 2008-11-09 23:52 --- Created an attachment (id=16643) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16643action=view) better patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21706
[Bug fortran/34771] [4.3 only] Parenthesis around character variables: No expression
--- Comment #1 from pault at gcc dot gnu dot org 2008-11-10 06:52 --- Tobias, Due to the parenthesis, it should print: Error: The upper bound in the last dimension must appear in the reference to the assumed size array (Error messages needs patch for PR 34665.) This is, of course, fixed (GNU Fortran (GCC) version 4.4.0 20081109). What do you want to do with 4.3?? If I remove the offedning part of gfc_get_parentheses in 4.3.3 20081108 (prerelease), it bootstrap and regtests OK. Further, this bug is gone:-) Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-10 06:52:36 date|| Summary|Parenthesis around character|[4.3 only] Parenthesis |variables: No expression|around character variables: ||No expression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34771
[Bug fortran/37159] RANDOM_SEED: PUT= check array size at compile time
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-11-10 03:16 --- If you check, the minimum size of count is 8 as returned by the size= argument if you use it. Try this. size is intent OUT. PROGRAM sort1 INTEGER Count(1) !Current value of system clock integer Size CALL Random_Seed(size=size) print *, size ! CALL Random_Seed(Put=Count) END PROGRAM sort1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37159
[Bug fortran/37836] ICE in gfc_trans_auto_array_allocation
--- Comment #3 from pault at gcc dot gnu dot org 2008-11-09 17:41 --- Subject: Bug 37836 Author: pault Date: Sun Nov 9 17:40:30 2008 New Revision: 141717 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141717 Log: 2008-11-09 Paul Thomas [EMAIL PROTECTED] PR fortran/37836 * intrinsic.c (add_functions): Reference gfc_simplify._minval and gfc_simplify_maxval. * intrinsic.h : Add prototypes for gfc_simplify._minval and gfc_simplify_maxval. * simplify.c (min_max_choose): New function extracted from simplify_min_max. (simplify_min_max): Call it. (simplify_minval_maxval, gfc_simplify_minval, gfc_simplify_maxval): New functions. 2008-11-09 Paul Thomas [EMAIL PROTECTED] PR fortran/37836 * gfortran.dg/minmaxval_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/minmaxval_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37836
[Bug bootstrap/38010] gcc/config.gcc needs adjustment for darwin10
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-09 21:12 --- Patch posted to gcc-patches... http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00333.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38010
[Bug middle-end/37809] [4.2/4.3/4.4 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi
--- Comment #7 from suckfish at ihug dot co dot nz 2008-11-10 07:44 --- Could someone commit the patch? [http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00147.html] I don't have SVN commit access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809
