[Bug fortran/20938] Dependency checking fails for equivalences
--- Comment #5 from patchapp at dberlin dot org 2006-02-25 08:15 --- Subject: Bug number PR20938 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01891.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20938
[Bug fortran/23092] scalar mask for minval/maxval/sum/product
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-02-25 10:32 --- Subject: Bug 23092 Author: tkoenig Date: Sat Feb 25 10:32:19 2006 New Revision: 111438 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111438 Log: 2006-02-25 Thomas Koenig [EMAIL PROTECTED] PR fortran/23092 * trans-intrinsic.c (gfc_conv_intrinsic_arith): If the mask expression exists and has rank 0, enclose the generated loop in an if (mask). * (gfc_conv_intrinsic_minmaxloc): Likewise. 2006-02-25 Thomas Koenig [EMAIL PROTECTED] PR fortran/23092 * scalar_mask_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/scalar_mask_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23092
[Bug ada/26465] New: Ada.Characters.Conversions comment announces Ada.Characters.Handling
both spec and body of Ada.Characters.Conversions announce the package -- A D A . C H A R A C T E R S . H A N D L I N G -- (Or is this Ada 2005 obsolescence magic?) -- Summary: Ada.Characters.Conversions comment announces Ada.Characters.Handling Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bauhaus at futureapps dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26465
[Bug driver/26466] New: multilib selection in gcc driver ignores removal of switches
I was trying to build a x86_32-linux-gnu version of gcc (the same as a
x86_64-linux-gnu version, except that the compiler default mode and its
binaries are 32-bit ones).
The essential ingredient was a DRIVER_SELF_SPECS %{!m32:%{!m64:-m32}},
%{m32:%m64}, such that 'gcc -m64 -m32' produces 32-bit binaries.
More details are described in:
ftp://ftpth.mppmu.mpg.de/pub/peb/x86-32/toolchain.ps
It turned out that everything worked fine, except the multilib selection wich
ignored that the switch m64 was removed by the DRIVER_SELF_SPECS.
This problem was fixed by the attached patch.
--
Summary: multilib selection in gcc driver ignores removal of
switches
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peb at mppmu dot mpg dot de
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26466
[Bug driver/26466] multilib selection in gcc driver ignores removal of switches
--- Comment #1 from peb at mppmu dot mpg dot de 2006-02-25 14:00 --- Created an attachment (id=10912) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10912action=view) bugfix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26466
[Bug fortran/20935] failed assertion for maxloc(n, mask=.true.)
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-02-25 14:26 --- *** Bug 26182 has been marked as a duplicate of this bug. *** -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20935
[Bug fortran/26182] (min|max)loc with scalar mask aborts at runtime
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-02-25 14:26 --- *** This bug has been marked as a duplicate of 20935 *** -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26182
[Bug tree-optimization/26406] [4.2 Regression] Forwardprop does harm for VRP to figure out if a point is non zero
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-02-25 15:49 --- This is a regression in fact. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Known to fail||4.2.0 Known to work||4.1.0 Summary|Forwardprop does harm for |[4.2 Regression] Forwardprop |VRP to figure out if a point|does harm for VRP to figure |is non zero |out if a point is non zero Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug java/26437] java build fails with relocation R_X86_64_32 error
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-25 15:55 --- I cannot reproduce this, I just built 4.0.3 lately and it worked. Can you try using a different binutils as this seems like a bug there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26437
[Bug target/26445] SSE byte-by-byte load instruction fails to compile
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-25 16:05 --- Also can you follow the instructions on http://gcc.gnu.org/bugs.html and attach the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26445
[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-02-25 17:07 --- This blocks PR 26338 getting fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||26338 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
[Bug tree-optimization/26443] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1867
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-25 17:08 --- I am just going to mark this as blocking PR 26338. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||26338 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26443
[Bug tree-optimization/19910] [4.2 regression] ICE with -ftree-loop-linear
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
[Bug driver/26466] multilib selection in gcc driver ignores removal of switches
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-25 17:29 --- Patches goto [EMAIL PROTECTED] with a changelog. Second please update the patch to the mainline first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26466
[Bug tree-optimization/26406] [4.2 Regression] Forwardprop does harm for VRP to figure out if a point is non zero
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-25 17:31 --- Why is forward prop doing this in the first place, this actually causes increased register pressure for sure, at least for non one use variables? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug c++/26467] New: GCC 4.0 not case-aware where GCC 3 was
I'm trying to compile a project under mac os x with gcc 4.0.1 that worked fine under gcc 3.3. I have code that looks something like this: src/ inc/ Assert.h test.C Basically, with Assert.h inside some other directory from the one that contains test.C. I provide -I inc to g++ when I compile. If I #include assert.h from test.C, it will find Assert.h from my project under gcc 4, but under gcc 3.3, it would find the system header. Also, if I #include cassert, it finds the system's cassert header, but the nested #include assert.h there finds my Assert.h. on gcc 3.3, both of these found the system header as expected. I can compile the project ok using -I-, but I know that if other projects have similar problems this might not work, so I'm filing a bug. I'm wondering why this worked under gcc 3.3, since the documentation for -I says: Directories named by -I are searched before the standard system include directories. So gcc 3 should have found my Assert.h, too! Was gcc-3 aware of case-preservation in HFS+? Did it check to make sure case matched even though the filesystem didn't? And why can't gcc 4 do this as well? Finally, I want to point out that gcc takes a lot of pains to make sure system includes work as intended, but in this case it's possible for a *system* header (cassert) to include MY header (Assert.h) instead of the header that was obviously intended (the standard c assert.h). Should it really be possible for users to break the intent of standard library writers by using headers of the same (or equivalent) names? Shouldn't #pragma GCC system_header ensure that any #includes in the header containing #pragma are ONLY searched in the standard include directories, in addition to what it already does? -- Summary: GCC 4.0 not case-aware where GCC 3 was Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tgamblin at cs dot unc dot edu GCC host triplet: powerpc-darwin-macosx http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26467
[Bug c++/26467] GCC 4.0 not case-aware where GCC 3 was
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-25 18:05 --- Are you using both of Apple's gcc 3.3 and Apple's gcc 4.0, if so please report this to Apple first instead of here. Second I think 3.3 did readdir instead of looking if the file exists which was wrong anyways. So this is in fact fixed in 4.0 and not really a bug. If you want case-sensitive file lookup use a case-sensitive file system like HFSX. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26467
[Bug c++/26467] GCC 4.0 not case-aware where GCC 3 was
--- Comment #2 from tgamblin at cs dot unc dot edu 2006-02-25 18:14 --- Should I file a separate bug report/feature request for my suggested treatment of system headers? I don't think that cassert should ever find a user's assert.h, even if the user specified -I. Shouldn't #includes from system headers be treated differently? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26467
[Bug tree-optimization/26443] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1867
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-02-25 18:16 --- Subject: Bug 26443 This should fix the problem. --- Comment #6 from dberlin at gcc dot gnu dot org 2006-02-25 18:16 --- Created an attachment (id=10913) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10913action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26443
[Bug c++/26467] GCC 4.0 not case-aware where GCC 3 was
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-25 18:18 --- -I supplies for the include dir still, if you want only for use -iquote which is there in 4.0 and above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26467
[Bug tree-optimization/26406] [4.2 Regression] Forwardprop does harm for VRP to figure out if a point is non zero
--- Comment #15 from law at redhat dot com 2006-02-25 18:31 --- Subject: Re: [4.2 Regression] Forwardprop does harm for VRP to figure out if a point is non zero On Sat, 2006-02-25 at 17:31 +, pinskia at gcc dot gnu dot org wrote: --- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-25 17:31 --- Why is forward prop doing this in the first place, this actually causes increased register pressure for sure, at least for non one use variables? Because in the case of multiple-use it's removing a partial redundancy. I've already stated I believe I have a way to fix this. Please be patient, there are more pressing matters to deal with first. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug c/8268] no compile time array index checking
--- Comment #38 from mueller at gcc dot gnu dot org 2006-02-25 18:37 --- I think the anaylize_array_indexes has the problem of the taking address of array sentinel as well. I'll look into moving it to VRP pass. re segfault: I got the same, will fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c++/26468] New: correct code doesn't compile (global namespace qualification)
#include string
namespace N {
struct X { static std::string s(); };
}
namespace N {
inline std::string ::N::X::s() { return ; }
}
int main() {}
compiled with version 3.4.3 or 4.0.2 yields
GCC_Fehler_25022006.cpp:6: error: #8216;struct std::string::N#8217; has not
been declared
GCC_Fehler_25022006.cpp:6: error: ISO C++ forbids declaration of
#8216;s#8217; with no type
GCC_Fehler_25022006.cpp: In function #8216;int N::s()#8217;:
GCC_Fehler_25022006.cpp:6: error: invalid conversion from #8216;const
char*#8217; to #8216;int#8217;
But I believe the above code is correct. Changing ::N::X::s() to N::X::s()
makes the code compile.
--
Summary: correct code doesn't compile (global namespace
qualification)
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: o dot kullmann at swansea dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26468
[Bug c++/26469] New: correct code doesn't compile (global namespace qualification)
#include string
namespace N {
struct X { static std::string s(); };
}
namespace N {
inline std::string ::N::X::s() { return ; }
}
int main() {}
compiled with version 3.4.3 or 4.0.2 yields
GCC_Fehler_25022006.cpp:6: error: #8216;struct std::string::N#8217; has not
been declared
GCC_Fehler_25022006.cpp:6: error: ISO C++ forbids declaration of
#8216;s#8217; with no type
GCC_Fehler_25022006.cpp: In function #8216;int N::s()#8217;:
GCC_Fehler_25022006.cpp:6: error: invalid conversion from #8216;const
char*#8217; to #8216;int#8217;
But I believe the above code is correct. Changing ::N::X::s() to N::X::s()
makes the code compile.
--
Summary: correct code doesn't compile (global namespace
qualification)
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: o dot kullmann at swansea dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26469
[Bug c++/26468] correct code doesn't compile (global namespace qualification)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-25 19:20 --- This is invalid code as white spaces don't matter. std::string ::N::X::s is the same as std::string::N::X::s. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26468
[Bug c++/26469] correct code doesn't compile (global namespace qualification)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-25 19:22 --- *** This bug has been marked as a duplicate of 26468 *** -- 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=26469
[Bug c++/26468] correct code doesn't compile (global namespace qualification)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-25 19:22 --- *** Bug 26469 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26468
[Bug c++/26470] New: correct code doesn't compile (global namespace qualification)
#include string
namespace N {
struct X { static std::string s(); };
}
namespace N {
inline std::string ::N::X::s() { return ; }
}
int main() {}
compiled with version 3.4.3 or 4.0.2 yields
GCC_Fehler_25022006.cpp:6: error: #8216;struct std::string::N#8217; has not
been declared
GCC_Fehler_25022006.cpp:6: error: ISO C++ forbids declaration of
#8216;s#8217; with no type
GCC_Fehler_25022006.cpp: In function #8216;int N::s()#8217;:
GCC_Fehler_25022006.cpp:6: error: invalid conversion from #8216;const
char*#8217; to #8216;int#8217;
But I believe the above code is correct. Changing ::N::X::s() to N::X::s()
makes the code compile.
--
Summary: correct code doesn't compile (global namespace
qualification)
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: o dot kullmann at swansea dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26470
[Bug c++/26470] correct code doesn't compile (global namespace qualification)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-25 19:33 --- *** This bug has been marked as a duplicate of 26468 *** -- 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=26470
[Bug c++/26468] correct code doesn't compile (global namespace qualification)
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-25 19:33 --- *** Bug 26470 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26468
[Bug rtl-optimization/26190] combine misses some distributivity
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-25 19:40 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-25 19:40:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26190
[Bug c++/26471] New: no warning available when binding a temporary to a const reference member
struct X {};
struct Y {
const X x;
Y(const X x) : x(x) {}
};
int main() {
Y y(X());
// here y.x dangling
}
does not create a warning with -Wall or any other warning option I tried.
However, binding a temporary value to a reference member seems to be
doomed in any possible situation --- once the constructor has been executed,
we get a dangling reference.
So I believe that this situation could be included in -Wall, or at least there
could be a special warning (especially since in all C++ books I have I didn't
find any mentioning of the point, that temporaries used in the construction of
an object will be destroyed as soon as the constructor is left, which is
different from binding non-class-member-const-references to temporaries).
--
Summary: no warning available when binding a temporary to a const
reference member
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: o dot kullmann at swansea dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26471
[Bug c++/26471] no warning available when binding a temporary to a const reference member
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-25 19:57 --- First: Y y(X()); that declares a function rather than a variable. You want: Y y((X())); Second, this is called life time and there is no way for GCC to know that constructure's argument is used only for assigning to a variable in this. And there is no way to know for GCC to know that the argument assigning to this-x comes from a temporary variable. Unless you have IPA and then it would be cost a lot of time to look. And if the C++ books you have don't talk about life time of a temporary variable, then they are not good C++ boks at all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26471
[Bug tree-optimization/22501] [meta-bug] tramp3d-v4 missed optimizations
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-25 20:09 --- PR 19431 shows up in tramp3d. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||19431 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22501
[Bug c++/26471] no warning available when binding a temporary to a const reference member
--- Comment #2 from o dot kullmann at swansea dot ac dot uk 2006-02-25 20:15 --- Sure, those additional brackets I missed because I created this case from scratch (and then forgot about it). But the other points I don't see: I seems trivial for gcc to find this sort of error: Just watch out for const reference members in classes, and then see whether they are bound to a temporary (gcc warns about this in other cases, so it seems to know about temporaries) --- this seems easy to observe and seems never to be of any use. I don't understand IPA. And finally, sure, books speak about lifetime of temporaries, but references are badly covered. And then this special behaviour of binding to temporaries, different for class members and block members, I carefully searched for it in the 30 something C++ books I have, but didn't find anything. (And if books not mentioning this are bad books, then most books seem to be bad, Stroustroup's, Meyers', Sutter's, etc. (maybe this is actually true)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26471
[Bug c++/26471] no warning available when binding a temporary to a const reference member
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-25 20:35 ---
(In reply to comment #2)
I seems trivial for gcc to find this sort of error: Just watch out for
const reference members in classes, and then see whether they are bound
to a temporary (gcc warns about this in other cases, so it seems to know
about temporaries) --- this seems easy to observe and seems never to
be of any use.
Lets look at how GCC (or anyother compiler) looks at this issue:
Y(const X x1) : x(x1) {}
How would GCC or anyother compiler know that x1 points to a temporary variable?
Y y((X()));
How does GCC know that the temporary that holds X() is going to be stored in y?
I don't understand IPA.
inter-procedure analysis.
And finally, sure, books speak about lifetime of temporaries, but references
are badly covered. And then this special behaviour of binding to temporaries,
different for class members and block members, I carefully searched for it in
the 30 something C++ books I have, but didn't find anything.
There is no special behavior really. Maybe that is your misunderstanding.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26471
[Bug middle-end/26022] [4.2 Regression] ICE with references and virtual functions
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-25 20:47 --- I think this is my bug caused by: 2006-01-23 Andrew Pinski [EMAIL PROTECTED] PR middle-end/24437 * tree-ssa-ccp.c (fold_stmt): Move folding of OBJ_TYPE_REF with a call expr to ... * fold-const.c (fold_ternary) case CALL_EXPR: Here. The problem is that we are not copying RSO on the CALL_EXPR. I am going to look into this more to see if I caused this and a fix for this issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end GCC host triplet|x86_64-suse-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26022
[Bug middle-end/26022] [4.2 Regression] ICE with references and virtual functions
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-25 20:51 --- I don't copy CALL_EXPR_RETURN_SLOT_OPT and/or CALL_EXPR_TAILCALL from the previous CALL_EXPR, I wonder if we have the same issue with builtins too, though most of those will not show it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26022
[Bug c++/26471] no warning available when binding a temporary to a const reference member
--- Comment #4 from o dot kullmann at swansea dot ac dot uk 2006-02-25 21:21 --- Y y((X())); How does GCC know that the temporary that holds X() is going to be stored in y? By the definition of Y, obviously. There seems to be a very special way of how GCC is parsing the input, and from that it seems to follow that this user error is hard to detect here. I simply argue from the user's point of view, not from the gcc-system point of view. And finally, sure, books speak about lifetime of temporaries, but references are badly covered. And then this special behaviour of binding to temporaries, different for class members and block members, I carefully searched for it in the 30 something C++ books I have, but didn't find anything. There is no special behavior really. Maybe that is your misunderstanding. This behaviour is a special section in the standard: 12.2, paragraph 5 in the standard: The first sentence states the expected behaviour: The temporary to which the reference is bound or the temporary that is the complete object to a subobject of which the temporary is bound persists for the lifetime of the reference except as specified below. (This is as one would expect from const references to a temporary at block scope --- it's the lifetime of the reference which rules here, and the temporary has to follow.) And then comes the exception: A temporary bound to a reference member in a constructor#8217;s ctorinitializer (12.6.2) persists until the constructor exits. So this seems to restrict the validity of the reference for this special case. Therefore I believe we have a special case here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26471
[Bug libgomp/25978] All libgomp tests timeout on ppc-darwin
--- Comment #5 from andreast at gcc dot gnu dot org 2006-02-25 21:24 --- http://gcc.gnu.org/ml/gcc-cvs/2006-02/msg00990.html -- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25978
[Bug middle-end/23673] fold does not fold (a^b) != 0 to a != b
--- Comment #6 from sayle at gcc dot gnu dot org 2006-02-25 22:27 --- Subject: Bug 23673 Author: sayle Date: Sat Feb 25 22:27:54 2006 New Revision: 111442 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111442 Log: PR middle-end/23673 * fold-const.c (fold_binary) EQ_EXPR: Fold (X^Y) == 0 as X == Y and (X^Y) != 0 as X != Y. Fold (X^Y) == Y as X == 0, and some symmetry related transformations. Fold (X^C1) == C2 as X == (C1^C2). * gcc.dg/fold-eqxor-1.c: New test case. * gcc.dg/fold-eqxor-2.c: Likewise. * gcc.dg/fold-eqxor-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/fold-eqxor-1.c trunk/gcc/testsuite/gcc.dg/fold-eqxor-2.c trunk/gcc/testsuite/gcc.dg/fold-eqxor-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23673
[Bug middle-end/23673] fold does not fold (a^b) != 0 to a != b
--- Comment #7 from roger at eyesopen dot com 2006-02-25 23:36 --- Fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23673
[Bug target/26472] New: Default path for libgcc_s.sl is build directory
This is a libtool installation issue. The problem is libgcc_s isn't a libtool library and we don't relink against the installed libgcc_s when installing libraries such as libstdc++.sl. As a result, we have a default path for libgcc_s.sl pointing to the GCC build directory. 529 (hiauly1)dave chatr libstdc++.sl libstdc++.sl: shared library shared library dynamic path search: SHLIB_PATH disabled second embedded path enabled first /opt/gnu/gcc/gcc-4.0.2/lib internal name: libstdc++.sl.6 shared library list: dynamic /usr/lib/libM.1 dynamic /xxx/gnu/gcc-3.3/objdir/gcc/libgcc_s.sl dynamic /usr/lib/libc.1 shared vtable support disabled static branch prediction disabled kernel assisted branch prediction enabled lazy swap allocation disabled text segment locking disabled data segment locking disabled third quadrant private data space disabled fourth quadrant private data space disabled data page size: 4K instruction page size: 4K The important part is the dynamic path to libgcc_s: /xxx/gnu/gcc-3.3/objdir/gcc/libgcc_s.sl. This is the absolete path for libgcc_s.sl in the build directory rather than the install directory. The HP dynamic loader has the unfortunate characteristic of trying the default dynamic path before the embedded or SHLIB_PATH. If the build directory contains an incompatible libgcc_s.sl (e.g., 64-bit build), the installation breaks. HP-UX 11 ld has a '+nodefaultrpath' option which could fix this, but it's not available on HP-UX 10. So, it would be better if libtool linked against the installed version of libgcc_s.sl when installing other libraries which depend on it. This problem is present in all GCC versions. -- Summary: Default path for libgcc_s.sl is build directory Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-hp-hpux* (32-bit) GCC host triplet: hppa*-hp-hpux* (32-bit) GCC target triplet: hppa*-hp-hpux* (32-bit) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472
[Bug target/26472] Default path for libgcc_s.sl is build directory
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-26 01:39 --- Isn't this really still a dup of bug 5291? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472
[Bug target/26472] Default path for libgcc_s.sl is build directory
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-26 02:50 --- Subject: Re: Default path for libgcc_s.sl is build directory Isn't this really still a dup of bug 5291? Yes. I got bitten by the bug today ;( Regarding comment #8 in PR 5291: Note that, on PA, the linker does indeed annotate an executable with the location in which it found the library, but that's just a cache, it doesn't require the library to be there in order to function. Libtool knows about that, and does the right thing when linking with a libtool library, but libgcc_s isn't a libtool library, so libtool can't do much. It's correct that the linker does annotate an executable with the location in which it finds a library when it is linked in with -l and the dynamic linker doesn't require the library to be there in order to function, but the dynamic linker will use an executable file with the correct name if it finds it in preference to doing a path search. So, one has to be very careful about doing builds for different versions and targets in different locations. The hppa64-*-hpux* situation is a little different: /bin/sh ../libtool --tag CXX --mode=link /test/gnu/gcc-4.1/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gcc-4.1/objdir/./gcc -nostdinc++ -L/test/gnu/gcc-4.1/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src -L/test/gnu/gcc-4.1/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -B/opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/sys-include -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o libstdc++.la -rpath /opt/gnu64/gcc/gcc-4.1.0/lib -version-info 6:7:0 -lm bitmap_allocator.lo pool_allocator.lo mt_allocator.lo codecvt.lo compatibility.lo complex_io.lo ctype.lo debug.lo debug_list.lo functexcept.lo globals_locale.lo globals_io.lo ios.lo ios_failure.lo ios_init.lo ios_locale.lo limits.lo list.lo locale.lo locale_init.lo lo! cale_facets.lo localename.lo stdexcept.lo strstream.lo tree.lo allocator-inst.lo concept-inst.lo fstream-inst.lo ext-inst.lo ios-inst.lo iostream-inst.lo istream-inst.lo istream.lo locale-inst.lo locale-misc-inst.lo misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-inst.lo streambuf.lo string-inst.lo valarray-inst.lo wlocale-inst.lo wstring-inst.lo atomicity.lo codecvt_members.lo collate_members.lo ctype_members.lo messages_members.lo monetary_members.lo numeric_members.lo time_members.lo basic_file.lo c++locale.lo ../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm *** Warning: This library needs some functionality provided by -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. The result is libgcc_s isn't linked against libstdc++. I had a hppa64 libtool patch that fixed a lot of problems on this port (it needs to be handled in a manner very similar to ia64-hpux) but gave when the patch was ignored upstream. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472
[Bug target/26472] Default path for libgcc_s.sl is build directory
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-26 02:58 --- *** This bug has been marked as a duplicate of 5291 *** -- 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=26472
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-02-26 02:58 --- *** Bug 26472 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug c++/26167] -Wconversion fails to detect signedness conversion from int to unsigned int in fuction call
--- Comment #4 from kristian dot hermansen at gmail dot com 2006-02-26 05:56 --- Go ahead and tackle it. I'm not going to fix this myself... -- Kristian Hermansen -- kristian dot hermansen at gmail dot com changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
[Bug target/26472] Default path for libgcc_s.sl is build directory
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2006-02-26 06:40 --- (In reply to comment #2) Subject: Re: Default path for libgcc_s.sl is build directory Isn't this really still a dup of bug 5291? Yes. I got bitten by the bug today ;( No, it is not. At least not exactly, from the Libtool POV: they likely need different fixes. The hppa64-*-hpux* situation is a little different: The result is libgcc_s isn't linked against libstdc++. I had a hppa64 libtool patch that fixed a lot of problems on this port (it needs to be handled in a manner very similar to ia64-hpux) but gave when the patch was ignored upstream. Please point me to your patch. Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472
