On 11/11/08, James Dennett [EMAIL PROTECTED] wrote:
On Tue, Nov 11, 2008 at 8:04 PM, Mark Tall [EMAIL PROTECTED] wrote:
On 12/11/2008, James Dennett [EMAIL PROTECTED] wrote:
In a union only one field can be active at one time, hence
initializing more than one makes no sense
...
2008/11/11 Eric Fisher [EMAIL PROTECTED]:
Hello,
Anyone could tell how to be a gcc maintainer? Is there any
requirement? Actually, my previous work are all not based on the gcc
trunk. So no patch submitted. Anyway, it's cool to contribute :-)
Do you actually mean a maintainer or a
Never mind, I figured this one out.
Ping? Is this the right thing to do? I'd like to get this (and a few
other m32c bugs) resolved before the next release.
This seems to work, with a suitable extendhipsi2 pattern for m32c:
Index: expr.c
===
--- expr.c
Hi,
with LTO getting closer it is obvious that IPA infrastructure needs work and
also is getting more interesting ;)
I don't think it makes sense to do all the work on LTO branch that
contains a lot of temporary stuff, so I've created pretty-ipa branch
that unlike LTO branch is targetted to merge
Great! Thanks for doing this. I would've offered using the LTO
branch, we have several patches that will be pushed out at the next
stage1. But if you prefer it this way, we can just import patches
from pretty-ipa.
Diego.
Hello
the file in bits/basic_string.tcc call it.
templatetypename _CharT, typename _Traits, typename _Alloc
template typename _InIterator
_CharT*
basic_string_CharT, _Traits, _Alloc::
_S_construct(_InIterator __beg, _InIterator __end, const _Alloc __a,
In the file target.c, I declare
SUBTARGET_OVERRIDE_OPTIONS to add more command options
for my target :
--
#ifndef SUBTARGET_OVERRIDE_OPTIONS
#define SUBTARGET_OVERRIDE_OPTIONS
#endif
#define OVERRIDE_OPTIONS
Hi Jeff,
create a GCC 4.5 pending patches PR and attach the updated patch to
that PR
Thanks a lot for your valuable suggestions and support.
GCC-4.5 pending patches PR is already created at the following link:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37515
The bug report
If all members of the union are const, why don't you just make the union
itself const?
class my_class_2
{
const union
{
int x;
int y;
};
my_class_2() : x(0) {}
};
--
René Bürgel
Software Engineer
Unicontrol Systemtechnik GmbH
OT Dittersbach
Sachsenburger Weg 34
09669
Hello
the file in bits/basic_string.tcc call it.
templatetypename _CharT, typename _Traits, typename _Alloc
template typename _InIterator
_CharT*
basic_string_CharT, _Traits, _Alloc::
_S_construct(_InIterator __beg, _InIterator __end, const _Alloc __a,
On 11/12/08, René Bürgel [EMAIL PROTECTED] wrote:
Mark Tall schrieb:
On 12/11/2008, René Bürgel [EMAIL PROTECTED] wrote:
If all members of the union are const, why don't you just
make the union itself const?
The const for the union seems to be ignored
I'd say, that's the real bug,
On Wed, Nov 12, 2008 at 12:53:54PM +1000, Mark Tall wrote:
Hello,
I've come across an oddity in C++, involving anonymous unions and
const variables. Neither of the two classes below will compile using
gcc 4.3.0. Is this a bug in gcc or the C++ standard itself ?
class my_class_1
{
On Tue, Nov 11, 2008 at 08:43:40PM -0800, James Dennett wrote:
(There are secondary uses of unions for type punning. Most such uses
are not valid portable C++, but g++ supports them because they're so
common in real code.)
On the contrary: the uses of unions for type-punning, while not
On Wed, Nov 12, 2008 at 10:40 AM, DJ Delorie [EMAIL PROTECTED] wrote:
Ping? Is this the right thing to do? I'd like to get this (and a few
other m32c bugs) resolved before the next release.
I don't think this is a suitable general solution. Can you instead try the
attached which again tries
On Wed, Nov 12, 2008 at 11:29 AM, Joe Buck [EMAIL PROTECTED] wrote:
On Tue, Nov 11, 2008 at 08:43:40PM -0800, James Dennett wrote:
(There are secondary uses of unions for type punning. Most such uses
are not valid portable C++, but g++ supports them because they're so
common in real code.)
Mark Tall schrieb:
On 12/11/2008, René Bürgel [EMAIL PROTECTED] wrote:
If all members of the union are const, why don't you just make the union
itself const?
The const for the union seems to be ignored
I'd say, that's the real bug, at least from my point of view. I don't
know, if
On 12/11/2008, René Bürgel [EMAIL PROTECTED] wrote:
If all members of the union are const, why don't you just make the union
itself const?
The const for the union seems to be ignored (code below). The
original reason behind the union shenanigans was to provide a
compile-time alias to another
On 11/12/08, James Dennett [EMAIL PROTECTED] wrote:
On Wed, Nov 12, 2008 at 11:29 AM, Joe Buck [EMAIL PROTECTED] wrote:
On Tue, Nov 11, 2008 at 08:43:40PM -0800, James Dennett wrote:
(There are secondary uses of unions for type punning. Most such uses
are not valid portable C++, but g++
Snapshot gcc-4.2-20081112 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20081112/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hello, i have some problems with empty (almost) structures containing
zero-sized arrays:
struct Zero { int value[0]; };
int main() {
std::cout sizeof(Zero)== sizeof(Zero) '\n';
return 0;
}
The output i get for every g++ i compile it on is:
sizeof(Zero)==0
Because of that i can't, for
On Thu, Nov 13, 2008 at 12:23:16AM +0100, nadult wrote:
Hello, i have some problems with empty (almost) structures containing
zero-sized arrays:
struct Zero { int value[0]; };
int main() {
std::cout sizeof(Zero)== sizeof(Zero) '\n';
return 0;
}
The output i get for every g++
On Wed, Nov 12, 2008 at 03:52:01PM -0800, Joe Buck wrote:
On Thu, Nov 13, 2008 at 12:23:16AM +0100, nadult wrote:
Hello, i have some problems with empty (almost) structures containing
zero-sized arrays:
struct Zero { int value[0]; };
int main() {
std::cout sizeof(Zero)==
Ah, maybe I should say contributor.
Best regards,
Eric
2008/11/12 Manuel López-Ibáñez [EMAIL PROTECTED]:
2008/11/11 Eric Fisher [EMAIL PROTECTED]:
Hello,
Anyone could tell how to be a gcc maintainer? Is there any
requirement? Actually, my previous work are all not based on the gcc
trunk.
On Thu, Nov 13, 2008 at 09:27:32AM +0800, Eric Fisher wrote:
Ah, maybe I should say contributor.
See http://gcc.gnu.org/contribute.html
On Fri, 7 Nov 2008, Martin Jambor wrote:
From the logs I see that the testsuite probably uses a cross-compiled
gcc? How do you configure gcc to get such a beats?
See http://gcc.gnu.org/simtest-howto.html.
(Don't ever change anything in the hardlinked /combined tree,
though and don't try to
Oh yes, it's my mistake.
I've got some grammar mistake in my code, so it didn't
run.
Thank you .
--- Michael Meissner [EMAIL PROTECTED]
wrote:
On Wed, Nov 12, 2008 at 01:43:50AM -0800, Dong
Phuong wrote:
In the file target.c, I declare
SUBTARGET_OVERRIDE_OPTIONS to add more
I've declared some macros in my target description
file to add more attributes to it.
When I built it, everything was OK and file cc1.exe
was created.
But when I use attributes in my C source file. For
example :
int x __attribute__ ((model (small)));
and use file cc1.exe to compile, there
The darwin-specific gcc.dg/cpp/subframework1.c -fno-show-column test case
is failing under gcc trunk for the excessive errors test because we now
get warnings...
warning: #import is a deprecated GCC extension
Is there a particular way to modify an excessive errors test case to
have a
--- Comment #4 from jakub at gcc dot gnu dot org 2008-11-12 08:17 ---
Subject: Bug 35366
Author: jakub
Date: Wed Nov 12 08:16:12 2008
New Revision: 141782
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141782
Log:
PR target/35366
* expr.c
--- Comment #9 from jakub at gcc dot gnu dot org 2008-11-12 08:20 ---
Subject: Bug 35334
Author: jakub
Date: Wed Nov 12 08:18:45 2008
New Revision: 141783
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141783
Log:
PR c++/35334
* c-pretty-print.c
--- Comment #1 from jakub at gcc dot gnu dot org 2008-11-12 08:30 ---
I guess it should use
#define CAP_INFINITY (((HOST_WIDEST_INT) 1) (HOST_BITS_PER_WIDEST_INT - 1))
instead. gcov_type (and HOST_WIDEST_INT) can be long long, long or __int64.
--
--- Comment #11 from alon dot barlev at gmail dot com 2008-11-12 09:04
---
I get the error only if I use -O3.
But the two bugs are related.
Last checked rev#141779
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37955
--- Comment #1 from martin dot jansa at mk dot cvut dot cz 2008-11-12
10:04 ---
Created an attachment (id=16658)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16658action=view)
Preprocessed source with -O0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38090
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-12 14:27 ---
I have tested:
2008-11-12 Jakub Jelinek [EMAIL PROTECTED]
PR bootstrap/38088
* mcf.c (CAP_INFINITY): Use HOST_WIDE_INT maximum, not GCC specific
__LONG_LONG_MAX__.
--- gcc/mcf.c.jj
--- Comment #3 from froydnj at gcc dot gnu dot org 2008-11-12 14:32 ---
Fixed in 4.3.
--
froydnj at gcc dot gnu dot org changed:
What|Removed |Added
This is my system information,
FreeBSD cowboy.branda.to 8.0-CURRENT FreeBSD 8.0-CURRENT #7: Fri Oct 17
22:32:29 CST 2008 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/cowboy
i386
My configuration command is
../configure --prefix=/home/thinker/tmp/dest \
--target=bfin-unknown-elf
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-12 15:31 ---
Revision 141780 is the case.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|Internal compiler error: in
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
CC||hp at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #5 from marc dot glisse at normalesup dot org 2008-11-12 16:19
---
This is not a bug (see previous comments).
--
marc dot glisse at normalesup dot org changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2008-11-12 16:30 ---
The testcase compiles OK with
GNU C (GCC) version 4.4.0 20081112 (experimental) [trunk revision 141785]
(x86_64-unknown-linux-gnu)
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #8 from marc dot glisse at normalesup dot org 2008-11-12 16:30
---
The comments already say this bug is a duplicate (of a now fixed bug), I am
just marking it for cleanup. Hope that is the right thing to do...
*** This bug has been marked as a duplicate of 27843 ***
--
--- Comment #12 from marc dot glisse at normalesup dot org 2008-11-12
16:30 ---
*** Bug 30083 has been marked as a duplicate of this bug. ***
--
marc dot glisse at normalesup dot org changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-12 17:03 ---
Subject: Bug 35366
Author: jakub
Date: Wed Nov 12 17:01:51 2008
New Revision: 141790
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141790
Log:
PR target/35366
PR fortran/33759
*
--- Comment #15 from jakub at gcc dot gnu dot org 2008-11-12 17:03 ---
Subject: Bug 33759
Author: jakub
Date: Wed Nov 12 17:01:51 2008
New Revision: 141790
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141790
Log:
PR target/35366
PR fortran/33759
*
--- Comment #5 from paolo at gcc dot gnu dot org 2008-11-12 10:00 ---
Subject: Bug 37986
Author: paolo
Date: Wed Nov 12 09:59:27 2008
New Revision: 141784
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141784
Log:
2008-11-12 Paolo Carlini [EMAIL PROTECTED]
PR
On Linux/ia32, revision 141781 gave
FAIL: gfortran.dg/private_type_4.f90 -O (test for errors, line 14)
--
Summary: gfortran.dg/private_type_4.f90 -O doesn't work
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-12
17:14 ---
Subject: Re: [4.4 Regression] FAIL: 26_numerics/complex/13450.cc: ICE in
verify_gimple_expr, at tree-cfg.c:3962
Created an attachment (id=16650)
--
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-12 10:42 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Hi,
H8SX target supports generation of bit instructions in memory addressing mode.
However, these instructions are not getting generated and the bits in memory
are operated using other instructions which consume more memory. The
attached patch h8sx.patch generates these bit instructions and
--- Comment #1 from prafullat at kpitcummins dot com 2008-11-12 10:09
---
Created an attachment (id=16660)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16660action=view)
Patch for bit insn enhancement
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38091
--- Comment #2 from dominiq at lps dot ens dot fr 2008-11-12 16:12 ---
With the patch for pr38065, compiling gfortran.dg/private_type_4.f90 without
-std=f95 does not return the expected error:
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/private_type_4.f90:14.24:
type(t1)
Trying to build libstdc++ on Solaris 11/SPARC with GNU ld 2.19 and Sun as fails
compiling src/compatibility.cc:
libtool: compile: /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/xgcc
-shared-libgcc -B/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc
-nostdinc++
--- Comment #5 from paolo dot carlini at oracle dot com 2008-11-12 10:12
---
May be related to libstdc++/38000...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2008-11-12 17:35 ---
Subject: Bug 34269
Author: jakub
Date: Wed Nov 12 17:33:48 2008
New Revision: 141793
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141793
Log:
PR c++/34269
* parser.c
--- Comment #14 from janis at gcc dot gnu dot org 2008-11-12 17:48 ---
Subject: Bug 37202
Author: janis
Date: Wed Nov 12 17:47:13 2008
New Revision: 141794
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141794
Log:
2008-11-12 Jack Howarth [EMAIL PROTECTED]
PR
--- Comment #2 from janis at gcc dot gnu dot org 2008-11-12 17:53 ---
Subject: Bug 38008
Author: janis
Date: Wed Nov 12 17:52:24 2008
New Revision: 141795
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141795
Log:
2008-11-12 Jack Howarth [EMAIL PROTECTED]
PR
Hmm, shouldn't the preprocessor just mark the include as a duplicate?
Sent from my iPhone
On Nov 12, 2008, at 8:50 AM, paolo dot carlini at oracle dot com [EMAIL PROTECTED]
wrote:
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gmail dot com 2008-11-12 18:01 ---
Subject: Re: [4.3/4.4 Regression] System header files not found once -isystem
/usr/include is used
Hmm, shouldn't the preprocessor just mark the include as a duplicate?
Sent from my iPhone
On Nov 12, 2008, at 8:50
Hello,
with gcc-4.4 from trunk (tested on revisions 140300 and 141769) I get internal
error while building kernel from git.
It happen after this commit to linux-2.6.git tree
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d6c88a507ef0b6afdb013cba4e7804ba7324d99a
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-12 12:38 ---
Fixed, either of the patch is sufficient to fix it, though the other patch is
still highly desirable.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-12 18:39 ---
Subject: Bug 38094
Author: burnus
Date: Wed Nov 12 18:38:08 2008
New Revision: 141798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141798
Log:
2008-11-12 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #14 from burnus at gcc dot gnu dot org 2008-11-12 18:39 ---
Subject: Bug 38065
Author: burnus
Date: Wed Nov 12 18:38:08 2008
New Revision: 141798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141798
Log:
2008-11-12 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #3 from mrs at apple dot com 2008-11-12 18:33 ---
I'm merely eching bits from the clang development list... Now they think the
above doesn't apply, but 3.4.5p3 does:
3 If the unquali#64257;ed-id is
#8764; type-name, the type-name is looked up in the context of the entire
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-12 18:46 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
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 #4 from martin dot jansa at mk dot cvut dot cz 2008-11-12
19:46 ---
(In reply to comment #3)
The testcase compiles OK with
GNU C (GCC) version 4.4.0 20081112 (experimental) [trunk revision 141785]
(x86_64-unknown-linux-gnu)
Confirmed, fixed between 141769 and 141785
--- Comment #2 from martin dot jansa at mk dot cvut dot cz 2008-11-12
10:05 ---
Created an attachment (id=16659)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16659action=view)
Preprocessed source with -O1
Created with:
gcc-4.4.0-pre -O1 -D__KERNEL__ -Iinclude
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-12 20:27 ---
While gfortran should not ICE, I'd be interested in knowing if
this code compiles with any other compiler. (Hint: remove
elemental from trim_append).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
--- Comment #2 from kargl at gcc dot gnu dot org 2008-11-12 20:29 ---
Add ice-on-invalid-code to keywords.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2008-11-12 20:39 ---
Whoop, it is valid Fortran 2003. I forgot that
Lahey's checker does not understand the F2003
array syntax.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jason at gcc dot gnu dot org 2008-11-12 20:52 ---
Subject: Bug 38007
Author: jason
Date: Wed Nov 12 20:50:45 2008
New Revision: 141800
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141800
Log:
PR c++/38007
/*
% gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /usr/local/gcc-4.4-20081107/src/gcc-4.4-20081107/configure
--enable-languages=c,c++,fortran,java
--with-gmp=/usr/local/gmp-4.2.3/x86_64-Linux-fc8-core2-gcc-4.3.1
--- Comment #5 from dominiq at lps dot ens dot fr 2008-11-12 21:02 ---
The test is still failing, now with two failures. One is due to the mismatch
between the expected error: cannot be of PRIVATE type and the actual one
Fortran 2003: PUBLIC variable 'f1' at (1) of PRIVATE derived type
--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-12 21:04 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #4 from dominiq at lps dot ens dot fr 2008-11-12 21:09 ---
Whoop, it is valid Fortran 2003. I forgot that
Lahey's checker does not understand the F2003 array syntax.
I was about to say that the code is compiled by ifort and g95.
--
--- Comment #6 from hp at gcc dot gnu dot org 2008-11-12 21:22 ---
No, NOT FIXED.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #7 from hp at gcc dot gnu dot org 2008-11-12 21:25 ---
(In reply to comment #6)
No, NOT FIXED.
At least not at 141791, though I see related changes for 141798 that might have
fixed it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
--- Comment #1 from ubizjak at gmail dot com 2008-11-12 21:29 ---
The paste of the ICE itself would be nice indeed:
pr38096.c: In function foo:
pr38096.c:13: internal compiler error: in vectorizable_store, at
tree-vect-transform.c:5447
Please submit a full bug report,
with
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-12 21:30 ---
Revision 141798 gave:
FAIL: gfortran.dg/private_type_4.f90 -O (test for errors, line 17)
FAIL: gfortran.dg/private_type_4.f90 -O (test for excess errors)
--
--- Comment #9 from dominiq at lps dot ens dot fr 2008-11-12 21:31 ---
Revision 141798 gave:
see comment #5. I have forgotten to give the revision: it was r141798.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
--- Comment #2 from ubizjak at gmail dot com 2008-11-12 21:31 ---
*** This bug has been marked as a duplicate of 37955 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #12 from ubizjak at gmail dot com 2008-11-12 21:31 ---
*** Bug 38096 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from janis at gcc dot gnu dot org 2008-11-12 21:35 ---
Subject: Bug 38010
Author: janis
Date: Wed Nov 12 21:33:34 2008
New Revision: 141803
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141803
Log:
2008-11-12 Jack Howarth [EMAIL PROTECTED]
PR
--- Comment #4 from irar at gcc dot gnu dot org 2008-11-12 10:37 ---
Subject: Bug 38079
Author: irar
Date: Wed Nov 12 10:36:03 2008
New Revision: 141785
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141785
Log:
PR tree-optimization/38079
* tree-vect-analyze.c
Compiling
module bar
implicit none
contains
!
elemental function trim_append(xx,yy) result(xy)
character (len=*), intent(in) :: xx,yy
character (len=len(xx) + len(yy)) :: xy
xy = trim(xx) // yy
end function trim_append
!
function same(xx) result(yy)
character (len=*), intent(in) :: xx(:)
--- Comment #30 from sje at gcc dot gnu dot org 2008-11-12 21:37 ---
Subject: Bug 27880
Author: sje
Date: Wed Nov 12 21:35:46 2008
New Revision: 141804
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141804
Log:
PR target/27880
* config/unwind_ipinfo.m4
--- Comment #6 from paolo dot carlini at oracle dot com 2008-11-12 10:02
---
Fixed again.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #31 from sje at gcc dot gnu dot org 2008-11-12 21:38 ---
Subject: Bug 27880
Author: sje
Date: Wed Nov 12 21:37:34 2008
New Revision: 141805
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141805
Log:
PR target/27880
* configure.ac
--- Comment #25 from dodji at gcc dot gnu dot org 2008-11-12 21:59 ---
Subject: Bug 27574
Author: dodji
Date: Wed Nov 12 21:57:44 2008
New Revision: 141807
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141807
Log:
gcc/ChangeLog:
2008-11-12 Dodji Seketeli [EMAIL PROTECTED]
--- Comment #2 from kamaraju at gmail dot com 2008-11-12 13:49 ---
Andrew (http://gcc.gnu.org/ml/gcc-help/2008-11/msg00131.html) suggested to use
#define CAP_INFINITY INTTYPE_MAXIMUM(HOST_WIDEST_INT)
I tried it out. The mcf.c compiles with this modification.
--
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-12 22:08 ---
I see gcc-testresults for this target posted in:
http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg00649.html
Was this with -fno-ira or is this bug gone?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37422
--- Comment #5 from jason at gcc dot gnu dot org 2008-11-12 22:09 ---
Subject: Bug 38007
Author: jason
Date: Wed Nov 12 22:08:01 2008
New Revision: 141808
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141808
Log:
PR c++/38007
--- Comment #5 from vivekrao4 at yahoo dot com 2008-11-12 22:12 ---
(In reply to comment #4)
Whoop, it is valid Fortran 2003. I forgot that
Lahey's checker does not understand the F2003 array syntax.
I was about to say that the code is compiled by ifort and g95.
I hope someone
--- Comment #6 from jason at gcc dot gnu dot org 2008-11-12 22:14 ---
Subject: Bug 38007
Author: jason
Date: Wed Nov 12 22:13:26 2008
New Revision: 141809
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141809
Log:
PR c++/38007
--- Comment #7 from jason at gcc dot gnu dot org 2008-11-12 22:15 ---
Fixed on all open branches.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #7 from jakub at gcc dot gnu dot org 2008-11-12 22:19 ---
Subject: Bug 36478
Author: jakub
Date: Wed Nov 12 22:18:03 2008
New Revision: 141810
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141810
Log:
PR c++/36478
Revert:
2007-05-07 Mike
1 - 100 of 125 matches
Mail list logo
