--- Comment #6 from aoliva at gcc dot gnu dot org 2007-03-13 07:56 ---
On it.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #16 from patchapp at dberlin dot org 2007-03-13 07:30 ---
Subject: Bug number PR30643
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/msg00815.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #29 from manu at gcc dot gnu dot org 2007-03-13 00:49 ---
Created an attachment (id=13198)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13198&action=view)
janis patch (try 2)
This is an updated version of Janis patch that fixes the issues described in
comment #21.
-
--- Comment #28 from manu at gcc dot gnu dot org 2007-03-13 00:44 ---
(In reply to comment #27)
> I still plan to find some time to dive into this issue, sorry it's taken so
> long.
>
My current show-stopper is the one described in comment #23. I think we should
be able to match that o
--- Comment #27 from janis at gcc dot gnu dot org 2007-03-13 00:34 ---
Manuel, please submit a patch to fix those tests. If they are using the
correct directives then perhaps someone will notice.
I still plan to find some time to dive into this issue, sorry it's taken so
long.
--
--- Comment #26 from manu at gcc dot gnu dot org 2007-03-13 00:29 ---
There are some tests that are using the wrong directive (or the test is
silently failing). Should I submit these as patches to gcc-patches?
Index: gcc/testsuite/gcc.dg/20050121-1.c
This test passed with 122852, started failing with 122864:
Running
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/execute.exp ...
FAIL: gcc.c-torture/execute/20030323-1.c compilation, -O2 (internal compiler
error)
FAIL: gcc.c-torture/execute/20030323-1.c compilation, -O3 -fomit-fra
The line number in the warning below points to the closing brace of the
initializer expression making it difficult to find the offending line if the
initializer is many lines long. I would like to suggest that the line number be
that of the problem line (and perhaps include the column number as wel
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-13 00:10
---
Mine, my patch is correct, just need to test it now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from law at redhat dot com 2007-03-13 00:06 ---
Subject: Re: [4.1/4.2/4.3 Regression] ICE with
computed goto and constants
On Mon, 2007-03-12 at 23:46 +, spark at gcc dot gnu dot org wrote:
>
> --- Comment #4 from spark at gcc dot gnu dot org 2007-03-12
--- Comment #4 from spark at gcc dot gnu dot org 2007-03-12 23:46 ---
This little patch below seems to get around the problem,
though I'm not really sure this is sufficient or not.
Index: tree-cfg.c
===
--- tree-cfg.c (rev
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-03-12 23:33
---
This is a bug in the gentoo distro ask them to fix how they do multilib.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #21 from pcarlini at suse dot de 2007-03-12 23:32 ---
(In reply to comment #15)
> ./build/gcc/include-fixed/stdio.h
...
> ./build/stage1-gcc/include-fixed/stdio.h
> ./build/prev-gcc/include-fixed/stdio.h
Interestingly, these stdio.h do not exist on my x86_64 builds...
--
--- Comment #76 from steven at gcc dot gnu dot org 2007-03-12 23:24 ---
Joost,
You wrote in comment #75:
"One issue with OpenMP is that it is very easy to break an OpenMP
code (it is just comments),"
This is a complaint I've heard before. I wonder if you have any suggestions to
make i
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-12 23:21
---
I proved to my self at least with a cross from x86 to ppc64, I get the correct
output:
change t:
long long t = 0x1234567890123456ULL;
and we get:
.tc FD_12345678_90123456[TC],0x1234567890123456
--
h
--- 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)
--- 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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
#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 #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
--- 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 #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
+++ 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 #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
--- 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 #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 #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 #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 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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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
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 #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
-
--
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
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 = {};
--- 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
--- 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
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 #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
--- 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
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 #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
-
--- 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 #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 #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 #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 #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 #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:56 ---
*** This bug has been marked as a duplicate of 31127 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- 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 #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
1 - 100 of 115 matches
Mail list logo
