#include algorithm
#include vector
using namespace std;
int main( int, char** )
{
vectorint v1;
vectorint v2;
vectorint v3;
set_union( v1.begin(), v1.end(), v2.begin(), v2.end(), v3.begin() );
return 0;
}
$ g++ -o t t.cc -D_GLIBCXX_DEBUG
...
debug/functions.h:317: error: no matching
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-29 08:46 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #9 from paolo dot carlini at oracle dot com 2008-05-29 08:54
---
*** Bug 36363 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from charlet at gcc dot gnu dot org 2008-05-29 08:56
---
Subject: Bug 864
Author: charlet
Date: Thu May 29 08:56:01 2008
New Revision: 136149
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136149
Log:
PR ada/864
* osint.ads, osint.adb
--- Comment #11 from charlet at gcc dot gnu dot org 2008-05-29 08:59
---
Fixed.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2008-05-29 08:54
---
*** This bug has been marked as a duplicate of 35541 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #12 from charlet at gcc dot gnu dot org 2008-05-29 09:04
---
Also a duplicate of PR864, which is now fixed.
*** This bug has been marked as a duplicate of 864 ***
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from chris at bubblescope dot net 2008-05-29 08:54 ---
This works fine for me on a couple of versions.
Could you give us the output of ' g++ -v ' ?
--
chris at bubblescope dot net changed:
What|Removed |Added
--- Comment #12 from charlet at gcc dot gnu dot org 2008-05-29 09:04
---
*** Bug 33857 has been marked as a duplicate of this bug. ***
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2008-05-29 09:35 ---
This fails for all optimization levels:
--cut here--
extern float c;
int test(void)
{
return !!c * 7LL == 0;
}
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36362
--- Comment #3 from rguenther at suse dot de 2008-05-29 09:42 ---
Subject: Re: [4.1/4.2/4.3/4.4 Regression] ICE in
simplify_subreg
On Thu, 29 May 2008, ubizjak at gmail dot com wrote:
--- Comment #2 from ubizjak at gmail dot com 2008-05-29 09:35 ---
This fails for all
template typename C struct A
{
static void assign (C c1, const C c2) { c1 = c2; }
};
template typename C, typename T struct B
{
struct D
{
static const C terminal;
static unsigned long stor[];
static D empty_rep ()
{
void *p = reinterpret_cast void *(stor);
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36364
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-29 10:32 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|---
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-29 10:32 ---
Subject: Bug 36346
Author: rguenth
Date: Thu May 29 10:31:58 2008
New Revision: 136152
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136152
Log:
2008-05-29 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-29 10:32 ---
Subject: Bug 36347
Author: rguenth
Date: Thu May 29 10:31:58 2008
New Revision: 136152
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136152
Log:
2008-05-29 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-29 10:32 ---
Subject: Bug 36343
Author: rguenth
Date: Thu May 29 10:31:58 2008
New Revision: 136152
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136152
Log:
2008-05-29 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-29 10:34 ---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #4 from ubizjak at gmail dot com 2008-05-29 10:23 ---
The problem is, that we enter simplify_gen_subreg from operand_subword with:
op:
(reg:QI 61)
outermode: word_mode (SImode)
innermode: DImode
This triggers assert in simplify_subreg:
gcc_assert (GET_MODE (op) ==
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-29 10:33 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from paolo dot carlini at oracle dot com 2008-05-29 10:29
---
Benjamin, can you double check this work? In debug mode the citerators
testcases, which predate it, fail for me...
--
paolo dot carlini at oracle dot com changed:
What|Removed
On the attached testcase with -O1 cc1plus either hangs, or spends enormous
amount of time in:
#7 0x007d9a4b in df_analyze () at ../../gcc/df-core.c:1265
#8 0x009a7935 in find_defs (loop=0x7f67f7de3dc0, body=0x669f640) at
../../gcc/loop-invariant.c:644
#9 0x009a861e in
--- Comment #1 from jakub at gcc dot gnu dot org 2008-05-29 10:55 ---
Created an attachment (id=15698)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15698action=view)
rh448273.ii.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
--- Comment #5 from rguenther at suse dot de 2008-05-29 10:59 ---
Subject: Re: [4.1/4.2/4.3/4.4 Regression] ICE in
simplify_subreg
On Thu, 29 May 2008, ubizjak at gmail dot com wrote:
--- Comment #4 from ubizjak at gmail dot com 2008-05-29 10:23 ---
The problem is, that
MODULE types
IMPLICIT NONE
TYPE :: inner
INTEGER, POINTER :: i(:)
END TYPE inner
TYPE :: outer
TYPE(inner), POINTER :: inr(:)
END TYPE outer
END MODULE types
MODULE mymod
IMPLICIT NONE
CONTAINS
FUNCTION test1()
USE
--- Comment #10 from burnus at gcc dot gnu dot org 2008-05-29 11:29 ---
Move comment from PR 36325, see also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/bb371413b5cbe3d7
The following is regarded as valid and did not work with one of the last
versions of proc
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-29 11:24 ---
A related problem also occurs with the POINTER attribute:
interface
real function bar()
end function bar
end interface
pointer :: bar
This allowed and means a procedure pointer. See
5.1.2.6 EXTERNAL
This typo in check_for_nested_with_variably_modified was present for 4 years
and hampered the inliner without anyone noticing:
Index: tree-nested.c
===
--- tree-nested.c (revision 136121)
+++ tree-nested.c (working copy)
Compiling this program:
#include sys/types.h
$ gcc a.c
In file included from /usr/include/sys/types.h:219,
from a.c:1:
/pdv/.tools/pkg/gcc/4.3.0/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed/sys/sysmacros.h:52:
error: expected ',' or ';' before '{' token
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-29 12:04 ---
Please specify the glibc version you are using and attach both the unfixed and
the fixed header.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-29 12:12 ---
Mine. I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from joerg dot richter at pdv-fs dot de 2008-05-29 12:21
---
Seems I've used gcc on a machine with a newer libc than it was built on.
Sorry for the noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36368
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-29 12:00 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
to TRUTH_NOT_EXPR's type.
* gcc.c-torture/execute/20080529-1.c: New test.
--- gcc/gimplify.c.jj 2008-05-18 22:14:23.0 +0200
+++ gcc/gimplify.c 2008-05-29 14:24:38.0 +0200
@@ -5748,7 +5748,8 @@ gimplify_expr (tree *expr_p, tree *pre_p
case TRUTH_NOT_EXPR
--- Comment #10 from hjl at gcc dot gnu dot org 2008-05-29 12:35 ---
Subject: Bug 35771
Author: hjl
Date: Thu May 29 12:35:04 2008
New Revision: 136159
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136159
Log:
gcc/
2008-05-29 H.J. Lu [EMAIL PROTECTED]
PR target/35771
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-29 12:40 ---
Confirm.
==1593== Invalid read of size 1
==1593==at 0xB51CD1: linemap_add (line-map.c:111)
That is libcpp/line-map.c:111:
source_location start_location = set-highest_location + 1;
I quickly looked at the
--- Comment #3 from gunnar at greyhound-data dot com 2008-05-29 12:50
---
Created an attachment (id=15699)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15699action=view)
Prefer 4 byte long LEA over 6 byte long ADD.L
Please include the attached patch for GCC.
The added patch has
#ifdef DEFINE_B
struct B
{
unsigned long b;
B operator= (bool x) { return *this; }
};
#endif
struct A
{
void *a;
};
bool operator = (const A x, long y)
{
typedef long __attribute__ ((may_alias)) long_a;
y = *reinterpret_cast const long_a * (x.a);
return true;
}
long test(const A x)
{
Hello,
I would like to use the psrlq sse2 instruction. There used to be
builtins named __builtin_ia32_psrlq128 and __builtin_ia32_psrlqi128.
The patch http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01571.html has
removed some SSE builtins, including these. However, the documentation
has not
--- Comment #1 from Emmanuel dot Thome at inria dot fr 2008-05-29 13:20
---
Created an attachment (id=15700)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15700action=view)
source file causing ICE on 4.3.0
tiramisu ~ $ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-29 13:26 ---
(I would like to stay away from -flax-vector-conversions, as the code above
in reality does no ``vector conversions'' per se).
Yes there is, the __builtin_ia32_psrlqi128 takes __m128 and not a vector type.
Also
--- Comment #2 from bonzini at gnu dot org 2008-05-29 13:31 ---
looks like a loop with 5000 basic blocks...
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2008-05-29 13:38 ---
Given that get_alias_set uses TYPE_MAIN_VARIANT on the type before
c_common_get_alias_set gets a chance to return 0 for types with may_alias
attribute, it is obvious why this depends on other code using the same base
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-29 13:43 ---
I think this is really a C++ front-end rather than a bug in the middle-end.
The follow program shows that we get the wrong aliasing set with the C++
front-end but not the C front-end:
struct g{long a;};
struct g
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-29 13:48 ---
For my testcase with the C front-end:
;; *y = *(const long_a *) x-a
(insn 7 6 8 t.cc:12 (set (reg:SI 61)
(mem:SI (reg/v/f:SI 59 [ x ]) [0 S4 A32])) -1 (nil))
While with the C++ front-end:
;; *y = *(const
--- Comment #3 from zadeck at naturalbridge dot com 2008-05-29 13:49
---
Subject: Re: [4.3/4.4 Regression] Hang in df_analyze
bonzini at gnu dot org wrote:
--- Comment #2 from bonzini at gnu dot org 2008-05-29 13:31 ---
looks like a loop with 5000 basic blocks...
--- Comment #4 from jakub at gcc dot gnu dot org 2008-05-29 13:54 ---
Quick hack that fixes this:
--- gcc/alias.c.jj 2008-05-18 22:14:23.0 +0200
+++ gcc/alias.c 2008-05-29 15:47:30.0 +0200
@@ -605,6 +605,8 @@ get_alias_set (tree t)
/* Variant qualifiers don't
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-29 13:58 ---
I was wrong about being C++ specific as here is a testcase which fails with
both front-ends:
struct g{long a;};
unsigned long f(struct g *a) { return *(unsigned long *)a-a;}
struct A
{
void *a;
};
int f1(const
--- Comment #6 from jakub at gcc dot gnu dot org 2008-05-29 14:00 ---
Yeah, or:
void *a;
int
f0 (long *y)
{
*y = *(const long *) a;
return 1;
}
int
f1 (long *y)
{
typedef long __attribute__ ((may_alias)) long_a;
*y = *(const long_a *) a;
return 1;
}
int
f2 (long *y)
{
*y
--- Comment #3 from Emmanuel dot Thome at inria dot fr 2008-05-29 14:02
---
Yes there is, the __builtin_ia32_psrlqi128 takes __m128 and not a vector
type.
ok. I guess you mean __m128i, for that particular case.
It very much seems that the texinfo documentation for this part of
--- Comment #7 from jakub at gcc dot gnu dot org 2008-05-29 14:08 ---
handle_may_alias_attribute is wrong though, as it modifies the alias set of
long int. Either may_alias causes creation of build_distinct_type_copy, or we
are in big trouble IMHO.
--
--- Comment #4 from Emmanuel dot Thome at inria dot fr 2008-05-29 14:09
---
This leaves the ICE problem in attachment 15700. Is my assembly constraint
bogus (in which case I'd prefer a nice diagnostic, as was the case in gcc
4.2.4, to an ICE) ? I tried three choices for the inline asm:
The first test case in PR36319 gives now:
character(len=3, kind=4), parameter, dimension(3) :: mychar = [ abc, def
1
Error: Incompatible types in assignment at (1); attempted assignment of
CHARACTER(4) to CHARACTER(1)
which
--- Comment #5 from ubizjak at gmail dot com 2008-05-29 14:30 ---
Please note that psrlq doesn't implement x[N] y[N] shift, but x[N] y
shift. That is, all elements are shifted by the same value. Please see Intel
instruction reference.
Also, psrlq doesn't support memory operands.
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-05-29 14:30 ---
The correct fix is to build a pointer with TYPE_REF_CAN_ALIAS_ALL for pointers
to types with the may_alias attribute. This is the only thing that will make
sure it works properly. This can be done in
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-05-29 14:41 ---
Of course the cleaner design of may_alias would have put it on pointer types
only, so we could have handled this in handle_may_alias_attribute ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
--- Comment #6 from Emmanuel dot Thome at inria dot fr 2008-05-29 14:49
---
(In reply to comment #5)
Please note that psrlq doesn't implement x[N] y[N] shift, but x[N] y
shift. That is, all elements are shifted by the same value. Please see Intel
instruction reference.
yeah, I
--- Comment #7 from ubizjak at gmail dot com 2008-05-29 15:03 ---
(In reply to comment #6)
Also, psrlq doesn't support memory operands.
It does (for the shift count). Or my AMD doc is bogus.
Uh, indeed. I was looking into sse.md patterns. Unfortunatelly, it takes 128bit
operand
templateclass T void
myPrintf( const char * fmt, ... )
__attribute__ ((__format__ (__printf__, 1, 2)));
templateclass T void
myPrintf( const char * fmt, ... )
{
}
void func()
{
myPrintfint( test );
}
$ g++ t.cc
t.cc: In function 'void func()':
t.cc:6: error: '__printf__' was not declared in
extern void abort (void);
struct Foo {
int *p;
int *q;
};
struct Foo __attribute__((noinline))
bar(int *p)
{
struct Foo f;
f.p = p;
return f;
}
void __attribute__((noinline))
foo(struct Foo f)
{
*f.p = 0;
}
int main()
{
int a, b;
a = 0;
b = 1;
struct Foo f;
f = bar (b);
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-29 15:07 ---
*** This bug has been marked as a duplicate of 35546 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-05-29 15:07 ---
*** Bug 36372 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-29 15:07 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-29 15:23 ---
First we miss the constraint
f = ANYTHING
from
f = bar (b);
but then we also do not handle at all the case of escaping pointers through
by-value passed structures
foo (f);
and thus we end up not
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-29 15:44 ---
I have a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36373
The attached code produces an error message, yet it is accepted by other
compilers and is judged legal in
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/82aebb2460cba148#
[EMAIL PROTECTED] bugtest]$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured
--- Comment #1 from sfilippone at uniroma2 dot it 2008-05-29 16:01 ---
Created an attachment (id=15701)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15701action=view)
test case
Fails on gcc version 4.4.0 20080509 as well
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36374
--- Comment #11 from hjl dot tools at gmail dot com 2008-05-29 16:08
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2008-05-29 16:28 ---
Well, if it is done frequently, perhaps we should spent a bit on it.
Or, make sure types with may_alias attribute get TYPE_ALIAS_SET 0 and
make TYPE_REF_CAN_ALIAS_ALL all pointers that point to alias set 0 types.
--- Comment #4 from paolo at gcc dot gnu dot org 2008-05-29 16:45 ---
Subject: Bug 35243
Author: paolo
Date: Thu May 29 16:44:29 2008
New Revision: 136174
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136174
Log:
/cp
2008-05-29 Paolo Carlini [EMAIL PROTECTED]
PR
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
|dot com
--- Comment #6 from a dot kaiser at gmx dot net 2008-05-29 17:01 ---
In a similar case I've got the impression that the ifcombine pass might be
responsible for rewriting the if into shift and mask. It is rather
questionable whether this really optimizes things for simple targets which
--- Comment #7 from tdragon at tdragon dot net 2008-05-29 17:31 ---
Created an attachment (id=15702)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15702action=view)
Minimal testcase for vtable issue
I'm not sure whether this is related, but the effect is similar so I'm adding
it
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-05-29 18:22 ---
Subject: Bug 36348
Author: dfranke
Date: Thu May 29 18:21:35 2008
New Revision: 136178
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136178
Log:
gcc:
2008-05-29 Daniel Franke [EMAIL PROTECTED]
PR
$ cat a.F90
# 1 a.F90
# 1 built-in
# 1 command-line
# 1 a.F90
print *, foo bargee
end
$ gfortran-svn -fpreprocessed a.F90
built-in:1:1: error: invalid flag __STDC__ in line directive
built-in:1:10: warning: extra tokens at end of ## directive
a.F90:1: internal compiler error: Segmentation
http://gcc.gnu.org/ml/fortran/2008-05/msg00354.html, issue 1:
When I compile a .F90 file with -save-temps, I get:
f951: warning: command line option -fpch-preprocess is valid for
C/C++/ObjC/ObjC++ but not for Fortran
--
Summary: -cpp -save-temps passes unknown options to f951
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2008-05-29
18:37 ---
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
Can you reduce the testcase so I can try to analyze this with a cross?
Here is a somewhat
http://gcc.gnu.org/ml/fortran/2008-05/msg00354.html, issue 2:
When I compile a .F90 file with -E, no newline is appended at the
end of the last line of output.
--
Summary: newline missing at end of preprocessed output
Product: gcc
Version: 4.4.0
A college of mine recently struggled compiling some Fortran files and it turned
out that they used (old) Mac line breaks, i.e. \r instead of Unix \n or Windows
\r\n.
(I have not checked how difficult it is to support this.)
Analogously, one could think of supporting \r line breaks in libgfortran,
http://gcc.gnu.org/ml/fortran/2008-05/msg00354.html, issue 3:
If I compile the following a.F90 file:
# 1 a.F90
# 1 built-in
# 1 command-line
# 1 a.F90
print *, foo bargee
end
with gfortran -E, I get garbage in the output:
# 1 a.F90
# 1 built-in
# 1 command-line
# 1 a.F90
# 1 a.F90*
# 1
--- Comment #10 from dfranke at gcc dot gnu dot org 2008-05-29 19:12
---
Implemented, but not yet fixed, in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
gcc/fortran/cpp.c (cpp_define_builtins) should define target-related macros via
usage of TARGET_*.
Warning: The definition of TARGET_* macros needs to be checked for all targets
as some assume to be used in gcc/c-cppbuiltin.c only.
--
Summary: preprocessing: define built-in
Follow up to PR36348:
[darwin-f.c] need[s] to implement darwin_register_frameworks, as well as the
-iframework option implemented by handle_c_option in darwin-c.c. I suggest
splitting that part of darwin-c.c into a new file darwin-cpp.c that is included
in all three of c_target_objs,
--- Comment #4 from janus at gcc dot gnu dot org 2008-05-29 20:06 ---
Here is a first attempt to fix this. The following patch should cope with the
original test case and the one in comment #1. The fix for the POINTER issues
will go into my procedure pointer patch. Any other attributes
--- Comment #5 from burnus at gcc dot gnu dot org 2008-05-29 20:58 ---
Any other attributes we need to handle?
I think that's all. I looked through the list of attributes and most are not
possible for procedures or are already rejected. Thus I think we have all.
--
--- Comment #8 from dannysmith at users dot sourceforge dot net 2008-05-29
21:00 ---
(In reply to comment #7)
Created an attachment (id=15702)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15702action=view) [edit]
Minimal testcase for vtable issue
I'm not sure whether this is
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-29 21:00 ---
Duplicate of PR 36276 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379
--- Comment #2 from burnus at gcc dot gnu dot org 2008-05-29 21:02 ---
Paul, do you have an idea? You are our module/interface specialist.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/3228dcee5e3d57c7
Some compilers (such as ifort) allow symbols which start with a $ sign - and
they allow IMPLICT with $. gfortran currently does not recognize these.
Solution:
a) Support it as ifort does
b) Document
See:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/12ac1683f64da0b8
! type t_a is public; type t_b is private
interface operator(+)
module procedure add_t_a, add_t_b
end interface
contains
pure function add_t_a(a1,a2) result(a)
type(t_a) :: a
type(t_a),
--- Comment #9 from tdragon at tdragon dot net 2008-05-29 22:13 ---
(In reply to comment #8)
Uhh, if you declare a struct as dllimport, then you are declaring that it's
vtable is defined in a dll. So why is this a bug?
Well, it's a change from mingw32/3.4.5's behavior. At any rate,
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-29 22:18
---
(In reply to comment #1)
Duplicate of PR 36276 ?
Doesn't have the same location, so I don't think so :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379
--- Comment #2 from hp at gcc dot gnu dot org 2008-05-30 00:59 ---
Ditto vconduMODE.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-05-30 04:21
---
This could be solved by judicious use of a good source code editor.
Also, we could have the scanner insert a '/n' if a '/r' is found and peeking
ahead does not find a '/n', assuming we are not between quotes in
97 matches
Mail list logo
