--- Additional Comments From Hu dot YuehWei at gmail dot com 2005-03-20
07:59 ---
so the "... = 3;" initialization statement below is a definition or a
declaration?
According to the C++ standard, its a definition.
Should the compiler allocate a memory space for it?
struct T
{
static
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-20 02:53
---
These test failures are fixed on mainline by:
2005-03-01 Paolo Bonzini <[EMAIL PROTECTED]>
* combine.c (gen_binary): Remove.
(known_cond, simplify_shift_const, find_split_point,
--- Additional Comments From commie1 at gmx dot net 2005-03-20 02:08
---
Testacse reduces to:
==
void SSEFunc(float* pDataIn)
{
float __attribute__ ((__mode__(__V4SF__))) accum;
accum = __builtin_ia32_xorps(accum,accum);
__builtin_ia32_storeaps(pDataIn, ac
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20
02:00 ---
With checking enabled we get an ICE:
t.cc: In function `int foo(int)':
t.cc:5: error: expected identifier before '*' token
t.cc:5: internal compiler error: tree check: expected identifier_node, have
error_m
The following program:
int foo(int dest)
{
int x = 0;
__label__ l1, l2, l3;
__label__ *lb[] = { &&l1, &&l2, &&l3 };
goto **lb[dest];
l1:
x += 1;
l2:
x += 1;
l3:
x += 1;
return x;
}
produce an infinite loop
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-20 01:26 ---
Oops, I had split up the patch into a non-critical (as far as
this bug report is concerned) part and a critical part, but messed up when
I pasted into bug report.
Following is the part for Self
--- Additional Comments From kahing at gmail dot com 2005-03-20 01:16
---
That works. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20561
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-20
00:58 ---
int b;
void foo (int a) {
if (a)
a = 3;
b = a;
}
GCC 3.3.5 (hammer-branch) on AMD64 -O2:
foo:
.LFB3:
testl %edi, %edi
movl$3, %eax
--- Additional Comments From pinskia at physics dot uc dot edu 2005-03-20
00:46 ---
Subject: Re: Error compiling jdtcore.jar on powerpc
I had meant -mlongcall.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20561
I had meant -mlongcall.
-- Pinski
--- Additional Comments From kahing at gmail dot com 2005-03-20 00:43
---
$ gcj-4.0 -mlong-branch -shared -findirect-dispatch -fjni -fPIC -o
./plugins/org.eclipse.jdt.core_3.0.1/jdtcore.jar.so
./plugins/org.eclipse.jdt.core_3.0.1/jdtcore.jar
jc1: error: invalid option ‘long-branch’
$ gc
--- Additional Comments From dkouroun at cc dot uoi dot gr 2005-03-20
00:38 ---
Subject: Re: cannot link program which uses std::(vector. deque) in SuSE
AMDx86_64
I did everything you said.
I installed gcc once again!
and I also removed gcc-3.4.3 from the .bashrc(PATH, LD_LIBRARY_PATH
--- Additional Comments From dkouroun at cc dot uoi dot gr 2005-03-19
23:47 ---
Subject: Re: cannot link program which uses std::(vector. deque) in SuSE
AMDx86_64
Quoting pcarlini at suse dot de <[EMAIL PROTECTED]>:
>
> --- Additional Comments From pcarlini at suse dot de 2005-
--- Additional Comments From mueller at kde dot org 2005-03-19 23:32
---
whoops, wrong frontend.
--
What|Removed |Added
Status|RESOLVED|UNCO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
23:19 ---
(In reply to comment #1)
> (In reply to comment #0)
> > There should be a "defined but not used" warning.
>
> Why, this is a constant array so it is removed right?
Never mind, but I can tell you this wa
--- Additional Comments From pcarlini at suse dot de 2005-03-19 23:17
---
> Do you really think is an installation problem?
Definitely. Those bash lines must *not* go inside .bashrc! Otherwise, are in
effect also when you use your system compiler and the wrong (3.4.3) library
is wronlgy
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
23:16 ---
(In reply to comment #0)
> There should be a "defined but not used" warning.
Why, this is a constant array so it is removed right?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20562
given this code:
=== Cut ===
static const char * const tcvnlocales[] = { "vi", 0 };
=== Cut ===
There should be a "defined but not used" warning.
--
Summary: no unused warning for static arrays
Product: gcc
Version: 4.0.0
Status: UNCONFIR
--- Additional Comments From dkouroun at cc dot uoi dot gr 2005-03-19
23:07 ---
Subject: Re: cannot link program which uses std::(vector. deque) in SuSE
AMDx86_64
Quoting pcarlini at suse dot de <[EMAIL PROTECTED]>:
>
> --- Additional Comments From pcarlini at suse dot de 2005-
--- Additional Comments From pcarlini at suse dot de 2005-03-19 22:45
---
...and also, at minimum, for the example:
'LD_LIBRARY_PATH="/usr/local/gcc34/lib:$LD_LIBRARY_PATH"; export
LD_LIBRARY_PATH'
Unfortunately, I think you had better removing completely the current gcc3.4.3
installat
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
22:44 ---
try compiling with -mlong-branch.
--
What|Removed |Added
Component|java
I followed the instruction on
http://developer.classpath.org/mediation/ClasspathShowcase to compile eclipse.
Here's the error:
Compiling ./plugins/org.eclipse.jdt.core_3.0.1/jdtcore.jar to native
/tmp/cccNhHCN.s: Assembler messages:
/tmp/cccNhHCN.s:1952484: Error: operand out of range (fff
--- Additional Comments From laurent at guerby dot net 2005-03-19 22:38
---
The bug is 4.1 only, it works on 4.0, consistent with front end problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548
--- Additional Comments From pcarlini at suse dot de 2005-03-19 22:38
---
> Yes I have also installed gcc-3.4.3!
> GCC-3.4.3 has no problem at all compiling that program!
> What can I do?
Ok, therefore this is only an installation problem, not a bug anywhere (I'm
going to close your rep
On Mar 19, 2005, at 5:27 PM, Demo Account wrote:
Hi, my gcc isn't working.
[EMAIL PROTECTED]:/mnt/lfs/sources$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1-20050313/configure --prefix=/tools
--libexecdir=/tools/lib --with-local-prefix=/tools --enable-clocale=gn
Hi, my gcc isn't working.
[EMAIL PROTECTED]:/mnt/lfs/sources$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1-20050313/configure --prefix=/tools
--libexecdir=/tools/lib --with-local-prefix=/tools --enable-clocale=gnu
--enable-shared --enable-threads=posix --enabl
--- Additional Comments From dkouroun at cc dot uoi dot gr 2005-03-19
22:07 ---
Subject: Re: cannot link program which uses std::(vector. deque) in SuSE
AMDx86_64
Quoting pcarlini at suse dot de <[EMAIL PROTECTED]>:
>
> --- Additional Comments From pcarlini at suse dot de 2005-
--- Additional Comments From dkouroun at cc dot uoi dot gr 2005-03-19
22:03 ---
Subject: Re: cannot link program which uses std::(vector. deque) in SuSE
AMDx86_64
Quoting pcarlini at suse dot de <[EMAIL PROTECTED]>:
>
> --- Additional Comments From pcarlini at suse dot de 2005-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:07 ---
*** Bug 20560 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:07 ---
I had meant PR 11624.
*** This bug has been marked as a duplicate of 11624 ***
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:07 ---
Woops wrong bug.
--
What|Removed |Added
Status|RESOLVED|UNCO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:06 ---
*** Bug 20560 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:06 ---
This is a dup of bug 16190.
*** This bug has been marked as a duplicate of 16190 ***
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:05 ---
Actually this is a dup, so reopening.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:05 ---
Fixed in 4.0.0 and above already.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:04 ---
Fixed in 4.0.0 and above.
--
What|Removed |Added
Status|UNCONFIRMED
At the moment it only warns, if there _is_ a non-virtual destructor:
-Wnon-virtual-dtor (C++ only)
Warn when a class appears to be polymorphic, thereby requiring a
virtual destructor, yet
it declares a non-virtual one. This warning is enabled by -Wall.
It doesn't warn
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-19 20:54 ---
In reply to comment #3
>From gnat_ugn.texi:
@findex Stdcall
@cindex Convention Stdcall
@item Stdcall
This is relevant only to NT/Win95 implementations of GNAT,
and specifies that the Stdcall c
--- Additional Comments From pcarlini at suse dot de 2005-03-19 20:52
---
Sorry about the apparently not-so-helpful reply, but really I think something is
broken with your specific setup: if this were a real bug, then basically no
non-trivial c++ program would work on x86_64, and this i
cannot link program which uses std::(vector. deque) in SuSE AMDx86_64
The compiler version is the default which comes with SuSE 9.2.
gcc (GCC) 3.3.4 (pre 3.3.5 20040809). The same program on SuSE 9.2
for i386 has no problem linking!
here it is:
---
#include
using namespace std;
#
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-19 19:54
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
19:53 ---
Subject: Bug 18525
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 19:52:53
Modified files:
gcc/fortran: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
19:45 ---
Subject: Bug 18525
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-19 19:45:46
Modified files:
gcc/fortran: ChangeLog dump-parse-tree.c resolve.c
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-19
19:33 ---
FWIW this bug is a major source of ifcvt1 opportunities, so fixing it
has positive downstream effects too.
--
What|Removed |Added
---
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-19
18:58 ---
Actually you can get this from any trivial "implicit set"-like
code, for example:
int b;
void foo (int a) {
if (a)
a = 3;
b = a;
}
The out-of-ssa pass turns that in
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
18:38 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
18:35 ---
Bacause T::A is a lvalue.
--
What|Removed |Added
Status|UNCONFIRMED
__builtin_isinf, __builtin_isnan and the various __builtin_is* functions
for unordered comparisons are declared as functions taking variable
arguments so they can be used directly to implement the corresponding C99
type-generic macros. However, __builtin_isinf does not work properly
as type-generi
--- Additional Comments From Hu dot YuehWei at gmail dot com 2005-03-19
18:25 ---
I see.
But why compiler doesn't also make a temporary variable for the constant defined
in a class scope?
Such as following codes:
struct T
{
static int const a = 3;
};
void
fff(int const &a)
{
}
int
m
--
What|Removed |Added
Target Milestone|4.1.0 |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20493
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
17:50 ---
Name lookup happens before accessibility happens. They are not tied together.
This is invalid. You can use a using statement in class C to remove the
ambigous.
--
What|Removed
Executing on host: /home/dave/gcc-4.1/objdir/gcc/xgcc -B/home/dave/gcc-4.1/objdi
r/gcc/ /home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.dg/pr18628.c -O2 -lm -o pr1
8628.exe(timeout = 300)
/home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.dg/pr18628.c: In function 'main':
/home/dave/gcc-4.1/gcc/gcc/testsui
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-19
17:38 ---
Fixed in CVS.
--
What|Removed |Added
Status|NEW |RESOLV
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
17:30 ---
Subject: Bug 20493
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 17:29:54
Modified files:
gcc: Change
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-19
17:25 ---
The last comment needs qualification. The technique doesn't work for
common symbols because of the special assembler semantics used for these
symbols on 32-bit hpux. However, it does work for other code an
Hi.
I'm writing a lookuptable container derived from 2 std::vectors (one public,
one
private).
The issue I came across can be witnessed by trying to compile:
[CODE]
#include
#include
using namespace std;
struct A
{
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
16:46 ---
Subject: Bug 20493
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-19 16:46:04
Modified files:
gcc: ChangeLog fold-const.c
Log message:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
16:39 ---
*** Bug 20555 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
16:39 ---
*** This bug has been marked as a duplicate of 20537 ***
--
What|Removed |Added
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-19
16:15 ---
What I was trying to indicate in the previous comment is that aliases
can be created on targets that don't support ASM_OUTPUT_DEF by emitting
the labels at the same time as the target label.
This happens in
After make install, PATH=... with mainline on x86_64 as of 20050319:
For C :
$ gcc z.c
/usr/bin/ld: crtbegin.o: No such file: No such file or directory
collect2: ld returned 1 exit status
For Ada:
$ gnatmake t.adb
fatal error, run-time library not installed correctly
cannot locate file
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-19
15:50 ---
On hppa2.0w-hp-hpux* (32-bit SOM targets), there is no assembler support
to create an alias except by emitting a label for the alias at the same
time as the target label. There is no way to defer emitting a
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
15:45 ---
Subject: Bug 18251
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 15:45:41
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
15:44 ---
Subject: Bug 18251
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 15:44:26
Modified files:
gcc: Change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
15:42 ---
2009-[12].c is a dup of bug 20524.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20554
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
15:41 ---
*** Bug 20553 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20524
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
15:41 ---
*** This bug has been marked as a duplicate of 20524 ***
--
What|Removed |Added
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-19
15:40 ---
Just a guess, but I would suspect this is caused by the following change:
2005-03-16 Richard Henderson <[EMAIL PROTECTED]>
PR middle-end/15700
* varasm.c (struct alias_pair): Rename from
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-19
15:38 ---
Uncovered by a front-end change. Not sure it can work on 64-bit machines now.
--
What|Removed |Added
-
--- Additional Comments From christian dot joensson at gmail dot com
2005-03-19 15:37 ---
I guess this is related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20553
and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20554
--
What|Removed |Added
-
--
What|Removed |Added
CC||christian dot joensson at
||gmail dot com
http://gcc.gnu.org/bu
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-19
15:34 ---
This also occurs on hppa64-hp-hpux11.11 (4.1.0)
--
What|Removed |Added
CC|
FAIL: gcc.c-torture/compile/2009-1.c -O0 (test for excess errors)
FAIL: gcc.c-torture/compile/2009-1.c -O1 (test for excess errors)
FAIL: gcc.c-torture/compile/2009-1.c -O2 (test for excess errors)
FAIL: gcc.c-torture/compile/2009-1.c -O3 -fomit-frame-pointer (test for ex
ce
--- Additional Comments From christian dot joensson at gmail dot com
2005-03-19 15:20 ---
This also happens on mainline, see
http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01267.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20553
--- Additional Comments From christian dot joensson at gmail dot com
2005-03-19 15:18 ---
[EMAIL PROTECTED] branch]$ /usr/local/src/branch/objdir32/gcc/xgcc -v
-save-temps -B/usr/local/src/branch/objdir32/gcc/ -O1 -w -c -o
2009-2.o /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-
t
Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u:
binutils-2.15.94.0.2-1.sparc
bison-1.875c-2.sparc
dejagnu-1.4.4-2.noarch
expect-5.42.1-1.sparc
gcc-3.4.2-6.fc3.sparc
gcc4-4.0.0-0.8sparc.sparc
glibc-2.3.3-99.sparcv9
glibc-2.3.3-99.sparc64
glibc-devel-2.3.3-99.sparc64
glibc
--- Additional Comments From laurent at guerby dot net 2005-03-19 14:59
---
I haven't tested x86_64 on current 4.0, will try this weekend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548
--- Additional Comments From p dot obry at wanadoo dot fr 2005-03-19 14:52
---
I had a closer look.
In GCC 3.4.x we have TARGET_IS_PE_COFF. So changing _WIN32 by
TARGET_IS_PE_COFF is ok.
In GCC 4.x we have:
#define TARGET_DLLIMPORT_DECL_ATTRIBUTES 1
So instead of using TARGET_IS_PE_C
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
14:49 ---
Do you know if this happens on say x86_64 (so it will then be targeted towards
4.0.0 and someone can
look into it)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20510
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
14:43 ---
The following patches might be the cause:
+2005-03-18 Jan Hubicka <[EMAIL PROTECTED]>
+
+ PR middle-end/20225
+ * cgraph.c (cgraph_mark_reachable_node): Assert that it is not called
+ too
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
14:34 ---
(In reply to comment #5)
> I understand what you mean.
> But why the following codes works:
>
> #include
> #include
>
> struct T
> {
> static char const a = 3;
> };
>
> std::vector ddd;
>
> int
> mai
--
What|Removed |Added
CC||ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20530
--- Additional Comments From Hu dot YuehWei at gmail dot com 2005-03-19
14:15 ---
I understand what you mean.
But why the following codes works:
#include
#include
struct T
{
static char const a = 3;
};
std::vector ddd;
int
main()
{
ddd.push_back(static_cast(T::a)); // <
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-19
14:15 ---
Fixed in 3.4/4.0/4.1.
--
What|Removed |Added
AssignedTo|lerdsuwa at gcc dot gnu dot
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
14:03 ---
(In reply to comment #2)
> But according the standard, 'const static' data members of an intergral type
> can
> now be initialized _inside_ their class. In this case, the initialization is
> _also_ a defini
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
14:01 ---
Subject: Bug 20240
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 14:01:02
Modified files:
gcc/cp : Change
--- Additional Comments From Hu dot YuehWei at gmail dot com 2005-03-19
14:01 ---
#include
struct T
{
static char const a = 3;
};
void
fff(char a)
{
}
std::vector b;
int
main()
{
fff(T::a); /* this line of codes is fine. */
b.push_back(T::a); /* however, this line of codes is
--- Additional Comments From charlet at adacore dot com 2005-03-19 13:54
---
Subject: Re: Windows errorcodes wrong in Ada when tasking
> IMO, resetting the error code set by the kernel whenever the internal Ada
> tasking functions are called successfully is a bug.
So you are saying th
--- Additional Comments From Hu dot YuehWei at gmail dot com 2005-03-19
13:53 ---
But according the standard, 'const static' data members of an intergral type can
now be initialized _inside_ their class. In this case, the initialization is
_also_ a definition, so _no_ further definitions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
13:48 ---
*** Bug 20551 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
13:48 ---
*** This bug has been marked as a duplicate of 6709 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
13:45 ---
No you need to add the following to your code:
const char T::a;
Since you don't supply the memory location otherwise (which is required by the
standard).
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
13:39 ---
(In reply to comment #2)
> Confirmed; compile the following reduced testcase with -Wstrict-prototypes
> to see the bug. I don't have --enable-checking release branch compilers
> (4.0 and previous releases)
--
What|Removed |Added
Keywords||ice-on-invalid-code
Known to work||4.0.0 4.1.0
http://gcc.gnu.org/bugzilla/s
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-19 13:34
---
*** Bug 20535 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-19 13:34
---
What you want is a better -Wconversion, "warn for any implicit conversion that
may change a value"; see bug 9072 (and also bug 6614). Bug 9072 effectively
tracks the need for a better -Wconversion while bug 6
--
What|Removed |Added
Attachment #8423|application/octet-stream|text/plain
mime type||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
13:30 ---
Reduced testcase:
template
t1 unique(t1 v1, t1 v2, t2 v3){}
struct row
{
int begin() const ;
int end() const;
};
template
void popSlot()
{
row ops;
unique(ops.begin, ops.end);
}
This is invalid c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
13:24 ---
(In reply to comment #10)
> (In reply to comment #8)
>
> > Due to general gfortran lameness only contained functions are ever inlined.
> >
> > Top-level functions are never inlined.
>
> Why?
I think P
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-19 13:23
---
Could someone with a Darwin build to hand check whether this bug is indeed fixed
as I suggest in my previous comment?
--
What|Removed |Added
--
1 - 100 of 127 matches
Mail list logo
