--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-12 08:16 ---
> Can someone try instead of doing "__real__ a += w[j] *__real__ mfi[*index];"
> Use "a+= xxx* yyy" and also use -std=c99 to get the correct multiplication?
Well, -std=c99 was used already and the "real(!) * complex"
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-12 08:50 ---
Created an attachment (id=13193)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13193&action=view)
Patch draft (by Paul Thomas)
Notes by Paul:
(i) gfc_find_symbol searches via proc_name->ns to o
--- Comment #8 from pcarlini at suse dot de 2007-03-12 09:07 ---
(In reply to comment #7)
> Also adding new features should not break old features
Here we are not talking about trade-offs, that should be rather clear by now.
We are talking about fixing for real the underlying very serio
--- Comment #15 from pcarlini at suse dot de 2007-03-12 09:26 ---
Actually in the latest mailing there are two new papers, N2151 and N2152.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20599
--- Comment #10 from Andreas dot Kowarz at tu-dresden dot de 2007-03-12
09:30 ---
THS (The Holy Standard :-) ) 3.7.4.2/3 reads to me that for standard library
implementations the delete operators must be called in any case but return
immediately if the first argument is NULL => NULL-che
--- Comment #7 from Woebbeking at web dot de 2007-03-12 09:37 ---
Any news on this? It's really annoying if you've many pimpls which often use
anonymous namespace.
--
Woebbeking at web dot de changed:
What|Removed |Added
---
e-werror
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug i486-linux-gnu --enable-libmudflap
--enable-checking=release
Thread model: posix
gcc version 4.3.0 20070312 (experimental)
--
Summary: ICE: in cse_find_path, at cse.c:5930
--- Comment #6 from manu at gcc dot gnu dot org 2007-03-12 12:10 ---
This seems a duplicate of PR 14710.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28774
The following two testcases should produce the same code after forwprop1:
struct foo { int i[3]; };
void bar (void)
{
struct foo Foo;
int i;
for (i=0; i<3; ++i)
{
void *p = &Foo.i[i];
int *pi = (int *)p;
if (pi != 0)
{
*pi = 0;
}
}
}
---
Hi,
compared to 4.1.2 the size increased by 50% and more. E.g. Qt 4.2.2
libQtGui.so.4.2.2.debug
- 4.2.0 97902763 bytes
- 4.1.2 62435403 bytes
We compile with -O2 -g. Is this a regression or just more (useful?)
information?
--
Summary: increased size of debug information
P
--- Comment #30 from amacleod at redhat dot com 2007-03-12 13:11 ---
Err, yeah. thats right. TER doesn't run without optimization, and I forgot this
was more than just an optimization issue. Where is that work to do basic SSA
optimizations at -O0 when you need it?? :-)
--
http://gc
--- Comment #10 from amacleod at redhat dot com 2007-03-12 13:33 ---
They do all have the (ab) next to them, I was just indicating that they all
occurred in a PHI together, and hence needed to be coalesced. I should have
been more precise.
Well, _t_3 definately does have the (ab) flag,
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-12 14:03 ---
It's more information - whether it's useful depends.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31147
--- Comment #2 from Woebbeking at web dot de 2007-03-12 14:22 ---
Subject: Re: increased size of debug information
On Monday 12 March 2007, rguenth at gcc dot gnu dot org wrote:
> It's more information - whether it's useful depends.
Wow, more than 50%. Are there any docs to this chang
--- Comment #5 from ingo dot donasch at L-3com dot com 2007-03-12 14:32
---
Subject: RE: ptr to member func __delta is 0 if ptr declar
ation does not match function porototype
I know our code is wrong, but my point is that gcc34 generated correct code
and gcc4x is not. A Gcc4x
--- Comment #4 from patchapp at dberlin dot org 2007-03-12 14:50 ---
Subject: Bug number PR30922
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-03/msg00728.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-12 14:51 ---
Figure out which source causes the increase and then attach the preprocessed
source and then we might be able to decide.
It could be that in 4.1.2, that we were not emitting enums and some other types
which should h
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-12 14:56 ---
*** This bug has been marked as a duplicate of 31127 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-12 14:56 ---
*** Bug 31145 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-12 14:59 ---
forwprop should NOT, I repeat should NOT look through casts for conditional if
the SSA_NAME that defines the cast is still used after the conditional.
Really this non zero optimization should be done by VRP.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-12 15:09 ---
I should mention, unless it can produce a constant result.
For an example this function:
void bar (void * a)
{
struct foo Foo;
int i;
for (i=0; i<3; ++i)
{
void *p = a;
int *pi = (int *)p;
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-12 15:24 ---
The testcase in comment 1 should be lifted and deposited in another PR; it is
going to be quite difficult to fix because the type and kind of an interface
function is established before the specification statements tha
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-12 15:25 ---
I just submitted a patch for this PR.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30870
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-12 15:35 ---
The problem is that for example FRE value numbers
void *p_4 = &a[0];
int *q_1 = (int *)p_4;
p_4 with void* type (even if &a[0] is of int* type) and so re-generates the
conversion to int* even though it is about
--- Comment #2 from pault at gcc dot gnu dot org 2007-03-12 15:40 ---
I just submitted a patch for this PR.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
Since ivec is not passed to sub, I think the two calls
to set_optional should be equivalent, but gfortran crashes
upon the second call.
u:\vrao\fortran type xopt_bug.f90
module sub_mod
contains
elemental subroutine set_optional(i,idef,iopt)
! set i to (iopt,idef) if iopt (is,is not) PRESENT
inte
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-12 15:41 ---
I think really this comes down to our type system, I remember posting a patch
for the LTO branch which adds back the explict cast to "void*", I can test
that, it should fix this testcase also :).
--
http://gcc.g
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-12 16:01 ---
Well sure - if we then would get
int *p_1 = &a[0];
void *q_1 = (void *)p_1;
int *r_1 = (int *)q_1;
if (r_1 != NULL)
...
then FRE would figure out that r_1 == p_1 and the forwprop pass after FRE will
fold the
Consider this code:
SUBROUTINE FOO(I)
I=0
END
SUBROUTINE BAR()
CALL FOO(1,2)
END
compiled with g77 3.4.6:
f77.f: In subroutine `bar':
f77.f:1:
SUBROUTINE FOO(I)
1
f77.f:6: (continued):
CALL FOO(1,2)
2
Too m
--- Comment #10 from mmitchel at gcc dot gnu dot org 2007-03-12 16:24
---
Subject: Bug 30108
Author: mmitchel
Date: Mon Mar 12 16:24:18 2007
New Revision: 122844
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122844
Log:
PR c++/30108
* call.c (convert_default_ar
--- Comment #4 from Woebbeking at web dot de 2007-03-12 16:46 ---
Created an attachment (id=13194)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13194&action=view)
preprocessed qcombobox.cpp
I added both versions (4.2.0 and 4.1.2). It's compiled with
-c -fno-exceptions -pipe -O2
Take:
int main()
{
char str[2][34] = {"a","b"};
__builtin_puts(str[0]);
return 0;
}
In 4.0.2, we used to get:
static char C.0[2][34] = {"a", "b"};
char str[2][34];
str = C.0;
__builtin_puts (&str[0][0]);
But in 4.1.1 and above, we get:
char str[2][34];
str = {};
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-12 16:47 ---
It would be helpful if you could reduce the testcase. Thanks.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
Am receiving following error during 'make bootstrap' for GCC v4.1.2 on AIX 5.3:
srcdir="/usr/local/gcc-4.1.2/fixincludes" /bin/sh
/usr/local/gcc-4.1.2/f
ixincludes/mkfixinc.sh powerpc-ibm-aix5.3.0.0
sed -e 's/@gcc_version@//' < > mkheadersT
/bin/sh: 0403-057 Syntax error at line 1
--- Comment #1 from jkurpa at co dot volusia dot fl dot us 2007-03-12
16:51 ---
Created an attachment (id=13195)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13195&action=view)
Screen output from 'make bootstrap'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31151
--- Comment #2 from jkurpa at co dot volusia dot fl dot us 2007-03-12
16:52 ---
Created an attachment (id=13196)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13196&action=view)
Screen output from configure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31151
--- Comment #4 from ian at airs dot com 2007-03-12 17:08 ---
First test case:
int f(int a)
{
if (a < 0)
a = -a;
return a < 0;
}
As far as I can tell the behaviour of this test case in VRP is unchanged by the
patch in this PR. And the code is still fully optimized.
Second test
--- Comment #5 from ian at airs dot com 2007-03-12 17:21 ---
Unfortunately my patch in comment #1 doesn't handle this test case correctly:
extern void abort (void);
void
foo (int a)
{
if (a <= (int) 0x8001)
{
a = - a;
if (a > 0)
abort ();
}
}
It turns
--- Comment #14 from manu at gcc dot gnu dot org 2007-03-12 17:22 ---
Tom,
your patch
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01853.html
will also fix this by adding Wdeprecated to the C front-end.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from rth at gcc dot gnu dot org 2007-03-12 17:15 ---
Subject: Bug 26090
Author: rth
Date: Mon Mar 12 17:15:44 2007
New Revision: 122847
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122847
Log:
PR target/26090
* config/alpha/alpha.c (alpha_elf_sel
--- Comment #19 from manu at gcc dot gnu dot org 2007-03-12 17:31 ---
(In reply to comment #18)
> Created an attachment (id=13025)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13025&action=view) [edit]
> Updated patch, output from "svn diff" as of 2007-02-07
>
Joerg, as Andrew s
The actual gcc version is
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
When compiled and run with this gcc version, using the command line
gcc -O xxx.c && a.out
the attached program outputs -1, whereas the correct output is 0. If
I use gcc 3.3.6 or leave away the -O flag, the prog
--- Comment #5 from manu at gcc dot gnu dot org 2007-03-12 17:39 ---
(In reply to comment #4)
> See also PR 23281
[snip]
> Consequently I'm filing this as a DR against the gcc DR reporting machinery
> itself, rather than against the compiler in particular. There needs to be
> categories
--- Comment #1 from anton at mips dot complang dot tuwien dot ac dot at
2007-03-12 17:43 ---
Subject: Re: New: -(x>y) generates wrong code
I cannot create an attachment in Bugzilla, so I'll just append the
test program here:
#include
#include
long foo(long x, long y);
int main()
--- Comment #6 from janis at gcc dot gnu dot org 2007-03-12 17:45 ---
The link in comment #5 is to David Edelsohn's message that RMS had approved the
license change. Ben Elliston changed the license in the decNumber files for
mainline and the 4.2 branch.
--
janis at gcc dot gnu dot
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-12 17:48 ---
(In reply to comment #1)
>
> It is, however, at least unspecified order of evaluation and a warning
> here would still make sense.
>
A candidate for -Wsequence-points ?
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #11 from mmitchel at gcc dot gnu dot org 2007-03-12 18:07
---
Subject: Bug 30108
Author: mmitchel
Date: Mon Mar 12 18:07:33 2007
New Revision: 122848
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122848
Log:
PR c++/30108
* call.c (convert_default_ar
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-03-12 18:09
---
Fixed in 4.2.0, 4.3.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from craig dot lawson at centrify dot com 2007-03-12 18:26
---
Perhaps there are different degrees of thread safety here.
If I write my multi-threaded program such that only one thread does stream I/O
with libstdc++, I would expect it to operate safely with respect to th
--- Comment #22 from mmitchel at gcc dot gnu dot org 2007-03-12 18:27
---
Danny, please apply the patch to 4.2.0.
Thanks,
-- Mark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-03-12 18:31
---
It appears from the audit trail that there is no GCC bug here, other than,
perhaps, the configuration options not defaulting to ideal choices. If that's
a problem, file a new PR; however, AFAICT, we do not have a
In functions declared to return unsigned int, -Wconversion correctly warns when
a constant signed int is returned. But -Wconversion fails to warn when the
return value is an identifier with type signed int.
Seen in gcc 3.2.3 (Red Hat) and 4.0.1 (Mac OS X)
--
Summary: -Wconversion doe
--- Comment #6 from sayle at gcc dot gnu dot org 2007-03-12 18:41 ---
Subject: Bug 30433
Author: sayle
Date: Mon Mar 12 18:40:56 2007
New Revision: 122852
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122852
Log:
2007-03-12 Roger Sayle <[EMAIL PROTECTED]>
Andrew P
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-12 18:45 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-03-12 18:45
---
Ulrich --
Did your patch fix this PR on mainline? Is a backport to 4.1/4.2 possible?
Thanks,
-- Mark
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pcarlini at suse dot de 2007-03-12 18:51 ---
(In reply to comment #4)
> Perhaps there are different degrees of thread safety here.
>
> If I write my multi-threaded program such that only one thread does stream I/O
> with libstdc++, I would expect it to operate safely
--- Comment #1 from craig dot lawson at centrify dot com 2007-03-12 18:53
---
Test program (Create a New Attachment is not working for me today):
const int i = -1;
unsigned int slip_one_by()
{
return i;
}
unsigned int caught_me()
{
return -1;
}
$ gcc -c unsigned_return.c -W
--- Comment #10 from pault at gcc dot gnu dot org 2007-03-12 19:04 ---
(In reply to comment #9)
>
> As a workaround, one could always use "minloc(...,dim=1)", then
> we get the inline version.
>
Thomas, it's a bit kludgy, but why not add a constant expression = 1, if dim is
not presen
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-12 19:09 ---
This is do to the fact that gfortran does no same-file checking; this checking
is outside the Fortran standard but still useful.
It is planed for this year; cf. PR 26227 and references therein.
*** This bug has been
--- Comment #8 from burnus at gcc dot gnu dot org 2007-03-12 19:09 ---
*** Bug 31149 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #23 from dberlin at gcc dot gnu dot org 2007-03-12 19:09
---
Subject: Bug 28544
Author: dberlin
Date: Mon Mar 12 19:09:05 2007
New Revision: 122857
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122857
Log:
2007-03-12 Daniel Berlin <[EMAIL PROTECTED]>
Fix
--- Comment #24 from dberlin at gcc dot gnu dot org 2007-03-12 19:12
---
Fixed
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
+++ This bug was initially created as a clone of Bug #30922 +++
gfortran currently does not like the following:
module x
implicit none
integer, parameter :: d=8
interface
real(d) function y()
import
end function
end interface
end module x
--- Comment #6 from craig dot lawson at centrify dot com 2007-03-12 19:23
---
> Anyway, what happens in the GNU systems is that errno is a per-thread variable
> and the __convert_to_v code has to do nothing special, just safely use it.
I agree. The problem is that this is not happening
--- Comment #6 from uweigand at gcc dot gnu dot org 2007-03-12 19:34
---
I haven't verified that this problem is fixed -- the patch was originally
intended to fix another bug uncovered by Peter Bergner, and I just added
this PR number to the check-in due to Andrew's comment #3 on this b
--- Comment #2 from janis at gcc dot gnu dot org 2007-03-12 19:45 ---
A regression hunt on powerpc-linux using the submitter's test case identified
this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=96084
r96084 | law | 2005-03-08 03:39:19 + (Tue, 08 Mar 2005)
--
janis
#define protected public
#include
#include
typedef std::vector int_collection;
typedef std::priority_queue > int_queue;
void
print(int_queue & q)
{
for (int_collection::iterator iter(q.c.begin()); iter != q.c.end(); ++iter)
std::cout << *iter << " ";
std::cout << std::endl;
}
i
--- Comment #1 from rmecklenburg at s5w dot com 2007-03-12 19:51 ---
Created an attachment (id=13197)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13197&action=view)
gcc -v -E version of the test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31155
--- Comment #7 from pcarlini at suse dot de 2007-03-12 19:51 ---
(In reply to comment #6)
> > Anyway, what happens in the GNU systems is that errno is a per-thread
> > variable
> > and the __convert_to_v code has to do nothing special, just safely use it.
>
> I agree. The problem is th
--- Comment #20 from j at uriah dot heep dot sax dot de 2007-03-12 19:55
---
(In reply to comment #19)
> Joerg, as Andrew said, you need a copyright assignment and you need to submit
> the patch to [EMAIL PROTECTED]
Patch submitted to list by 2007-02-09, message-id is
<[EMAIL PROTECTE
--- Comment #1 from brooks at gcc dot gnu dot org 2007-03-12 20:03 ---
Subject: Bug 30635
Author: brooks
Date: Mon Mar 12 20:03:33 2007
New Revision: 122861
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122861
Log:
PR 30635
* doc/install.texi: Document --enable-stage1-languages
--- Comment #2 from pcarlini at suse dot de 2007-03-12 20:05 ---
This is how priority_queue works: it makes an "heap" (in the exact computer
science meaning), therefore, in particular, there is no guarantee that the
contents are all fully sorted, only that the smallest is the first one (
--- Comment #3 from law at redhat dot com 2007-03-12 20:06 ---
Subject: Re: [4.1/4.2/4.3 Regression] ICE with
computed goto and constants
On Mon, 2007-03-12 at 19:45 +, janis at gcc dot gnu dot org wrote:
>
> --- Comment #2 from janis at gcc dot gnu dot org 2007-03-12
--- Comment #8 from craig dot lawson at centrify dot com 2007-03-12 20:07
---
Not on Linux: correct.
I could give it a try, but I haven't built this library before. If you could
point me to a brief how-to, I could give it a try on a Solaris 10 SPARC.
Rather than code around it, I woul
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-12 20:09 ---
Fixed, as per the previous comment.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pcarlini at suse dot de 2007-03-12 20:14 ---
(In reply to comment #8)
> Not on Linux: correct.
Ok.
> I could give it a try, but I haven't built this library before. If you could
> point me to a brief how-to, I could give it a try on a Solaris 10 SPARC.
>
> Rather t
--- Comment #21 from manu at gcc dot gnu dot org 2007-03-12 20:15 ---
(In reply to comment #20)
> Patch submitted to list by 2007-02-09, message-id is
> <[EMAIL PROTECTED]>
>
> I've got a copyright assignment on file since 2003-03-19 (date of
> confirmation email from Jessica Natale).
>
--- Comment #3 from dje at gcc dot gnu dot org 2007-03-12 20:19 ---
The problem appears to be occurring in real.c conversions from CONST_DOUBLE to
TARGET_DOUBLE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-12 20:19 ---
> Andrew, have you verified that the problem is fixed now?
Yes the patch fixed the problem for me.
>Was this impression mistaken?
Yes but in my own testing of a private tree of GCC 4.1.1 modifed for the PS3
game OS
--- Comment #22 from patchapp at dberlin dot org 2007-03-12 20:40 ---
Subject: Bug number preprocessor/23479
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-02/msg00810.html
--
http://gcc.gnu.org
--- Comment #17 from b33fc0d3 at gmail dot com 2007-03-12 20:48 ---
I can confirm this patch works on an amd64 gentoo sytem too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
--- Comment #18 from pcarlini at suse dot de 2007-03-12 21:08 ---
(In reply to comment #17)
> I can confirm this patch works on an amd64 gentoo sytem too.
And what happens if you just change that #include_next to #include ,
that would be useful in understanding the issue and how much of
The following code fails to compile:
begin
#include
class Foo
{
Foo(const Foo&); // private
public:
Foo(int x) { }
};
std::ostream &operator <<(std::ostream &out, const Foo &)
{
return out;
}
int main()
{
std::cout << Foo(5);
}
// test.cpp:5: error: 'Foo::
--- Comment #7 from simon_baldwin at yahoo dot com 2007-03-12 21:48 ---
PR 14710 isn't really quite the same thing as PR 28774. PR 14170 is concerned
with unnecessary casts; PR 28774 is concerned with unnecessary "const" or
"volatile" qualifiers within otherwise valid and perhaps necess
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-03-12 21:56 ---
Subject: Bug 30835
Author: rakdver
Date: Mon Mar 12 21:56:12 2007
New Revision: 122866
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122866
Log:
PR tree-optimization/30835
* lambda-code.c (c
--- Comment #1 from fang at csl dot cornell dot edu 2007-03-12 21:56
---
See PR 25950 and PR 12226 (dup).
The resolution is that you need an accessible copy-constructor, regardless of
whether or not the compiler elides it during temporary creation.
--
fang at csl dot cornell dot e
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-12 21:59 ---
*** This bug has been marked as a duplicate of 25950 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #26 from pinskia at gcc dot gnu dot org 2007-03-12 21:59
---
*** Bug 31156 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25950
--- Comment #4 from dje at gcc dot gnu dot org 2007-03-12 22:20 ---
I do not believe this is an endian issue. It is a coincidence that the output
value looks like the original constant. GCC converts the __builtin_memcpy()
into a VIEW_CONVERT_EXPR. The constant is equivalent to a NaN a
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-12 22:25 ---
Wconversion is implemented in the front-end and there is no data-flow solving
on front-ends, so basically it is impossible to know the value of i.
In addition, up to GCC 4.3, Wconversion was not meant to warn about
sig
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-12 22:25 ---
Index: ../../gcc/fold-const.c
===
--- ../../gcc/fold-const.c (revision 122864)
+++ ../../gcc/fold-const.c (working copy)
@@ -7357,6 +7357,7 @@
--- Comment #19 from martin dot jansa at mk dot cvut dot cz 2007-03-12
22:30 ---
(In reply to comment #18)
> (In reply to comment #17)
> > I can confirm this patch works on an amd64 gentoo sytem too.
>
> And what happens if you just change that #include_next to #include ,
> that would
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-12 22:38 ---
>From native_encode_int, we get:
(gdb) p/x *(unsigned int[2]*)ptr
$14 = {0x0f00, 0x}
Which is obviously wrong, it should have encoded it as:
{0x000f, 0x}
So we get the wrong answer to begin
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-12 22:44 ---
(In reply to comment #6)
> From native_encode_int, we get:
> (gdb) p/x *(unsigned int[2]*)ptr
> $14 = {0x0f00, 0x}
No that is right, I was looking at while doing a cross so (unsigned int[2]*)
meant we ha
Following testcase compiles fine with gcc 3.4.6 but not with gcc 4.2.0 20070307
:
- cut here -
#include
using namespace std;
class Foo
{
public:
Foo() { x=1; y=0; };
unsigned int x:12;
unsigned int y;
};
int main()
{
Foo bar;
max(bar.y,bar.x);
return
--- Comment #1 from ismail at pardus dot org dot tr 2007-03-12 23:03
---
Original code was from WebKit SVN.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31157
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-12 23:08 ---
the issue is with native_interpret_real really, tmp is getting the wrong words
order.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
--- Comment #20 from pcarlini at suse dot de 2007-03-12 23:09 ---
(In reply to comment #19)
...
> this isn't enough even with building with this brand new
> gcc-4.3.0_alpha20070309.
> I'll repeat it with include of proper stdio.h, which looks in gentoo multilib
> like this
>
> jama gcc
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-12 23:18 ---
Here is my new patch:
Index: ../../gcc/fold-const.c
===
--- ../../gcc/fold-const.c (revision 122864)
+++ ../../gcc/fold-const.c (working copy)
1 - 100 of 115 matches
Mail list logo
