--- Comment #10 from olh at suse dot de 2005-12-06 08:38 ---
Odd, -O1 doesnt fix it for me:
+CFLAGS_hash_utils_64.o += -O1
gcc version 4.2.0 20051206 (experimental)
GNU ld version 2.16.91 20051206
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
--- Comment #11 from olh at suse dot de 2005-12-06 08:44 ---
same is true for a r99558 compiled object file, in a gcc40 kernel.
-O1 doesnt help there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2005-12-06 09:21
---
Dorit, this is a bad interaction between versioning and reduction.
The compiler segfaults in tree-ssa-dce.c because a PHI node declared as
having 2 operands has only 1. It is created by the vectorizer, namely
ve
--- Comment #16 from amodra at gcc dot gnu dot org 2005-12-06 09:55 ---
Subject: Bug 13873
Author: amodra
Date: Tue Dec 6 09:55:04 2005
New Revision: 108110
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108110
Log:
PR other/13873
* longlong.h: Merge PPC tests f
--- Comment #17 from amodra at gcc dot gnu dot org 2005-12-06 10:03 ---
Subject: Bug 13873
Author: amodra
Date: Tue Dec 6 10:02:57 2005
New Revision: 108111
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108111
Log:
PR other/13873
* longlong.h: Merge PPC tests f
--- Comment #18 from amodra at gcc dot gnu dot org 2005-12-06 10:04 ---
Subject: Bug 13873
Author: amodra
Date: Tue Dec 6 10:04:04 2005
New Revision: 108112
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108112
Log:
PR other/13873
* longlong.h: Merge PPC tests f
--- Comment #19 from amodra at gcc dot gnu dot org 2005-12-06 10:05 ---
Subject: Bug 13873
Author: amodra
Date: Tue Dec 6 10:05:47 2005
New Revision: 108113
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108113
Log:
PR other/13873
* longlong.h: Merge PPC tests f
--- Comment #20 from amodra at bigpond dot net dot au 2005-12-06 10:06
---
Fixed.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
Status|ASS
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
Target Milestone|--- |3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13873
--- Comment #10 from reichelt at gcc dot gnu dot org 2005-12-06 11:01
---
Subject: Bug 21383
Author: reichelt
Date: Tue Dec 6 11:00:46 2005
New Revision: 108114
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108114
Log:
Backport:
2005-10-18 Nathan Sidwell <[E
--- Comment #11 from reichelt at gcc dot gnu dot org 2005-12-06 11:02
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from reichelt at gcc dot gnu dot org 2005-12-06 11:06
---
Taking care of the backport.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from samuel dot thibault at ens-lyon dot org 2005-12-06
11:15 ---
Created an attachment (id=10416)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10416&action=view)
Testcase with linker script
This testcase uses a linker script. The proposed patch
http://gcc.gnu.or
--- Comment #2 from bonzini at gnu dot org 2005-12-06 12:28 ---
Created an attachment (id=10417)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10417&action=view)
proposed patch
I bootstrapped this on i686-pc-linux-gnu, all languages. Eric, can you test it
on a non-C99 platform?
the bug is in sizeof(element) - i've made unlucky structure, some
time ago, where sum of sizeof(each_element) gives size of 14 and
sizeof(whole_struct) returns 16. on old gcc-2.9.x there was the same
problem.
as an example program i've wrote shor one, that shows sizeof() from
struct having 14 char'
--- Comment #9 from gcc-bugzilla at kayari dot org 2005-12-06 13:07 ---
I've often found this warning to be a nuisance, because it's correct and
well-defined to omit some braces from the initializer.
There are many cases where the warning is useful, e.g. with aggregates that
have severa
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-12-06 13:08 ---
The C standard allows for arbitrary padding in between elements, so this
behavior is expected. Use __attribute__((packed)) on the type to get a struct
without padding if you need that for whatever reason (it will be
I'm describing a error which occures when running GCC
4.0.2 compiled with internal coverage checks (when
gcc_assert() produces code).
There is a place in 'ggc-common.c' at line 870:
> gcc_assert (!*slot);
This assertion ALWAYS fail when using the PCH. I think
it must be removed.
Edward Chernen
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-06
13:27 ---
Subject: Re: [4.0 regression/hpux] gcc generates incorrect stabs debug output
> By using subspa, the L$etext label is placed back at the beginning of the
> original code section, so it does not properl
--- Comment #12 from rguenth at gcc dot gnu dot org 2005-12-06 13:37
---
Note that in the reduced testcase we have
pr25248.c: In function ?htab_bolt_mapping?:
pr25248.c:15: warning: integer constant is too large for ?unsigned long? type
pr25248.c: In function ?main?:
pr25248.c:24: warn
--- Comment #13 from rguenth at gcc dot gnu dot org 2005-12-06 13:39
---
hmhm, maybe I'm in a ppc32 chroot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
--- Comment #14 from bergner at vnet dot ibm dot com 2005-12-06 13:40
---
sizeof(unsigned long) and sizeof(unsigned long long) are both 8 bytes on ppc64.
Olaf, -O1 isn't a workaround, it's the minimum optimization level that still
shows the bug. Trying some -fno-* options, using -fno-
--- Comment #15 from rguenth at gcc dot gnu dot org 2005-12-06 13:43
---
So, CCing zdenek. Btw., checking -floop-optimize2 may also be worth trying
(setting up a rpoper chroot now).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from dir at lanl dot gov 2005-12-06 13:47 ---
If you look at the output from format 2030, you will see that that comma at the
end of the "44h e n d..." statement is printed, but the comma is the 45th
character after the 44h . Like wise the '/' after the 8 is printed inspit
--- Comment #16 from rguenth at gcc dot gnu dot org 2005-12-06 13:48
---
Confirmed. -fno-ivopts fixes it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from rguenth at gcc dot gnu dot org 2005-12-06 13:59
---
IVOPTs truncates pstartD.1866_10 down to int, which is wrong:
htab_bolt_mapping (pstartD.1866, cntD.1867)
{
unsigned intD.3 D.1959;
long unsigned intD.4 D.1960;
long unsigned intD.4 ivtmp.50D.1954;
unsigne
--- Comment #2 from sayle at gcc dot gnu dot org 2005-12-06 14:00 ---
Subject: Bug 25263
Author: sayle
Date: Tue Dec 6 14:00:09 2005
New Revision: 108119
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108119
Log:
PR c++/25263
* decl.c (compute_array_index_type)
--- Comment #18 from olh at suse dot de 2005-12-06 14:26 ---
Adding -fno-ivopts to CFLAGS for hash_utils_64.o fixes it for me.
Tested with gcc-4_1-branch r108104 and current binutils.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
--- Comment #1 from krebbel at gcc dot gnu dot org 2005-12-06 14:33 ---
Shorter testcase:
long long
foo (long long x, int y)
{
return x << ((y + 1) & 63);
}
The count operand of a shift instruction is a somewhat weird
thing on S/390. It is basically an address accepting the sum of
an
--- Comment #2 from jakub at gcc dot gnu dot org 2005-12-06 14:48 ---
Yeah, making separate
(define_insn "*di3_and_31"
[(set (match_operand:DI 0 "register_operand" "=d")
(SHIFT:DI (match_operand:DI 1 "register_operand" "0")
(and:SI (match_operand:SI 2 "shift_c
Last known to work with: "Mon Dec 5 12:27:13 UTC 2005 (revision 108052M)".
First known to fail with: "Mon Dec 5 22:19:13 UTC 2005 (revision 108077M)".
Running /home/hp/combined/combined/gcc/testsuite/gcc.dg/dg.exp ...
...
FAIL: gcc.dg/attr-weakref-1.c execution test
With the message in the .log
#include
__v8qi foo(const __v8qi x, const __v8qi y){return x+y;}
__v8qi bar(const __v8qi x, const __v8qi y){return __builtin_ia32_paddb(x,y);}
$ gcc tmp.c -S -O2 -mmmx
3.3.6 produces the same code for foo() and bar():
foo:movq4(%esp), %mm0
paddb 12(%esp), %mm0
movq
--- Comment #1 from pluto at agmk dot net 2005-12-06 15:02 ---
(In reply to comment #0)
> $ gcc tmp.c -S -O2 -mmmx
fix: -S -O2 -mmmx -fomit-frame-pointer -mregparm=3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25277
--- Comment #19 from rakdver at gcc dot gnu dot org 2005-12-06 15:28
---
Seems like some problem in iv analysis:
ssa name pstart_17
type long unsigned int
base (long unsigned int) (unsigned int) D.1301_7 + (long unsigned int)
(unsigned int) pstart_10
step (long unsigned int) step
--- Comment #14 from roger at eyesopen dot com 2005-12-06 15:39 ---
Fixed for gcc v4.2
--
roger at eyesopen dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from roger at eyesopen dot com 2005-12-06 15:43 ---
Fixed. I've checked all other uses of TREE_OVERFLOW in cp/decl.c and c-decl.c
to confirm that the C front-end isn't affected by a similar issue there.
Sorry for any inconvenience.
--
roger at eyesopen dot com changed
--- Comment #20 from rakdver at gcc dot gnu dot org 2005-12-06 15:43
---
This patch should fix the problem:
Index: tree-scalar-evolution.c
===
*** tree-scalar-evolution.c (revision 108078)
--- tree-scalar-evolution.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-06 16:04 ---
This is not fully a regression as this was on purpose change until emms was
emmitted correctly. Anyways this is very much related to PR 22076 and PR 14552
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #87 from pluto at agmk dot net 2005-12-06 17:05 ---
current 4.1(+libstdc++ patch) works fine for PR21382 on amd64 and ppc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Comment #3 from reichelt at gcc dot gnu dot org 2005-12-06 17:30
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-12-06 17:31
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #2 from reichelt at gcc dot gnu dot org 2005-12-06 17:32
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
from ChangeEndianness(T* begin,const T* end) so that the generic
version ChangeEndianness(T& t) is called instead generating and error because
the default class for SwapEndianness does not contain any swap method.
This has been tested with gcc version 4.2.0 20051206 (experimental).
Note also tha
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2005-12-06 17:39 ---
Created an attachment (id=10419)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10419&action=view)
The code describing the regression.
Simplify compile with g++
--
http://gcc.gnu.org/
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-06 17:48 ---
No, GCC is correct to reject this code. What is happening is that the
overloaded set for the ChangeEndianness in the second ChangeEndianness is only
the first and the second so there is no way to consider the third
#include
int foo(double x)
{
return round(x);
}
causes
$ gcc -c t.c
t.c: In function 'foo':
t.c:5: warning: incompatible implicit declaration of built-in function 'round'
the transformation of round to lround here done in convert_to_integer is
likely the cause for this. Compiling with -std=
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-06 17:59 ---
This is a glibc bug. round is not prototype any where when looking at the
preprocessed source for the file but is when adding -std=c99.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-12-06 18:03
---
Working on a patch.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from janis at gcc dot gnu dot org 2005-12-06 18:04 ---
Subject: Bug 25247
Author: janis
Date: Tue Dec 6 18:04:00 2005
New Revision: 108124
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108124
Log:
PR testsuite/25247
* lib/target-supports-dg.exp (
--- Comment #21 from olh at suse dot de 2005-12-06 18:11 ---
Created an attachment (id=10420)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10420&action=view)
pr25248.patch
This patch fixes it for me.
Let me attach it in a readable form.
--
http://gcc.gnu.org/bugzilla/show_bu
Hello,
A bug #24675 was logged on Nov 4th for gcc 3.2.1 (arm arch). After
several emails communication by helpful people, it was determined that
the issue is similar to bug #23150 and is still there for:
gcc 3.2.1,
gcc 3.3.3, gcc 3.3.6, gcc 3.4.4
gcc 4.0.1 and gcc 4.0.2
It was tested and
Hello,
A bug #24675 was logged on Nov 4th for gcc 3.2.1 (arm arch). After
several emails communication by helpful people, it was determined that
the issue is similar to bug #23150 and is still there for:
gcc 3.2.1,
gcc 3.3.3, gcc 3.3.6, gcc 3.4.4
gcc 4.0.1 and gcc 4.0.2
It was tested and
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Request fix for Bug #23150 |[3.4/4.0 only] Request fix
|(aka Bug #24675) in gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-06 18:39 ---
*** This bug has been marked as a duplicate of 25281 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-06 18:39 ---
*** Bug 25282 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25281
cause
> the default class for SwapEndianness does not contain any swap method.
>
> This has been tested with gcc version 4.2.0 20051206 (experimental).
>
> Note also that things slightly improved since
> gcc version 4.2.0 20051124 (experimental)
> which failed also if the e
--- Comment #22 from bergner at vnet dot ibm dot com 2005-12-06 18:47
---
...and I can verify that the patch fixes the reduced test case. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
--- Comment #4 from theodore dot papadopoulo at sophia dot inria dot fr
2005-12-06 18:51 ---
(In reply to comment #2)
I may accept that g++ is right to reject this code. I cannot convince myself
from reading the standard but I'm not a langage lawyer. I think that this is a
major flaw in
gcj generates an invalid signature for the anonymous constructor
in this test case:
public class t {
public t(char[][] args) { }
public Object m() {
return new t(new char[][] { "hi".toCharArray(),
"bob".toCharArray(),
"and jo
--- Comment #20 from pluto at agmk dot net 2005-12-06 19:26 ---
Created an attachment (id=10421)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10421&action=view)
patch for current 4.1 branch.
I would love to see a ppc-linux part for this patch.
--
http://gcc.gnu.org/bugzilla/
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-06 19:27 ---
The reason why removing one enum works is because the size of the RGB will be
one instead of two so that the specialized version of SwapEndianness::swap can
be used. There is nothing magical here with respect with t
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-12-06 19:27
---
*** Bug 25278 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
inside main(), a call is made to function testo() which simply returns a
double(1415.149). The correct double value is returned only if main.c has
#include , which is where testo() is declared.
I've compiled two versions of this program, with and without the include line,
withinclude.a.out and wi
--- Comment #7 from eedelman at gcc dot gnu dot org 2005-12-06 19:38
---
(In reply to comment #6)
> Working on a patch.
Posted a pacth here: http://gcc.gnu.org/ml/fortran/2005-12/msg00116.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18197
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-06 19:40 ---
The C standard says that if a function is not declared (prototyped) then
implicately it returns the type of int.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from gnassre at earthlink dot net 2005-12-06 19:40 ---
Created an attachment (id=10422)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10422&action=view)
output of gcc -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25284
--- Comment #3 from gnassre at earthlink dot net 2005-12-06 19:41 ---
Created an attachment (id=10423)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10423&action=view)
testo() function definition file from gcc --save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25284
--- Comment #4 from gnassre at earthlink dot net 2005-12-06 19:41 ---
Created an attachment (id=10424)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10424&action=view)
main() function definition file from gcc --save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25284
--- Comment #6 from aldyh at gcc dot gnu dot org 2005-12-06 19:45 ---
Subject: Bug 24138
Author: aldyh
Date: Tue Dec 6 19:45:00 2005
New Revision: 108126
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108126
Log:
PR C++/24138
* tree.c (integer_all_onesp): Always
--- Comment #5 from gnassre at earthlink dot net 2005-12-06 19:45 ---
(In reply to comment #1)
> The C standard says that if a function is not declared (prototyped) then
> implicately it returns the type of int.
>
ok thanks, that makes sense =)
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #7 from aldyh at gcc dot gnu dot org 2005-12-06 19:48 ---
Fixed.
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01175.html
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
-
This is the gcc-4.0 reincarnation of PR 15242. Since about gcc-3.2 or
so gcc tends to compile "goto *" into direct jumps to a shared
indirect jump. Gcc-4.0 tries to undo this in a later stage, but
apparently it is not completely successful:
This is a fragment from the engine1.i file I will
attac
--- Comment #1 from anton at mips dot complang dot tuwien dot ac dot at
2005-12-06 20:00 ---
Created an attachment (id=10425)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10425&action=view)
test case input
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25285
FAIL: ext/pool_allocator/allocate_chunk.cc execution test
appeared on mainline between 20051117 and 20051118 (revisions 107115 and
107161) on hppa2.0w-hp-hpux11.11 and still appears present on mainline and 4.1
branch. This test previously passed.
The failure in bug 25168 appeared between the same
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-12-06 20:20 ---
Reopening since this was only fixed for 4.2.0 and not also for 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org
|dot org
--- Comment #23 from rakdver at gcc dot gnu dot org 2005-12-06 20:33
---
Patch: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00454.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-06 20:46 ---
__asm__(""); makes stuff worse.
Anyways it looks like the code in GCC only deals with non conditional jumps
(unless I am missing something).
Is there a conditional jump of an indirect jump for x86/x86_64?
--
ht
--- Comment #21 from pluto at agmk dot net 2005-12-06 20:55 ---
ok, I hope this ppc-elf-linux fix for pr20218-x86-32_64.patch is correct.
with this both testcases work.
diff -uNrp a/gcc/config/rs6000/linux.h b/gcc/config/rs6000/linux.h
--- a/gcc/config/rs6000/linux.h2005-11-30 11:15
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-06 20:57 ---
Since there is no conditional indirect jumps on x86 this is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Code:
int f(void *a, int b)
{
if (b ==1) goto *a;
g();
if (b ==2) goto *a;
g();
return 1
}
This is very minor but I thought it would be cool if GCC could do something
like:
.f:
mflr %r0
cmpwi %cr7,%r4,1
std %r30,-16(%r1)
std %r31,-8(%r1)
mr %r30,%r
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-06 21:09 ---
Ignore the:
.L3:
mtctr %r30
bctr
Part
and "beqctr %cr7,.L3" should have been "beqctr %cr7"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25287
--- Comment #1 from pcarlini at suse dot de 2005-12-06 21:09 ---
(In reply to comment #0)
> The failure in bug 25168 appeared between the same pair of revisions; I don't
> know if they are related.
At least, both testcases replace operator new...
--
http://gcc.gnu.org/bugzilla/show
According to section 23.2.2.3 [lib.list.modifiers] of the C++ specification,
for all the insert member functions of std::list, "If an exception is thrown
there are no effects."
However, this doesn't appear to be the case for libstdc++. It's possible for
an exception to be thrown out of an insert
--- Comment #1 from lennox at cs dot columbia dot edu 2005-12-06 21:30
---
Created an attachment (id=10426)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10426&action=view)
C source file, constructing a list with a custom debug allocator.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #2 from lennox at cs dot columbia dot edu 2005-12-06 21:31
---
Created an attachment (id=10427)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10427&action=view)
Custom debug allocator, based on libstdc++'s malloc_allocator.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #22 from tkoenig at gcc dot gnu dot org 2005-12-06 21:45
---
Added new patch.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
U
--- Comment #4 from anton at mips dot complang dot tuwien dot ac dot at
2005-12-06 21:46 ---
Subject: Re: pessimization of goto * ("computed goto")
pinskia at gcc dot gnu dot org wrote:
> __asm__(""); makes stuff worse.
I just applied the following patch to engine1.i:
--- engine1.i
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-06 21:58 ---
(In reply to comment #4)
> So, no, the code is not worse, but much better. I hope this
> workaround will continue to work in future versions.
You are wrong in general since this is a conditional indirect jump. Sin
--- Comment #1 from tkoenig at gcc dot gnu dot org 2005-12-06 22:14 ---
(In reply to comment #0)
> PROGRAM BUG
> external real function Mfunc
This declares an external symbol called
"realfunctionmfunc" (fixed form), which is
probably not what you intended.
If you replace t
--- Comment #2 from dpatel at apple dot com 2005-12-06 22:19 ---
This is already fixed.
--
dpatel at apple dot com changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #4 from listor1 dot rombobeorn at comhem dot se 2005-12-06
22:21 ---
Subject: Re: Discriminant is left uninitialized.
laurent at guerby dot net wrote:
> The problem is that you are using "Unbounded_String" in your record, and
> this brings in lots of dope information for F
--- Comment #5 from dpatel at apple dot com 2005-12-06 22:23 ---
Created an attachment (id=10430)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10430&action=view)
zem's patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
--- Comment #3 from pcarlini at suse dot de 2005-12-06 22:36 ---
Ouch! Luckily seems not too difficult to fix, consistently with other similar
situations in the library. Thanks for your report.
--
pcarlini at suse dot de changed:
What|Removed |Adde
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-06 22:37 ---
*** This bug has been marked as a duplicate of 19266 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-12-06 22:37
---
*** Bug 25280 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from albertm at uphs dot upenn dot edu 2005-12-06 22:52
---
Subject: Re: gfortran ignores explicit return type for
fun ctions
Thank you very much. My apologies. I don't understand Fortran as
well as I should.
Sincerely,
Mike Albert
On Tue, 6 Dec 2005, tkoenig at
malo /tmp $ cat a.f
integer*1 abyte
integer*8 n
n = huge(0_4)
n = 256 * n
print *, n
open(10,file="foo",recl=1,form='unformatted',access='direct')
write(10,rec=n) abyte
close(10)
end
malo /tmp $ ifort a.f && ./a.out
549755813632
malo /
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-12-06 23:43 ---
So the 3.3 was a regression so closing as fixed for 3.4.0 as 3.3.x is no longer
being maintained.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-06 23:55 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
1 - 100 of 119 matches
Mail list logo
