--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-30
06:54 ---
Subject: Bug 21286
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-30 06:54:08
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/inclu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
05:46 ---
I think this is invalid but I don't have the standard in front of me.
--
What|Removed |Added
--- Additional Comments From hpreg at vmware dot com 2005-04-30 05:33
---
*** Bug 20304 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From hpreg at vmware dot com 2005-04-30 05:33
---
Bug 21279 is about the same issue, but has a better simpler standalone test
case.
*** This bug has been marked as a duplicate of 21279 ***
--
What|Removed |Added
-
--- Additional Comments From jvdelisle at verizon dot net 2005-04-30 05:06
---
I am getting serious regressions here. i686-pc-linux-gnu
gcc version 4.1.0 20050430 (experimental)
with -O2
cbb.out: ZBB: 11 out of 3000 tests failed to pass the threshold
cbb.out: ZBB: 12 out of 300
--- Additional Comments From ncm-nospam at cantrip dot org 2005-04-30
03:49 ---
(In reply to comment #5)
> ... Thus, if you're writing structs, the reader will
> see half a struct.
Sorry, that's "will never see half a struct".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=212
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-30 03:34
---
I've got a patch in testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21294
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu
|dot org |
Status|UNCONFIRMED
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-30
03:06 ---
because they are supposed to also be constant, because even though overflowed,
they do not change, ever. :)
constants are constants are constants are constants. If it's not a constant, it
shouldn't be a _
--
What|Removed |Added
CC||kazu at cs dot umass dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21294
--- Additional Comments From dalej at gcc dot gnu dot org 2005-04-30 02:45
---
Certainly. Presumably the expectation was that overflowed constants would not
get here.
But I confess I don't see why not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21293
--- Additional Comments From ncm-nospam at cantrip dot org 2005-04-30
02:11 ---
Just to add... if sgetn() loops reading until it gets n bytes, but
underflow() accepts a pipe's short reads, then in_avail() will report
the size of the short read. Then, istream::read_some() will
rdbuf->
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-30
01:58 ---
This is also what i figured was the patch that fixed it
However, it *is* necessary for correctness because we need to consider constants
to be invariant, or else set_value_handle and friends will break.
We
--- Additional Comments From dalej at gcc dot gnu dot org 2005-04-30 01:56
---
Yes, I figured out that allowing overflowed constants in
is_gimple_min_invariant would fix it. But
that doesn't seem like it should be necessary for correctness. Zdenek changed
it to improve
optimization,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
01:46 ---
For VRP to catch this, extract_range_from_unary_expr has to be enhanced to deal
with ADDR_EXPR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21294
struct f
{
int i;
};
void link_error ();
void g(struct f *i)
{
i->i = 1;
if (&i->i == 0)
link_error ();
}
int main()
{
struct f n;
g(&n);
}
There should be no references to link_error.
The following is optimized:
void link_error ();
void g(int *i)
{
*i = 1;
if (i == 0)
link_e
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
01:29 ---
Reduced even further:
struct {
double x[1];
} g;
void k( double *, double*);
void h(int Tmp8)
{
int i;
for(i = 1;i <= Tmp8;i++)
k(&g.x[ + -1],&g.x[ Tmp8 + -1]);
}
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
01:17 ---
I just checked and a back porting of that patch fixes the ICE.
I might do the bootstrap/testing if I get some time tomorrow or later this week.
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
01:10 ---
This works on the mainline but fails on the 4.0.0 branch.
I think this was fixed on the mainline by:
2005-03-14 Zdenek Dvorak <[EMAIL PROTECTED]>
* tree-cfg.c (find_taken_edge_cond_expr): Use zero
On Apr 29, 2005, at 8:52 PM, Martin Sebor wrote:
I was surprised to see macro definitions in the output of gcc
-E -g3 (see below). Is that behavior by design or is it a bug?
(I haven't seen anything about it in the manual, other than what
-g/leve/ mentions about debugger support for macro expansion
I was surprised to see macro definitions in the output of gcc
-E -g3 (see below). Is that behavior by design or is it a bug?
(I haven't seen anything about it in the manual, other than what
-g/leve/ mentions about debugger support for macro expansion).
Thanks
Martin
$ cat t.cpp && gcc -E t.cpp -g3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
00:46 ---
(In reply to comment #1)
> Fold turns
>
> D.1157 = &fmcom_D.1134.x_D.1132[0] + -8B;
> into
>
> D.1157 = &fmcom_D.1134.x_D.1132[-1];
>
> which seems very wrong (we eventually crap out on the overf
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-30 00:21
---
We will not be setting __NO_MATH_INLINES for any reason. Work with glibc to get
the inlines disabled at the source under the correct conditions.
--
What|Removed |Added
-
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-30
00:17 ---
Fold turns
D.1157 = &fmcom_D.1134.x_D.1132[0] + -8B;
into
D.1157 = &fmcom_D.1134.x_D.1132[-1];
which seems very wrong (we eventually crap out on the overflowed constant)
--
http://gcc.gnu.org
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-30 00:06
---
Fixed in 4.0.0. c-decl.c in 3.4 was part way through a rewrite and
that intermediate version is fairly buggy and fragile, so backporting
fixes to that version seems inadvisable.
--
What|Remo
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-30 00:05
---
Fixed in 4.0.0. c-decl.c in 3.4 was part way through a rewrite and
that intermediate version is fairly buggy and fragile, so backporting
fixes to that version seems inadvisable.
--
What|Remo
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-30 00:04
---
Fixed in 4.0.0. c-decl.c in 3.4 was part way through a rewrite and
that intermediate version is fairly buggy and fragile, so backporting
fixes to that version seems inadvisable.
--
What|Remo
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-30 00:02
---
Fixed in 4.0.0. c-decl.c in 3.4 was part way through a rewrite and
that intermediate version is fairly buggy and fragile, so backporting
fixes to that version seems inadvisable.
--
What|Remo
--
Bug 15698 depends on bug 1, which changed state.
Bug 1 Summary: [3.4 regression] dremf type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
What|Old Value |New Value
-
The following crashes at compile time with -O2, on a local compiler built from
4.0 branch sources:
foo3.c: In function 'gciprt_':
foo3.c:8: internal compiler error: in set_value_handle, at tree-vn.c:179
(This has been cut down from a large original which did not have all those
uninitialized varia
The following failures of newly added tests are present on mainline for
ia64-hpux (both -milp32 and -mlp64); gcc-testresults shows them also on
ia64-linux.
FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vectorized 0 loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-29 22:39
---
That last sentence didn't make much sense, sorry; I meant that if you can't
initially reproduce the problem, please ask me if I've got more recent
failures to try out. Meanwhile, I'll post any short testcases
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-29 22:27
---
Today I'm seeing the same ICE building mesa and sometimes building 176.gcc.
Tests apsi. fma3d, gap, and gcc all cause GCC to segfault with "-O2
-ftree-vectorize -maltivec", some with -m32, some with -m64, and
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-04-29
22:11 ---
I have a fix for this.
The problem is like this:
- Sometimes, assign_stack_temp can generate an invalid memory address. Even if
the address was
always valid, it's not always offsettable, which is what th
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
21:58 ---
(In reply to comment #3)
> I can't build the Objective Caml compiler with this gcc error :/
If we change the asm to like so:
asm(""
: "+r" (a), "+r" (b), "+m" (blen), "+m" (out), "=&r" (tmp)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
21:52 ---
*** Bug 21290 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
21:52 ---
Even the code given in the bug has no dead code the bug is in the same in that
GCC creates dead code.
*** This bug has been marked as a duplicate of 19699 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
21:45 ---
Reduced testcase:
typedef unsigned long bngdigit;
typedef bngdigit * bng;
typedef unsigned int bngcarry;
typedef unsigned long bngsize;
bngdigit bng_ia32_mult_sub_digit
(bng a , bngsize alen,
bng
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-29 21:44 ---
(In reply to comment #5)
> Is this a regression?
Yes.
--
What|Removed |Added
--- Additional Comments From pluto at pld-linux dot org 2005-04-29 21:43
---
(In reply to comment #2)
> This is most likely not really a bug.
I can't build the Objective Caml compiler with this gcc error :/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
--- Additional Comments From dnovillo at redhat dot com 2005-04-29 21:39
---
Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
On Fri, Apr 29, 2005 at 09:11:12PM -, dnovillo at redhat dot com wrote:
> Huh. Odd. I just finished a bootstrap with
>
> $
--- Additional Comments From pcarlini at suse dot de 2005-04-29 21:31
---
Ok, I have asked privately Nathan Myers and what we need is rather simple: add
looping on short reads inside filebuf::sgetn, rather straightforward to
implement. Stay tuned!
--
What|Removed
--
What|Removed |Added
CC||mmazur at kernel dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
21:27 ---
This is most likely not really a bug.
--
What|Removed |Added
Component|other
--- Additional Comments From pluto at pld-linux dot org 2005-04-29 21:22
---
Created an attachment (id=8768)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8768&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
works with -O0, fails with -O[123].
gcc-4.0.0 + patches for pr20973,21173.
--
Summary: can't find a register in class 'GENERAL_REGS' while
reloading 'asm'
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
--- Additional Comments From gcc at magfr dot user dot lysator dot liu dot
se 2005-04-29 21:15 ---
Created an attachment (id=8767)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8767&action=view)
Example program demonstrating the problem
Compile with g++ -Wall -O1 -c foo.C to see t
When compiling I get the annoying warning below.
I did not get it with g++-3.4. g++-4.0 do produce it.
$ g++ --version
g++ (GCC) 4.1.0 20050429 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not
==GNAT BUG DETECTED======+
> | 4.1.0 20050429 (experimental) (i386-pc-solaris2.10) GCC error: |
> | in set_value_range, at tree-vrp.c:124|
> | Error detected at sem_intr.adb:437:1 |
>
>
--- Additional Comments From uros at kss-loka dot si 2005-04-29 20:48
---
(In reply to comment #5)
> Hmm, even though floor is C99, some libc (or in this case newlib) don't have
> full
> TARGET_C99_FUNCTIONS support.
Andrew, did you mean floorf in your comment?
The problem is that (i
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-29
20:37 ---
(In reply to comment #1)
> Confirmed, to me if the range of a variable is not really a range but one
value, it should always merge. I
> think that is safe.
It's only safe if both old ranges dominate the n
--- Additional Comments From trt at acm dot org 2005-04-29 20:20 ---
The patch given in comment #4 no successfully applies because the warning()
function has new initial parameter. Also the fold_buildN() cleanup invalidated
(and fixed) the "REAL_CST" part of the patch.
Some "speculative
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-29
19:58 ---
Created an attachment (id=8766)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8766&action=view)
This patch fixes some more alignment inconsistencies.
--
What|Removed
==+
| 4.1.0 20050429 (experimental) (i386-pc-solaris2.10) GCC error: |
| in set_value_range, at tree-vrp.c:124|
| Error detected at sem_intr.adb:437:1 |
Rainer
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-04-29 19:51 ---
Subject: Re: [PR tree-optimization/21029, RFC] harmful chrec type conversions
Thanks to Roger Sayle for pointing me at this PR.
Alexandre Oliva wrote:
>
> This is not a final patch; if the idea
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
19:49 ---
Hmm, even though floor is C99, some libc (or in this case newlib) don't have
full
TARGET_C99_FUNCTIONS support.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21282
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
19:47 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--
What|Removed |Added
CC||rth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21259
--- Additional Comments From uros at kss-loka dot si 2005-04-29 19:34
---
Hm, I would also suggest setting __NO_MATH_INLINES for -mfpmath=sse to prevent
the performance degradation for XMM->x87 registers when x87 ASM code is included
from mathinlines.h. x87 intrinsics are disabled for th
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
19:28 ---
Confirmed, to me if the range of a variable is not really a range but one
value, it should always merge. I
think that is safe.
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
19:26 ---
Oh, this is why CSiBE has been broken, I might look into it later if I get some
time.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
19:24 ---
Fixed. Will show up in 4.0.1.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
19:20 ---
So does recompiling gcc with --with-pic fix the problem?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
19:19 ---
libstdc++'s configure contains the docs for --with-pic:
--with-pic try to use only PIC/non-PIC objects default=use both
I think this is a standard libtool based option.
--
http://gcc.gnu.o
Consider
int
foo (int a, int b)
{
if (a == 1)
if (a < b)
if (a == 1)
return 1;
return 0;
}
VRP does not remove the third "if" even though 'a' is known to be 1.
This is because the symbolic range obtained from the second "if"
spoils the numeric range [1, 1] obtained from th
--
What|Removed |Added
Keywords||build, ice-on-valid-code
Summary|fortran bootstrap issues|bootstrap issues with
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
19:08 ---
Fixed.
(In reply to comment #7)
> This is now fixed, but it seems, even though I'm logged in, I can't change
> the state
> of this report.
I will get you admin. access.
--
What|Removed
--- Additional Comments From matz at suse dot de 2005-04-29 19:03 ---
This is now fixed, but it seems, even though I'm logged in, I can't change the
state
of this report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21144
--- Additional Comments From uros at kss-loka dot si 2005-04-29 18:56
---
Hm, this should be fixed by a fix for PR21004:
http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00794.html.
If I understand correctly, the problem is shown only with newlib. Does newlib
set TARGET_C99_FUNCTIONS?
--
ht
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29
18:52 ---
Subject: Bug 21266
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-29 18:51:58
Modified files:
gcc: ChangeLog
Log message:
2005
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29
18:52 ---
Subject: Bug 21272
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-29 18:51:58
Modified files:
gcc: ChangeLog
Log message:
2005
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
18:51 ---
Fixed. Add the PR number too.
--
What|Removed |Added
Status|NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29
18:50 ---
Subject: Bug 21238
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-29 18:50:01
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/inclu
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-29
18:48 ---
Removing target milestone; SH is not a primary or secondary target.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-29
18:48 ---
Removing target milestone; S390 is not a primary or secondary target.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29
18:43 ---
Subject: Bug 21115
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-29 18:43:25
Modified files:
gcc/java : builtins.c
Log message:
200
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29
18:43 ---
Subject: Bug 19285
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-29 18:43:25
Modified files:
gcc/java : builtins.c
Log message:
200
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29
18:42 ---
Subject: Bug 21115
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-29 18:42:50
Modified files:
gcc/java : java-tree.h expr.c decl.c class.c con
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29
18:42 ---
Subject: Bug 19285
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-29 18:42:50
Modified files:
gcc/java : java-tree.h expr.c decl.c class.c con
--- Additional Comments From tromey at gcc dot gnu dot org 2005-04-29
18:41 ---
I checked this in on the 4.0 branch.
It will appear in 4.0.1.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29
18:40 ---
Subject: Bug 21136
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-29 18:40:00
Modified files:
libjava: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29
18:39 ---
Subject: Bug 21144
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-29 18:39:23
Modified files:
gcc: ChangeLog postreload.c
Log message:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29
18:38 ---
Subject: Bug 21144
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-29 18:38:44
Modified files:
gcc: Change
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-29
18:38 ---
Removing target milestone; OpenDarwin is not a primary or secondary target.
--
What|Removed |Added
--
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-29
18:36 ---
This is invalid code, so removed rejects-valid marker.
--
What|Removed |Added
Key
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29
18:35 ---
Subject: Bug 19285
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-29 18:35:37
Modified files:
libjava: prims.cc link.cc ChangeLog
l
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-29
18:35 ---
Removed target milestone; SH is not a primary or secondary target.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-29
18:30 ---
Removing rejects-valid marker; spurious warnings do not count as rejects-valid.
--
What|Removed |Added
--
--
Bug 20280 depends on bug 19199, which changed state.
Bug 19199 Summary: [3.3/3.4 Regression] Wrong warning about returning a
reference to a temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
What|Old Value |New Value
---
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-29
18:28 ---
As per comment #37, closing as WONTFIX.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From pcarlini at suse dot de 2005-04-29 17:52
---
Really, you have to include math.h: the ISO Standard that we are implementing
is *very* clear about that, sorry. Much better, please move to and
in namespace std:: take seriously the warning! Thanks.
--
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-29 17:50
---
dpatel checked in a fix referencing PR 21272. That patch fixes the problems
I reported in 21272.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21266
(1) if you download core, g++, and fortran, only c and c++ are built; fortran is
not, unlike in prior releases.
(2) configuring with --enable-languages=c,c++,f95 and no other options; then
using make profiledbootstrap, I get an ICE:
/bin/sh ./libtool --mode=compile /var/tmp/bhudson-gcc/4.0.0/gcc/
--- Additional Comments From pcarlini at suse dot de 2005-04-29 17:28
---
Indeed, this is easily explained considering that we have a new optimization
that issues larger underlying read sys-calls (have a look to xsgetn in
fstream.tcc
to see what I mean): when everything goes well ;) are
I am trying to complie a simple program with math functions sqrt() and fabs
using gcc 3.4.3 (Red Hat 3.4.3-9.EL4). I am not able to compile without
including #include but same code works with earlier versions of gcc
3.3.3 (Suse ) and gcc 3.3.3 (Red Hat 3.2.3-42).
Code:
#include
int main()
{
--
What|Removed |Added
CC||ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21284
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29
16:29 ---
Subject: Bug 21030
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-29 16:23:20
Modified files:
gcc: ChangeLog tree-vrp.c
gcc/tes
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-04-29 16:29 ---
Subject: Re: MATMUL failing with ALLOCATED matrices,
unless base indices given
paulthomas2 at wanadoo dot fr wrote:
> --- Additional Comments From paulthomas2 at wanadoo dot fr
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-29 16:27
---
Just checked in a patch.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-29 16:25
---
Just checked in a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
1 - 100 of 164 matches
Mail list logo
