--- 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
--- 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 #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 #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 #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 #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
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> cha
--- 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
--- 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=gcc&view=rev&rev=111442
Log:
PR middle-end/23673
* fold-const.c (fold_binary)
--- 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 #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 inp
--- 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/bu
--- 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 #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 ot
--- 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 watc
--- 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
Bugs
--- 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 assigni
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:40 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- 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:33 ---
*** This bug has been marked as a duplicate of 26468 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
#include
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: ‘struct std::string::N’ has not
been declared
GCC_Fehler_25022006.cpp:6: err
--- 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
--- 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 #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
#include
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: ‘struct std::string::N’ has not
been declared
GCC_Fehler_25022006.cpp:6: err
#include
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: ‘struct std::string::N’ has not
been declared
GCC_Fehler_25022006.cpp:6: err
--- 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/bug
--- 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 #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 #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
--- 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 fr
--- 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 t
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++ whe
--- 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
--- 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
--
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 #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
--
--- 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 #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 #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 #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 #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 #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=10912&action=view)
bugfix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26466
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:%ftp://ftpth.mppmu.mpg.de/pub/peb/x86-32/toolch
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.
--- 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=gcc&view=rev&rev=111438
Log:
2006-02-25 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- 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/sh
49 matches
Mail list logo
