[Bug fortran/30430] Memory corruption in the module search path code
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-01-11 08:01 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30430
[Bug target/30406] ICE in LOGICAL(8) functions
--- Comment #23 from fxcoudert at gcc dot gnu dot org 2007-01-11 08:08 --- The same code seems to be present in 4.1 and 4.2 branches. Andrew, would you mind include add a testcase to testsuite/gfortran.dg/ when you commit a patch? (if Andrew doesn't commit the patch, same request for the person actually doing it :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.0 |4.3.0 4.2.0 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406
[Bug tree-optimization/29516] gfortran miscompiled
--- Comment #31 from rakdver at gcc dot gnu dot org 2007-01-11 09:02 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00970.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||01/msg00970.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
[Bug c++/30434] New: wrong parse of exception declaration list in virtual functions with multiple inheritence
The C++ standard allows to add exceptions to the list of throwable exceptions
in virtual functions. But this does not work with multiple inheritence, as the
following example shows:
// CODE BEGIN
#include
#include
#include
#include
class my_exception
{
protected :
std::string error_message_;
public :
my_exception(std::string const & error_message)
:error_message_(error_message) {}
virtual ~my_exception() throw() {}
std::string const & what() const throw() {return error_message_;}
};
template
class A
{
protected :
T obj_;
public :
A(T const & obj) :obj_(obj) {}
virtual ~A() {}
virtual std::string get_obj_type() const =0;
};
class B : public A
{
public :
B(std::string const & obj) :A(obj) {}
virtual ~B() {}
virtual std::string get_obj_type() const throw(std::exception) {return
"string";}
};
class C : public A >
{
public :
C(std::vector const & obj) :A >(obj) {}
virtual ~C() {}
virtual std::string get_obj_type() const throw(std::exception) {return
"vector";}
};
class D : public B, public C
{
public :
D(std::string const & obj1, std::vector const & obj2) :B(obj1),
C(obj2) {}
virtual ~D() {}
virtual std::string get_obj_type() const
throw(std::exception,my_exception)
{
throw my_exception("which object?");
return 0;
}
};
int main(int argc, char ** argv)
{
D d("stupid string", std::vector());
try
{
std::cout << "type: " << d.get_obj_type() << std::endl;
}
catch (my_exception const & error)
{
std::cerr << error.what() << std::endl;
return -1;
}
return 0;
}
// CODE END
The compilation result is:
test_bis.cc:60: error: looser throw specifier for virtual std::string
D::get_obj_type() const throw (std::exception, my_exception)
test_bis.cc:40: error: overriding virtual std::string B::get_obj_type()
const throw (std::exception)
I have no error when D only inherits from either B or C.
--
Summary: wrong parse of exception declaration list in virtual
functions with multiple inheritence
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: florent_teichteil at yahoo dot fr
GCC build triplet: amd64 (x86_64)
GCC host triplet: amd64 (x86_64)
GCC target triplet: amd64 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30434
[Bug fortran/30435] New: Slash at end of input not recognized according to standard
The Fortran standard states that when you have list directed input, and a forward slash (/) appears at the end of a line of input, that any variables in the read statement that have not been initialized should simply be skipped over (ignored). When gfortran encounters a slash at the beginning of a line, it does not exhibit the correct behavior. For example, this data: 6.34 1.34 4345.34534 / with this read statement read(50, *)r1,r2,r3,r4 should set r1 to 6.34, r2 to 1.34, r3 to 4345.34534, and leave r4 unchanged. But gfortran code issues the following run time error: Fortran runtime error: Bad real number in item 4 of list input All other fortran compilers that I use (xlf, ifort, etc) handle this case correctly. -- Summary: Slash at end of input not recognized according to standard Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drewmccormack at mac dot com GCC build triplet: Configured with: ../gcc-4.3-20061223/configure --enable- language GCC host triplet: gcc version 4.3.0 20061223 (experimental) GCC target triplet: Target: powerpc-apple-darwin8.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30435
[Bug target/30429] internal compiler error: in emit_move_insn, at expr.c:2809
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-11 15:16 --- The 3.4 branch is no longer maintained, please try the latest release which is 4.1.1. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30429
[Bug driver/30437] New: -Wno-all is rejected
(Ignore that I have gcc installed in $HOME/powerpc, that's Apple's fault for not setting $HOSTTYPE correctly...) delices ~ $ ./powerpc/bin/gcc -Wno-all foo.c cc1: error: unrecognized command line option "-Wno-all" delices ~ $ ./powerpc/bin/gcc -v Using built-in specs. Target: i386-apple-darwin8.8.1 Configured with: ../configure --prefix=/Users/Chris/powerpc --enable-languages=c --with-mpfr=/Users/Chris/powerpc --with-gmp=/Users/Chris/powerpc Thread model: posix gcc version 4.3.0 20070110 (experimental) delices ~ $ gcc -Wno-all foo.c delices ~ $ gcc -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-arch=nocona --with-tune=generic --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5363) magic ~ $ gcc -Wno-all foo.c magic ~ $ gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/home/user/cpicke/x86_64 : (reconfigured) ../configure --enable-languages=c,c++,java : (reconfigured) ../configure --prefix=/home/user/cpicke/x86_64 --disable-multilib --enable-languages=c,c++,java Thread model: posix gcc version 4.1.1 [EMAIL PROTECTED]:~$ gcc -Wno-all ../test.c cc1: error: unrecognized command line option "-Wno-all" [EMAIL PROTECTED]:~$ gcc --version gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) [EMAIL PROTECTED]:~/120588/build$ gcc/xgcc -B gcc/ -Wno-all ~/pr24525.C cc1plus: error: unrecognized command line option "-Wno-all" [EMAIL PROTECTED]:~/120588/build$ gcc/xgcc --version xgcc (GCC) 4.3.0 20070108 (experimental) -- Summary: -Wno-all is rejected Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris dot pickett at mail dot mcgill dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug driver/30437] -Wno-all is rejected
--- Comment #1 from manu at gcc dot gnu dot org 2007-01-11 16:00 --- This seems like a regression to me. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug fortran/30438] New: Unused variable should raise warning with -Wunused
Just so that I don't forget, in the following code, t is set but never used: integer, parameter :: nconf = 4000, nmol = 300 integer, parameter :: nhist = 200 real, parameter :: delta = 0.05 integer :: conf, i, cote, idO, idH1, idH2 integer(kind=8) :: hist(2,2,nhist) real :: t, dist(2,3*nmol) open(10,file="e_dist.moy") open(20,file="cat_dist.moy") do conf = 1, nconf read(10,*) t, dist(1,:) read(20,*) t, dist(2,:) do i = 1, nmol if (dist(1,3*i-2) < dist(2,3*i-2)) then ! Côté électron cote = 1 else ! Côté cation cote = 2 end if idO = 1 + int(dist(cote,3*i-2) / delta) idH1 = 1 + int(dist(cote,3*i-1) / delta) idH2 = 1 + int(dist(cote, 3*i ) / delta) if (idO <= nhist) hist(cote,1,idO) = hist(cote,1,idO) + 1_8 if (idH1 <= nhist) hist(cote,2,idH1) = hist(cote,2,idH1) + 1_8 if (idH2 <= nhist) hist(cote,2,idH2) = hist(cote,2,idH2) + 1_8 end do end do close(10) close(20) end -- Summary: Unused variable should raise warning with -Wunused Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30438
[Bug preprocessor/15185] -M default target - -MT documentation
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-11 16:27 --- Subject: Bug 15185 Author: tromey Date: Thu Jan 11 16:26:55 2007 New Revision: 120679 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120679 Log: PR preprocessor/15185, PR preprocessor/20989: * doc/cppopts.texi <-MT>: Update description of algorithm for computing default target. <-M, -MD>: Reword "basename" text. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/cppopts.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15185
[Bug preprocessor/20989] The -M option gives object file names without directory
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-11 16:27 --- Subject: Bug 20989 Author: tromey Date: Thu Jan 11 16:26:55 2007 New Revision: 120679 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120679 Log: PR preprocessor/15185, PR preprocessor/20989: * doc/cppopts.texi <-MT>: Update description of algorithm for computing default target. <-M, -MD>: Reword "basename" text. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/cppopts.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20989
[Bug tree-optimization/1046] gcc less efficient than jdk for recursion with -finline-functions
--- Comment #15 from hubicka at gcc dot gnu dot org 2007-01-11 16:45 --- Subject: Bug 1046 Author: hubicka Date: Thu Jan 11 16:44:56 2007 New Revision: 120680 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120680 Log: PR tree-optimization/1046 * tree-tailcall.c (suitable_for_tail_call_opt_p): Use TREE_ADDRESSABLE when alias info is not ready. (pass_tail_recursion): Do not require aliasing. * tree-ssa-copyrename.c (pass_rename_ssa_cop): Likewise. * tree-ssa-ccp.c (pass_ccp, pass_fold_builtins): Likewise. * tree-ssa-copy.c (pass_copy_prop): Likewise. * tree-ssa-forwprop.c (pass_forwprop): Likewise. * tree-ssa-dce.c (pass_dce, pass_dce_loop, pass_cd_dce): Likewise. * passes.c (init_optimization_passes): Execute rename_ssa_copies, ccp, forwprop, copy_prop, merge_phi, copy_prop, dce and tail recursion before inlining. * tree-ssa-operands.c (add_virtual_operand, get_indirect_ref_operand): When aliasing is not build, mark statement as volatile. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/always_inline3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr15349.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr20701.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr21658.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr25501.c trunk/gcc/testsuite/gcc.dg/tree-ssa/tailrecursion-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/tailrecursion-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/tailrecursion-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/tailrecursion-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp05.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp11.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1046
[Bug tree-optimization/1046] gcc less efficient than jdk for recursion with -finline-functions
--- Comment #16 from hubicka at gcc dot gnu dot org 2007-01-11 16:50 --- Subject: Bug 1046 Author: hubicka Date: Thu Jan 11 16:50:32 2007 New Revision: 120681 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120681 Log: PR tree-optimization/1046 * tree-tailcall.c (suitable_for_tail_call_opt_p): Use TREE_ADDRESSABLE when alias info is not ready. (pass_tail_recursion): Do not require aliasing. * tree-ssa-copyrename.c (pass_rename_ssa_cop): Likewise. * tree-ssa-ccp.c (pass_ccp, pass_fold_builtins): Likewise. * tree-ssa-copy.c (pass_copy_prop): Likewise. * tree-ssa-forwprop.c (pass_forwprop): Likewise. * tree-ssa-dce.c (pass_dce, pass_dce_loop, pass_cd_dce): Likewise. * passes.c (init_optimization_passes): Execute rename_ssa_copies, ccp, forwprop, copy_prop, merge_phi, copy_prop, dce and tail recursion before inlining. * tree-ssa-operands.c (add_virtual_operand, get_indirect_ref_operand): When aliasing is not build, mark statement as volatile. * gcc.dg/tree-ssa/tailrecursion-4.c: Update dump file. * gcc.dg/tree-ssa/tailrecursion-1.c: Update dump file. * gcc.dg/tree-ssa/tailrecursion-2.c: Update dump file. * gcc.dg/tree-ssa/tailrecursion-3.c: Update dump file. * gcc.dg/tree-ssa/pr21658.c: Likewise. * gcc.dg/tree-ssa/pr15349.c: Likewise. * gcc.dg/tree-ssa/pr25501.c: Likewise. * gcc.dg/tree-ssa/vrp11.c: Make more complex so it still test transformation in question. * gcc.dg/tree-ssa/vrp05.c: Likewise. * gcc.dg/tree-ssa/pr20701.c: Likewise. * gcc.dg/always_inline3.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/tree-pass.h trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-ssa-copy.c trunk/gcc/tree-ssa-copyrename.c trunk/gcc/tree-ssa-dce.c trunk/gcc/tree-ssa-forwprop.c trunk/gcc/tree-ssa-operands.c trunk/gcc/tree-ssanames.c trunk/gcc/tree-tailcall.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1046
[Bug fortran/30404] Wrong FORALL result
--- Comment #3 from roger at eyesopen dot com 2007-01-11 16:56 --- Ok, I've now spent some time reading the code, I understand what's going wrong and what needs to be done to fix it. The problem resolves around the "nest_flag" argument to gfc_trans_nested_forall_loop. This argument only ever has the value zero when called from gfc_trans_forall_1 when calculating the mask for a nested forall. Unfortunately, this use is incorrect. Conceptually in a nested forall the mask needs to have one element for each execution/iteration of the assignment statement. So in Paul's reduced testcase in comment #5, the inner mask (translated as needs temp.5) to help in an array of size 4! This is required because the body of the loop may potentially affect either the inner or outer mask condition. So there's good news and bad news. The bad news is that in the general case, we can't determine how many times the loop body will be iterated at compile-time. When the loop bounds are constant, we can simply multiply together innersize * outersize. But often, the shape of the iteration may be irregular, such as triangular operations: forall(i=1:10,mask1[i]) forall(j=1:i,mask2[i,j]) foo(i,j) or completely irregular such as forall(i=1:10,mask1[i]) forall(j=1:bound[i],mask2[i,j]) bar(i,j) The good news is that the current expansion of forall loops can be restructured to get the fortran9x semantics correct. In the worst case, we need to generate another nested set of loops to determine the mask size, at run-time, before allocating and then populating the array. One nice aspect of this is that the inner mask can take into account how sparse the outermask is. i.e. for bar() above we can do better than sum(bound[1:10]). The bad news is this form of conservative implementation is likely to be less efficient than the current incorrect (and poor) implementation. The good news is that in follow-up patches, we should be able to significantly optimize FORALL much like we now do with WHERE and generate much more efficient code for the common case, with mask elimination, loop fusion etc... For Paul's example in comment #5, it should be possible to implement this loop without any mask arrays, as a single doubly-nested loop. However, the most immediate goal is rewriting gfortran's forall expansion to produce the correct result. Hopefully, I'll have the first in a series of patches to rewrite the basics of nested FORALL expansion soon. Unfortunately, its taking slightly longer than I anticipated, though I've now confirmed that this isn't a simple few-line fix, but a more fundamental design issue in nested forall expansion. Paul, Steve, Please let me know if you see an issue with the above analysis. Hopefully, the three-loop strategy of (i) determine mask size, (ii) populate mask and (iii) conditionally execute loop makes sense? -- roger at eyesopen dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |roger at eyesopen dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-01-08 11:23:23 |2007-01-11 16:56:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30404
[Bug fortran/30435] Slash at end of input not recognized according to standard
--- Comment #1 from kargl at gcc dot gnu dot org 2007-01-11 17:00 --- The relevant section of the F2003 standard is 10.9.1.1. It appears that in list-directed input that if we advance to a newline during the read and the first item hit is a / when get it wrong. Here a test program. program t integer a, b, c, d ! This works as expected open(unit=10, file='tmp.dat') write(10,*) '1 2 3 / 4' rewind(10) a = -1; b = -1; c = -1; d = -1; read(10,*) a,b,c,d print *, a,b,c,d ! This works as expected rewind(10) write(10,*) '1 2 3 /' rewind(10) a = -2; b = -2; c = -2; d = -2; read(10,*) a,b,c,d print *, a,b,c,d ! This works as expected. rewind(10) write(10,*) '1 2' write(10,*) '3 /' rewind(10) a = -3; b = -3; c = -3; d = -3; read(10,*) a,b,c,d print *, a,b,c,d ! This fails as reported. rewind(10) write(10,*) '1 2 3' write(10,*) '/' rewind(10) a = -4; b = -4; c = -4; d = -4; read(10,*) a,b,c,d print *, a,b,c,d close(unit=10, status='delete') end program t -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30435
[Bug fortran/30435] Slash at end of input not recognized according to standard
-- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-11 17:01:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30435
[Bug target/30429] internal compiler error: in emit_move_insn, at expr.c:2809
--- Comment #2 from hald at kc dot rr dot com 2007-01-11 17:03 --- This is one of the HP Testdrive machines (td176.testdrive.hp.com), so I am unable to modify what version of gcc is installed on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30429
[Bug fortran/30399] testsuite failures in actual_array_constructor_2.f90 and actual_array_substr_2.f90
--- Comment #19 from ghazi at gcc dot gnu dot org 2007-01-11 17:04 --- (In reply to comment #18) > Well then please accept my humble apology. No intent to disparage. I was > attempting to concur with Kaveh's suggestion in Comment #13 that ""WONTFIX" > may > be a more accurate description if that is the group decision." I should have > chosen better wording or simply remained silent. Apology accepted. IMHO a key part of my sentence you quote that you ignored in practice was "group decision". Two other gcc developer's (Eric and David) have signed up because they also care about this bug. Let's hold off on "WONTFIX" until the 4.0 branch is closed for good. Then we can eliminate 4.0-only bugs en-masse as I'm sure many remain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30399
[Bug fortran/30399] testsuite failures in actual_array_constructor_2.f90 and actual_array_substr_2.f90
--- Comment #20 from ghazi at gcc dot gnu dot org 2007-01-11 17:16 --- (In reply to comment #14) > Subject: Re: testsuite failures in actual_array_constructor_2.f90 > and actual_array_substr_2.f90 > Kaveh > > --- Comment #13 from ghazi at gcc dot gnu dot org 2007-01-10 21:45 > > --- > > Paul - The bug is not "FIXED" in 4.0, please don't mark it as such yet. > > "WONTFIX" may be a more accurate description if that is the group decision. > > You can remove yourself from the assigned field if you aren't able to work > > on > > it. > > > I am sorry, but I genuinely thought that only the testscases were present: > I checked out fortran and the testsuite from gcc-4_0-branch and could > not find any trace of this patch in the ChangeLogs but the testcases ARE > there. On this basis, I thought that there was nothing to fix. > > Regarding your last checkin to 4.0, the archives seem to show that you were > > the > > one who checked in the testcase and the fortran patches. > > > > http://gcc.gnu.org/viewcvs/branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/actual_array_constructor_2.f90?view=log > > > > So I'm somewhat mystified by your "hands unknown" comment. :-) > > > The evidence is incontrovertible :-) OK, it is obvious that I am > missing something here. Why does the 4.0 branch not reflect this patch? > > Could you please take a second look? Maybe the whole patch and the > > testcases > > should be reverted on 4.0? > > > Yes, please. Note that this is not a WONTFIX but rather a CANTFIX; my > time is taken by other things than gcc, right now, and, additionally, I > no longer have a 4.0 tree; in fact I just scrubbed 4.1 as well. > I am not trying to be difficult, cantankerous or awkward - I tried to > look into it and just do not understand what is going on. > Cheers > Paul Paul - I understand that you may not have time to actually fix the bug. However something seems to have gone wrong here and we need to address it. Your help in understanding where to go from here is necessary. And I believe that since you were the proximate cause of the problem (by mistakenly checking in the patch to 4.0) you are at least morally obligatged to help us understand what's the best course of action, within the confines of a volunteer effort. Can we agree on that? Now I see several possible paths forward: 1. Fix the actual bug. Probably not going to happen unless someone volunteers. 2. Revert just the testcases. 3. Revert the testcases and the code changes. I think if we go with 2 or 3 we need to understand what are the ramifications of leaving in or taking out the fortran frontend code changes that you mistakenly checked in last summer. That's where I think your help would be appreciated. Can you offer an opinion on which option is safer and why? "Safety" and avoiding regressions is paramount on 4.0 right now, as this branch should be kept very stable. Thanks, --Kaveh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30399
[Bug fortran/30404] Wrong FORALL result
--- Comment #4 from kargl at gcc dot gnu dot org 2007-01-11 17:25 --- (In reply to comment #3) > Paul, Steve, Please let me know if you see an issue with the above analysis. > Hopefully, the three-loop strategy of (i) determine mask size, (ii) populate > mask and (iii) conditionally execute loop makes sense? Roger, I haven't looked too closely at the guts of the forall implementation, but your analysis and 3-loop strategy to fixing the bug seems reasonable. In fact, most of the forall code may be the original code implemented by pbrook. I particularly like the concept of "make it work and then worry about optimizations". One thing to keep in mind is that the forall statement is a parallel assignment operation. You may be able to take advantage of the tree-vectorize work for the inner loop. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30404
[Bug c/30439] New: Intended Behaviour? #include searches for signal.h in local directory
Problem: #include does not include /usr/include/signal.h (the library header) if ./signal.h exists. Expected Behavior: If a file ./signal.h exists, #include includes /usr/include/signal.h and #include "signal.h" includes ./signal.h As far as I know, ANSI C states that #include includes only library files and not user files (e.g. in the local directory). Steps to Reproduce: try to compile attached testcase Additional Information: gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/gcc-4.1.1-r1/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.1 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.1 (Gentoo 4.1.1-r1) -- Summary: Intended Behaviour? #include searches for signal.h in local directory Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andersin at freenet dot de GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30439
[Bug c/30439] Intended Behaviour? #include searches for signal.h in local directory
--- Comment #1 from andersin at freenet dot de 2007-01-11 17:29 --- Created an attachment (id=12884) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12884&action=view) testcase Testcase: if ./signal.h exists, it fails to compile, since sig_atomic_t is not defined. If ./signal.h does not exist it works fine, since /usr/include/signal.h is included. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30439
[Bug c/30439] Intended Behaviour? #include searches for signal.h in local directory
--- Comment #2 from andersin at freenet dot de 2007-01-11 17:31 --- Created an attachment (id=12885) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12885&action=view) output on failure output of gcc -v source.c if ./signal.h exists -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30439
[Bug tree-optimization/30440] New: internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472
Internal compiler error in tree-ssa-pre.c when compiling lib_vwk.c in Situs version 2.2.1. To reproduce: tar xvzf Situs_2.2.1.tar.gz cd Situs_2.2.1 make all The result: gcc -I/usr/local/include -I../fftw -O3 -g -Wall -D_SMP_ -DMAX_NUM_THREADS=16 -c ./lib_vwk.c ./lib_vwk.c: In function 'create_laplacian': ./lib_vwk.c:536: internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472 Build & platform: gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) Kubuntu 6.10 (Edgy), with current updates as of 1/11/07 Additional information: Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix -- Summary: internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jasonmbechtel at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
[Bug c/30439] Intended Behaviour? #include searches for signal.h in local directory
--- Comment #3 from andersin at freenet dot de 2007-01-11 17:32 --- Created an attachment (id=12886) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12886&action=view) preprossesed source on error Preprocessed source when ./signal.h exists and compiling fails -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30439
[Bug c/30439] Intended Behaviour? #include searches for signal.h in local directory
--- Comment #4 from andersin at freenet dot de 2007-01-11 17:33 --- Created an attachment (id=12887) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12887&action=view) output on success Output when running gcc -v signal.c when ./signal.h is not present -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30439
[Bug c/30439] Intended Behaviour? #include searches for signal.h in local directory
--- Comment #5 from andersin at freenet dot de 2007-01-11 17:33 --- Created an attachment (id=12888) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12888&action=view) preprossesed source on success Preprocessed source when ./source.h is not present -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30439
[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #1 from jasonmbechtel at gmail dot com 2007-01-11 17:33 --- Created an attachment (id=12889) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12889&action=view) Preprocessed source This is the file GCC told me to attach to my bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #2 from jasonmbechtel at gmail dot com 2007-01-11 17:36 --- Created an attachment (id=12890) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12890&action=view) complete package for executing steps to reproduce error It's a GPL-ed program. ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
[Bug fortran/30441] New: optimisation bug (ICE) on lapack sget33.f and dget33.f
compilation of two testing functions of lapack fails (ICE) with the -O2 or -O3 optimisation levels level -O1 works gfortran -funroll-all-loops -O3 -fomit-frame-pointer -c dget33.f dget33.f: In function dget33: dget33.f:1: erreur interne du compilateur: dans insert_into_preds_of_block, à tree-ssa-pre.c:2750 Veuillez soumettre un rapport complet d'anomalies, avec le source pré-traité si nécessaire. The message is the french for internal compiler error -- Summary: optimisation bug (ICE) on lapack sget33.f and dget33.f Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Jean-pierre dot vial at wanadoo dot fr GCC build triplet: x86_64_unknown_linux GCC host triplet: x86_64_unknown_linux GCC target triplet: x86_64_unknown_linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30441
[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #3 from jasonmbechtel at gmail dot com 2007-01-11 17:42 --- I have since been able to successfully compile this program using the following 'build (platform)'s: gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-52) gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- jasonmbechtel at gmail dot com changed: What|Removed |Added CC||jasonmbechtel at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
[Bug fortran/30441] optimisation bug (ICE) on lapack sget33.f and dget33.f
--- Comment #1 from Jean-pierre dot vial at wanadoo dot fr 2007-01-11 17:45 --- Created an attachment (id=12891) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12891&action=view) the two lapack files that show the bug (from lapack-3.1.0) note that lapack has other similar files sget34.f sget35.f etc... which compile without problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30441
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-01-11 18:12 --- Again tonight - Mark broke bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug libgcj/30419] libjava failed to build
--- Comment #6 from hjl at lucon dot org 2007-01-11 18:12 --- Created an attachment (id=12892) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12892&action=view) An updated patch "cp -L" may not be portable. This updated patch tries "cp -LpR" before "cp -pR". -- hjl at lucon dot org changed: What|Removed |Added Attachment #12880|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30419
[Bug fortran/30441] optimisation bug (ICE) on lapack sget33.f and dget33.f
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-11 18:28 --- *** This bug has been marked as a duplicate of 29922 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30441
[Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-01-11 18:28 --- *** Bug 30441 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||Jean-pierre dot vial at ||wanadoo dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
[Bug target/19520] protected function pointer doesn't work right
--- Comment #22 from thiago at kde dot org 2007-01-11 18:42 --- Is there any update on this bug? According to http://sourceware.org/ml/binutils/2005-01/msg00401.html, a protected function symbol cannot be used in a R_386_GOTOFF. I don't claim to understand the full implications of the issue, but it seems that the ld decision means gcc must not emit that relocation. -- thiago at kde dot org changed: What|Removed |Added CC||thiago at kde dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug fortran/30399] testsuite failures in actual_array_constructor_2.f90 and actual_array_substr_2.f90
--- Comment #21 from paulthomas2 at wanadoo dot fr 2007-01-11 19:28 --- Subject: Re: testsuite failures in actual_array_constructor_2.f90 and actual_array_substr_2.f90 Kaveh, > Paul - I understand that you may not have time to actually fix the bug. > However something seems to have gone wrong here and we need to address it. > Your help in understanding where to go from here is necessary. And I believe > that since you were the proximate cause of the problem (by mistakenly checking > in the patch to 4.0) you are at least morally obligatged to help us understand > what's the best course of action, within the confines of a volunteer effort. > Can we agree on that? > The problem is that I do not see the patch corresponding to the ChangeLogs for the PRs on the gcc-4_0-branch; I downloaded fortran and the testsuite last night. Why is that? > Now I see several possible paths forward: > > 1. Fix the actual bug. Probably not going to happen unless someone > volunteers. > > 2. Revert just the testcases. > > 3. Revert the testcases and the code changes. > > I think if we go with 2 or 3 we need to understand what are the ramifications > of leaving in or taking out the fortran frontend code changes that you > mistakenly checked in last summer. That's where I think your help would be > appreciated. Can you offer an opinion on which option is safer and why? > "Safety" and avoiding regressions is paramount on 4.0 right now, as this > branch > should be kept very stable. > However, I note that the commit to which you pointed, was made by me to trunk: http://gcc.gnu.org/ml/gcc-cvs/2006-07/msg00074.html The commit to 4.0 that introduced the testcases was made by aoliva at gcc dot gnu dot org in: http://gcc.gnu.org/ml/gcc-cvs/2006-07/msg00077.html From this I deduce that (i) the "unseen hands" were not mine and that (ii) It is perfectly safe to revert the testcases. Paul This gcc-cvs entry corresponds with what I see in the 4.0 branch; ie. no patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30399
[Bug c++/29573] [4.0/4.1/4.2/4.3 regression] ICE after parse error in template argument
--- Comment #3 from simartin at gcc dot gnu dot org 2007-01-11 19:46 --- Subject: Bug 29573 Author: simartin Date: Thu Jan 11 19:46:03 2007 New Revision: 120683 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120683 Log: 2007-01-11 Simon Martin <[EMAIL PROTECTED]> PR c++/29573 * tree.c (cp_tree_equal): Properly handle MODOP_EXPR trees. Added: trunk/gcc/testsuite/g++.dg/template/sizeof-template-argument.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29573
[Bug c/30442] New: Array initialization can use memset builtin function
Array initialization could use memset builtin function. In following two
testcases, array is initialized without use of memset:
--cut here--
long long foo(long long *);
long long test1(void)
{
long long a[32];
a[0] = 0;
a[1] = 0;
a[2] = 0;
a[3] = 0;
a[4] = 0;
a[5] = 0;
a[6] = 0;
a[7] = 0;
a[8] = 0;
a[9] = 0;
a[10] = 0;
a[11] = 0;
a[12] = 0;
a[13] = 0;
a[14] = 0;
a[15] = 0;
a[16] = 0;
a[17] = 0;
a[18] = 0;
a[19] = 0;
a[20] = 0;
a[21] = 0;
a[22] = 0;
a[23] = 0;
a[24] = 0;
a[25] = 0;
a[26] = 0;
a[27] = 0;
a[28] = 0;
a[29] = 0;
a[30] = 0;
a[31] = 0;
return foo(a);
}
long long test2(void)
{
long long a[32];
int i;
for (i = 0; i < 32; i++)
a[i] = 0;
return foo(a);
}
--cut here--
gcc -O3 -m32 -S -fomit-frame-pointer
test1:
subl$268, %esp
leal8(%esp), %eax
movl$0, 8(%esp)
movl$0, 12(%esp)
movl$0, 16(%esp)
movl$0, 20(%esp)
movl$0, 24(%esp)
movl$0, 28(%esp)
movl$0, 32(%esp)
movl$0, 36(%esp)
movl$0, 40(%esp)
movl$0, 44(%esp)
movl$0, 48(%esp)
movl$0, 52(%esp)
movl$0, 56(%esp)
movl$0, 60(%esp)
movl$0, 64(%esp)
movl$0, 68(%esp)
movl$0, 72(%esp)
movl$0, 76(%esp)
movl$0, 80(%esp)
movl$0, 84(%esp)
movl$0, 88(%esp)
movl$0, 92(%esp)
movl$0, 96(%esp)
movl$0, 100(%esp)
movl$0, 104(%esp)
movl$0, 108(%esp)
movl$0, 112(%esp)
movl$0, 116(%esp)
movl$0, 120(%esp)
movl$0, 124(%esp)
movl$0, 128(%esp)
movl$0, 132(%esp)
movl$0, 136(%esp)
movl$0, 140(%esp)
movl$0, 144(%esp)
movl$0, 148(%esp)
movl$0, 152(%esp)
movl$0, 156(%esp)
movl$0, 160(%esp)
movl$0, 164(%esp)
movl$0, 168(%esp)
movl$0, 172(%esp)
movl$0, 176(%esp)
movl$0, 180(%esp)
movl$0, 184(%esp)
movl$0, 188(%esp)
movl$0, 192(%esp)
movl$0, 196(%esp)
movl$0, 200(%esp)
movl$0, 204(%esp)
movl$0, 208(%esp)
movl$0, 212(%esp)
movl$0, 216(%esp)
movl$0, 220(%esp)
movl$0, 224(%esp)
movl$0, 228(%esp)
movl$0, 232(%esp)
movl$0, 236(%esp)
movl$0, 240(%esp)
movl$0, 244(%esp)
movl$0, 248(%esp)
movl$0, 252(%esp)
movl$0, 256(%esp)
movl$0, 260(%esp)
movl%eax, (%esp)
callfoo
addl$268, %esp
ret
test2:
subl$268, %esp
movl$2, %eax
movl$0, 8(%esp)
leal8(%esp), %edx
movl$0, 12(%esp)
.p2align 4,,7
.L2:
movl$0, -8(%edx,%eax,8)
movl$0, -4(%edx,%eax,8)
addl$1, %eax
cmpl$33, %eax
jne .L2
movl%edx, (%esp)
callfoo
addl$268, %esp
ret
IIRC, this optimization was recently implemented in gfrortran...
--
Summary: Array initialization can use memset builtin function
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30442
[Bug libfortran/30415] MINLOC, MAXLOC missing for integer kinds 1 and 2
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-01-11 20:32 --- Subject: Bug 30415 Author: tkoenig Date: Thu Jan 11 20:32:42 2007 New Revision: 120685 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120685 Log: 2007-01-11 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30415 * iresolve.c (gfc_resolve_maxloc): If the rank of the return array is nonzero and we process an integer array smaller than default kind, coerce the array to default integer. * iresolve.c (gfc_resolve_minloc): Likewise. 2007-01-11 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30415 * minmaxloc_integer_kinds_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/minmaxloc_integer_kinds_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30415
[Bug fortran/30389] ACHAR() intrinsic gives erroneous errors in constant-folding.
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-01-11 20:55 --- We should be consistent to program main integer :: i i = 154 print *,achar(i) end program main Confirmed. I'll do this. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-11 20:55:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30389
[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-11 21:47 --- Works for me - I bet this is a dup of PR28545. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
[Bug middle-end/30442] Array initialization can use memset builtin function
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-11 22:16 --- > IIRC, this optimization was recently implemented in gfrortran... That is because in Fortran, you have "a = 0" and instead of lowering it into a loop, it lowers it to a memset instead. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30442
[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-11 22:19 --- Can you try with a newer 4.1.2? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
[Bug libstdc++/30443] New: 4.3 internal compiler error: verify_cgraph_node failed
svn 120684 sstream-inst.ii costs 640kb. i cannot attach it to bugzilla $ /tmp/gcc/host-i686-pc-cygwin/gcc/xgcc -shared-libgcc -B/tmp/gcc/host-i686-pc- cygwin/gcc -nostdinc++ -L/tmp/gcc/i686-pc-cygwin/libstdc++-v3/src -L/tmp/gcc/i6 86-pc-cygwin/libstdc++-v3/src/.libs -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-c ygwin/lib/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sy s-include -I/tmp/gcc/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin -I/tmp/ gcc/i686-pc-cygwin/libstdc++-v3/include -I/tmp/gcc/libstdc++-v3/libsupc++ -fno- implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show -location=once -ffunction-sections -fdata-sections -O2 -c ../../.././libstdc++- v3/src/sstream-inst.cc -o sstream-inst.o -save-temps ../../.././libstdc++-v3/src/sstream-inst.cc:50: error: edge std::basic_stringbuf <_CharT, _Traits, _Alloc>::basic_stringbuf(const std::basic_string<_CharT, _Trai ts, _Alloc>&, std::_Ios_Openmode) [with _CharT = char, _Traits = std::char_trait s, _Alloc = std::allocator]->std::basic_string<_CharT, _Traits, _All oc>::~basic_string() [with _CharT = char, _Traits = std::char_traits, _All oc = std::allocator] has no corresponding call_stmt __comp_dtor (D.32487_16); ../../.././libstdc++-v3/src/sstream-inst.cc:50: error: edge std::basic_stringbuf <_CharT, _Traits, _Alloc>::basic_stringbuf(const std::basic_string<_CharT, _Trai ts, _Alloc>&, std::_Ios_Openmode) [with _CharT = char, _Traits = std::char_trait s, _Alloc = std::allocator]->void std::terminate() has no correspond ing call_stmt terminate (); std::basic_stringbuf<_CharT, _Traits, _Alloc>::basic_stringbuf(const std::basic_ string<_CharT, _Traits, _Alloc>&, std::_Ios_Openmode) [with _CharT = char, _Trai ts = std::char_traits, _Alloc = std::allocator]/843: (inline copy in std::basic_istringstream<_CharT, _Traits, _Alloc>::basic_istringstream(const st d::basic_string<_CharT, _Traits, _Alloc>&, std::_Ios_Openmode) [with _CharT = ch ar, _Traits = std::char_traits, _Alloc = std::allocator]/324) availa bility:available(303) 133 insns (203 after inlining) 1 bytes stack usage 2 bytes after inlining tree externally_visible finalized inlinable called by: std::basic_istringstream<_CharT, _Traits, _Alloc>::basic_istringstr eam(const std::basic_string<_CharT, _Traits, _Alloc>&, std::_Ios_Openmode) [with _CharT = char, _Traits = std::char_traits, _Alloc = std::allocator] /324 (inlined) calls: std::basic_streambuf<_CharT, _Traits>::basic_streambuf() [with _CharT = char, _Traits = std::char_traits]/844 (inlined) std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, typename _Alloc::rebind<_CharT>:: other::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits , _Alloc = std::allocator]/522 void std::basic_stringbuf<_CharT, _Tr aits, _Alloc>::_M_stringbuf_init(std::_Ios_Openmode) [with _CharT = char, _Trait s = std::char_traits, _Alloc = std::allocator]/845 (inlined) std::ba sic_string<_CharT, _Traits, _Alloc>::~basic_string() [with _CharT = char, _Trait s = std::char_traits, _Alloc = std::allocator]/846 (inlined) void st d::terminate()/502 std::basic_streambuf<_CharT, _Traits>::~basic_streambuf() [wi th _CharT = char, _Traits = std::char_traits]/849 (inlined) void std::term inate()/502 ../../.././libstdc++-v3/src/sstream-inst.cc:50: internal compiler error: verify_ cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. sstream-inst.s = .file "sstream-inst.cc" .section .text$_ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE7_M_syncEPcjj,"x" .linkonce discard .align 2 .p2align 4,,15 .globl __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE7_M_syncEPcjj .def__ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE7_M_syncEPcjj; .scl2; .type 32; .endef __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE7_M_syncEPcjj: pushl %ebp movl%esp, %ebp subl$20, %esp movl8(%ebp), %ecx movl%ebx, -12(%ebp) movl16(%ebp), %ebx movl%esi, -8(%ebp) movl12(%ebp), %esi movl%edi, -4(%ebp) movl32(%ecx), %eax movl%esi, %edx movl%eax, -16(%ebp) shrl$3, %eax andl$1, %eax movb%al, -17(%ebp) movl36(%ecx), %eax addl-12(%eax), %edx cmpl%eax, %esi movl-8(%eax), %edi je L12 addl%ebx, %edx xorl%ebx, %ebx movl%edx, %edi L4: cmpb$0, -17(%ebp) je L5 leal(%esi,%ebx), %eax movl%esi, 4(%ecx) movl%eax, 8(%ecx) movl%edx, 12(%ecx) L5: testb $16, -16(%ebp) je L10 movl20(%ebp), %eax movl%esi, 20(%ecx) addl%eax, 20(%ecx) cmpb$0, -17(%ebp) movl
[Bug libstdc++/30443] 4.3 internal compiler error: verify_cgraph_node failed
--- Comment #1 from jojelino at gmail dot com 2007-01-11 22:30 --- Created an attachment (id=12893) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12893&action=view) sstream-inst.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30443
[Bug middle-end/30443] [4.3 Regression] 4.3 internal compiler error: verify_cgraph_node failed
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|libstdc++ |middle-end Keywords||build, ice-on-valid-code Known to work||4.2.0 Summary|4.3 internal compiler error:|[4.3 Regression] 4.3 |verify_cgraph_node failed |internal compiler error: ||verify_cgraph_node failed Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30443
[Bug fortran/30444] New: sfstubs.f90:48: internal compiler error: Illegal instruction
gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-53) from Fedora Development. f95 -fPIC -c sfstubsf95.f90 sfstubs.f90:48: internal compiler error: Illegal instruction -- Summary: sfstubs.f90:48: internal compiler error: Illegal instruction Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: orion at cora dot nwra dot com GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30444
[Bug middle-end/30443] [4.3 Regression] 4.3 internal compiler error: verify_cgraph_node failed
--- Comment #2 from echristo at apple dot com 2007-01-11 22:34 --- I can see this on x86-darwin. -- echristo at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-11 22:34:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30443
[Bug fortran/30444] sfstubs.f90:48: internal compiler error: Illegal instruction
--- Comment #1 from kargl at gcc dot gnu dot org 2007-01-11 22:41 --- Can you try the compiler available from the fortran wiki? Can you attach the fortran code? -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30444
[Bug fortran/30399] testsuite failures in actual_array_constructor_2.f90 and actual_array_substr_2.f90
--- Comment #22 from ghazi at gcc dot gnu dot org 2007-01-11 22:54 --- > However, I note that the commit to which you pointed, was made by me to > trunk: > http://gcc.gnu.org/ml/gcc-cvs/2006-07/msg00074.html > The commit to 4.0 that introduced the testcases was made by aoliva at > gcc dot gnu dot org in: > http://gcc.gnu.org/ml/gcc-cvs/2006-07/msg00077.html > From this I deduce that (i) the "unseen hands" were not mine and that > (ii) It is perfectly safe to revert the testcases. > Paul > This gcc-cvs entry corresponds with what I see in the 4.0 branch; ie. no > patch I must have misread the svn archive, looks like you're right. I've ping'ed Alexandre and if he cops to the error then I'll take care of removing the testcases. And as I flasely blamed you for the problem I apologize! Hopefully we can resolve this one way or another soon. Thanks, --Kaveh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30399
[Bug fortran/30444] sfstubs.f90:48: internal compiler error: Illegal instruction
--- Comment #2 from orion at cora dot nwra dot com 2007-01-11 23:21 --- I'm getting a bugzilla error when I try to make and attachment (reported). Source can be found here: http://www.cora.nwra.com/~orion/f95bug.tar.gz, or in the fedora buzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222371 The wiki version appears to compile it fine. -- orion at cora dot nwra dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30444
[Bug fortran/30444] sfstubs.f90:48: internal compiler error: Illegal instruction
--- Comment #3 from kargl at gcc dot gnu dot org 2007-01-11 23:40 --- The code at http://www.cora.nwra.com/~orion/f95bug.tar.gz is broken. laptop:kargl[226] gfc4x -c sfstubs.f90 sfstubs.f90:127.21: real(kind=plflt) x0, y0, xtick, ytick 1 Error: Symbol 'plflt' at (1) has no IMPLICIT type sfstubs.f90:124.26: There are several subroutines that are missing 'include plflt.inc' in sfstubs.f90. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30444
[Bug fortran/30444] sfstubs.f90:48: internal compiler error: Illegal instruction
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2007-01-11 23:45 --- Subject: Re: sfstubs.f90:48: internal compiler error: Illegal instruction On Thu, Jan 11, 2007 at 11:40:07PM -, kargl at gcc dot gnu dot org wrote: > > --- Comment #3 from kargl at gcc dot gnu dot org 2007-01-11 23:40 --- > The code at http://www.cora.nwra.com/~orion/f95bug.tar.gz > is broken. > > laptop:kargl[226] gfc4x -c sfstubs.f90 > sfstubs.f90:127.21: > > real(kind=plflt) x0, y0, xtick, ytick > 1 > Error: Symbol 'plflt' at (1) has no IMPLICIT type > sfstubs.f90:124.26: > > There are several subroutines that are missing 'include plflt.inc' > in sfstubs.f90. > I forgot to mention that f95 -fPIC -c sfstubsf95.f90 compile without a problem with gfortran 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30444
[Bug tree-optimization/29516] gfortran miscompiled
--- Comment #32 from rakdver at gcc dot gnu dot org 2007-01-12 00:18 --- Subject: Bug 29516 Author: rakdver Date: Fri Jan 12 00:17:50 2007 New Revision: 120695 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120695 Log: PR tree-optimization/29516 * tree-ssa-address.c (tree_mem_ref_addr, add_to_parts, most_expensive_mult_to_index, addr_to_parts, create_mem_ref, maybe_fold_tmr): Make the type of fields of TARGET_MEM_REF sizetype. (move_fixed_address_to_symbol, move_pointer_to_base): New functions. * tree.def (TARGET_MEM_REF): Add comment on types of the operands. * gcc.dg/tree-ssa/loop-20.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-20.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-address.c trunk/gcc/tree.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
[Bug fortran/30435] Slash at end of input not recognized according to standard
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-01-12 00:57 --- I think I was the last to touch on this section of code so I will take a look and see if I can fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30435
[Bug middle-end/30443] [4.3 Regression] 4.3 internal compiler error: verify_cgraph_node failed
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-01-12 01:43 ---
Patch in testing. It is related to function cloning update needed by Razya's
IPCP code.
Honza
Index: tree-inline.c
===
*** tree-inline.c (revision 120681)
--- tree-inline.c (working copy)
*** tree_function_versioning (tree old_decl,
*** 3209,3224
DECL_ARTIFICIAL (new_decl) = 1;
DECL_ABSTRACT_ORIGIN (new_decl) = DECL_ORIGIN (old_decl);
/* Generate a new name for the new version. */
if (!update_clones)
{
DECL_NAME (new_decl) = create_tmp_var_name (NULL);
SET_DECL_ASSEMBLER_NAME (new_decl, DECL_NAME (new_decl));
SET_DECL_RTL (new_decl, NULL_RTX);
}
-
- /* Prepare the data structures for the tree copy. */
- memset (&id, 0, sizeof (id));
id.decl_map = splay_tree_new (splay_tree_compare_pointers, NULL, NULL);
id.src_fn = old_decl;
--- 3209,3225
DECL_ARTIFICIAL (new_decl) = 1;
DECL_ABSTRACT_ORIGIN (new_decl) = DECL_ORIGIN (old_decl);
+ /* Prepare the data structures for the tree copy. */
+ memset (&id, 0, sizeof (id));
+
/* Generate a new name for the new version. */
if (!update_clones)
{
DECL_NAME (new_decl) = create_tmp_var_name (NULL);
SET_DECL_ASSEMBLER_NAME (new_decl, DECL_NAME (new_decl));
SET_DECL_RTL (new_decl, NULL_RTX);
+ id.statements_to_fold = pointer_set_create ();
}
id.decl_map = splay_tree_new (splay_tree_compare_pointers, NULL, NULL);
id.src_fn = old_decl;
*** tree_function_versioning (tree old_decl,
*** 3233,3239
id.transform_new_cfg = true;
id.transform_return_to_modify = false;
id.transform_lang_insert_block = false;
- id.statements_to_fold = pointer_set_create ();
current_function_decl = new_decl;
old_entry_block = ENTRY_BLOCK_PTR_FOR_FUNCTION
--- 3234,3239
*** tree_function_versioning (tree old_decl,
*** 3299,3316
/* Clean up. */
splay_tree_delete (id.decl_map);
! fold_marked_statements (0, id.statements_to_fold);
! pointer_set_destroy (id.statements_to_fold);
! fold_cond_expr_cond ();
if (gimple_in_ssa_p (cfun))
{
free_dominance_info (CDI_DOMINATORS);
free_dominance_info (CDI_POST_DOMINATORS);
! delete_unreachable_blocks ();
update_ssa (TODO_update_ssa);
! fold_cond_expr_cond ();
! if (need_ssa_update_p ())
! update_ssa (TODO_update_ssa);
}
free_dominance_info (CDI_DOMINATORS);
free_dominance_info (CDI_POST_DOMINATORS);
--- 3299,3323
/* Clean up. */
splay_tree_delete (id.decl_map);
! if (!update_clones)
! {
! fold_marked_statements (0, id.statements_to_fold);
! pointer_set_destroy (id.statements_to_fold);
! fold_cond_expr_cond ();
! }
if (gimple_in_ssa_p (cfun))
{
free_dominance_info (CDI_DOMINATORS);
free_dominance_info (CDI_POST_DOMINATORS);
! if (!update_clones)
! delete_unreachable_blocks ();
update_ssa (TODO_update_ssa);
! if (!update_clones)
! {
! fold_cond_expr_cond ();
! if (need_ssa_update_p ())
! update_ssa (TODO_update_ssa);
! }
}
free_dominance_info (CDI_DOMINATORS);
free_dominance_info (CDI_POST_DOMINATORS);
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2007-01-11 22:34:30 |2007-01-12 01:43:16
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30443
[Bug fortran/30444] sfstubs.f90:48: internal compiler error: Illegal instruction
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2007-01-12 02:20 --- Subject: Re: sfstubs.f90:48: internal compiler error: Illegal instruction On Thu, Jan 11, 2007 at 03:41:38PM -0800, Steve Kargl wrote: > > I forgot to mention that > f95 -fPIC -c sfstubsf95.f90 > compile without a problem with gfortran 4.3. > (apoligies for possible duplicate from fat fingers) This also compiles with gfortran 4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30444
[Bug fortran/30399] testsuite failures in actual_array_constructor_2.f90 and actual_array_substr_2.f90
--- Comment #23 from aoliva at gcc dot gnu dot org 2007-01-12 04:04 --- I can't imagine why I might have added or merged those files. I'm pretty sure I had no intention of merging them. I may have goofed in the merge command, or I ran into some SVN bug. Whatever it was, I apologize for not having noticed it at that time. Feel free to remove it. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30399
[Bug bootstrap/30342] Tough time building 4.2.0 (CVS) on WinXP with Cygwin
--- Comment #2 from rob1weld at aol dot com 2007-01-12 05:12 --- Thank you kindly for your comments and e-mails everyone. Firstly, I am NOT building in the source directory. My result (as of a while ago) for libmudflap are: === libmudflap Summary === # of expected passes 1194 # of unexpected failures 588 Complete result (for an OLD build) are here: http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00052.html I since have it working so well I can type "make check" (without the -k) and I am able to type "make install" with only a single warning. I removed some of the fancy optimization parameters from the CFLAGS I was building with and built a less optimized but more stable bootstrap. The extra optimizations worked well for the most part but Ada did not enjoy them. My "patch" for gomp (as you refer to it) is simply to enable it in the ./configure script - I did NOT change one line of the source for gomp. Mmap does NOT work when compiling java with the flags _I_ was using. The error I was getting was "java.io.IOException: mmap not implemented" and that was with the CVS "AS-IS", with no changes. Much of mmap DOES work but __some__ portion of it does not work with a small portion of java (on the particular day I obtained the CVS and then built it - it _might_ be OK now - I'll try re-enabling it). I have a newer build that I will post the results of shortly. Nearly everything is nearly OK - except the pch (which _I_ don't use) doesn't pass many tests. I do have the newest cygwin and do check their site for updates. Thanks again to everyone who read my post. I hope more people are encouraged to try a WinXP cygwin build of 4.2.0 and post the (FULL) test results. Please note (with the CVS from a few days ago) that "make check" misses some things. To get all the logs you need to type: make check make check-target-boehm-gc make check-target-libffi make check-target-libgomp make check-target-libmudflap make check-target-zlib -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30342
[Bug libobjc/30445] New: Fix for FIXME in gcc-4_2-branch/libobjc/Makefile.in
This info is a fix for a "FIXME" in gcc-4_2-branch/libobjc/Makefile.in To create libobjc.dll a fix to /cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/Makefile, is needed. This makefile is created from gcc-4_2-branch/libobjc/Makefile.in There is no author name or e-mail given but these words are enclosed in the file: # # FIXME -- The following part does not fit in the libtool context. # Libtool is supposed to [going to] be able to create a win 32 DLL # without extra code but since I don't have a win machine to test # if it already works, I leave the old code here. # #Origonal: # libobjc_s.a: libobjc.la mv libobjc.a libobjc_s.a # Create a relocatable DLL libobjc.dll: libobjc_s.a libobjc_entry.o $(CC) -mdll -Wl,--base-file -Wl,libobjc.base \ -o libobjc.dll libobjc_s.a libobjc_entry.o -lkernel32 $(DLLTOOL) --dllname libobjc.dll --def $(srcdir)/libobjc.def \ --base-file libobjc.base --output-exp libobjc.exp $(GCC_FOR_TARGET) -mdll -Wl,--base-file libobjc.base libobjc.exp \ -o libobjc.dll libobjc_s.a libobjc_entry.o -lkernel32 $(DLLTOOL) --dllname libobjc.dll --def $(srcdir)/libobjc.def \ --base-file libobjc.base --output-exp libobjc.exp $(GCC_FOR_TARGET) libobjc.exp -mdll \ -o libobjc.dll libobjc_s.a libobjc_entry.o -lkernel32 $(DLLTOOL) --dllname libobjc.dll --def $(srcdir)/libobjc.def \ --output-lib libobjc.a # # #New: (change "mv" to "cp ./libs" and add 3 -lobjc 's # libobjc_s.a: libobjc.la cp .libs/libobjc.a libobjc_s.a # mv libobjc.a libobjc_s.a # Create a relocatable DLL libobjc.dll: libobjc_s.a libobjc_entry.o $(CC) -mdll -Wl,--base-file -Wl,libobjc.base \ -o libobjc.dll libobjc_s.a libobjc_entry.o -lkernel32 -lobjc $(DLLTOOL) --dllname libobjc.dll --def $(srcdir)/libobjc.def \ --base-file libobjc.base --output-exp libobjc.exp $(GCC_FOR_TARGET) -mdll -Wl,--base-file libobjc.base libobjc.exp \ -o libobjc.dll libobjc_s.a libobjc_entry.o -lkernel32 -lobjc $(DLLTOOL) --dllname libobjc.dll --def $(srcdir)/libobjc.def \ --base-file libobjc.base --output-exp libobjc.exp $(GCC_FOR_TARGET) libobjc.exp -mdll \ -o libobjc.dll libobjc_s.a libobjc_entry.o -lkernel32 -lobjc $(DLLTOOL) --dllname libobjc.dll --def $(srcdir)/libobjc.def \ --output-lib libobjc.a # # Then, use these commands to run make and create libobjc_entry.o and libobjc.dll: cd /cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libobjc make libobjc_entry.lo make -i -k libobjc.dll DLLTOOL=dlltool GCC_FOR_TARGET="/cygdrive/c/gcc-4_2-branch-build/gcc/xgcc -B/cygdrive/c/cygwin/lib/gcc/athlon_xp-pc-cygwin/4.1.1/ -B/cygdrive/c/gcc-4_2-branch-build/gcc/ -B/usr/athlon_xp-pc-cygwin/bin/ -B/usr/athlon_xp-pc-cygwin/lib/ -isystem /usr/athlon_xp-pc-cygwin/include -isystem /usr/athlon_xp-pc-cygwin/sys-include" Result (which is likely to be different depending on your initial ./configure and CFLAGS: /bin/sh ./libtool --mode=compile /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc -B/cygdrive/c/gcc-4_2-branch-build/./gcc/ -B/usr/athlon_xp-pc-cygwin/bin/ -B/usr/athlon_xp-pc-cygwin/lib/ -isystem /usr/athlon_xp-pc-cygwin/include -isystem /usr/athlon_xp-pc-cygwin/sys-include -c -I. -I/cygdrive/C/makecygwin/gcc-4_2-branch/libobjc -I/usr/include -I/include -I/usr/local/include -O2 -march=athlon-xp -ffast-math -mfancy-math-387 -mmmx -m3dnow -msse -msse2 -msse3 -mfpmath=sse,387 -pipe -mthreads -fno-eliminate-unused-debug-types -W -Wall -Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -fexceptions -I/cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/objc -I/cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/../gcc -I/cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/../gcc/config -I../.././gcc -I/cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/../include -I/cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/../boehm-gc/include -I../boehm-gc/include /cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/libobjc_entry.c /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc -B/cygdrive/c/gcc-4_2-branch-build/./gcc/ -B/usr/athlon_xp-pc-cygwin/bin/ -B/usr/athlon_xp-pc-cygwin/lib/ -isystem /usr/athlon_xp-pc-cygwin/include -isystem /usr/athlon_xp-pc-cygwin/sys-include -c -I. -I/cygdrive/C/makecygwin/gcc-4_2-branch/libobjc -I/usr/include -I/include -I/usr/local/include -O2 -march=athlon-xp -ffast-math -mfancy-math-387 -mmmx -m3dnow -msse -msse2 -msse3 -mfpmath=sse,387 -pipe -mthreads -fno-eliminate-unused-debug-types -W -Wall -Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -fexceptions -I/cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/objc -I/cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/../gcc -I/cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/../gcc/config -I../.././gcc -I/cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/../include -I/cygdrive/C
[Bug bootstrap/30342] Tough time building 4.2.0 (CVS) on WinXP with Cygwin
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-12 05:31 --- > Please note (with the CVS from a few days ago) that "make check" misses > some things. To get all the logs you need to type: No you just do "make -k check". I mentioned this before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30342
[Bug libobjc/30445] Fix for FIXME in gcc-4_2-branch/libobjc/Makefile.in
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-12 05:34 --- The hash* functions were renamed because they conflict with some functions in some other library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30445
[Bug fortran/29786] [4.1/4.2/4.3 Regression] rejects equivalence
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-12 06:00 --- The attached bootstraps and regtests on IA64/FC5 - it even fixes the bug, as the testcase shows. (I will have to do the attaching a bit later - whatever I try with cookies does not seem to work right now.) The patch works by checking for overlapping equivalence members with initializers, which gfc already did; on detecting such overlaps, a new char* field is created that spans the entire union. The equivalence group is then scanned for initializers, which are then byte-wize converted to char* (Note that this is half the job of simplify_array_transfer:) ). The char* in it's turn is converted into a tree-ssa vector constructor, which becomes the only initializer for the union. Another approach to this would have been to create a structure field, with components corresponding to the non-null, non-overlapping constructors. I did not do this on grounds of simplicity. The patch does not implement overlapping derived types with initializers; it could be done without too much trouble and probably should be, in spite of all the gotcha's that are involved in putting derived types in equivalences. The part of the patch that is giving me pause is the conversion of integers; because gmp does not offer a mpz_t to signed long long, I used the conversion in tree-const.c and write from two longs. These have to be ordered according to endian-ness. Could somebody advise on how to do this, please? Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-11-09 20:14:18 |2007-01-12 06:00:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug fortran/30399] testsuite failures in actual_array_constructor_2.f90 and actual_array_substr_2.f90
--- Comment #24 from pault at gcc dot gnu dot org 2007-01-12 06:09 --- Kaveh, > I must have misread the svn archive, looks like you're right. I've ping'ed > Alexandre and if he cops to the error then I'll take care of removing the > testcases. And as I flasely blamed you for the problem I apologize! That's OK. It would have been nice if you had taken note of what I said from the outset, though - the patch was not present on the branch; just the testcases. That's why I could not respond to the problem. Have a nice day:) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30399
[Bug fortran/30438] Unused variable should raise warning with -Wunused
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-12 06:35 --- Simpler example: real :: t, dist t = 12 dist = 5 if (dist < 0) then print *, dist end if end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30438
[Bug fortran/30446] New: -J option doesn't add patch to search list
pito /tmp $ mkdir mod pito /tmp $ cat > a.f90 module foo end module foo use foo end pito /tmp $ ~/gfortran/devel/irun/bin/gfortran -v Using built-in specs. Target: powerpc-apple-darwin8.8.0 Configured with: ../trunk/configure --prefix=/Users/fx/gfortran/devel/irun --enable-languages=c,fortran --with-gmp=/Users/fx/gfortran/gfortran_libs/macosx --disable-bootstrap Thread model: posix gcc version 4.3.0 20070109 (experimental) pito /tmp $ ~/gfortran/devel/irun/bin/gfortran -Jmod a.f90 a.f90:4.7: use foo 1 Fatal Error: Can't open module file 'foo.mod' for reading at (1): No such file or directory pito /tmp $ ls mod/foo.mod mod/foo.mod This is not what the doc says: "-Jdir This option specifies where to put .mod files for compiled modules. It is also added to the list of directories to searched by an USE statement." A trivial workaround is to use -Jdir -Idir. -- Summary: -J option doesn't add patch to search list Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30446
[Bug fortran/30446] -J option doesn't add patch to search list
-- 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 |org Severity|normal |minor Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-12 06:42:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30446
[Bug libfortran/27107] Make dependency on io/io.h broken
-- 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 |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||01/msg00594.html Status|NEW |ASSIGNED Keywords||patch Known to fail||4.1.2 4.2.0 4.3.0 Last reconfirmed|2006-09-29 15:55:19 |2007-01-12 06:47:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27107
[Bug libfortran/29649] Force core dump on runtime library errors
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649
