--- 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
--- 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: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: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: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 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
--
What|Removed |Added
CC||rth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21259
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-29
19:47 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- 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 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
==+
| 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 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
--- 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 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 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
==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 |
>
>
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
--- 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
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 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
--- 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
--
What|Removed |Added
CC||mmazur at kernel dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
--- 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
--- 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 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 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 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 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: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: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 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 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 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
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
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
--
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
-
--- 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
--- 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: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: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 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 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 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
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
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
--- 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
--- 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: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
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: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
--- 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 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 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 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
--
What|Removed |Added
CC||kazu at cs dot umass dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21294
--- 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
AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu
|dot org |
Status|UNCONFIRMED
--- 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
--- 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 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 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 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 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 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
101 - 164 of 164 matches
Mail list logo
