--- Comment #7 from rwild at gcc dot gnu dot org 2010-09-18 05:55 ---
I'll look into it. (Not changing state to Assigned, as I haven't confirmed
yet.)
>From looking at libstdc++-v3/src/Makefile.am, the issue should have been
present for the last few (>=3) years already, though. If you
--- Comment #7 from hjl dot tools at gmail dot com 2010-09-18 03:36 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01461.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #6 from hjl dot tools at gmail dot com 2010-09-18 02:59 ---
This patch:
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01459.html
fixes the bug, but caused:
FAIL: g++.dg/conversion/op5.C (test for errors, line 18)
FAIL: g++.dg/conversion/op5.C (test for excess errors)
Now,
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-18 01:31
---
Fixed for 4.6.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo at gcc dot gnu dot org 2010-09-18 01:29 ---
Subject: Bug 45713
Author: paolo
Date: Sat Sep 18 01:29:31 2010
New Revision: 164388
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164388
Log:
2010-09-17 Luc Hermitte
Paolo Carlini
P
--- Comment #17 from t7 at gmail dot com 2010-09-18 01:14 ---
(In reply to comment #15)
> (In reply to comment #14)
> > Created an attachment (id=21820)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21820&action=view) [edit]
> > testcase for problem
> >
> > As this test need m
--- Comment #16 from t7 at gmail dot com 2010-09-18 01:04 ---
(In reply to comment #15)
> (In reply to comment #14)
> > Created an attachment (id=21820)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21820&action=view) [edit]
> > testcase for problem
> >
> > As this test need m
--- Comment #6 from paolo dot carlini at oracle dot com 2010-09-18 00:42
---
I used to, and tried again moments ago, everything is fine here. Maybe we are
talking about another path?!? I'm puzzled. Let's add in CC Ralf...
--
paolo dot carlini at oracle dot com changed:
W
--- Comment #5 from redi at gcc dot gnu dot org 2010-09-18 00:26 ---
I nearly *always* build with ../gcc/configure --enable-libstdcxx-debug and
haven't seen this on GNU/Linux (I'm not saying Makefile.am is right, just that
the problem isn't apparent for me)
--
http://gcc.gnu.org/bug
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-17 23:53
---
Confirmed, I will apply a variant (__n is unsigned here and the original
expression can be simplified) of your patch momentarily, after testing. Of
course the issue is really noticeable only on 32-bit machines.
--- Comment #1 from meissner at gcc dot gnu dot org 2010-09-17 23:29
---
Created an attachment (id=21826)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21826&action=view)
Fortran program from spec 2006 that shows the bug
Fortran program derived from spec 2006 that shows the bug.
This fortran program fails for both x86_64 and powerpc when an appropriate
veclibabi is specified that includes support for optimizing a pow invocation to
V2DF variables.
On the x86_64 you need to use:
-O3 -march=core2 -mavx -ffast-math -mveclibabi=svml
On the powerpc you need to use:
-O3 -mcpu=p
--- Comment #2 from meissner at gcc dot gnu dot org 2010-09-17 23:21
---
Created an attachment (id=21825)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21825&action=view)
Potential patch to fix the problem
This bandaid patch will allow the compiler to not segfault, but I'm unsure
--- Comment #1 from meissner at gcc dot gnu dot org 2010-09-17 23:19
---
Created an attachment (id=21824)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21824&action=view)
Source file that shows the problem.
This is a somewhat cutdown source file that shows the problem.
--
ht
Hello,
std::bitset cannot be instantiated with an extremely big number of bits like
ULONG_MAX.
e.g.
- >% --
#include
#include
int main()
{
std::cout << sizeof (std::bitset<0x>) << std::endl;
}
- >% --
outputs 1 with g++ 3.4.4 and 4.3.4 on cygw
The attached file that is derived from the spec 2006 benchmark suite fails if
you compile it with minimal optimization and -g. If I remove the -g option, it
compiles fine.
I initially noticed this on powerpc64-linux-gnu, but it looked like a machine
independent bug, so I tried it on a x86_64-unkn
--- Comment #5 from hjl dot tools at gmail dot com 2010-09-17 22:20 ---
Revision 127647 is the first revision which failed to compile this.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #4 from hjl dot tools at gmail dot com 2010-09-17 22:17 ---
Revision 127647:
http://gcc.gnu.org/ml/gcc-cvs/2007-08/msg00541.html
introduced:
[...@gnu-26 gcc]$ ./xgcc -B./ -S -O ../../../pr45709.cc
../../../pr45709.cc: In member function virtual void foo::bar():
../../..
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 22:02 ---
It was introduced between revision 127644 and 127649.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #55 from paolo dot carlini at oracle dot com 2010-09-17 21:59
---
> I'm
> getting the impression that you guys got tired after a long redesign process
> and oversimplified the state machine.
Not me. Wh
--- Comment #1 from kargl at gcc dot gnu dot org 2010-09-17 21:53 ---
Could you format your bug report any more poorly?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45710
--- Comment #54 from potswa at mac dot com 2010-09-17 21:51 ---
Well, for my part, a few years ago I played around with fstream a little,
noticed the tellg requirement was weird (I only discovered it by throwing the
kitchen sink at the problem), wasn't able to interpret the standard well
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-17 21:43
---
So, did this change recently?!?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-17 21:36 ---
manphiz: it's a bug
the build_debug and install_debug targets in libstdc++-v3/src/Makefile.am are
broken if you run configure using a relative path
the Makefile.am is broken
it does "cd debug && make install"
t
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-17 21:33
---
This doesn't happen on Linux, seems a Target issue. Please try to figure out
much more exactly when the problem started (possibly which specific revision,
use SVN), because very few among the C++ library develo
--- Comment #53 from paolo dot carlini at oracle dot com 2010-09-17 21:22
---
What can I say, I don't know anybody still using GCCs dating back to 2003. In
any case, my point wasn't really about seek(0, cur) and its optimization, etc,
my point was about the general design, where you use
--- Comment #1 from manphiz at gmail dot com 2010-09-17 21:19 ---
Created an attachment (id=21823)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21823&action=view)
Full build log. (Built using a custom Portfile through macports system)
--
http://gcc.gnu.org/bugzilla/show_bug.c
Since gcc 4.6.0 trunk snapshot 20100904 (or maybe earlier), the building fails
with option "--enable-libstdcxx-debug". The last 30 some lines of build log
shows:
- BEGIN -
Making install in src
(cd debug && /usr/bin/make CXXFLAGS='-g3 -O0' all)
make[4]: Nothing to be done for `all'.
test -
--- Comment #52 from don dot wakefield at gmail dot com 2010-09-17 21:11
---
(In reply to comment #51)
> ...As a matter of fact, many users found it also quite easy to
> use, because - in case wasn't clear already from my previous comments -
> **nobody ever** complained.
I just have t
rtran.
!
! Also, note that a large NAMELIST group would require a very large character
variable length.
!
! 20100917 - JSU
PROGRAM NMIF
! when writing a NAMELIST group to an internal file the entire NAMELIST
! output is written to a single character variable, and no wrapping is
! provided even i
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-17 20:35 ---
Not what is happening is an interaction between the inlining and the return
slot optimization and the named value optimization.
Before inlining we have:
# storage_1 = PHI <&.storage[0](2), &.storage[1](3)>
...
c
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-17 20:25 ---
Reduced testcase:
struct Region {
int storage[4];
int count;
};
static inline Region subtract(int lhs)
{
Region reg;
int* storage = reg.storage;
if (lhs > 0)
storage++;
reg.count = storage - reg.s
--- Comment #19 from hjl dot tools at gmail dot com 2010-09-17 20:24
---
It comes back with revision 164375:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00669.html
for PR 45678. On Linux/ia32, I got
FAIL: gcc.target/i386/incoming-9.c scan-assembler-not andl[\\t ]*\\$-16,[\\t
]*%esp
It
--- Comment #51 from paolo dot carlini at oracle dot com 2010-09-17 20:07
---
If you can allow writes after reads and viceversa *also* without seeks in the
middle, and without affecting performance and without adding data members,
that's fine. Let's see what you come up with it. By the
--- Comment #50 from potswa at mac dot com 2010-09-17 19:56 ---
(In reply to comment #49)
> with seeks
> switching between reading and writing via state variables, then it's fine, in
> principle.
Why require seeks? The whole point is that they are extraneous. I'm not
proposing to break
[...@gnu-35 rrs]$ cat foo.cc
struct foo {
virtual void bar();
struct Rect {
int bottom;
};
struct Region {
static Region subtract(const Rect& lhs, const Rect& rhs)
{
Region reg;
Rect* storage = reg.storage;
{
if (lhs.bottom > rhs.bottom
--- Comment #49 from paolo dot carlini at oracle dot com 2010-09-17 19:50
---
It was **a ton** of work and discussions in public and among the maintainers,
in private. Anyway, if you have something which doesn't touch basic_streambuf,
keeps the get and put areas of basic_filebuf complet
--- Comment #48 from potswa at mac dot com 2010-09-17 19:45 ---
I'm having trouble finding the discussion that precedes the June 24, 2003
redesign, but I'll add "unified" to the search terms.
Actually, last week I started some changes with the aim of fixing the bug, not
changing the phi
--- Comment #47 from paolo dot carlini at oracle dot com 2010-09-17 19:38
---
To further clarify: what you have in mind isn't something which can belong to a
casual PR, is a major redesign of basic_filebuf, according to a different basic
philosophy, which at the time, Nathan called unif
--- Comment #46 from paolo dot carlini at oracle dot com 2010-09-17 19:26
---
Ok, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #45 from potswa at mac dot com 2010-09-17 19:21 ---
Already did copyright assignment :vP
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #44 from paolo dot carlini at oracle dot com 2010-09-17 19:17
---
By the way, if, for the future, you mean to contribute in these areas, if you
are really interested in these topics, I would recommend starting immediately
the Copyright assignment paperwork http://gcc.gnu.org
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-17 19:12
---
This is a major redesign in any case, which would change completely the user
experience. Again, please analyze carefully all the discussions which led to
the current design (possibly get in contact with Nathan
--- Comment #43 from potswa at mac dot com 2010-09-17 19:11 ---
Thanks for the pointer, I'll read that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #42 from paolo dot carlini at oracle dot com 2010-09-17 19:10
---
Before any other bug or analysis, I would recommend going back to the ton of
discussions in 2002 / 2003 when the design of basic_filebuf has been changed to
use _M_reading and _M_writing, **on purpose**. Didn'
--- Comment #2 from potswa at mac dot com 2010-09-17 19:09 ---
ABI bump? Would this require additional data members? I would think it requires
less.
Isn't this at least a duplicate of something?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45708
--- Comment #41 from potswa at mac dot com 2010-09-17 19:04 ---
Well, I'm happy if you'd like to merge the diffs. My code was written with the
intent of optimizing the output case, too, but I guess it's not too inefficient
or awkward from the perspective of input only.
I just filed a bu
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-17 19:03
---
Not going to happen, at least not until the very far future, in the occasion of
an ABI bump or a global redesign.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #9 from spop at gcc dot gnu dot org 2010-09-17 19:01 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
basic_filebuf (and therefore fstream) does not allow you to put a write
operation directly after a read operation, or vice versa. Instead, the write
and the read must be separated by a seek or tell (tell being equivalent to a
seek-to-current-position).
As the Standard specifies behavior in terms o
--- Comment #40 from paolo dot carlini at oracle dot com 2010-09-17 18:53
---
In general, our users know that seeking allows to switch from reading to
writing, and viceversa (when the stream has been appropriately opened of
course). This assumption remained true for years and years. Thu
--- Comment #15 from ktietz at gcc dot gnu dot org 2010-09-17 18:37 ---
(In reply to comment #14)
> Created an attachment (id=21820)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21820&action=view) [edit]
> testcase for problem
>
> As this test need more then on header, please ext
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-09-17 18:21 ---
The problem is a big one. In short, placement new operator changes
the type of an object to another, which re-sets up the VMT. Then there
is call of a virtual method of the latter type. CCP however happily
propagat
--- Comment #39 from potswa at mac dot com 2010-09-17 18:04 ---
Oops, no, I'm on the 4.5.2 series, not mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #17 from hjl at gcc dot gnu dot org 2010-09-17 18:00 ---
Subject: Bug 45234
Author: hjl
Date: Fri Sep 17 18:00:40 2010
New Revision: 164377
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164377
Log:
Make sure that all variable sized adjustments are multiple of prefer
--- Comment #38 from potswa at mac dot com 2010-09-17 17:51 ---
Created an attachment (id=21822)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21822&action=view)
Works with codecvt. Tested Tested x86_64-darwin, mainline
Ah, now I see the trick:
if (__off == 0 && !(_M_mode
--- Comment #26 from hjl at gcc dot gnu dot org 2010-09-17 17:49 ---
Subject: Bug 45678
Author: hjl
Date: Fri Sep 17 17:49:30 2010
New Revision: 164375
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164375
Log:
Update stack alignment when increasing local variable alignment.
gc
--- Comment #25 from hjl dot tools at gmail dot com 2010-09-17 17:26
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01425.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #5 from iains at gcc dot gnu dot org 2010-09-17 17:05 ---
(In reply to comment #4)
> >> Ok ... I fixed the testcase in trunk.
> >
> > Is there not a simpler way to fix the test with dejagnu directives?
>
> Probably. :-)
well that's why I added the /torture dir under objc.
--- Comment #1 from nicola at gcc dot gnu dot org 2010-09-17 16:53 ---
Thanks
well spotted :-)
Unfortunately, the list_remove_elem() function is obsolete (never used inside
the runtime itself, and deprecated for usage outside of it as of 4.6.0) so
there is not much point in working on
--- Comment #4 from nicola at gcc dot gnu dot org 2010-09-17 16:40 ---
>> Ok ... I fixed the testcase in trunk.
>
> Is there not a simpler way to fix the test with dejagnu directives?
Probably. :-)
The fix in trunk does work and is consistent with other files in the same
directory.
--- Comment #24 from hjl dot tools at gmail dot com 2010-09-17 16:35
---
Created an attachment (id=21821)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21821&action=view)
A patch
The problem is we failed to update stack alignment when
we increase alignment of local variable. Thi
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-17 16:32 ---
This code depends on two undefined behavior. First it depends on an
uninitialized value of i. If i is greater than 0 to begin with it depends on
signed integer overflow which is undefined.
--
pinskia at gcc dot
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 16:30 ---
For some reason, it only fails with 32bit gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-17 16:30 ---
(In reply to comment #1)
> This passes for me, even in -m32 mode (if -msse is added, like vect.exp
> does):
>
> % ./cc1 -ftree-vectorize -fno-vect-cost-model -msse2 -O2 \
> vect-114.c -ftree-vectorizer-verbose=2 2
#include
int main()
{
int i;
while(1)
{
if(i<0)
{
break;
}
i++;
}
return 0;
}
compiled with -O3
infinite loop:
.L5:
jmp .L5
--
Summary: infinite loop
Product: gcc
Version: 4.4.3
--- Comment #1 from matz at gcc dot gnu dot org 2010-09-17 16:12 ---
This passes for me, even in -m32 mode (if -msse is added, like vect.exp
does):
% ./cc1 -ftree-vectorize -fno-vect-cost-model -msse2 -O2 \
vect-114.c -ftree-vectorizer-verbose=2 2>&1 | grep note:
vect-114.c:13: note:
On Linux/ia32, revision 164369 gave
FAIL: gcc.dg/vect/vect-114.c scan-tree-dump-times vect "vectorized 0 loops" 1
Revision 164366 is OK. It may be caused by revision 164367:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00661.html
--
Summary: [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #9 from dominiq at lps dot ens dot fr 2010-09-17 15:57 ---
Apparently the problem is that when compiled with -fipa-matrix-reorg -O[123s]
-fwhole-program in 64 bit mode, the executable gives:
...
a.out(83070) malloc: *** error for object 0x1001000c0: pointer being freed was
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-09-17 15:46 ---
Reopen.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-17 15:45 ---
Confirmed. Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedT
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45705
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-17 15:39 ---
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c (revision 164371)
+++ tree-ssa-dom.c (working copy)
@@ -1804,6 +1804,37 @@ eliminate_redundant_co
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-17 15:19 ---
>ce1+combine removed it.
I think it still does on targets that don't have a direct to memory store of 0
like PPC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #7 from dominiq at lps dot ens dot fr 2010-09-17 15:18 ---
> You mean it still fails?
Yes!-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-17 15:18 ---
Eventually predicated value-numbering will fix this as part of the
redundant store removal eliminate() performs.
A similar thing can be added to DOM, which already can do the predication.
I'll give that a quick try.
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-17 15:13 ---
(In reply to comment #5)
> Should we just XFAIL this on darwin then?
You mean it still fails?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
int x;
void
foo (void)
{
if (x == 0)
x = 0;
}
was optimized into empty routine with gcc 3.4 and 4.0, but isn't any longer in
4.1+. In 4.0 apparently the store went away in *.optimized, and with
-fno-tree-ter in ce1+combine removed it. This occurs quite a lot in
http://embed.cs.utah.edu/em
--- Comment #8 from jamborm at gcc dot gnu dot org 2010-09-17 15:08 ---
(In reply to comment #7)
>
> The added MEM = SR.1_10 uses location_t of the stmt after it, as
> sra_modify_expr
> emits statements before gsi. I'm arguing that in this case the MEM[(struct S
> *)&D.2694] = SR.1_10;
A cast to volatile int pointer is ignored on gcc 4.5 with this test case.
struct st {
int ptr;
};
int foo(struct st *st)
{
int v = *(volatile int *)&st->ptr;
return v & 0xff;
}
mipsel-linux-gcc-4.5.1 -O2 foo.c -S output:
lbu $2,0($4)
j $31
--- Comment #18 from jamborm at gcc dot gnu dot org 2010-09-17 14:46
---
Honza submitted a patch
(http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01369.html) so I guess it is his
PR now :-)
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-09-17 14:39 ---
I'll have a look at it but please be patient, my bug queue is rather long at
the moment.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
gcc --help -v no longer runs ld --help because collect2 handles --help itself
without running ld.
--
Summary: [4.6 regression] --help -v no longer shows linker help
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
P
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 14:29 ---
It is caused by revision 159362:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00414.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-09-17
14:21 ---
Should we just XFAIL this on darwin then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
--- Comment #12 from rguenther at suse dot de 2010-09-17 14:14 ---
Subject: Re: [4.6 Regression] New LTO test failures
On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote:
> --- Comment #11 from hjl dot tools at gmail dot com 2010-09-17 14:11
> ---
> (In reply to comme
--- Comment #11 from hjl dot tools at gmail dot com 2010-09-17 14:11
---
(In reply to comment #9)
> Subject: Re: [4.6 Regression] New LTO test failures
>
> On Fri, 17 Sep 2010, jakub at gcc dot gnu dot org wrote:
>
> > --- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17
--- Comment #10 from hjl dot tools at gmail dot com 2010-09-17 14:08
---
(In reply to comment #6)
> With -r -nostdlib when -lm is mentioned on the command line, it is looking for
> libm.a. Guess you have it installed on one box and not on the other one.
> That said, the tests really sh
--- Comment #9 from rguenther at suse dot de 2010-09-17 14:07 ---
Subject: Re: [4.6 Regression] New LTO test failures
On Fri, 17 Sep 2010, jakub at gcc dot gnu dot org wrote:
> --- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04 ---
> Dejagnu adds it always for
--- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04 ---
Dejagnu adds it always for dg-do link/run, and there doesn't seem to be a way
to bypass that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
--- Comment #14 from ktietz at gcc dot gnu dot org 2010-09-17 14:01 ---
Created an attachment (id=21820)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21820&action=view)
testcase for problem
As this test need more then on header, please extract it and compile then
main.c to reprod
--- Comment #7 from rguenther at suse dot de 2010-09-17 13:58 ---
Subject: Re: [4.6 Regression] New LTO test failures
On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote:
> --- Comment #5 from hjl dot tools at gmail dot com 2010-09-17 13:52
> ---
> Works fine in 64bit
--- Comment #6 from jakub at gcc dot gnu dot org 2010-09-17 13:57 ---
With -r -nostdlib when -lm is mentioned on the command line, it is looking for
libm.a. Guess you have it installed on one box and not on the other one.
That said, the tests really shouldn't have -lm on their link line
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-09-17 13:57
---
Subject: Bug 45678
Author: rguenth
Date: Fri Sep 17 13:57:04 2010
New Revision: 164369
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164369
Log:
2010-09-17 Richard Guenther
PR middle-end/45678
--- Comment #5 from hjl dot tools at gmail dot com 2010-09-17 13:52 ---
Works fine in 64bit with -m32
[...@gnu-6 gcc]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r
--- Comment #4 from rguenther at suse dot de 2010-09-17 13:48 ---
Subject: Re: [4.6 Regression] New LTO test failures
On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote:
> --- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 13:36
> ---
> -m32 works on Intel6
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-17 13:45 ---
It might have been exposed by that revision, but that merely points out
a deficiency in RTL if conversion. The final gimple code doesn't have
explicit jumps in the inner loop, but uses cond_expr:
:
# s_22 = PHI <0(2
--- Comment #7 from rguenther at suse dot de 2010-09-17 13:43 ---
Subject: Re: ICE with -fwhopr/-flto when using strlen and
strcat without previous declaration
On Fri, 17 Sep 2010, hubicka at ucw dot cz wrote:
>
>
> --- Comment #6 from hubicka at ucw dot cz 2010-09-17 13:30 --
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 13:36 ---
-m32 works on Intel64 since gcc driver passes
/export/build/gnu/gcc/build-x86_64-linux/gcc/collect-ld --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o pr28712.exe -r
-L/export/build/gnu/gcc/build-x86
1 - 100 of 148 matches
Mail list logo
