--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33495
The C++ frontend generates a broken diagnostic for the following code
snippet since GCC 4.0.0:
==
void foo()
{
if (({while(true);}))
;
}
==
bug.cc: In function 'void foo()':
bug.cc:3: error: could not co
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33494
The C++ frontend generates a broken diagnostic for the following code
snippet since GCC 3.4.0:
==
template void foo(int(*f=0)());
==
bug.cc:1: error: variable or field 'foo' declared void
bug.cc:1: error: 'f'
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33493
The C++ frontend generates a broken diagnostic for the following code
snippet since GCC 3.4.0:
==
template void foo() { delete 0 ? 1 : 0; }
==
bug.cc: In function 'void foo()':
bug.cc:1: error: could not conve
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-09-19 06:40
---
> The C++ frontend generates a broken diagnostic for the following code
> snippet since GCC 3.4.0:
Sorry, that's actually since GCC 3.0.
--
reichelt at gcc dot gnu dot org changed:
What|Removed
The C++ frontend generates a broken diagnostic for the following code
snippet since GCC 3.4.0:
===
void foo()
{
if (throw 0)
;
}
===
bug.cc: In function 'void foo()':
bug.cc:3: error: could not convert 'throw((__cxa_allocate_exception(4u),
#'must_not_
--- Comment #7 from ubizjak at gmail dot com 2007-09-19 06:20 ---
*** Bug 33482 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from ubizjak at gmail dot com 2007-09-19 06:20 ---
I'll backport http://gcc.gnu.org/viewcvs?view=rev&revision=128328 from PR
target/33369 to fix this issue.
*** This bug has been marked as a duplicate of 33369 ***
--
ubizjak at gmail dot com changed:
What
--- Comment #26 from eweddington at cso dot atmel dot com 2007-09-19 05:28
---
Subject: RE: [avr-gcc] Optimization decrease performance of
struct assignment.
> > c:/avrdev/gcc/gcc-4.3-20070914/libobjc/Object.m:66: error:
> unrecognizable
> > insn:
> > (insn 54 4 55 2
> c:/avrdev/gc
--- Comment #3 from bangerth at dealii dot org 2007-09-19 03:13 ---
Confirmed. Using sizeof with an argument that appears to have side effects
but isn't evaluated seems like an error waiting to happen.
W.
--
bangerth at dealii dot org changed:
What|Removed
It would be nice if there was a bit more documentation on parallel mode v3.
This could include some of Johannes' papers summarized here
http://algo2.iti.uni-karlsruhe.de/singler/mcstl/index.php?page=publications
Of even more interest I would find if the following: parallel mode probably
implement
The parallel version of std::accumulate assumes that iterator_traits
are declared for the iterator arguments. However, the standard only
requires them to be of kind InputIterator, and the table that describes
what types of this kind have to satisfy does not include the necessity
to declare a specia
This program compiles in sequential mode but not in debug mode:
-
#include
struct X { X(int); };
bool operator< (const X&, const X&);
void f () {
X *p, *q;
std::sort (p, q);
}
---
The reason is that X does not have a default constructor. I don't think the
--- Comment #2 from bangerth at math dot tamu dot edu 2007-09-19 02:43
---
Subject: Re: parallel v3: do not use __builtin_alloca,
use VLA
> shouldn't using __extension__ fix the warning/error for VLAs?
Yes, that's the other option. I guess Benjamin also wanted to find out for
good
This little program
--
#include
void f () {
bool *p, *q;
std::accumulate (p, q, 0U);
}
--
counts the 'true's in the range [p,q) but this doesn't work in parallel mode,
the compiler says that it can't resolve a function call. It should as per
26.4.1.
I
As a corollary to PR 33486, here is a valid program that doesn't
compile in parallel mode:
--
#include
void f () {
int *p, *q;
std::random_shuffle (p, q);
}
--
The reason is that random_shuffle internally calls a function that isn't
found in the correct namespac
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-19 02:37 ---
shouldn't using __extension__ fix the warning/error for VLAs?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33485
The following three programs compile just fine in normal mode, but
don't in parallel mode:
#include
#include
void f () {
std::set boundary_indicators;
find (boundary_indicators.begin(), boundary_indicators.end(), 1);
}
#include
#include
void f () {
find_template in parallel/find.h used to use a VLA, but Benjamin changed this
to use __builtin_alloca a couple of days ago because VLAs are not in C++98
and therefore trigger a warning.
He says the right thing to do is to use a VLA but make sure that the file
is recognized as a system header so th
--- Comment #6 from patchapp at dberlin dot org 2007-09-19 02:24 ---
Subject: Bug number PR 14688
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-09/msg01498.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-09-19
00:58 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01498.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14688
--- Comment #1 from yyounan at fort-knox dot org 2007-09-18 23:44 ---
Created an attachment (id=14222)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14222&action=view)
Patch against latest version in svn
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33484
--- Comment #3 from daney at gcc dot gnu dot org 2007-09-18 23:35 ---
The LOCKED bit is set. All the other fields in the hash entry are zero.
I think adding a memory barrier at the end of compare_and_swap fixes the
problem.
Currently I have:
inline static bool
compare_and_swap(volati
According to the man page, -mpreferred-stack-boundary allows one to specify
what the stack is aligned at.
"Attempt to keep the stack boundary aligned to a 2 raised to num byte boundary.
If -mpreferred-stack-boundary is not specified, the default is 4 (16 bytes or
128 bits)."
Example:
# gcc -mpref
--- Comment #2 from yuri at tsoft dot com 2007-09-18 22:58 ---
Warning should be issued in this case as well. Since this isn't an expected
behavior to ignore "n++".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33483
--- Comment #15 from bkoz at gcc dot gnu dot org 2007-09-18 22:55 ---
This should be cc'd to a build system maintainer, not libstdc++, which is only
peripherally involved.
I suggest Alexandre Oliva or Paolo Bonzoni.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-18 22:53 ---
Well when VLA's get added, sometimes sizeof will have side effects.
An example:
sizeof(int[n++])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33483
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
#include
using namespace std;
Here is a very dangerous situation that compiler can catch illustrated by the
following example: when sizeof has non-lvalue argument.
--- example ---
int f() {
cout << "I am f" << endl;
return 5;
}
int main() {
cout << "sizeof=" << sizeof(f()) << endl; // HER
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-09-18 22:49 ---
Subject: Bug 32819
Author: bkoz
Date: Tue Sep 18 22:49:24 2007
New Revision: 128589
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128589
Log:
2007-09-17 Benjamin Kosnik <[EMAIL PROTECTED]>
Chalat
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-09-18 22:49 ---
Subject: Bug 32822
Author: bkoz
Date: Tue Sep 18 22:49:24 2007
New Revision: 128589
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128589
Log:
2007-09-17 Benjamin Kosnik <[EMAIL PROTECTED]>
Chalat
--- Comment #2 from Hans dot Boehm at hp dot com 2007-09-18 22:26 ---
I assume the LOCKED bit in *he is actually set when gdb looks at it? What does
the rest of the hash entry look like? That might give you a hint as to the
culprit.
Clearly someone sets the LOCKED bit on a hash entry
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-18
22:24 ---
Subject: Re: FAIL: abi_check
> So, maybe something with libmath config, config for C99 functions?
Think so, I see asinf isn't found, yet it's there. I'm going
to remove "-j 2" from my make script. That
--- Comment #3 from bkoz at gcc dot gnu dot org 2007-09-18 21:54 ---
These all appear to be fails from missing C99 math functionality: tanl, etc.
So, maybe something with libmath config, config for C99 functions?
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32666
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-18 21:34
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-09-18 21:25
---
Subject: Bug 31119
Author: fxcoudert
Date: Tue Sep 18 21:25:40 2007
New Revision: 128587
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128587
Log:
PR fortran/31119
* trans-array.c (gfc_c
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-18 21:03
---
(In reply to comment #6)
> FX, which version of gfortran are you using? I cannot reproduce it (with
> valgrind) under x86_64-openSUSE-10.3b3 with today's gfortran 4.3 (Rev. 128538)
> - neither for -m32 nor -m64.
Testcase (test1.c):
#include
__m128i test_fn1(__m128i x)
{
__m128i y;
return _mm_srl_epi64(x,_mm_set_epi32(0,0,31,31));
}
gcc -O1 -c test1.c
/tmp/ccBc8BO7.s: Assembler messages:
/tmp/ccBc8BO7.s:7: Error: suffix or operands invalid for `psrlq'
gcc -O1 -S test1.s
test_fn1:
.LFB501:
p
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-09-18 20:07 ---
Subject: Re: data initialization with more than 2**32 elements
On Tue, Sep 18, 2007 at 07:26:22PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
>
> If I'm not mistaken, this will
--- Comment #25 from rask at gcc dot gnu dot org 2007-09-18 19:49 ---
> c:/avrdev/gcc/gcc-4.3-20070914/libobjc/Object.m:66: error: unrecognizable
> insn:
> (insn 54 4 55 2 c:/avrdev/gcc/gcc-4.3-20070914/libobjc/Object.m:65 (set
> (reg:QI 22 r22 [ D.2345 ])
> (subreg:QI (const:HI
--- Comment #8 from paolo at gcc dot gnu dot org 2007-09-18 19:42 ---
Subject: Bug 33462
Author: paolo
Date: Tue Sep 18 19:42:42 2007
New Revision: 128585
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128585
Log:
cp/
2007-09-18 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu
2007-09-18 19:26 ---
Subject: Re: data initialization with more than 2**32 elements
On Tue, Sep 18, 2007 at 07:16:42PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
>
> Ugh. I have a patch that would
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2007-09-18 19:16 ---
Subject: Re: data initialization with more than 2**32 elements
On Tue, Sep 18, 2007 at 06:02:03PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
> >
> > The problem is found in dec
--- Comment #1 from bangerth at dealii dot org 2007-09-18 19:16 ---
Can you try to come up with an example that is self-contained,
i.e. only contains those parts of the Tiny Vector Matrix library
that are really used (or none at all)?
W.
--
bangerth at dealii dot org changed:
--- Comment #8 from bangerth at dealii dot org 2007-09-18 19:13 ---
This works with a snapshot from yesterday.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #7 from pcarlini at suse dot de 2007-09-18 19:06 ---
If Gaby agree with that change, I'm ok with it.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #24 from eweddington at cso dot atmel dot com 2007-09-18 19:06
---
Subject: RE: [avr-gcc] Optimization decrease performance of
struct assignment.
> --- Comment #23 from rask at gcc dot gnu dot org
>
> In define_insn_and_split "*movhi", add the line
>
>&& LABEL_R
--- Comment #1 from pcarlini at suse dot de 2007-09-18 19:04 ---
*** This bug has been marked as a duplicate of 33475 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2007-09-18 19:04 ---
*** Bug 33480 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
--- Comment #3 from pcarlini at suse dot de 2007-09-18 19:04 ---
*** Bug 33481 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
--- Comment #1 from pcarlini at suse dot de 2007-09-18 19:04 ---
*** This bug has been marked as a duplicate of 33475 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|x86_64-suse-linux-gnu |
GCC host triplet|x86_64-suse-linux-gnu |
GCC target triplet
--- Comment #1 from bangerth at dealii dot org 2007-09-18 18:59 ---
Confirmed.
A simpler to understand testcase is this one (all crud removed):
-
class A {
class B { };
friend class X;
};
class X {
A::B mx;
class Y : A::B {
A::B my;
};
};
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived class
--- Comment #4 from bangerth at dealii dot org 2007-09-18 18:48 ---
To be quite clear: you can re-associate references (unlike pointers), so
when you do Ainst = Cinst, you copy the A-part of Cinst, but you still have
a 'B' whose 'A' component has just been overwritten.
W.
--
http:/
--- Comment #1 from daney at gcc dot gnu dot org 2007-09-18 18:48 ---
SyncTest never completes. When it gets into this state the threads are in the
followin state:
(gdb) thread 6
[Switching to thread 6 (Thread 758265024 (LWP 29566))]#0 0x2ce68fac in
pthread_cond_wait@@GLIBC_2.3.2 () f
--- Comment #2 from bangerth at dealii dot org 2007-09-18 18:41 ---
*** This bug has been marked as a duplicate of 33475 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--
--- Comment #2 from bangerth at dealii dot org 2007-09-18 18:41 ---
*** Bug 33477 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-09-18 18:47 ---
No this is not fixed. The error message is incorrect. Most users will not use
__builtin_va_arg directly, they will be using va_arg. So when they see
__builtin_va_arg, it will confuse them. Can you please change i
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived class
--- Comment #1 from bangerth at dealii dot org 2007-09-18 18:41 ---
*** Bug 33476 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
--- Comment #1 from bangerth at dealii dot org 2007-09-18 18:41 ---
*** This bug has been marked as a duplicate of 33475 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--
As noted in:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00818.html
With this configuration:
../trunk/configure --prefix=/home/ddaney/gccsvn/trunk-install
--target=mipsel-linux --build=mipsel-linux --host=mipsel-linux
--with-gmp=/home/ddaney/mp --with-mpfr=/home/ddaney/mp --with-arch=sb1
--d
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #1 from pcarlini at suse dot de 2007-09-18 18:29 ---
*** Bug 33478 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33477
--- Comment #1 from pcarlini at suse dot de 2007-09-18 18:29 ---
*** This bug has been marked as a duplicate of 33477 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived class
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived class
--- Comment #5 from pcarlini at suse dot de 2007-09-18 18:06 ---
Fixed in mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at
--- Comment #4 from paolo at gcc dot gnu dot org 2007-09-18 18:05 ---
Subject: Bug 33462
Author: paolo
Date: Tue Sep 18 18:05:40 2007
New Revision: 128584
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128584
Log:
/cp
2007-09-18 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2007-09-18 18:02 ---
Subject: Re: data initialization with more than 2**32 elements
On Tue, Sep 18, 2007 at 05:56:36PM -, kargl at gcc dot gnu dot org wrote:
>
> The problem is found in decl.c(top_val_list) at li
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived class
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived class
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-18 17:56 ---
A compiler comparison:
real(4) gfortran g95 NAGf95 ifort sunf95 openf95
default 808 0808 808 0 0
1PG20.6 18811881 1881 1881 18811881
1PG20.7 808 808808 808 808
--- Comment #1 from kargl at gcc dot gnu dot org 2007-09-18 17:56 ---
confirmed.
The problem is found in decl.c(top_val_list) at lines 404-411, which
are
signed int tmp;
msg = gfc_extract_int (expr, &tmp);
gfc_free_expr (expr);
if (msg != NULL)
--- Comment #3 from william dot adams at dot dot state dot fl dot us
2007-09-18 17:24 ---
4.2.1 had other build problems.
but this particular one appeared after i upgraded binutils to 2.18.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32272
Build failure in target libiberty:
/home/rask/build/gcc-bfin-unknown-elf/./gcc/xgcc
-B/home/rask/build/gcc-bfin-unknown-elf/./gcc/ -nostdinc
-B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/ -isystem
/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/targ-include
-isystem
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-18 16:40 ---
Subject: Re: [4.1/4.2/4.3 regression] Broken diagnostic: 'va_arg_expr' not
supported by dump_expr
On 18 Sep 2007 15:34:16 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> +case VA_ARG_EXPR:
> +
On 18 Sep 2007 15:34:16 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> +case VA_ARG_EXPR:
> + pp_cxx_identifier (cxx_pp, "__builtin_va_arg");
I would not use __builtin_va_arg here since this diagnostic, I would
just use va_arg.
Thanks,
Andrew Pinski
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2007-09-18
15:59 ---
Confirmed.
Also breaks bootstrap if CFLAGS is set to -O3.
I couldn't reproduce this with 4.1 so "reported against = 4.1.0" is probably
typo.
Can be reproduced in a cross compiler.
--
belyshev at depni
--- Comment #2 from pcarlini at suse dot de 2007-09-18 15:39 ---
Thanks a lot Jakub, I'm going to do exactly that but as part of
cxx_pretty_print.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33462
--- Comment #1 from jakub at gcc dot gnu dot org 2007-09-18 15:34 ---
--- gcc/cp/error.c.jj 2007-09-11 12:43:28.0 +0200
+++ gcc/cp/error.c 2007-09-18 17:25:14.0 +0200
@@ -2054,6 +2054,15 @@ dump_expr (tree t, int flags)
dump_type (t, flags);
break;
+
--- Comment #2 from pcarlini at suse dot de 2007-09-18 15:40 ---
Fixed in mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at
--- Comment #1 from paolo at gcc dot gnu dot org 2007-09-18 15:38 ---
Subject: Bug 33463
Author: paolo
Date: Tue Sep 18 15:38:02 2007
New Revision: 128582
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128582
Log:
/cp
2007-09-18 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #3 from photon at seznam dot cz 2007-09-18 15:12 ---
(In reply to comment #1)
> No, "B" is correct.
>
>
> A &Aref = Binst;
> Aref = Cinst;
>
> is the same as:
> Binst = (A)Cinst;
>
The compiler treats this case as Ainst = (A) Cinst.
--
photon at sezna
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #2 from pcarlini at suse dot de 2007-09-18 14:36 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from paolo at gcc dot gnu dot org 2007-09-18 14:35 ---
Subject: Bug 33464
Author: paolo
Date: Tue Sep 18 14:35:42 2007
New Revision: 128578
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128578
Log:
/cp
2007-09-18 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #4 from ubizjak at gmail dot com 2007-09-18 14:03 ---
Sorry, this is already fixed in latest SVN.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2007-09-18 13:48 ---
Insn constraint for following insn should be fixed:
(define_insn "*floatdi2_i387"
[(set (match_operand:MODEF 0 "register_operand" "=f,f")
(float:MODEF
(match_operand:DI 1 "nonimmediate_operand" "m,?r")
--- Comment #2 from ubizjak at gmail dot com 2007-09-18 13:40 ---
Caused by X86_USE_VECTOR_CONVERTS or X86_TUNE_INTER_UNIT_CONVERSIONS patch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
-
--- Comment #1 from rswan at signetic dot ca 2007-09-18 13:38 ---
Created an attachment (id=14221)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14221&action=view)
testcase archive
Extract archive. Invoke make within gch_bug directory. Bug seen in generated
main.d dependency outpu
--- Comment #3 from rask at gcc dot gnu dot org 2007-09-18 13:34 ---
With bug 33388 and bug 33397 fixed, the fix for bug 32154 fixes this one as
well (as of revision 128577).
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
-
Hello;
GCC does not correctly generate dependencies correctly with g++ -MD when
precompiled headers are used. I've attached an example which generates main.d
while compiling main.cpp. main.cpp includes include/bink.h. When the include
path contains the precompiled bink.h.gch (only), main.d does no
--- Comment #4 from rask at gcc dot gnu dot org 2007-09-18 13:28 ---
Fixed with revision 128577.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
S
1 - 100 of 131 matches
Mail list logo
