--- Comment #2 from kargl at gcc dot gnu dot org 2008-05-30 06:19 ---
(In reply to comment #1)
> 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
--- 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 a
--- 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 #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 #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,
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), intent(
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 t
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywo
--- 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
---
--- 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 #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=15702&action=view) [edit]
> Minimal testcase for vtable issue
>
> I'm not sure whether th
--- 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.
--
http://gcc.gnu.
--- 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 w
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, cxx_target_o
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 target-re
--- 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
http://gcc.gnu.org/ml/fortran/2008-05/msg00354.html, issue 3:
If I compile the following a.F90 file:
# 1 "a.F90"
# 1 ""
# 1 ""
# 1 "a.F90"
print *, "foo" "bar""gee"
end
with "gfortran -E", I get garbage in the output:
# 1 "a.F90"
# 1 ""
# 1 ""
# 1 "a.F90"
# 1 "a.F90*"
# 1 "ߪ▒*"
# 1 ""
# 1
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 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
Stat
--- 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 reduce
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
$> cat a.F90
# 1 "a.F90"
# 1 ""
# 1 ""
# 1 "a.F90"
print *, "foo" "bar""gee"
end
$> gfortran-svn -fpreprocessed a.F90
:1:1: error: invalid flag "__STDC__" in line directive
:1:10: warning: extra tokens at end of ## directive
a.F90:1: internal compiler error: Segmentation fault
--
--- 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=gcc&view=rev&rev=136178
Log:
gcc:
2008-05-29 Daniel Franke <[EMAIL PROTECTED]>
--- 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=15702&action=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 #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
--
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 #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=gcc&view=rev&rev=136174
Log:
/cp
2008-05-29 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- 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 #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
Status|UNCONFI
--- 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=15701&action=view)
test case
Fails on gcc version 4.4.0 20080509 as well
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36374
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 wi
--- 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
--- 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 clobber
--- 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
AssignedTo|unassigned
--- 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 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
--
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);
template void
myPrintf( const char * fmt, ... )
__attribute__ ((__format__ (__printf__, 1, 2)));
template void
myPrintf( const char * fmt, ... )
{
}
void func()
{
myPrintf( "test" );
}
$ g++ t.cc
t.cc: In function 'void func()':
t.cc:6: error: '__printf__' was not declared in this scope
t.cc
--- 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 f
--- 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
--- 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 #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 build_pointer_
--- 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.
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 #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:
--- 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.
--
http://gcc.gnu.org/bugzilla/sh
--- 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 g
--- 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 #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 #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 aff
--- 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 #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 l
--- 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 f(st
--- 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
t
--- 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 #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 #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=15700&action=view)
source file causing ICE on 4.3.0
tiramisu ~ $ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Con
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 been
#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 (&x.a);
return true;
}
long test(const A &x)
{
long a;
--- 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=15699&action=view)
Prefer 4 byte long LEA over 6 byte long ADD.L
Please include the attached patch for GCC.
The added patch ha
--- 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 sou
--- 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=gcc&view=rev&rev=136159
Log:
gcc/
2008-05-29 H.J. Lu <[EMAIL PROTECTED]>
PR target/35
t
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
ca
--- 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:12 ---
Mine. I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assi
--
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: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
--- 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
Status|UNCON
Compiling this program:
#include
$ 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
/pdv/.tools/pkg/gcc/4.3.0/bin
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)
@
--- 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 p
--- 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
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 type
--- 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
--
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 #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=15698&action=view)
rh448273.ii.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
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 fin
--- 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 t
--- 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 #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=gcc&view=rev&rev=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=gcc&view=rev&rev=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 36346
Author: rguenth
Date: Thu May 29 10:31:58 2008
New Revision: 136152
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=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 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|---
--- 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
--- 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) == inner
--
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
template struct A
{
static void assign (C &c1, const C &c2) { c1 = c2; }
};
template struct B
{
struct D
{
static const C terminal;
static unsigned long stor[];
static D &empty_rep ()
{
void *p = reinterpret_cast (&stor);
return *reinterpret_cast (p);
}
--- 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 op
--- 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 #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 #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 #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
Status|ASSIGNE
--- 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=gcc&view=rev&rev=136149
Log:
PR ada/864
* osint.ads, osint.adb (Program_Na
--- 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 #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 #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 #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|
#include
#include
using namespace std;
int main( int, char** )
{
vector v1;
vector v2;
vector 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 function for call to
__che
98 matches
Mail list logo
