--- Comment #1 from torsten at debian dot org 2007-08-20 19:10 ---
Created an attachment (id=14084)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14084&action=view)
Preprocessed source causing the failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33126
--- Comment #5 from patchapp at dberlin dot org 2007-08-20 19:10 ---
Subject: Bug number PR32985
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/2007-08/msg01299.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from mec at google dot com 2007-08-20 19:31 ---
"new T[0]" looks like defined behavior to me.
[expr.new] 5.3.4 -7-
When the value of the expression in a direct-new-declarator is zero, the
allocation function is called to allocate an array with no elements. The
pointer re
Compilation of following code fails with error:
a.cpp: In constructor `c::c()':
a.cpp:14: error: reference to `i' is ambiguous
a.cpp:8: error: candidates are: int b::i
a.cpp:3: error: int a::i
a.cpp:14: error: `i' was not declared in this scope
class a{
private:
int i;
--- Comment #1 from schwab at suse dot de 2007-08-20 20:25 ---
Member lookup does not take accessibility into account. An inaccessible but
otherwise visible member is still considered a candidate.
--
schwab at suse dot de changed:
What|Removed |Ad
--- Comment #1 from hemant dot jaiswal at gmail dot com 2007-08-20 20:30
---
arm-linux-gcc is Configured with: ../gcc-3.4.6/configure
--prefix=/usr/local/swdevel/tools/arm --
target=arm-linux-gnu
--with-local-prefix=/usr/local/swdevel/tools/arm/arm-linux-
gnu/usr
--with-gxx-include-dir=
--- Comment #22 from h dot b dot furuseth at usit dot uio dot no
2007-08-20 22:45 ---
Subject: Re: warn for uninitialized arrays passed as const* arguments
manu at gcc dot gnu dot org writes:
> But it seems that the current policy of GCC is to not assume that such
> functions actually
The uniform_int distribution in the following program (copied from start of the
Boost random documentation) returns a value (-1) that is outside of its range.
Thanks,
Mark Johnson
#include
#include
int main() {
std::tr1::mt19937 rng;
std::tr1::uniform_int<> six(1,6);
std::tr1::variate
--- Comment #3 from gdr at cs dot tamu dot edu 2007-08-20 23:23 ---
Subject: Re: C++ frontend should not warn about new a[0] in template context
"mec at google dot com" <[EMAIL PROTECTED]> writes:
| "new T[0]" looks like defined behavior to me.
|
| [expr.new] 5.3.4 -7-
| When the val
--- Comment #1 from mj1 at cog dot brown dot edu 2007-08-20 23:24 ---
Created an attachment (id=14085)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14085&action=view)
Sample program showing that uniform_int() returns value out of range
returns -1 when run on
[EMAIL PROTECTED] tm
--- Comment #4 from ian at airs dot com 2007-08-20 23:30 ---
The problem I see is that this unconditional warning warns about code which is
completely safe and correct. That break -Werror builds. There is no natural
way to avoid the warning in a template. Given that, if we want to hav
In the C++ standard section 14.6.4.2 [temp.dep.candidate] says this:
"
For a function call that depends on a template parameter, if the function name
is an unqualified-id but not a template-id, the candidate functions are found
using the usual lookup rules (3.4.1, 3.4.2) except that:
-- For the p
--- Comment #5 from gdr at cs dot tamu dot edu 2007-08-21 00:19 ---
Subject: Re: C++ frontend should not warn about new a[0] in template context
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| The problem I see is that this unconditional warning warns about code which
is
| complet
--- Comment #1 from gdr at cs dot tamu dot edu 2007-08-21 00:23 ---
Subject: Re: New: C++ frontend finds static function in argument dependent
lookup based on template parameter
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| In the C++ standard section 14.6.4.2 [temp.dep.candida
I can not get past this error and build gcc/gfortran with or without bootstrap
enabled. Latest trunk.
In file included from
/home/jerryd/gcc/obj43/./prev-gcc/include-fixed/bits/string2.h:1308,
from /usr/include/string.h:417,
from ../../gcc43/libiberty/regex.c:14
--- Comment #2 from michelin60 at gmail dot com 2007-08-21 00:48 ---
This failure to boot perdures since since about 11.00 am. The extensive changes
submitted by Chao-ying Fu did not change anything.
Per telephone inquiry the same ICE occurs on a pentium3 but does not occur on a
pentium
--- Comment #3 from michelin60 at gmail dot com 2007-08-21 01:01 ---
Pr 33126 by torsten.debian.org seems to confirm this, even as that build was
for a cross-boot.
--
michelin60 at gmail dot com changed:
What|Removed |Added
Build was successful after stripping out all the -Werror flags from the
makefiles.
/tmp/gcc--4.2.1.build/./gcc/xgcc -B/tmp/gcc--4.2.1.build/./gcc/
-B/opt/tg/powerpc-ibm-aix4.3.3.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.3.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.3.0/include -isystem
/opt/tg/powerpc-ib
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-21 03:36 ---
*** This bug has been marked as a duplicate of 33126 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-21 03:36 ---
*** Bug 33125 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33126
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-21 03:37 ---
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01288.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
101 - 121 of 121 matches
Mail list logo
