The test still fails at -O2 -gnato... All the current FAIL
still fail with -gnato, and we even have two additional failures
(unexpected constraint_error):
c45532e
c45532g
So we have to look carefully at what the front-end does with modular
types here.
Note that cxa4025, cxa4028, cxa4033 are
Comments? I'm of course also volunteering to write the patch, provided that
an adept at the new bootstrap (black) magic gives me a clue as to where I
should start. :-)
You just have to write the test in the toplevel configure.in, and place
it just before the AC_SUBST(stage1_cflags).
The
On 02 March 2006 00:02, Mike Stump wrote:
On Mar 1, 2006, at 3:47 AM, HASSAN AL MOATASSIME wrote:
I have a problem with the compiler gcc 3.4.4.
With the gcc 3.2 compiler, i have no problem with the following
instruction : creal(U0[i])=PartieReelle;
Hi! Is it possible to receive only special trees from -fdump-tree-{all-raw}?
I only need original, generic and gimple. Is there a description about the
generic-file somewhere? I read
http://zenii.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf but it's
not enough yet.
Thank you very much in
it's not a bug, -gnato is clearly documented as required in this
case, what makes you think otherwise?
Laurent's message.
Sorry about that, -gnato indeed has always been specified for this test.
--
Eric Botcazou
# BLOCK 6
# PRED: 4 (false,exec)
L1:;
iftmp.78_63 = D.1309_32;
iftmp.78_64 = D.1309_32;
D.1316_65 = (c460008__unsigned_edge_8) D.1309_32;
if (D.1316_65 == 255) goto L3; else goto L4;
# SUCC: 7 (true,exec) 8 (false,exec)
[...]
The problem (of course) is D.1316_65 can and
Hi,
On 2006-03-01 08:43:46 +0100, Maurizio Loreti wrote:
/usr/soft/lib/libmpfr.a and /usr/soft/lib/libgmp.a are from gmp 4.1.4
The MPFR version distributed with GMP 4.1.4 is old, very buggy, and
no longer maintained. It is highly recommended to compile GMP without
MPFR support and compile the
Excerpt from utils2.c:
/* Likewise, but only return types known to the Ada source. */
tree
get_ada_base_type (tree type)
{
while (TREE_TYPE (type)
(TREE_CODE (type) == INTEGER_TYPE
|| TREE_CODE (type) == REAL_TYPE)
!TYPE_EXTRA_SUBTYPE_P (type))
type =
Hi there,
Nobody seems to know about this in gcc-help, so, there I go:
Forwarded Message
From: David Fernandez [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: i686 architecture behaviour in gcc
Date: Tue, 21 Feb 2006 17:08:32 +
Hi there,
On 2006-03-01 14:51:45 -0800, H. J. Lu wrote:
Here are diffs of -O2 -mtune=nocona -ffast-math vs
-O2 -mtune=generic -ffast-math on Nocona:
[...]
Optimization is much less important than correct results. From
this point of view, I don't think that using an option known to
produce incorrect
With this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01877.html
gcc no longer mixes SSE and x387 math by default. However glibc
still assumes gcc mixes SSE and x387 math. The x86-64 FP control
routines in glibc change both SSE and x387 units, which is no
longer necessary with the newer
On 3/2/06, H. J. Lu [EMAIL PROTECTED] wrote:
With this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01877.html
gcc no longer mixes SSE and x387 math by default. However glibc
still assumes gcc mixes SSE and x387 math. The x86-64 FP control
routines in glibc change both SSE and x387
On Thu, Mar 02, 2006 at 04:08:54PM +0100, Richard Guenther wrote:
On 3/2/06, H. J. Lu [EMAIL PROTECTED] wrote:
With this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01877.html
gcc no longer mixes SSE and x387 math by default. However glibc
still assumes gcc mixes SSE and x387
Hi all,
I am trying to build/install gcc-4.1.0 on my Linux box (RHEL-3), in a
non-standard prefix.
I use -with-libiconv-prefix the tell configure where to find libiconv,
and the configure step works.
The build step fails in libcpp:
/apa/gnu/Linux-RH-WS-3/gcc/gcc-3.4.4/bin/gcc -O2
On 3/2/06, H. J. Lu [EMAIL PROTECTED] wrote:
On Thu, Mar 02, 2006 at 04:08:54PM +0100, Richard Guenther wrote:
On 3/2/06, H. J. Lu [EMAIL PROTECTED] wrote:
With this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01877.html
gcc no longer mixes SSE and x387 math by default.
On Thu, Mar 02, 2006 at 04:34:09PM +0100, Richard Guenther wrote:
On 3/2/06, H. J. Lu [EMAIL PROTECTED] wrote:
On Thu, Mar 02, 2006 at 04:08:54PM +0100, Richard Guenther wrote:
On 3/2/06, H. J. Lu [EMAIL PROTECTED] wrote:
With this patch:
On Thu, Mar 02, 2006 at 07:38:47AM -0800, H. J. Lu wrote:
Yes. That is for float and double functions in libm.
to touch x387
flags for XFmode long long operations.
I assume you meant long double. If the library knows it doesn't long
double, it doesn't need to touch x87 unit control.
On Thu, Mar 02, 2006 at 04:44:50PM +0100, Jakub Jelinek wrote:
On Thu, Mar 02, 2006 at 07:38:47AM -0800, H. J. Lu wrote:
Yes. That is for float and double functions in libm.
to touch x387
flags for XFmode long long operations.
I assume you meant long double. If the library knows
On 3/2/06, H. J. Lu [EMAIL PROTECTED] wrote:
On Thu, Mar 02, 2006 at 04:44:50PM +0100, Jakub Jelinek wrote:
On Thu, Mar 02, 2006 at 07:38:47AM -0800, H. J. Lu wrote:
Yes. That is for float and double functions in libm.
to touch x387
flags for XFmode long long operations.
I
On Thu, Mar 02, 2006 at 05:19:20PM +0100, Richard Guenther wrote:
On 3/2/06, H. J. Lu [EMAIL PROTECTED] wrote:
On Thu, Mar 02, 2006 at 04:44:50PM +0100, Jakub Jelinek wrote:
On Thu, Mar 02, 2006 at 07:38:47AM -0800, H. J. Lu wrote:
Yes. That is for float and double functions in libm.
Hello,
There is a wikibook that describes the internals of GCC and GEM, an
extensibility framework.
http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals
GEM allows programmers to write extensions to GNU C. We will submit the
framework as a GCC patch. Please give us feedback on the
This change:
2006-02-17 Roger Sayle [EMAIL PROTECTED]
PR middle-end/25600
* fold-const.c (fold_binary): Fold (X C) != 0 into X 0 when
C is one less than the width of X (and related transformations).
* simplify-rtx.c (simplify_unary_operation_1): Transform
On Thu, 2006-03-02 at 14:05 +0100, Eric Botcazou wrote:
# BLOCK 6
# PRED: 4 (false,exec)
L1:;
iftmp.78_63 = D.1309_32;
iftmp.78_64 = D.1309_32;
D.1316_65 = (c460008__unsigned_edge_8) D.1309_32;
if (D.1316_65 == 255) goto L3; else goto L4;
# SUCC: 7 (true,exec) 8
Just to be 100% clear, I'm leaving this one in the hands of the
Ada maintainers. I'm not qualified to fix it.
Right.
We're also still need the uintp fix installed. I'm not qualified to
say if Kenner's fix is correct or not, thus I'm not comfortable
checking in that
Just to be 100% clear, I'm leaving this one in the hands of the
Ada maintainers. I'm not qualified to fix it. Once the Ada
maintainers have this issue fixed, I'll re-run the Ada testsuite
and attack the next regression introduced by the VRP changes
(if any are left).
Sure. My message was
On Thu, 2 Mar 2006, Jeffrey A Law wrote:
Is causing 961206-1.c to regress at -O1 and -O2 on i686-pc-linux-gnu
and possibly other platforms.
Doh! This doesn't fail on x86_64-unknown-linux-gnu, where I developed
that patch, but I am now seeing those failures on i686-pc-linux-gnu.
OUCH.
On Thu, 2006-03-02 at 12:35 -0700, Roger Sayle wrote:
Sorry for the breakage. I'll have a fix before the sun goes down,
that performs the shift in the correct mode, then appropriately
sign extends, zero extends or truncates if necessary.
Many thanks for analyzing this failure. Sorry
On Thu, 2006-03-02 at 14:04 +0100, Eric Botcazou wrote:
it's not a bug, -gnato is clearly documented as required in this
case, what makes you think otherwise?
Laurent's message.
I missed the fact that the test was already in overflow.lst :)
Laurent
On Thu, 2006-03-02 at 01:34 +0100, Robert Dewar wrote:
Laurent GUERBY wrote:
VRP might now force us to update the overflow list but I'm not sure
about switching to a full -gnato everywhere.
well you can expect some fiddling each version if you work this way
The list for -gnato tests
I missed the fact that the test was already in overflow.lst :)
No worries, so did I. :-)
--
Eric Botcazou
Roman Belenov wrote:
David Edelsohn [EMAIL PROTECTED] writes:
Upgrading GNU tar to 1.15.1 fixed the problem for me.
So what is the actual requirement - 1.14 or 1.14 or above ?
The latter.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Snapshot gcc-4.0-20060302 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060302/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hello,
I am building a generic installation program for GNU
coding standards-compliant packages.
http://www.gnu.org/software/sourceinstall/
I am also helping all GNU projects with a
non-compliant build system make the move to the GNU
coding standards, with patches and support.
I have a problem
Jan Wegner wrote:
Hi! Is it possible to receive only special trees from -fdump-tree-{all-raw}?
Try reading the docs for the -fdump-tree-* options. You can choose
which dump files are created by using the appropriate option.
I only need original, generic and gimple. Is there a description
On Mar 2, 2006, at 7:23 PM, Claudio Fontana wrote:
The problem is that, while an user can read a message
like:
configure: error: you must configure in a separate
build directory
This is a bug only in the 4.0.x series of GCC and nowhere else.
-- Pinski
On Thu, Mar 02, 2006 at 04:23:42PM -0800, Claudio Fontana wrote:
I am building a generic installation program for GNU
coding standards-compliant packages.
http://www.gnu.org/software/sourceinstall/
I have a problem with current builddir != srcdir
requirement in glibc and recent versions of
Yoav Etsion wrote:
I'm designing a new hardware that needs to know which GPR contains a
simple integer, and which contained pointer. The hardware simply needs
different load operations for both (we're talking load/store machines,
with no indirect addressing to make life easier).
You can try
David Fernandez wrote:
Can anyone explain why has been chosen that -march=i686 makes the
compiler change the normal behaviour, and zero-expand unsigned short
parameters into 32-bit registers by all means?
You failed to mention the gcc version, and your testcase doesn't
actually use
Hello Andrew,
thanks for your answer.
--- Andrew Pinski [EMAIL PROTECTED] ha scritto:
On Mar 2, 2006, at 7:23 PM, Claudio Fontana wrote:
The problem is that, while an user can read a
message
like:
configure: error: you must configure in a separate
build directory
This is a bug
Hi,
I've ported gcc to mytarget-linux version. The object file compiled
now are shared one. My current simulator is able to run static
executable program and just translate binary code one by one. I know
shared file needs dynamic linker to load. So I'd like to know can I
run shared file on my sim?
We are pleased to announce the availability of GCC for SPARC (R) Systems
(GCCfss) at http://cooltools.sunsource.net/gcc/
GCCfss extends GCC to be able to use
the optimizing Sun(tm) Code Generator for SPARC systems (SCGfss).
We encourage you to download it and try it.
The compiler commands are
Current mainline gcc appears to miscompile FFTW:
wget http://fftw.org/fftw-3.1.tar.gz
tar xvzf fftw-3.1.tar.gz
cd fftw-3.1
/scratch/fftw-3.1 gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/gcc/configure --quiet
--prefix=/afs/mpa/data/martin/ugcc
--- Comment #17 from mattias at virtutech dot se 2006-03-02 09:22 ---
We have resorted to case-by-case workarounds, usually a cast which would have
been an identity operation had the condition been true. That is,
if (sizeof x == 8)
return x 32 | x;
would have its second line
--- Comment #3 from wielemak at science dot uva dot nl 2006-03-02 09:24
---
Andrew,
If you think this is a real and still present bug I could try to add a
little main() to the file and turn the file into a stand-alone program.
I guess it is pretty likely it depends on nasty details in
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2006-03-02 09:37
---
(In reply to comment #17)
For i=3 or greater, gfortran and ifort agree on the value of b. However, for
the above, gfortran now gives 0, whilst ifort gives 1. I happen to think that
0 makes more sense
--- Comment #4 from wielemak at science dot uva dot nl 2006-03-02 10:08
---
Oops, must be ./configure --enable-mt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26511
--- Comment #2 from pcarlini at suse dot de 2006-03-02 10:24 ---
Benjamin, can you have a look? The issue seems simple, in its essence: on
64-bit machines the recently added __copy_streambufs export is wrong - in fact
we are not exporting anything - because it reads everywhere:
--- Comment #10 from aph at gcc dot gnu dot org 2006-03-02 10:31 ---
No, that patch doesn't help. Still get the same result at -O2:
[EMAIL PROTECTED] eclipse]$ /home/aph/gcc/install/bin/gcj -c -O2 -g -fPIC
-findirect-dispatch -fjni AbstractCommentParser.class
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org |
--- Comment #2 from bonzini at gnu dot org 2006-03-02 10:47 ---
Recategorizing to bootstrap since it is a build system bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26500
--- Comment #1 from martin at mpa-garching dot mpg dot de 2006-03-02 11:00
---
I just checked that
CFLAGS=-O3 ./configure --enable-portable-binary
fails, but
CFLAGS=-O3 ./configure --enable-portable-binary
works as it should.
--
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-03-02 11:01
---
(In reply to comment #1)
I just checked that
CFLAGS=-O3 ./configure --enable-portable-binary
fails, but
CFLAGS=-O3 ./configure --enable-portable-binary
Sorry for the typo here. I meant, of course,
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-02 12:15 ---
Do you have a simple testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
--- Comment #4 from martin at mpa-garching dot mpg dot de 2006-03-02 12:18
---
(In reply to comment #3)
Do you have a simple testcase?
I wish I had :(
At the moment I'm trying to find out which optimisation flags are causing the
trouble. The current minimum set of flags to reproduce
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-03-02 12:20
---
Subject: Bug 26291
Author: reichelt
Date: Thu Mar 2 12:20:52 2006
New Revision: 111637
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111637
Log:
PR c++/26291
* decl.c (grok_op_properties):
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-03-02 12:22
---
Now also fixed on the 4.1 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:29 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:37 ---
According to known to fail, it fails in 4.1.0 but Jim's comment suggest
otherwise, hmm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26330
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:53 ---
This still happens as of today.
with the C testcase from comment #1, we get:
Invalid sum of incoming frequencies 894, should be 9
L5:;
__builtin_abort ();
Invalid sum of incoming frequencies 9106, should be
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-02 12:57 ---
Confirmed. It's dom2 messing up.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-02 13:00 ---
4.1.0 has also after dom2:
Invalid sum of incoming frequencies 673, should be 21
L5:;
__builtin_abort ();
Invalid sum of incoming frequencies 9327, should be 9979
L6:;
return;
4.0.2 has even different
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-02 13:40 ---
(In reply to comment #4)
-O1 -ftree-vrp -finline-functions.
More to come...
Can you try -O3 -fwrapv? It might be the source have undefined code in it
for signed overflow and changes to VRP exposed it.
Also do
--- Comment #6 from martin at mpa-garching dot mpg dot de 2006-03-02 13:52
---
(In reply to comment #5)
Can you try -O3 -fwrapv? It might be the source have undefined code in it
for signed overflow and changes to VRP exposed it.
Bingo! Thanks for this hint, I wouldn't have found
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-02 14:00 ---
CCing Honza, maybe he knows the answer but I cannot find it in the ISA
documention.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dir at lanl dot gov 2006-03-02 14:02 ---
Hi Jerry,
As you may have guessed, I added this problem to the things that my program
looks for. You got that one and all the ones like it, but here is another one
from a slightly different class (rewind after reading
--- Comment #6 from brett dot albertson at stratech dot com 2006-03-02
14:15 ---
(In reply to comment #5)
A real patch for 4.2 is posted at
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00094.html
I can confirm that this patch allows me to bootstrap again. I'm running the
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-03-02 14:15
---
*** This bug has been marked as a duplicate of 26053 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-03-02 14:15
---
*** Bug 24345 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-02 14:21
---
(In reply to comment #9)
Acutally f3 is not fixed but I don't understand how not.
No f3 is fine, f4 is broken still.
*p = (int) *p != -1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18908
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-02 14:24 ---
This is interesting, we now get BIT_FIELD_REF.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
--- Comment #3 from randolph at tausq dot org 2006-03-02 14:27 ---
Subject: Re: gcc generates code that does not allow retrieval
of struct arguments with debugger
pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:37
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-debug
Known to fail|4.0.3 4.1.0 |4.0.3
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-03-02 14:29
---
(In reply to comment #6)
If I understand correctly, this is most likely a bug in FFTW, right? If so,
I'll report it to FFTW people.
On the other hand, gcc 4.1 also has VRP, but it seems to work fine. Has
--- Comment #4 from pluto at agmk dot net 2006-03-02 14:32 ---
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf
page 33:
[ Zero-Extension of 32-Bit Results. ]
(...) when performing 32-bit operations with a GPR destination
in 64-bit mode, the processor
--- Comment #5 from jakub at gcc dot gnu dot org 2006-03-02 14:48 ---
(define_insn *movdi_xor_rex64
[(set (match_operand:DI 0 register_operand =r)
(match_operand:DI 1 const0_operand i))
(clobber (reg:CC FLAGS_REG))]
TARGET_64BIT (!TARGET_USE_MOV0 || optimize_size)
--- Comment #5 from luiscasinhas at mail dot telepac dot pt 2006-03-02
15:03 ---
Sure! Please feel free to change the current bug status to whatever status you
may see fit.
Best regards
--
luiscasinhas at mail dot telepac dot pt changed:
What|Removed
--- Comment #3 from bjkeen at super dot org 2006-03-02 16:03 ---
Created an attachment (id=10956)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10956action=view)
compute_frame_pointer_to_cfa_displacement internal error source trigger
--
When moving from gcc 3.4.3 to 4.1.0, I found a record definition, that causes a
compiler crash:
4.1.0 (i686-pc-linux-gnu) in get_memory_rtx, at builtins.c:1086
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380
The compiler has been compiled from source without any special settings, i.e.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-02 16:04 ---
Fixed for 4.2.0 by enabling of toplevel bootstrap.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from bjkeen at super dot org 2006-03-02 16:06 ---
I have this same problem, only with Fedora Core 2/x86, building the
cross-compiler for AVR as well. gcc4.1 and gcc 4.03 both stop with this error.
I have attached the preprocessed source file resulting from the following
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-02 16:10 ---
(In reply to comment #7)
On the other hand, gcc 4.1 also has VRP, but it seems to work fine. Has VRP
become more aggressive, or might it have a new bug?
VRP has become more aggressive or it might be still a bug.
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-02 16:10 ---
aermod of Polyhedron has the same problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 16:12 ---
gcc_assert (! DECL_BIT_FIELD (field));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26529
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 16:19 ---
__builtin_memcpy (_init-protocol_characteristics.F, T52s.F, 30);
Reduced testcase:
package DATA is
type UNSIGNED_8 is new INTEGER range 0 .. (2 ** 8) - 1;
for UNSIGNED_8'SIZE use 8;
type
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-02 16:27 ---
This also happens on the 4.1 branch too, I did not notice it until today.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following code will segfault when saying:
g++ -Os test.cpp -o test ./test
but not with any other -O? options such as
g++ -O3 test.cpp -o test ./test
preprocessed source:
# 1 test.cpp
# 1 built-in
# 1 command line
# 1 test.cpp
int main()
{
try{
throw 8;
}catch(...){}
}
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 16:32 ---
This works in 4.1.0 and above. Closing as fixed since this is not a
regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2006-03-02 17:47 ---
Not being able to use the HP assembler is definitely not a GCC bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26508
Given the following code:
BEGIN CODE
template typename A, typename B
class SomeClass
{
};
#define MYMACRO(BLOCK) \
{ \
BLOCK\
} \
int
main(void)
{
MYMACRO({
SomeClassint,int test;
});
}
END CODE
gcc (3.3.5
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 18:27 ---
This is not a bug.
There are two arguments passed to the macro MYMACRO, {\nSomeClassint and
int test;\n }.
the only way to force an argument passed to the preprocessor macros is to wrap
them in parentheses.
Martin Sebor wrote:
Andrew Pinski wrote:
On Mar 1, 2006, at 7:48 PM, Martin Sebor wrote:
Is there a recommended version of GNU binutils for 4.1? I have been
using 2.13 but the latest compiler doesn't seem to be happy with it.
I tried the latest, 2.16.1, but I get the same error with it as
--- Comment #6 from janis at gcc dot gnu dot org 2006-03-02 19:10 ---
The test case starts passing on mainline with this patch:
http://gcc.gnu.org/viewcvs?view=revrev=109088
r109088 | sayle | 2005-12-27 23:27:34 + (Tue, 27 Dec 2005) | 11 lines
* fold-const.c
From
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00084.html
there are
=== libmudflap tests ===
Running target unix
FAIL: libmudflap.c++/pass41-frag.cxx (test for excess errors)
WARNING: libmudflap.c++/pass41-frag.cxx compilation failed to produce
executable
FAIL:
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-03-02 19:44
---
I said:
I'm considering adding equivalent code to varasm.c. This will fix
an inconsistency in the handling of zero-sized decls: sometimes
they get a byte of storage allocated to them (giving them a unique
--- Comment #5 from wilbur dot harvey at spirentcom dot com 2006-03-02
20:01 ---
Subject: Re: compute_frame_pointer_to_cfa_displacement
erro r for avr target with --with-dwarf2
I gave up and deleted everything related.
I will see if I can re-create the environment again.
Wilbur
--- Comment #6 from eric-gcc at omnifarious dot org 2006-03-02 20:25
---
I'm pleased that I came up with such a difficult test case for the optimizer.
I never thought it'd be that hard. :-)
I don't know anything about the internals, but...
The compiler has to generate everything
This is probably pretty dodgy C code, but I
find it strange that program foo.c compiles
while program bar.c gives an error. Is this
a bug?
--- foo.c --
#include stdio.h
int main()
{
int ii;
ii = 276;
void *vv = (void *)ii;
}
--- foo.c --
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 21:14 ---
The first one is ok C even though it is not OK C89 but it is fine C99.
The second one is not ok C at all, since you are deferencing a void pointer.
--
pinskia at gcc dot gnu dot org changed:
What
#include stdio.h
struct X
{
unsigned a:4;
};
int main()
{
struct X x = { 63u };
printf(%u\n, x.a);
return 0;
}
// end.
result:
g++bug.cpp; ./a
15
g++ -O bug.cpp; ./a
63
wrong result!!
--
Summary: bitfield wrong optimize
Product: gcc
Version:
1 - 100 of 133 matches
Mail list logo
