--- Comment #14 from ubizjak at gmail dot com 2007-08-23 08:33 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01513.html.
This is target-only patch that fakes fcomi instructions. It doesn't need to
rescan insn stream and creates the same output as in Comment #8. It also
doesn
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-23 08:56 ---
Indeed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33154
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-23 09:33 ---
IIRC # processing happens first before string concatenation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33156
Hi GCC people,
the following code gives me a warning when compiling
(on an IA32 host).
~/c/tests 37> cat intptr.cpp
#include "stdint.h"
#include "stdlib.h"
int main(void)
{
intptr_t t = 0;
if (t != ((intptr_t)NULL)) t = 1;
return 0;
}
lnxsodt25 ~/c/tests 38> g++ --version
g++ (GCC) 4.2.
--- Comment #10 from bonzini at gnu dot org 2007-08-23 10:18 ---
fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32557
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-23 10:22
---
Subject: Bug 33095
Author: fxcoudert
Date: Thu Aug 23 10:22:18 2007
New Revision: 127732
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127732
Log:
PR fortran/33095
* trans-intrinsic.c (g
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-23 10:22
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
The failure was not detected because of an incorrect scan-assembler pattern.
--
Summary: [4.3 Regression] cmov4.c fails on i686
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
In gcc.target/i386/cmov4.c no store sinking is performed for this code
for (i = 0; i < ARCHnodes; i++) {
nodekind[i] = (int) nodekindf[i];
if (nodekind[i] == 3)
nodekind[i] = 1;
}
I would expect it to be rewritten as
for (i = 0; i < ARCHnodes; i++) {
int x = (int) nodekin
The testcase looks like this:
int *nodekind;
float *nodekindf;
...
for (i = 0; i < ARCHnodes; i++) {
nodekind[i] = (int) nodekindf[i]; /* <<< */
if (nodekind[i] == 3)
nodekind[i] = 1;
}
In the marked statement, the nodekind variable gets a new VDEF, which is wrong:
D.2012_
--
bonzini at gnu dot org changed:
What|Removed |Added
BugsThisDependsOn|33159 |
Status|UNCONFIRMED |NEW
Ever Confirmed|0
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|000
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||i?86-*-*
Target Milestone|--- |4.3.0
http
typedef int __attribute__((mode(pointer))) intptr_t;
int main(void)
{
intptr_t t = 0;
if (t != ((intptr_t)__null)) t = 1;
return 0;
}
sss.cc: In function 'int main()':
sss.cc:5: warning: NULL used in arithmetic
--
Summary: wrong "NULL used in arithmetic" warning
Product
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail|
--- Comment #6 from tbptbp at gmail dot com 2007-08-23 11:01 ---
(In reply to comment #5)
> Fixed.
Please fix the extension documentation accordingly.
--
tbptbp at gmail dot com changed:
What|Removed |Added
-
Compiling the following program, with "g++ A.cpp" fails to link
with the following error message :
/tmp/ccehheUK.o:(.rodata+0x0): undefined reference to `A::x'
collect2: ld returned 1 exit status
struct A {
static const int x = 0;
};
const int & i = A::x;
int main() {
--- Comment #16 from jakub at gcc dot gnu dot org 2007-08-23 12:13 ---
But doesn't ipa_type_escape_field_does_not_clobber_p do what is documented?
At least for the uses in nonoverlapping_memrefs_p where
ipa_type_escape_field_does_not_clobber_p is always called on some field, first
argume
--- Comment #11 from rask at gcc dot gnu dot org 2007-08-23 12:18 ---
I don't know if it has been fixed on powerpc64-suse-linux-gnu yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32557
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-23 12:38 ---
Another testcase:
extern enum warn overflow;
int
foo (void)
{
return overflow;
}
Here 3.4.x silently compiled it and used SImode for the variable, eventhough
TYPE_SIZE on the enum warn type nor DECL_SIZE on overflow
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-08-23 12:42
---
Subject: Bug 32328
Author: rguenth
Date: Thu Aug 23 12:41:59 2007
New Revision: 127736
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127736
Log:
2007-08-23 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-08-23 12:43
---
The testcase is not fixed and you didn't add a testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-08-23 13:03
---
Subject: Bug 23138
Author: fxcoudert
Date: Thu Aug 23 13:03:35 2007
New Revision: 127739
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127739
Log:
PR libfortran/23138
* acinclude.m4 (LIB
--
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 #3 from danglin at gcc dot gnu dot org 2007-08-23 13:25 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #17 from dberlin at gcc dot gnu dot org 2007-08-23 13:45
---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On 23 Aug 2007 12:13:13 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #16 from jakub at
--- Comment #11 from dberlin at gcc dot gnu dot org 2007-08-23 13:45
---
It did not fail for me at the point i committed the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772
--- Comment #1 from dberlin at gcc dot gnu dot org 2007-08-23 13:48 ---
I'm not sure what you are talking about. Do you mean nodekindf?
Do you have a case i can compile on another platform?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33159
--- Comment #2 from bonzini at gnu dot org 2007-08-23 13:55 ---
The testcase is cross-platform (at least as far as this PR and PR33158 are
concerned).
Of the four VDEFs, only the ones for SMT.8 and ARCHnodes seem correct to me.
The "int" assignment should not cause aliasing for either
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-08-23 14:01 ---
Subject: Re: [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
On 23 Aug 2007 13:55:21 -, bonzini at gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #2 from bonzini at gnu dot org 2007-08-23
--- Comment #4 from bonzini at gnu dot org 2007-08-23 14:04 ---
Hmmm, a store into an "int *" could not touch nodekind itself, only a store
into an "int **" could.
Isn't SMT.8 the VDEF saying it could touch *the thing pointed to by nodekind*?
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #5 from dberlin at gcc dot gnu dot org 2007-08-23 14:05 ---
Subject: Re: [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
On 8/23/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On 23 Aug 2007 13:55:21 -, bonzini at gnu dot org
> <[EMAIL PROTECTED]> wrote:
> >
> >
Yes, you are right.
I wasn't thinking clearly
> --- Comment #4 from bonzini at gnu dot org 2007-08-23 14:04 ---
> Hmmm, a store into an "int *" could not touch nodekind itself, only a store
> into an "int **" could.
>
> Isn't SMT.8 the VDEF saying it could touch *the thing pointed to by n
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-08-23 14:09 ---
Subject: Re: [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
Yes, you are right.
I wasn't thinking clearly
> --- Comment #4 from bonzini at gnu dot org 2007-08-23 14:04 ---
> Hmmm, a store into an
--- Comment #9 from manu at gcc dot gnu dot org 2007-08-23 14:17 ---
(In reply to comment #8)
> Despite what I said before, for this particular case, we should never give a
> "is used" warning if the BB is not executed with 100% probability. Hmm, I'll
> check whether we can detect this.
--- Comment #15 from uros at gcc dot gnu dot org 2007-08-23 14:23 ---
Subject: Bug 17390
Author: uros
Date: Thu Aug 23 14:23:40 2007
New Revision: 127742
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127742
Log:
PR target/17390
* config/i386/i386.c (ix86_expand_
--- Comment #16 from ubizjak at gmail dot com 2007-08-23 14:26 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from bonzini at gnu dot org 2007-08-23 14:26 ---
-O does not enable strict-aliasing, invalid
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #8 from ubizjak at gmail dot com 2007-08-23 14:28 ---
(In reply to comment #7)
> Created an attachment (id=13911)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13911&action=view) [edit]
> Updated patch with test case a bug fix.
>
> I've added a test case of the changes
--- Comment #18 from jakub at redhat dot com 2007-08-23 14:49 ---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On Thu, Aug 23, 2007 at 01:45:11PM -, dberlin at dberlin dot org wrote:
> > If you take address of the whole struct rather than so
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-08-23 16:14
---
So, on the mainline we now generate wrong-code?!
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
Example:
print *, dcos(1.0)
print *, dcos(1d0)
gfortran treats them as it does with "cos()": Any kind of REAL is accepted.
However, DCOS is a specific name of COS which only accepts REAL(8).
The bug should be fixed such that the following works as well:
PROCEDURE(DCOS):: my1
PROCEDURE(COS) :
--- Comment #9 from dougkwan at google dot com 2007-08-23 16:32 ---
Subject: Re: [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
No, FALSE, `(), nil, #f, 0 :)
-Doug
23 Aug 2007 14:28:51 -, ubizjak at gmail dot com
<[EMAIL PROTECTED]>:
>
>
> --- Comment #8 fro
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-23 16:34 ---
*** This bug has been marked as a duplicate of 30745 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-23 16:34 ---
*** Bug 33161 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #19 from dberlin at gcc dot gnu dot org 2007-08-23 17:08
---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On 23 Aug 2007 14:49:43 -, jakub at redhat dot com
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #18 from jakub at redh
/usr/local/gcc-4.0.4/bin/h8300-elf-gcc -S -O3 -Wall -msx -fshort-enums
-fomit-frame-pointer -finline-functions -funroll-loops
-I/home/fgiovagnini/acts/bendia/test/include
-I/home/fgiovagnini/acts/bendia/system/include
/home/fgiovagnini/acts/bendia/test/source/library.c
/home/fgiovagnini/acts/bendia
--- Comment #1 from fabio dot giovagnini at aurion-tech dot com 2007-08-23
17:20 ---
const unsigned char Nib_to_Hex[16] =
{0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x41,0x42,0x43,0x44,0x45,0x46};
void ul_to_8_cifre(unsigned char vett[8],unsigned long a1)
{
/* LOCAL VARIABLES
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2007-08-23
17:24 ---
(In reply to comment #1)
> Huh? The warnings should be ok. What exact error are you getting because I
> don't see -Werror on the command line so the warnings should not be stoping
> the
> build?
Oops. I'
--- Comment #2 from igodard at pacbell dot net 2007-08-23 17:50 ---
Whether # is before or after string concatenation, string concatenation should
happen *sometime* and doesn't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33156
While writing a script to extract data from tm.texi, found the following markup
bugs:
TARGET_ASM_RELOC_RW_MASK needs return type
TARGET_CC_MODES_COMPATIBLE needs {} around return type
TARGET_CHECK_PCH_TARGET_FLAGS needs {} around return type
TARGET_DEFAULT_TARGET_FLAGS should be @deftypevr
TARGET_
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-23 18:27 ---
(In reply to comment #2)
> Whether # is before or after string concatenation, string concatenation should
> happen *sometime* and doesn't.
Huh? Stringification happens and turns #("a " "b") into "\"a \" \"b\"" so
t
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-23 18:31 ---
(In reply to comment #6)
> Please fix the extension documentation accordingly.
The documentation already says:
The operations behave like C++ valarrays. Addition is defined as the addition
of the corresponding eleme
--- Comment #8 from tbptbp at gmail dot com 2007-08-23 18:45 ---
Subject: Re: vector float | vector float is accepted
On 23 Aug 2007 18:31:25 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> --- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-23 18:31
> -
--- Comment #9 from pinskia at gmail dot com 2007-08-23 18:49 ---
Subject: Re: vector float | vector float is accepted
On 23 Aug 2007 18:45:47 -, tbptbp at gmail dot com
<[EMAIL PROTECTED]> wrote:
> Your patch and documentation conflict . Fix either, at your convenience.
Read the
/*
PROBLEM: name lookup failure in inheritance tree
PLATFORM: HP nx8220 Fedora Core 6
PACKAGES: gcc-4.1.2-13.fc6
PACKAGES: gcc-c++-4.1.2-13.fc6
PACKAGES: libgcc-4.1.2-13.fc6
OUTPUT: g++ -v -o a a.cc
---
Using built-in specs.
Target
--- Comment #4 from zadeck at naturalbridge dot com 2007-08-23 18:59
---
Subject: Re: Invalid insn with pre_inc
pinskia at gcc dot gnu dot org wrote:
> --- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-22 22:41
> ---
> I think we need a new predicate for this rtl in
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-23 19:00 ---
No, this is correct, f in B hides all of f's in A, no matter what argument
types of f are in A. You have to add "using A::f;" inside B to get the
behavior you want.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from mwheeler at pittstate dot edu 2007-08-23 19:06 ---
I'm having this exact same problem. I'm building on AIX 5.3. My output looks
almost exactly the same as the other posters. My only configure option was:
--prefix=/usr/local
Here is the output:
make[3]: Entering direc
--- Comment #4 from igodard at pacbell dot net 2007-08-23 19:30 ---
Ah! I see. So if string cat is after there's only one string, which does
contain embedded quotes as printed.
And if string cat were before you couldn't compose a string out of a sequence
of macro calls and literals. Mak
--- Comment #10 from tbptbp at gmail dot com 2007-08-23 19:42 ---
Subject: Re: vector float | vector float is accepted
On 23 Aug 2007 18:49:22 -, pinskia at gmail dot com
<[EMAIL PROTECTED]> wrote:
> Read the next line. That is where my quote is from. Please read the
> whole sect
--- Comment #1 from tbm at cyrius dot com 2007-08-23 19:55 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
void ConvertAddr (char *saddr, void **addr)
{
*addr = (void *) &saddr;
}
void DefineSelf (char *addr)
{
int i;
for (i = 0; i < 20; i += 4) {
ConvertAddr (addr,
--- Comment #2 from tbm at cyrius dot com 2007-08-23 19:58 ---
This also happens with 20070720 but not with 20070616.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33166
I get the following ICE with current trunk:
(sid)28159:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O3
tightvnc-access.c
tightvnc-access.c: In function 'DefineSelf':
tightvnc-access.c:8: internal compiler error: in get_indirect_ref_operands, at
tree-ssa-operands.c:1698
Please submit a
--- Comment #7 from eweddington at cso dot atmel dot com 2007-08-23 20:10
---
Confirmed for AVR. GCC 4.2.1 for avr generates this:
foo:
/* prologue: frame size=0 */
push r14
push r15
push r16
push r17
/* prologue end (size=4) */
movw r14,r22
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Severity|normal |minor
Priority|P2 |P5
http
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-23 20:36 ---
It is unfortunate that gimple can only initialize the whole array, unless
__builtin_memcpy is used. Unfortunately __builtin_memcpy has a different
drawback - the var will be forced to be TREE_ADDRESSABLE even when it
--- Comment #15 from eweddington at cso dot atmel dot com 2007-08-23 20:39
---
Closing bug as WORKSFORME based on Bjoern's observations in comment #13.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-23 20:59 ---
# VUSE { saddr SMT.6 }
D.2252_6 = *&saddr
This happens in forwprop.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
There seems to be a problem with how gcc parses the \x escape sequences. It
doesn't look at just the first 2 hex digits, but will take the right most 2 hex
digits in a string of hex digits.
[Recreate]
---[ SNIP ]-
// test.c
#include
#include
int main() {
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-23 21:59 ---
No GCC is correct.
The standard says:
Each octal or hexadecimal escape sequence is the longest sequence of characters
that can constitute the escape sequence.
So that means the B is going to be taken and be used for
20070823 (experimental) (GCC)
/usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1plus -E -quiet -nostdinc++
-v
-I/var/tmp/43/build-140/powerpc-unknown-linux-gnu/libstdc++-v3/include/powerpc-unknown-linux-gnu
-I/var/tmp/43/build-140/powerpc-unknown-linux-gnu/libstdc++-v3/include
-I/var/tmp/43/gcc-4.3.0
--- Comment #12 from eweddington at cso dot atmel dot com 2007-08-23 22:26
---
Seems to be fixed in 4.3 20070817 snapshot.
An additional minor patch is needed, not for this bug, but to allow Objective-C
to build for the AVR. (It's unknown if Objective-C will actually *work* on the
AVR.
--- Comment #1 from michelin60 at gmail dot com 2007-08-23 22:28 ---
Created an attachment (id=14097)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14097&action=view)
preprocessed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
The compiler generates two different relocs for the same function call, which
causes the linker to get confused.
- Input -
#include "pthread.h"
#include
#include
typedef __gnu_cxx::__pool_alloc > myalloc;
int main() {
std::map, myalloc> y;
pthread_mutex_lock(0);
}
-
b
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-23 23:23 ---
Subject: Bug 31941
Author: jakub
Date: Thu Aug 23 23:23:26 2007
New Revision: 127747
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127747
Log:
PR c++/31941
* error.c (resolve_virtual_fun_from_
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-23 23:27 ---
Subject: Bug 32898
Author: jakub
Date: Thu Aug 23 23:27:34 2007
New Revision: 127749
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127749
Log:
PR c++/32898
* name-lookup.c (set_decl_namespace)
--- Comment #7 from jakub at gcc dot gnu dot org 2007-08-23 23:30 ---
Subject: Bug 32946
Author: jakub
Date: Thu Aug 23 23:29:57 2007
New Revision: 127750
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127750
Log:
PR tree-optimization/32573
PR middle-end/32946
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-23 23:30 ---
Subject: Bug 32573
Author: jakub
Date: Thu Aug 23 23:29:57 2007
New Revision: 127750
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127750
Log:
PR tree-optimization/32573
PR middle-end/32946
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-24 00:24 ---
Yes this is a dup of PR 28116.
*** This bug has been marked as a duplicate of 28116 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from pinskia at gcc dot gnu dot org 2007-08-24 00:24
---
*** Bug 28358 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from atgraham at gmail dot com 2007-08-24 00:40 ---
This problem is due to the fact that GTHREAD_USE_WEAK is incorrectly defined
for this architecture.
--
atgraham at gmail dot com changed:
What|Removed |Added
---
This patch
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01634.html
causes gcc.target/i386/cmov4.c regression.
--
Summary: [4.3 Regression] revision 123223 causes
gcc.target/i386/cmov4.c
Product: gcc
Version: 4.3.0
Status: UNCONFI
--- Comment #1 from ianw at gelato dot unsw dot edu dot au 2007-08-24
05:04 ---
Created an attachment (id=14098)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14098&action=view)
-S output with no optimisation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33171
--- Comment #2 from ianw at gelato dot unsw dot edu dot au 2007-08-24
05:04 ---
Created an attachment (id=14099)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14099&action=view)
-S output with -O2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33171
--- Comment #1 from bonzini at gnu dot org 2007-08-24 05:17 ---
*** Bug 33170 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from bonzini at gnu dot org 2007-08-24 05:17 ---
*** This bug has been marked as a duplicate of 33157 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
Hi,
The following example, when built with -O2, results in
~$ .gcc -O2 -o test2 ~/test2.c
/tmp/cc6SGh7Z.s: Assembler messages:
/tmp/cc6SGh7Z.s:16: Error: syntax error; found `,' but expected `('
/tmp/cc6SGh7Z.s:16: Error: junk at end of line: `,0'
This code is extracted from libatomic-ops (see
--- Comment #2 from ubizjak at gmail dot com 2007-08-24 06:04 ---
This patch
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01634.html
causes gcc.target/i386/cmov4.c regression.
--
ubizjak at gmail dot com changed:
What|Removed |Added
-
--- Comment #2 from jakub at gcc dot gnu dot org 2007-08-24 06:55 ---
Subject: Bug 32567
Author: jakub
Date: Fri Aug 24 06:54:49 2007
New Revision: 127760
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127760
Log:
PR c++/32567
* typeck.c (build_unary_op) : Return
--- Comment #3 from steven at gcc dot gnu dot org 2007-08-24 06:36 ---
It's not even supposed to pass on i686:
/* { dg-options "-O2 -march=k8" } */
(see
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.target/i386/cmov4.c?revision=127731&view=markup)
Note I'm not even going to look
--- Comment #4 from bonzini at gnu dot org 2007-08-24 06:50 ---
It's supposed to pass on K8 in 32-bit mode. It did, and it does not. However,
I think reverting the patch is not the right thing to do.
Anyway, given Steven's highly constructive remark, I think we can only wait for
it to
--- Comment #5 from bonzini at gnu dot org 2007-08-24 06:57 ---
Anyway, it fails on 64-bit mode too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
93 matches
Mail list logo
