--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-24 07:03 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from steven at gcc dot gnu dot org 2007-08-24 07:10 ---
Re. comment #4 -- as if it is constructive to annoy me by CC-ing me on
gcc-patches and in this PR when I've made it pretty damn clear that I don't
want to work on gcc anymore...
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #7 from jakub at gcc dot gnu dot org 2007-08-24 07:40 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from jakub at gcc dot gnu dot org 2007-08-24 07:42 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-08-24 08:48
---
As per comment #6.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-24 09:23 ---
MIPS-linux uses elf which has weak support.
So I don't see why you think GTHREAD_USE_WEAK should not be defined.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-24 09:02 ---
No, the inline-asm is just wrong, you need to use a different thing for
including non indexed load/stores.
The inline-asm function should be written as:
static inline unsigned long
load_acquire(volatile unsigned lon
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-08-24 10:20
---
Since this one seems to be a documentation issue, I'll take it. I intend to
write a *-*-mingw32 entry to the target-specific installation notes.
--
fxcoudert at gcc dot gnu dot org changed:
What
--- Comment #8 from uros at gcc dot gnu dot org 2007-08-24 10:58 ---
Subject: Bug 33157
Author: uros
Date: Fri Aug 24 10:58:12 2007
New Revision: 127766
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127766
Log:
PR middle-end/33157
* ifcvt.c (noce_find_if_block):
--- Comment #7 from ubizjak at gmail dot com 2007-08-24 10:42 ---
Sometimes it is neccessary to check where you clear a structure.
Attached patch fixes this PR.
Index: ifcvt.c
===
--- ifcvt.c (revision 127761)
+++ ifcv
--- Comment #9 from ubizjak at gmail dot com 2007-08-24 11:06 ---
(In reply to comment #6)
> Re. comment #4 -- as if it is constructive to annoy me by CC-ing me on
> gcc-patches and in this PR when I've made it pretty damn clear that I don't
> want to work on gcc anymore...
Sorry to hea
Background:
===
In the Linux kernel one often sees the following idiom:
static void foo_func(void)
{
}
static struct foo_type foo_struct = {
.foo_call = foo_func,
};
some_init_func(...)
{
register_foo(&foo_struct);
}
some_exit_func(...)
{
unregister_foo(&foo_struct
I see the following error with trunk from 20070820:
(sid)28233:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -O -c tor-test.c
tor-test.c: In function 'test_dir_format':
tor-test.c:16: internal compiler error: in set_uids_in_ptset, at
tree-ssa-structalias.c:4704
Please submit a full bug repor
--- Comment #1 from tbm at cyrius dot com 2007-08-24 12:22 ---
Created an attachment (id=14100)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14100&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33173
--- Comment #2 from tbm at cyrius dot com 2007-08-24 12:24 ---
Works with 20070811.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33173
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:43
---
ICE still there, not mingw specific.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-24 12:44 ---
It also naturally would fit in the phiopt framework given the structure of
virtual operands:
# SMT.4_26 = VDEF
*D.2016_7 = D.2019_13;
if (D.2019_13 == 3)
goto ;
else
goto ;
:
goto ;
:
# SMT.4_
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:46
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dir at lanl dot gov 2007-08-24 12:46 ---
Created an attachment (id=14101)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14101&action=view)
testsuite output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174
Some of my programs run Ok with gfortran on the Macintosh and Linux, but fail
on CYGWIN and MSYS - so I ran the testsuite. Several unexpected failures were
found -
=== gcc Summary ===
# of expected passes47388
# of unexpected failures60
# of unexpected successe
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:53
---
Also works on mainline (4.3).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:31
---
This is still working fine. mingw development is focusing on 4.3, so this bug
probably stands little chance of being fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
Some of my programs run Ok with gfortran on the Macintosh and Linux, but fail
on CYGWIN and MSYS - so I ran the testsuite. Several unexpected failures were
found -
=== gcc Summary ===
# of expected passes47388
# of unexpected failures60
# of unexpected successe
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:56
---
Same kind of thing happens for ld, see PR24382.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pranav dot bhandarkar at gmail dot com 2007-08-24
13:28 ---
Created an attachment (id=14102)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14102&action=view)
Another testcase displaying the said behaviour
IMHO, the code generated for the following can benefit
--- Comment #5 from nikolay at totalviewtech dot com 2007-08-24 13:15
---
This is not fixed neither in 4.1.0 nor in any later version. The problem is
that DIE for static foofoo was indeed produced, but produced in wrong place.
<2><260>: Abbrev Number: 7 (DW_TAG_subprogram) --- Construc
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-24 13:07
---
As indicated in PR29826, this bug was fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-08-24 13:11 ---
Shorter testcase, fails at -O:
static void ConvertAddr (char *saddr, void **addr)
{
*addr = (void *) &saddr;
}
void DefineSelf (char *addr)
{
ConvertAddr (addr, (void **) &addr);
if (addr[0] == 127 && addr[3]
The code:
template
bool confirm(T t, int i) { return t == i; }
int main() {
int i = 0, j = 1, k = 2;
if (i == j) && confirm(j, k) ) { i = 2; }
return 0;
}
gets you:
~/ootbc/sim/src$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:5: error: expected `;' before '(' token
foo.cc:5:
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-24 13:59 ---
I have a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33166
--- Comment #6 from seppo at totalviewtech dot com 2007-08-24 13:52 ---
Hi Andrew,
Reopened the bug (see comment above). Do also notice that the (due to the
above) static foofoo inside constructor is still not visible to either TV or
gdb.
I have changed the title of the bug to reflect
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-08-24 14:14 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-24 14:13 ---
Confirmed. Only after early inlining we know enough to do this, but the
decision
is already made before it seems. Honza?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from paolo dot bonzini at lu dot unisi dot ch 2007-08-24
14:53 ---
Subject: Re: missed store sinking opportunity
Danny said he knows how to fix it (I guess in store sinking though he
didn't say). From knowing him, there might be additional less obvious
cases that thi
--- Comment #4 from patchapp at dberlin dot org 2007-08-24 14:46 ---
Subject: Bug number PR33139
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-08/msg01651.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-08-24 14:37 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-24 15:03 ---
FIXED for gfortran 4.3.0.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-24 15:04 ---
I said: FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-24 15:05 ---
*** This bug has been marked as a duplicate of 33174 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-24 15:05 ---
*** Bug 33175 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-24 15:09 ---
Subject: Bug 33166
Author: rguenth
Date: Fri Aug 24 15:09:10 2007
New Revision: 127771
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127771
Log:
2007-08-24 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-08-24 15:18 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-24 15:01 ---
Subject: Bug 33139
Author: burnus
Date: Fri Aug 24 15:00:59 2007
New Revision: 127770
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127770
Log:
2007-08-24 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #20 from jakub at gcc dot gnu dot org 2007-08-24 15:38 ---
Created an attachment (id=14103)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14103&action=view)
gcc43-pr33136.patch
Here is what I have been playing with.
But I'd really like to see some testcases where the
i
--- Comment #21 from dberlin at gcc dot gnu dot org 2007-08-24 15:42
---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On 24 Aug 2007 15:38:58 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #20 from jakub at
With the following test case, nint gives wrong result.
svn Revision: 127756
! Program to test the real->integer conversion routines.
program intrinsic_integer
implicit none
real :: val
integer :: i
val = 0.7
i = nint(val)
print *, val, i
val = -0.7
i = nint(val)
print *, val, i
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-08-24 15:57
---
"Finished", so unassigning.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from atgraham at gmail dot com 2007-08-24 16:00 ---
Here is a smaller bit of code for reproducing this problem. This doesn't
depend on any C++.
#include "pthread.h"
static __typeof(pthread_mutex_lock) __gthrw_pthread_mutex_lock __attribute__
((__weakref__("pthread_mutex_
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0019cb490586ed91/
SIGN with INTEGER arguments is allowed for initialization expressions in
Fortran 95; using REAL arguments it is only allowed for Fortran 2003.
gfortran -std=f95 prints the wrong error message for:
in
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-08-24 16:03 ---
None of the testcases in comment #3 fail on the mainline configured with
--enable-checking=yes,types. So either this bug is fixed or the patches from
Andrew did some slightly different checking. Or both ;)
--
--- Comment #2 from weston at computer dot org 2007-08-24 16:04 ---
Yep, looks like you are right from the standard. That sucks then. I wish it
were the other way because I don't see a way to enter a literal single
character in hex followed a by single character [A-Z0-9] without escape
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-08-24 16:04 ---
Might (or might not) be induced by my changes in this area. I'm currently in no
position to do anything about it, sorry :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33178
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-24 16:06 ---
The testcase is fine with mainline and --enable-checking=yes,types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22474
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-24 16:06 ---
So what is happening is that you are using the function directly and also via a
weakref. Can you give the output of GCC (that is the -S file)? This might be
really a binutils bug.
--
http://gcc.gnu.org/bugzill
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-24 16:07 ---
The testcase is fixed with mainline and --enable-checking=yes,types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22374
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-24 16:14 ---
This all comes down to cloning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-08-24 16:14 ---
Subject: Re: [4.3 Regression] ICE in set_uids_in_ptset, at
tree-ssa-structalias.c:4704
Accidently reversed test in tree-ssa-alias.c: find_used_portions
Testing fix now.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #22 from jakub at gcc dot gnu dot org 2007-08-24 16:16 ---
Not sure how, could I pass the buck to you then?
My thought was just that may_alias_p could for STRUCT_FIELD_TAG call
ipa_type_escape_field_does_not_clobber (TREE_TYPE (SFT_PARENT_VAR (var)),
TREE_TYPE (var)) (i.e. d
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-08-24 16:16 ---
Subject: Bug 32972
Author: tkoenig
Date: Fri Aug 24 16:16:16 2007
New Revision: 127774
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127774
Log:
2007-08-24 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-24 16:16 ---
So one goes the GOT (the weakref) while the other does not (straight call).
I am guess this is really a bug in binutils if a bug at all. Though two
different relocs for the same symbol should be ok.
>and thusly ch
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-24 16:17
---
This is a cygwin bug:
$ cat a.c
#include
#include
int main (void) {
float x = 0.7;
int i = (int) lroundf (x);
printf ("%d\n", i);
}
$ gcc a.c && ./a.exe
0
I you replace lroundf() with lround(), it works
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-24 16:24
---
cygwin or msys? What is the host, what is the target?
As far as I see, there is only one gfortran failure:
FAIL: gfortran.fortran-torture/compile/pr32417.f90, "-O" (internal compiler
error)
I don't see it on
--- Comment #5 from atgraham at gmail dot com 2007-08-24 16:12 ---
Created an attachment (id=14104)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14104&action=view)
Output of "mipsel-linux-gcc -Os -s tworelocs.c"
gcc output attached.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #23 from dberlin at gcc dot gnu dot org 2007-08-24 16:21
---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On 24 Aug 2007 16:16:44 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #22 from jakub at
--- Comment #8 from dpgrote at lbl dot gov 2007-08-24 16:29 ---
Subject: Re: array pointer assignment gives incorrect
dimensions
Great! Thanks for fixing this!
Dave
burnus at gcc dot gnu dot org wrote:
> --- Comment #7 from burnus at gcc dot gnu dot org 2007-08-24 15:04
> -
--- Comment #17 from jakub at gcc dot gnu dot org 2007-08-24 16:33 ---
Does this make sense to do this for POINTER_TYPE_P in 4.1/4.2, which
reassociate
in many other places?
I belive in 4.3 that changed with POINTER_PLUS_EXPR stuff.
struct A { int i; int v[1]; };
int *foo (struct A
--- Comment #7 from atgraham at gmail dot com 2007-08-24 16:34 ---
binutils bug created:
http://sourceware.org/bugzilla/show_bug.cgi?id=4959
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-08-24 16:40
---
Maybe - I was just conservative here to not possibly introduce new overflow
with the re-association as elsewhere we may rely on the undefinedness of
overflow.
Another way to fix this particular regression is to di
--- Comment #8 from nikolay at totalviewtech dot com 2007-08-24 16:45
---
(In reply to comment #7)
> This all comes down to cloning.
>
What do you mean?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
On 24 Aug 2007 16:45:41 -, nikolay at totalviewtech dot com
<[EMAIL PROTECTED]> wrote:
> What do you mean?
The IA64 C++ ABI requires two (or three) versions of constructor. So
GCC "clones" functions to deal with that. And we emit the context of
the local static variable part of the original
--- Comment #9 from pinskia at gmail dot com 2007-08-24 16:51 ---
Subject: Re: Local static variable in C++ constructor not visible for
debugging
On 24 Aug 2007 16:45:41 -, nikolay at totalviewtech dot com
<[EMAIL PROTECTED]> wrote:
> What do you mean?
The IA64 C++ ABI requires tw
--- Comment #24 from jakub at gcc dot gnu dot org 2007-08-24 16:36 ---
Removing that call in 4.1/4.2 would indeed cure c#8 testcase.
c#22 would be still broken (ipa_type_escape_field_does_not_clobber_p isn't
called at all on that testcase, neither in 4.1, nor 4.2, nor 4.3.
Guess c#22 tes
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-24 17:07 ---
Subject: Bug 32610
Author: jakub
Date: Fri Aug 24 17:06:59 2007
New Revision: 127776
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127776
Log:
PR debug/32610
* dwarf2out.c (gen_decl_die): Don'
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-24 17:10 ---
Subject: Bug 32898
Author: jakub
Date: Fri Aug 24 17:09:50 2007
New Revision: 12
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=12
Log:
PR c++/32898
* name-lookup.c (set_decl_namespace)
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-24 17:16 ---
Subject: Bug 32912
Author: jakub
Date: Fri Aug 24 17:15:51 2007
New Revision: 127779
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127779
Log:
PR middle-end/32912
* fold-const.c (fold_binary):
--- Comment #5 from jakub at gcc dot gnu dot org 2007-08-24 17:22 ---
Subject: Bug 32912
Author: jakub
Date: Fri Aug 24 17:21:42 2007
New Revision: 127781
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127781
Log:
PR middle-end/32912
* fold-const.c (fold_binary):
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-24 17:24 ---
Subject: Bug 32912
Author: jakub
Date: Fri Aug 24 17:23:43 2007
New Revision: 127783
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127783
Log:
PR middle-end/32912
* fold-const.c (fold_binary):
--- Comment #5 from jakub at gcc dot gnu dot org 2007-08-24 17:24 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2007-08-24 17:25 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from jakub at gcc dot gnu dot org 2007-08-24 17:29 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2007-08-24 17:13 ---
Subject: Bug 31941
Author: jakub
Date: Fri Aug 24 17:12:41 2007
New Revision: 127778
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127778
Log:
PR c++/31941
* error.c (resolve_virtual_fun_from_
--- Comment #2 from martinwguy at yahoo dot it 2007-08-24 17:34 ---
Also present using -mfloat-abi=softfp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33147
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-24 17:28 ---
Fixed.
On 4.1 branch with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127781
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from patchapp at dberlin dot org 2007-08-24 18:40 ---
Subject: Bug number PR33178
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-08/msg01675.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from dir at lanl dot gov 2007-08-24 18:40 ---
The Host and the Target was cygwin. There 60 unexpected failures in the gcc
testsuite and one in the fortran testsuite.
I have the latest version of gcc (3.4.4) that the cygwin site gives out. Is
that the "fresh mingw native
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-24 18:44 ---
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01566.html
Broke this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from wvangulik at xs4all dot nl 2007-08-24 18:52 ---
Created an attachment (id=14105)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14105&action=view)
Assembler output of testcase using 4.1.2
This is the requested assembler output that Eric asked for
--
http://
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-24 18:43 ---
I get this too:
/home/apinski/src/local/gcc/libstdc++-v3/src/system_error.cc:67: error:
std::system_category causes a section type conflict
--
pinskia at gcc dot gnu dot org changed:
What|Removed
It looks like gfortran is using a descriptors to display allocatable arrays in
f90, but I could never figure what is the type of the array:
<1><202>: Abbrev Number: 2 (DW_TAG_structure_type)
DW_AT_name: array_descriptor2
<2><21c>: Abbrev Number: 3 (DW_TAG_member)
DW_AT_n
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-24 19:26 ---
Subject: Bug 33178
Author: burnus
Date: Fri Aug 24 19:26:42 2007
New Revision: 127786
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127786
Log:
2007-08-24 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #5 from dir at lanl dot gov 2007-08-24 19:27 ---
> gfortran --v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../gcc/configure --disable-bootstrap --enable-multilib
--prefix=/usr/local/gfortran --enable-languages=c,fortran
--with-gmp=/usr/local/lib --with-m
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-24 19:28 ---
Fixed. Was a regression and kind of a typo.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from daney at gcc dot gnu dot org 2007-08-24 19:34 ---
Currently both libffi.call/return_sl.c and libffi.call/return_ul.c pass. These
cover all the cases in the ffitarget.c attached to the bug.
--
daney at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from wvangulik at xs4all dot nl 2007-08-24 19:36 ---
(In reply to comment #2)
> 4.3.0 20070817 snapshot generates this for the testcase:
>
Well at least the extra clr r25 is gone...
I just tried some simpler code:
extern unsigned char foo();
unsigned char test(unsig
--- Comment #3 from raeburn at raeburn dot org 2007-08-24 19:45 ---
(In reply to comment #2)
> Yep, looks like you are right from the standard. That sucks then. I wish it
> were the other way because I don't see a way to enter a literal single
> character in hex followed a by single cha
The following program might be invalid as all compilers I tried (gfortran, g95,
ifort, NAG f95, ifort) reject it with:
IMPORT-name must be the name of an entity in the host scoping unit
Error: 't' name in IMPORT statement does not exist in a host program unit
Error: Cannot IMPORT 't' from host sco
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #5 from eweddington at cso dot atmel dot com 2007-08-24 20:25
---
Created an attachment (id=14106)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14106&action=view)
Correct assembler output of test case for 4.1.2.
--
eweddington at cso dot atmel dot com changed:
--- Comment #6 from eweddington at cso dot atmel dot com 2007-08-24 20:30
---
Created an attachment (id=14107)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14107&action=view)
Test case assembler output for 4.2.1.
Not really any better than 4.1.2.
--
http://gcc.gnu.org/bugzi
--- Comment #7 from eweddington at cso dot atmel dot com 2007-08-24 20:35
---
Created an attachment (id=14108)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14108&action=view)
Test case assembler output for 4.3.0 20070817 snapshot.
Again, only marginally better.
--
http://gc
1 - 100 of 114 matches
Mail list logo
