--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
07:51 ---
Yes and this is a dup of bug 16068 which shows that ICC has the same problem
and you filed the same
bug before.
*** This bug has been marked as a duplicate of 16068 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
07:51 ---
*** Bug 20311 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16068
--- Additional Comments From igodard at pacbell dot net 2005-03-04 07:47
---
"To tell you the truth, a template is not a type."
Exactly, yet the diagnostic says it is an (unknown) type, which is false.
Yes, I know this code is an error; that's not the reported bug. The report is
about
--- Additional Comments From konqueror at gmx dot de 2005-03-04 07:45
---
Subject: Re: [4.0 regression] libgcj configured with --enable-gtk-cairo fails
on installation
On Thu, Mar 03, 2005 at 10:38:55PM -, doko at debian dot org wrote:
>
> --- Additional Comments From doko at
--- Additional Comments From giovannibajo at libero dot it 2005-03-04
07:35 ---
To tell you the truth, a template is not a type. A template specialization (as
in: foo) is a type, but not a template. So, this is correct. The error
happens because "foo" does not name a type and thus P ca
--- Additional Comments From mark at codesourcery dot com 2005-03-04 07:26
---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
Alexandre Oliva wrote:
>
>>>+ // Hmm... I don't think these should be accepted. The conditional
>>>+ // expressions are lvalu
In :
template
void foo(T) {};
template
void bar(T, P) {}
int main() {
bar(0, foo);
}
you get:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `int main()':
foo.cc:7: error: no matching function for call to `bar(int, )'
The second argument is not ""; the compiler knows it's a template
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04
06:59 ---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
On Mar 4, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> we should be doing the same for all types (well except for
>> bitf
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04
06:34 ---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
On Mar 3, 2005, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On Mar 3, 2005, at 2:50 AM, Alexandre Oliva wrote:
>> I'm bootstrapp
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
06:30 ---
(In reply to comment #7)
> Yeah, it permits, but only in certain circumstances that AFAICT aren't
> met. This expression AFAICT is an lvalue that isn't a bit-field, so
> it has to bind directly, per the fir
--
Bug 20130 depends on bug 15784, which changed state.
Bug 15784 Summary: fold misses binary optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15784
What|Old Value |New Value
--
Bug 19986 depends on bug 15784, which changed state.
Bug 15784 Summary: fold misses binary optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15784
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
06:26 ---
Reopening as this patch had to reverted as it caused a bootstrap failure on
ppc-darwin. I think there
really is a latent bug with -1 - A being converted to ~A and then ~A is
constant folded to -1 but it
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-04
06:24 ---
Subject: Bug 15784
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-04 06:24:12
Modified files:
gcc: ChangeLog fold-const.c
Log message:
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04
06:01 ---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
On Mar 3, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
> \
>> I went ahead and verified that I didn't
--- Additional Comments From smcpeak at cs dot berkeley dot edu 2005-03-04
05:00 ---
I think I have answered my own question: indeed, qualified lookup
only considers name from the definition context, and not the
instantiation context.
I found this thread at google groups:
http://grou
--- Additional Comments From stevenj at fftw dot org 2005-03-04 04:46
---
Subject: Re: COMPLEX function returns incompatible with
g77
> Just to be clear, what exactly do you feel are the concrete practical
> advantages to -ff2c?
(Sorry, I mean -fno-f2c. The practical advantages to b
--- Additional Comments From stevenj at fftw dot org 2005-03-04 04:44
---
Subject: Re: COMPLEX function returns incompatible with
g77
On Thu, 3 Mar 2005, tobi at gcc dot gnu dot org wrote:
> I agree with you that -ff2c should imply -fsecond-underscore. I don't
> agree that the advan
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
04:37 ---
Confirmed, also fails on 3.3.
Here is the ICE:
+===GNAT BUG
DETECTED==+
| 4.0.0 20050225 (experimental) (powerpc-apple-darwin7.7.0) Assert_Failure
namet.
--- Additional Comments From kho at redhat dot com 2005-03-04 04:35 ---
Still working on it but it's taking some time. If anyone wants to work on it,
I'll be happy to reassign it to them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17275
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
04:14 ---
What version of gcc are you using? Also you did not provide the preprocessed
source as requested only
the source code so closing as invalid as there has been no feedback in the
correct way for 3 months.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
04:04 ---
Invalid as you are violating aliasing rules.
--
What|Removed |Added
Status|UNCON
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2004-12-03 1
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2004-07-15 0
--- Additional Comments From smcpeak at cs dot berkeley dot edu 2005-03-04
03:59 ---
Andrew, I think you are misinterpreting [temp.dep.candidate]
(14.6.4.2). That section modifies the lookup rules for
unqualified-ids that are dependent, but does *not* say that only
unqualified-ids can b
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2004-12-03 0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
03:55 ---
Confirmed.
We spend 46.3% of the time in output_float.
8.0% in finalize_transfer.
4.8% in _gfortrani_free_fnodes
4.8% in write_float
Comparing to g77, where we spend:
48.5% in wrt_E
7.4% in wrt_F
7.4% in x_
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-03-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
03:41 ---
Here is a testcase which we semi optimize on the RTL level but not at the tree
level:
sum cannot alias a or b at all because of the default option for gfortran.
subroutine dot_product (sum, a, b, n)
rea
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
03:28 ---
Fixed at least on the mainline.
--
What|Removed |Added
Known to work|3.3.3 3.2.3
--
What|Removed |Added
Target Milestone|--- |4.1.0
Version|4.1.0 |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15784
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
03:18 ---
*** Bug 20310 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
03:18 ---
*** This bug has been marked as a duplicate of 12786 ***
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-04
03:08 ---
Subject: Bug 20253
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-04 03:08:11
Modified files:
gcc: ChangeLog c-opts.c dwarf2out.c
Added
--
Bug 19986 depends on bug 15784, which changed state.
Bug 15784 Summary: fold misses binary optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15784
What|Old Value |New Value
--
Bug 20130 depends on bug 15784, which changed state.
Bug 15784 Summary: fold misses binary optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15784
What|Old Value |New Value
--- Additional Comments From phython at gcc dot gnu dot org 2005-03-04
02:55 ---
The binary conditions below are all folded now.
--
What|Removed |Added
Status|AS
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-04
02:49 ---
Subject: Bug 15784
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-04 02:48:32
Modified files:
gcc: ChangeLog fold-const.c
gcc/t
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-04
02:16 ---
The revised version is OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19311
--- Additional Comments From mark at codesourcery dot com 2005-03-04 01:36
---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
Alexandre Oliva wrote:
\
> I went ahead and verified that I didn't break bit-field lvalues in
> conditional expressions (my first a
The "single" value profiler (gen_one_value_profiler)
can emit values that gcov-io doesn't like to see, namely
negative values, per this check in gcov_read_counter:
if (value < 0)
gcov_var.error = -1;
Testcase:
[brat1]$ cat a.i
# 1 "a.c"
# 1 ""
# 1 ""
# 1 "a.c"
int j = 1<<31;
main ()
{
--- Additional Comments From jifl-bugzilla at jifvik dot org 2005-03-04
00:48 ---
Created an attachment (id=8324)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8324&action=view)
Suggested patch to correctly treat -0.0 and subnormals
No problem, here it is.
--
http://gcc.gnu.or
--- Additional Comments From ericw at evcohs dot com 2005-03-04 00:38
---
Could you attach your proposed patch insted of putting it inline in the comment?
Thanks
Eric
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20227
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-04 00:29
---
I'm not sure if it is actually a bug in the compiler that compiles macro.c
or in libcpp.c.
The code in question is:
cpp_token *token = _cpp_temp_token (pfile);
token->type = (*paste_flag)->type;
token
--- Additional Comments From doko at debian dot org 2005-03-04 00:21
---
install is called as:
PATH=/build/buildd/gcc-snapshot-20050227/bin:$PATH \
/usr/bin/make -C /build/buildd/gcc-snapshot-20050227/build \
CFLAGS="-g -O2" \
LDFLAGS="" \
BOOT_CFLAGS="-O2" \
DESTDIR=/
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-04 00:01
---
Assembly diff between bad and good:
diff -pU6 macro1.s.{broken,good}
--- macro1.s.broken 2005-03-03 19:00:26.0 -0500
+++ macro1.s.good 2005-03-03 19:00:15.0 -0500
@@ -159,14 +159,13 @
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-03 23:57
---
Created an attachment (id=8323)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8323&action=view)
The 2 routines
Yes, it does. Attaching the 2 routines which are miscompiled on s390x
at -O2.
--
http:
The -force option forces gcjh to overwrite generated files where necessary, even
if there is no difference between the old and new file.
--
Summary: gcjh needs a -force option
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
--- Additional Comments From olh at suse dot de 2005-03-03 23:52 ---
can these errors still be reproduced with current gcc 4.0 branch?
the applied patch causes regressions:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305
--
http:/
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
23:32 ---
Adding Jakub to the CC so he does not miss the updates from this bug since this
and PR 20305 look to
be the one and same bug really. Also note olh, has identified the patch which
caused it for PPC64,
Ja
--- Additional Comments From olh at suse dot de 2005-03-03 23:31 ---
the change above allowed a bootstrap of gcc-4.0.0-20050228 with itself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
23:30 ---
Adding olh, so he does not miss the updates from this side since both bugs
really the same bug.
--
What|Removed |Added
--
--- Additional Comments From fitzsim at redhat dot com 2005-03-03 23:26
---
What do you mean "installing into a temporary location"? What does the "make
install" line look like?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20251
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
23:25 ---
Hmm, this is the reduced testcase (but I don't know if this is invalid as
Comeau also rejects it but I think
it is valid):
template int nick(int e);
template struct operation{int nick;};
template
bool alph
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-03
23:24 ---
Subject: Re: pointer function with RESULT specified returns pointer to "ptr"
rather than "*ptr"
Is this connected with functions that return character pointers being so
completely screwed up?
- Origi
--- Additional Comments From olh at suse dot de 2005-03-03 23:17 ---
After this patch, gcc could not boostrap itself anymore:
TZ=UTC cvs diff -pu -D '20041031 09:00' -D '20041031 10:00' gcc/
I'm testing this patch currently on mainline:
Index: gcc/ChangeLog.12
=
--
What|Removed |Added
CC||bernie at develer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
22:54 ---
Nope, qualified names bind right away, see PR 11828.
And from the standard:
>From [temp.dep.candidate]:
For a function call that depends on a template parameter, if the function name
is an "unqualified-id"
--- Additional Comments From giovannibajo at libero dot it 2005-03-03
23:00 ---
(In reply to comment #4)
I strongly agree with everything in JSM's post. There is simply no reason for
keeping such a stupid limit, and even less for manually optimizing conditions
to enhance the limit. Us
--- Additional Comments From joseph at codesourcery dot com 2005-03-03
22:58 ---
Subject: Re: Can't push more than 16 nested visibility
On Thu, 3 Mar 2005, pinskia at gcc dot gnu dot org wrote:
> This is a documented behavior.
Arbitrary limits are still generally undesirable, even wh
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
22:55 ---
*** Bug 20307 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:54
---
In this particular case (sym vs sym->result) the right thing IMO would be to
either *always* create a sym->result variable, which takes on all the functions
attributes, or to *always* copy the attributes of the
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20292
--- Additional Comments From j dot gnu at uriah dot heep dot sax dot de
2005-03-03 22:49 ---
(In reply to comment #9)
> There has been the suggestion to 1.) distinguish between pointer variables
> that
> are marked "volatile" and pointer variables that are not declared "volatile"
> a
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-03
22:43 ---
Subject: Re: pointer function with RESULT specified returns pointer to "ptr"
rather than "*ptr"
I have become convinced that graphical/diagrammatic rendering of some of the
structures that we are using wo
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-03 22:39
---
The replace_args miscompilation seems to matter e.g. on:
typedef int Elf64_Dyn;
#define ElfW(type) _ElfW (Elf, 64, type)
#define _ElfW(e,w,t) _ElfW_1 (e, w, _##t)
#define _ElfW_1(e,w,t) e##w##t
ElfW(Dyn) x;
wh
--- Additional Comments From doko at debian dot org 2005-03-03 22:38
---
The complete build logs can be found at
http://buildd.debian.org/build.php?&pkg=gcc-snapshot
check for the 2005027 logs for i.e. powerpc and ia64.
the build starts with a clean environment. I rechecked with an un
--- Additional Comments From fitzsim at redhat dot com 2005-03-03 22:28
---
Also, was this a clean rebuild? In other words, did you start with an empty
build directory and empty prefix before configuring and building? If not, I
suggest you try that.
--
http://gcc.gnu.org/bugzilla/
--- Additional Comments From fitzsim at redhat dot com 2005-03-03 22:22
---
What platform are you on? Can you paste the exact configure and make lines that
cause the build failure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20251
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-03-03 22:21 ---
Hi,
in order to completely resolve this issue, IIUC, one would have to sacrifice
the post-increment addressing modes. In case of the X-Register, forcing the
high-byte first rule allways would resu
--- Additional Comments From fitzsim at redhat dot com 2005-03-03 22:18
---
Fixed on mainline and gcc-4_0-branch. Closing.
--
What|Removed |Added
Status|NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-03
22:17 ---
Subject: Bug 20292
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-03 22:17:26
Modified files:
libjava: ChangeLog
libjava/testsuite/
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:17
---
Hm, there seems to be some confusion between when to use sym and when
sym->result for a function. My fix won't make it worse, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:08
---
Found the bug. Fixing.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:06
---
I agree with you that -ff2c should imply -fsecond-underscore. I don't agree
that the advantages of -ff2c outweigh the disadvantages of -fno-f2c so far that
-fno-f2c should be the default. If we don't switch t
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
22:02 ---
> There are other places where TREE_SIDE_EFFECTS matters. (Like, "do we
> have to emit this expression at all, if its result is not used?")
OK.
> The counter to your argument is that I don't see why th
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 21:59
---
This is weird. I just came across code (written by me) that should ensure the
right behavior here.
--
What|Removed |Added
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-03
21:59 ---
Subject: Bug 20292
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-03 21:59:23
Modified files:
libjava: Change
--- Additional Comments From stevenj at fftw dot org 2005-03-03 21:49
---
Subject: Re: COMPLEX function returns incompatible with
g77
On Thu, 3 Mar 2005, tobi at gcc dot gnu dot org wrote:
> BTW I will also propose a patch to make -fno-second-underscore the
> default, once this is fi
--- Additional Comments From igodard at pacbell dot net 2005-03-03 21:48
---
Created an attachment (id=8322)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8322&action=view)
Source code (-save-temps) (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
--- Additional Comments From igodard at pacbell dot net 2005-03-03 21:47
---
Created an attachment (id=8321)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8321&action=view)
Compiler output (-v -save-temps)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
In the attached code, the parser gets confused by a use of operator< in the
body
of a function template. If the operator is changed (to ">" or "==" for example)
the code compiles. I've not been able to figure out why it thinks it's in a
constant expression. Changing the variable names involved
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 21:36
---
BTW I will also propose a patch to make -fno-second-underscore the default, once
this is fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
--- Additional Comments From mark at codesourcery dot com 2005-03-03 21:19
---
Subject: Re: [3.4 Regression] const/pure functions result
in bad asm
ebotcazou at gcc dot gnu dot org wrote:
> --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
> 21:12 ---
--- Additional Comments From daney at gcc dot gnu dot org 2005-03-03 21:19
---
Thanks Richard,
The patch applies cleanly against 3.4.3 (with an offset of something like 9
lines). I found no regressions with a top level make -k check for an i686-linux
-> mipsel-linux cross compiler with
In the program:
--
extern "C" int puts(const char*);
template
void foo(A a, B b)
{
puts("ERROR: foo");
}
template
void bar(X a)
{
#ifdef ERROR
::foo(a, a);
#else
foo(a, a);
#endif
}
template
void foo(A a, A b)
{
puts("OK: foo");
}
int main()
{
int a = 0;
bar(
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
21:12 ---
> I don't think I'd try to be that clever. We might want the
> stabilization to occur even in other cases. In looking at it more
> closely, it definitely looks like stabilize_reference should deal with
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 20:51
---
Working on this.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-03
20:27 ---
Same thing on i686:
$ gfortran write-many.f
$ time ./a.out
real0m5.576s
user0m5.508s
sys 0m0.038s
$ g77 write-many.f
$ time ./a.out
real0m3.252s
user0m3.185s
sys 0m0.041s
--
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-03 20:10
---
There are two routines likely miscompiled in libcpp/macro.c:
replace_args and cpp_get_token (I removed all static keywords from the file,
then did a binary search on which routines cause this).
If all of macro
--- Additional Comments From schlie at comcast dot net 2005-03-03 19:47
---
(In reply to comment #6)
Nope, these are peripheral i/o registers, and like any pheripheral interface
may have
access sequence requirements which need to be satsifyed within it's driver.
These
perpheral registe
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:52 ---
Just a note from 20282, since I think this is the same bug:
the breakage appeared between 20041027 and 20041101.
--
What|Removed |Added
--
--
What|Removed |Added
Keywords||build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
--- Additional Comments From ericw at evcohs dot com 2005-03-03 19:49
---
Subject: Re: AVR assignment of a value through a 16 bit
pointer generates out of order code
schlie at comcast dot net wrote:
>--- Additional Comments From schlie at comcast dot net 2005-03-03 19:47
>-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:48 ---
Confirmed, C testcase which shows that this is defintely a regression:
void f(double _Complex *f,int len)
{
int i = 0;
for(i = 0 ;i<20;i++)
{
*f = 0.0;
f++;
}
}
--
What|Remo
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Target Milestone|---
--- Additional Comments From mark at codesourcery dot com 2005-03-03 19:34
---
Subject: Re: [3.4 Regression] const/pure functions result
in bad asm
ebotcazou at gcc dot gnu dot org wrote:
> --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
> 19:25 ---
--- Additional Comments From steve at netfuel dot com 2005-03-03 19:31
---
I have looked for this bug and did not see one.
15501 is similar but is not the same problem or is a subset of the problems
defined in my report. As my bug also affects any Extends with Exceptions
defined in the
--- Additional Comments From dje at gcc dot gnu dot org 2005-03-03 19:26
---
Example Fortran code derived from BLAS ZGEMM routine.
SUBROUTINE Z ( M, N, C, LDC )
* .. Scalar Arguments ..
INTEGERM, N, LDC
* .. Array Arguments ..
COMPLEX*16 C(
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
19:25 ---
> It really seems like the C++ front end is doing the right thing,
> abstractly -- these functions don't have side-effects! So, either the
> inliner or stabilize reference seems like it needs fixing. M
1 - 100 of 148 matches
Mail list logo
