--- 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
--
--- 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
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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--
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
--- 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
--- 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
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++
--- 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
--- 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
--- 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)
--
--- 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
--- 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
--- 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.
--
#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
#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
--- 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
--- 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
--- 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
#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
--- 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
--- 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
--- 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
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 ---
--- 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
--- 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
--- 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
--- 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
--- 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 ...
--- 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.
--
--- 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,
--- 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
--- 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)
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
49 matches
Mail list logo
