I write a file, code as that:
#include
#include
using namespace std;
using namespace __gnu_cxx;
struct str_hash
{
size_t operator()(const string& str) const
{
return __stl_hash_string(str.c_str());
}
};
class A
{
public:
hash_map map_body;
public:
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-02-24 10:05 ---
/usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_pair.h:74:
error: `std::pair<_T1, _T2>::second' has incomplete type
tt.cpp:14: error: forward declaration of `class A'
You cannot use the
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-02-24 10:08 ---
Your program is buggy. This bugzilla is not for getting help on writing C
programs - try using a debugger and debug yourself.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-02-24 10:13 ---
Confirmed. Trying to get a small testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from jakub at gcc dot gnu dot org 2006-02-24 10:26 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #6 from jakub at gcc dot gnu dot org 2006-02-24 10:26 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-24 10:29 ---
Testcase: -O1 -ftree-vectorize -march=pentium4
void matmul_i4 (int bbase_yn, int xcount)
{
int x;
int * restrict dest_y;
const int * abase_n;
for (x = 0; x < xcount; x++)
{
dest_y[x]
--- Comment #3 from steven at gcc dot gnu dot org 2006-02-24 10:46 ---
"Don't worry, Jim. I'm monitoring the situation. I'm on top of things."
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pault at gcc dot gnu dot org 2006-02-24 10:51 ---
Subject: Bug 25395
Author: pault
Date: Fri Feb 24 10:51:42 2006
New Revision: 111416
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111416
Log:
2006-02-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2006-02-24 10:51 ---
Subject: Bug 24519
Author: pault
Date: Fri Feb 24 10:51:42 2006
New Revision: 111416
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111416
Log:
2006-02-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #4 from pault at gcc dot gnu dot org 2006-02-24 10:53 ---
Fixed on trunk.
As soon as 4.1 is reopened, it will be fixed there too.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pault at gcc dot gnu dot org 2006-02-24 10:53 ---
Fixed on trunk.
As soon as 4.1 is reopened, it will be fixed there too.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-24 11:28 ---
gfc_sym_type()
if (gfc_option.flag_f2c
&& sym->attr.function
&& sym->ts.type == BT_REAL
&& sym->ts.kind == gfc_default_real_kind
&& !sym->attr.always_explicit)
{
/* Special case:
The code below generates an ICE with g++ 3.3 (debian stable),
g++ 3.4 (debian testing):
[pollindd] ~ >g++-3.3 -c ice-typeid.cc
ice-typeid.cc: In function `int bug5(BaseB*)':
ice-typeid.cc:43: internal compiler error: in expand_expr, at expr.c:8833
P
--- Comment #1 from com dot d2 at free dot fr 2006-02-24 12:38 ---
Created an attachment (id=10907)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10907&action=view)
Code leading to ICE
Compile it with -DBUG=xyz to activate bug xyz
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #2 from com dot d2 at free dot fr 2006-02-24 12:40 ---
Created an attachment (id=10908)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10908&action=view)
Preprocessor output (gcc 3.4.4)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26455
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 13:04 ---
Actually this happens after VRP2 which might mean it is a bug for Jeff Law to
look into.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26443
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 13:06 ---
Confirmed. Though VRP2 is just doing constant propagation at this point.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 13:11 ---
can you give the full output of gcc -v?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26445
--- Comment #8 from pault at gcc dot gnu dot org 2006-02-24 13:15 ---
(In reply to comment #7)
> A few binary search steps later: Works with revision 111270, fails with
> 111271.
> It seems to be related to the patch
>
First, I am sorry to be a "doubting Thomas" - I finally succeeded
--- Comment #9 from pault at gcc dot gnu dot org 2006-02-24 13:54 ---
Subject: Bug 26409
Author: pault
Date: Fri Feb 24 13:54:06 2006
New Revision: 111417
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111417
Log:
2006-02-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #10 from pault at gcc dot gnu dot org 2006-02-24 14:15 ---
First, I am sorry to be a "doubting Thomas" - I finally succeeded in
reproducing the problem.
Second, I unpatched the above and find that this is indeed the problem. I will
try to understand why but:
(i) I have po
OpenMP C programs deadlock immediately after starting when OMP_NUM_THREADS is >
1.
For example, the following simple code just hangs:
#include
main() {
int i;
#pragma omp parallel for private(i)
for (i = 0; i < 100; i++)
printf("Thread = %d.\n", omp_get_thread_num());
}
This occurs on
--- Comment #1 from eloranta at jyu dot fi 2006-02-24 14:23 ---
Most likely this is just OS X specific bug.
--
eloranta at jyu dot fi changed:
What|Removed |Added
--- Comment #13 from Ralf dot Wildenhues at gmx dot de 2006-02-24 14:57
---
(In reply to comment #12)
> It appears that the LT stands for libtool. So the first one (LIBICONV) is
> supposed to be used for linking if you aren't using libtool, and the second
> one
> (LTLIBICONV) is used
The following code snippet, compiled with -Os -fstack-protector:
#include
int StringChecksum(char *s)
{
char buffer[2048];
int i;
int checksum = 0;
memset(buffer, 0, 2048);
strcpy(buffer, s);
for (i=0; i<2048; i++)
checksum += bu
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-02-24 15:08
---
Patch submitted:
http://gcc.gnu.org/ml/fortran/2006-02/msg00498.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 15:09 ---
This is Darwin specific.
This is a dup of bug 25978.
*** This bug has been marked as a duplicate of 25978 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 15:09 ---
*** Bug 26456 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 15:10 ---
More information about this issue is at the following thread:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00167.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25978
--- Comment #1 from jakub at gcc dot gnu dot org 2006-02-24 15:11 ---
To my knowledge xorl %eax, %eax is just a shorter form of xorq %rax, %rax,
both clear all 64 bits of %rax.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 15:12 ---
This is an issue of agrument passing really as eax is used to pass 0 to memset
though I don't know if this is really an issue or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-02-24 15:20
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-02-24 15:20
---
Ivopts fail to use the complex addressing mode, thus forcing one more biv into
inner loop. Since this makes it impossible to allocate registers for the loop,
we get another penalty for spilling.
Changing the ini
Prior behavior handled passing a char* with a NULL value into an output stream;
the result was that nothing printed. As of versions 3 and later this behavior
has changed. Perhaps a bug, perhaps a new enforcement.
The result is that the output stream no longer writes anything (to file or
stdout)
--- Comment #1 from pcarlini at suse dot de 2006-02-24 16:53 ---
The change is certainly intended and the important point is that is not true
that there is no indication of the failure, quite to the contrary the badbit is
set. Try changing your test like this:
char *str = NULL;
cout
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-24 17:25 ---
I want to say this is exactly the same issue as PR 25392, looking at the fact
it is the return value which is causing the issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 17:32 ---
Actually I could not reproduce this with "4.2.0 20060221"?
Is it only with the patch to fix PR 26421?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26439
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-24 17:34 ---
Actually this looks like it is x86 specific. Please next time add the target
if you think it is x86 specific and also pelase mention this was also using the
C++ front-end.
--
pinskia at gcc dot gnu dot org chang
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-24 17:36 ---
Actually I cannot reproduce this with "4.2.0 20060218" either on x86? What
were you doing to reproduce this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26439
--- Comment #37 from dcb314 at hotmail dot com 2006-02-24 17:38 ---
(In reply to comment #33)
> Created an attachment (id=10902)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10902&action=view) [edit]
> updated patch.
>
> better patch. I'm going to post that one when regtesting co
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-24 17:40 ---
Actually looking at the simplified testcase this is a dup of bug 25392.
*** This bug has been marked as a duplicate of 25392 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 17:40 ---
*** Bug 26440 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-24 17:42 ---
I cannot reproduce this with "4.2.0 20060218".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26444
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-24 17:46 ---
(In reply to comment #6)
> Actually I cannot reproduce this with "4.2.0 20060218" either on x86? What
> were you doing to reproduce this?
Or even the 20th.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26439
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-24 17:47 ---
I can reproduce this on the 20th though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26444
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-24 17:48 ---
So what this means I could not have caused this as the only patch after my 18th
GCC and my 20th GCC is not a patch which I committed that would have caused
this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-02-24 17:53
---
Note -O3 enables complete unrolling at the tree level, I think there might be
another related bug to this one. I bet it is failing in VRP2 also, just like
the other one.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #8 from ska at resqnet dot com 2006-02-24 17:53 ---
Any chances to get it resolved ?
This severe bug is a showstopper for using OpenCobol with GCC on AIX platform
because all C programs are generated and there are no way to reduce the size of
the programs automatically due t
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-02-24 17:54
---
(In reply to comment #10)
> Note -O3 enables complete unrolling at the tree level, I think there might be
> another related bug to this one. I bet it is failing in VRP2 also, just like
> the other one.
That would
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|ICE with -march=pentium4 - |[4.2 Regression
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-24 18:14
---
(In reply to comment #11)
> (In reply to comment #10)
> > Note -O3 enables complete unrolling at the tree level, I think there might
> > be
> > another related bug to this one. I bet it is failing in VRP2 also, j
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-02-24 18:16
---
Subject: Bug 26423
Author: jvdelisle
Date: Fri Feb 24 18:16:25 2006
New Revision: 111420
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111420
Log:
2006-02-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-24 18:22 ---
Actually never mind I see the issue now but I still say this is a latent bug
and not really my bug.
And the patch is wrong anyways in general as most of those places really should
have been testing
something like
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 18:23 ---
Actually this is still a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-02-24 18:23
---
Subject: Bug 26423
Author: jvdelisle
Date: Fri Feb 24 18:23:38 2006
New Revision: 111421
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111421
Log:
2006-02-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-24 18:24 ---
This is a dup of bug 25952.
*** This bug has been marked as a duplicate of 25952 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 18:24 ---
*** Bug 26452 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 18:30 ---
*** This bug has been marked as a duplicate of 26417 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 18:30 ---
*** Bug 26455 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
When configuring gcc with:
--target=powerpc-unknown-linux-gnuspe --host=powerpc-unknown-linux-gnuspe
--enable-e500_double
this file will be included:
gcc/config/rs6000/e500-double.h
which in turn uses the variable
rs6000_float_gprs_string
which is not defined anywhere. (So the build stops with unde
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 18:42 ---
It is obvious that it was caused by:
2005-05-05 Aldy Hernandez <[EMAIL PROTECTED]>
David Edelsohn <[EMAIL PROTECTED]>
* config.gcc: Add .opt magic for the rs6000 ports.
.
--
pinskia at
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 18:43 ---
It also tells us that testing powerpc-linux-gnuspe is not important as it has
been broken for over a half of a year.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #2 from phil at mitre dot org 2006-02-24 18:45 ---
Subject: RE: Passing a NULL char* into output stream now breaks the output
stream
Thanks for the quick response. This came up when some old systems were
ported from Solaris using gcc-2.9.5 or so and out output files just
s
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 18:48 ---
Confirmed, had 3.4 was the last import.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from edmar at freescale dot com 2006-02-24 18:49 ---
(In reply to comment #2)
> It also tells us that testing powerpc-linux-gnuspe is not important as it has
> been broken for over a half of a year.
>
We test all releases, the last one was 4.0.2 and it was OK.
--
ht
--- Comment #3 from phil at mitre dot org 2006-02-24 18:54 ---
See comment #2.
--
phil at mitre dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 18:55 ---
I think Paolo forgot to mention this is required by the C++ standard.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 18:59 ---
Well this one class file is not enough to reproduce this failure as I get
errors:
java/util/Comparator.java: In class
'org.eclipse.jdt.internal.compiler.parser.AbstractCommentParser':
java/util/Comparator.java: In co
--- Comment #5 from phil at mitre dot org 2006-02-24 19:00 ---
(In reply to comment #4)
> I think Paolo forgot to mention this is required by the C++ standard.
Well that's different then. I realize that many non-standard things were
allowed pre gcc-3.0 and that 3+ was starting to enfor
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-02-24 19:04
---
Edmar --
Does changing:
if (rs6000_float_gprs_string == NULL) \
rs6000_float_gprs = 2;
too:
if (!rs6000_explicit_options.float_gprs) \
rs6000_float_gprs = 2;
work? Not just compile, but also gener
--- Comment #5 from edmar at freescale dot com 2006-02-24 19:10 ---
(In reply to comment #4)
> Edmar --
>
> Does changing:
>
> if (rs6000_float_gprs_string == NULL) \
> rs6000_float_gprs = 2;
>
> too:
>
> if (!rs6000_explicit_options.float_gprs) \
> rs6000_float_gprs = 2;
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 19:13 ---
This is ICEing when printing a warning:
1038warning (0, "mudflap cannot track %qs in stub function",
1039 IDENTIFIER_POINTER (DECL_NAME (decl)));
DECL_NAME (decl) is NULL as t
--- Comment #6 from mark at codesourcery dot com 2006-02-24 19:14 ---
Subject: Re: [4.1/4.2 Regression] gcc fails to build on
powerpc e500-double targets
edmar at freescale dot com wrote:
> I started a build. This is a very slow target, it will take several hours...
If you've got a
--- Comment #2 from sayle at gcc dot gnu dot org 2006-02-24 19:29 ---
Subject: Bug 24952
Author: sayle
Date: Fri Feb 24 19:29:34 2006
New Revision: 111425
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111425
Log:
PR middle-end/24952
* combine.c (try_combine): E
--- Comment #3 from roger at eyesopen dot com 2006-02-24 19:37 ---
This has now been fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #23 from jakub at gcc dot gnu dot org 2006-02-24 19:45 ---
Created an attachment (id=10909)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10909&action=view)
gcc-trunk-pr26208.patch
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #24 from jakub at gcc dot gnu dot org 2006-02-24 19:45 ---
Created an attachment (id=10910)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10910&action=view)
binutils-trunk-pr26208.patch
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #25 from jakub at gcc dot gnu dot org 2006-02-24 19:56 ---
Updated patches. Unfortunately, it seems even this is not enough as Java
(and C++ as well, but there we aren't expecting to throw through signal
frames), the personality routine does the same as uw_frame_state_for wa
--- Comment #6 from pcarlini at suse dot de 2006-02-24 19:56 ---
(In reply to comment #2)
> Otherwise, there's great potential that the output stream (the data)
> will become corrupted, even if you manage to check it state.
By the way, there is no such thing as a "corrupted stream". Eit
--- Comment #7 from phil at mitre dot org 2006-02-24 20:40 ---
Subject: RE: Passing a NULL char* into output stream now breaks the output
stream
Agreed, the stream object itself hopfully doesn't get corrupted (bad),
but what I was refering to was "the data" itself, not the stream
objec
--- Comment #7 from edmar at freescale dot com 2006-02-24 20:45 ---
Created an attachment (id=10911)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10911&action=view)
Input program that causes ICE on gcc-4.1.0 RC2
No deal. I got an ICE now:
[root:/local/edmar/obj_gcc/powerpc-unkn
--- Comment #4 from steven at gcc dot gnu dot org 2006-02-24 20:48 ---
I'm not sure how to fix this. The debug trace here says it all: We try to
force something into an operand using an optab with a mode for which we have no
handler:
Starting program: /home/steven/devel/build-trunk/gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
I ran into this problem with stock gcc-4.0.2 on Fedora Core 2. The problem
shows when the following code is compiled with -O2: the address of "array"
seems to be cached and reused across calls to function "h". This becomes a
problem when function h saves its execution context in one thread and resu
stop
end
[dir:~/tests/gfortran-D] dir% gfortran --v
Using built-in specs.
Target: powerpc-apple-darwin8.5.0
Configured with: ../gcc/configure --prefix=/Users/dir/gfortran
--enable-languages=c,f95
Thread model: posix
gcc version 4.2.0 20060224 (experimental)
[dir:~/tests/gfortran-D] dir
$ cat const.c
#define B0 (+1.0l/5/1/6)
const double c0 = B0; // initializer element is not computable at load time
const double c0_tab[1] = { B0 }; // initializer element is not constant
#define B1 (+1.0l/5)
const double c1 = B1; // ok.
const double c1_tab[1] = { B1 }; // initializer element is
--- Comment #8 from pcarlini at suse dot de 2006-02-24 21:03 ---
(In reply to comment #7)
> . In my recent example I was
> explaining how, even if I asserted ostream state and detected that an
> error had occurred, I would not be able to determine
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 21:04 ---
This is a dup of bug 26374. The problem is that the middle-end does not fold
IBM 128bit long double format currently. See PR 19405 for history on why.
*** This bug has been marked as a duplicate of 26374 ***
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-24 21:04 ---
*** Bug 26462 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from mark at codesourcery dot com 2006-02-24 21:07 ---
Subject: Re: [4.1/4.2 Regression] gcc fails to build on
powerpc e500-double targets
edmar at freescale dot com wrote:
> --- Comment #7 from edmar at freescale dot com 2006-02-24 20:45 ---
> Created an attac
--- Comment #9 from phil at mitre dot org 2006-02-24 21:14 ---
Subject: RE: Passing a NULL char* into output stream now breaks the output
stream
Yup. But by providing the ability to batch stream inserts, per the
standard I presume otherwise it's not much of a stream, then you create
t
--- Comment #9 from edmar at freescale dot com 2006-02-24 21:15 ---
(In reply to comment #8)
> Subject: Re: [4.1/4.2 Regression] gcc fails to build on
> powerpc e500-double targets
>
>
>
> Bummer.
>
> Please attach preprocessed source and configuration options so that we
> have a s
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-02-24 21:17 ---
Subject: Re: [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in
matmul_i4.c in loop invariant motion
> I'm not sure how to fix this. The debug trace here says it all: We try to
> f
--- Comment #10 from pcarlini at suse dot de 2006-02-24 21:22 ---
(In reply to comment #9)
> ... If the standard says you can
> string together inserts, and that a failed insert will "disable" the
> stream until the error is cleared, but not allowing
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 21:32 ---
Why do you think this can ever work in general?
Also why do you need this to work this way? It seems like you are trying to
deal with your own threading system instead of allowing the OS do its work.
--
pinskia
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Component|c |middle-end
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2006-02-24 21:40
---
I will have to revert back a bit and see if this too is a regression or
something new. (yer killin me man! ;) )
Seriuously, though. We'll take all the testing we can get, even if it is
frustrating. Thanks.
-
1 - 100 of 120 matches
Mail list logo
