The pattern subqi_2 and subqi_3 contain a reference to a construct (minus:HI
(match_operand:QI) (match_operand:QI)). It is not obvious because the
match_operand are written as match_dup. Such a RTL will never be generated.
--
Summary: X86: wrong mode in subqi_2
Product:
--- Comment #6 from pluto at agmk dot net 2008-06-25 07:52 ---
forwarded to libc bugzilla:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=6693
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36568
I compiled the following code with gcc 4.3.0 mingw (more details at the end of
the report) with:
g++ -std=c++0x test.cpp
#include iostream
#include typeinfo
int rvalue();
int lvalueref();
int rvalueref();
decltype(true ? rvalue() : rvalue()) f()
{}
decltype(true ? lvalueref() :
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-06-25 08:41
---
Subject: Bug 35518
Author: rguenth
Date: Wed Jun 25 08:41:14 2008
New Revision: 137100
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137100
Log:
2008-06-25 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #1 from schwab at suse dot de 2008-06-25 08:53 ---
In a cast in functional notation only a simple-type-specifier is allowed.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-25 09:15
---
You mean decltype, right? And I would guess you stumbled on the issue while
implementing common_type... Let's CC Doug, the main author of the code.
--
paolo dot carlini at oracle dot com changed:
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-06-25 10:05
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-25 10:10 ---
Confirmed. Looks like a cutpaste error. Uros?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jakub at gcc dot gnu dot org 2008-06-25 10:20 ---
And the miscompiled tlsc.f inline (compile with just -O2):
SUBROUTINE TLSC (A,B,AUX,IPIV,EPS,X)
COMMON /TLSDIM/ M1,M,N,L,IER
COMMON /SLATE/ BETA,H,I,IB,IB1,ID,ID1,IEND,II,IST,J,JA,JB,JK
+
--- Comment #14 from jakub at gcc dot gnu dot org 2008-06-25 11:31 ---
I have no idea why is speculation even attempted here (it doesn't make any
sense,
the pointer is surely non-NULL, it points to a global variable), and apparently
nothing checks whether it is safe to move over the
--- Comment #15 from jakub at gcc dot gnu dot org 2008-06-25 11:32 ---
Wrong-code bug on secondary arch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-06-25 11:51 ---
Wrong code on primary arch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-25 11:54 ---
Not a regression. $Summary was true always.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-06-25 11:57
---
Actually we made it work at some point and that is even documented:
First, we @strong{highly} recommend that GCC be built into a
separate directory than the sources which does @strong{not} reside
within the
--- Comment #6 from jakub at gcc dot gnu dot org 2008-06-25 12:00 ---
Simplified testcase (fails at -Os -m32):
/* PR target/36613 */
extern void abort (void);
static inline int
lshifts (int val, int cnt)
{
if (val 0)
return val;
return val cnt;
}
static inline unsigned int
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-06-25 12:01 ---
It looks like you run out of stack space during GC walk. You can check if so
by raising the stack limit with 'ulimit -s unlimited'.
I recall that Jakub had a patch to limit recursion in GC somewhat?
--
rguenth
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36315
--- Comment #7 from jakub at gcc dot gnu dot org 2008-06-25 12:06 ---
That was PR36060 and is already fixed in 4.3/4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36037
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36397
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36411
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36440
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36444
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36445
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36458
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P4
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||diagnostic
Priority|P3 |P2
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36511
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-25 12:12 ---
C testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36554
When I attempt to compile the 06/20/08 snapshot of gcc on an x86_64 system
under SuSE Linux 10.0 I get the following error:
/home/mrichmon/gcc-4.4-20080620/g95/./gcc/xgcc
-B/home/mrichmon/gcc-4.4-20080620/g95/./gcc/
-B/home/mrichmon/irun/x86_64-unknown-linux-gnu/bin/
void
foo (unsigned char *x, short y)
{
short i;
i = 2;
while (i y)
{
x[i - 1] = x[i];
i = i + 1;
}
}
ICEs at -O3 on x86_64-linux in 4.3/4.4, works in 4.2 with -O3 -ftree-vectorize.
--
Summary: [4.3/4.4 Regression] ICE in
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36630
--- Comment #2 from ubizjak at gmail dot com 2008-06-25 13:40 ---
(In reply to comment #1)
Confirmed. Looks like a cutpaste error. Uros?
Indeed: I'm testing following patch:
Index: i386.md
===
--- i386.md (revision
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-25 14:27 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
The following code generates a recursive inlining error in 4.3.[01] while it
did not in 4.[12]. Somehow, the bug requires having both always_inline
attributes.
templatetypename T
struct B {
struct C {
__attribute__((always_inline)) C(C const c)
{
This testcase causes GNU Fortran versions shown below (as far as I know):
4.2.1
4.3.0
to crash with `internal compiler error'.
This testcase shows some features that must exist in order to cause the
compiler to fail:
- inside the OpenMP section, it accesses a module variable (ModuleVar)
-
--- Comment #1 from wirawan0 at gmail dot com 2008-06-25 19:25 ---
Created an attachment (id=15813)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15813action=view)
Fortran95 source code
No postprocessing needed. To reproduce the error, use:
gfortran -c -fopenmp crash.f95
--
--- Comment #2 from laurent at guerby dot net 2008-06-25 20:04 ---
To my knowledge there's no exception in C and I know next to nothing in C++ so
I unfortunately can't contribute a c++ testcase. May be Eric can help?
--
laurent at guerby dot net changed:
What|Removed
--- Comment #22 from aoliva at gcc dot gnu dot org 2008-06-25 20:20 ---
Sorry that it took me so long to look at this.
Richi, I have a feeling that your patch will just paper over the problem.
See, if we take a bit-range that's not the entire bit-field, it will emit the
same shifts,
When deleting an array of dynamically allocated objects that inherit some base
class, a pointer offset calculation is modified during the optimization process
of a delete [] operator. The result is a subscript operation with a negative
index and this causes the warning to be emitted (erroneously I
--- Comment #1 from chris dot fairles at gmail dot com 2008-06-25 20:53
---
Created an attachment (id=15814)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15814action=view)
Test case that issues warning with compiling with -O2,-Wall
--
--- Comment #2 from chris dot fairles at gmail dot com 2008-06-25 20:54
---
Created an attachment (id=15815)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15815action=view)
File from tree dump before subscript operator appears.
--
--- Comment #3 from chris dot fairles at gmail dot com 2008-06-25 20:55
---
Created an attachment (id=15816)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15816action=view)
File from tree dump with the negative subscript index
--
--- Comment #4 from chris dot fairles at gmail dot com 2008-06-25 20:56
---
Adding CC as requested.
--
chris dot fairles at gmail dot com changed:
What|Removed |Added
--- Comment #5 from chris dot fairles at gmail dot com 2008-06-25 20:59
---
This bug is similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35593 which
is fixed in mainline.
--
chris dot fairles at gmail dot com changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-06-25 20:59 ---
D.2148_2 = (struct D[7] *) D.2168_1;
D.2149_3 = D.2148_2 + 8;
D.2169_4 = (long unsigned int *) D.2149_3;
D.2170_5 = D.2169_4 + -8;
That seems wrong. Why are we going from a struct D[7] * to a long
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-06-25 21:00 ---
(In reply to comment #5)
This bug is similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35593 which
is fixed in mainline.
It is like that but this one is really the C++ front-end emitting weird trees
to begin
--- Comment #3 from uros at gcc dot gnu dot org 2008-06-25 21:07 ---
Subject: Bug 36627
Author: uros
Date: Wed Jun 25 21:06:20 2008
New Revision: 137122
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137122
Log:
PR target/36627
* config/i386/i386.md : Change
--- Comment #4 from ubizjak at gmail dot com 2008-06-25 21:09 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-06-25 21:11
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
The -msecure-plt ABI requires that -fpic/-fPIC calls via the PLT have the GOT
pointer register valid. gcc accomplishes this by adding pic_offset_table_rtx
to CALL_INSN_FUNCTION_USAGE for such calls at rtl expansion time. See
rs6000.md define_expand call. Now, indirect calls do *not* need a GOT
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org
--- Comment #16 from mkuvyrkov at gcc dot gnu dot org 2008-06-25 21:33
---
I can't reproduce the error with today mainline. When I put in one file
'PROGRAM PR35659' and 'SUBROUTINE TLSC (A,B,AUX,IPIV,EPS,X)' and compile it
with any optimization level I get the same STOP 0 message. Am
--- Comment #23 from rguenther at suse dot de 2008-06-25 21:48 ---
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
On Wed, 25 Jun 2008, aoliva at gcc dot gnu dot org wrote:
--- Comment #22 from aoliva at gcc dot gnu dot org
--- Comment #5 from jason at gcc dot gnu dot org 2008-06-25 21:49 ---
Here's another example:
struct A { int i[100]; };
void f(struct A);
int main()
{
f((struct A){1});
}
Here we build up the compound literal on the stack and then copy it into the
argument slot.
This seems to be a
with: ../configure --program-prefix=current-
--enable-languages=c,c++ --prefix=/home/regehr
Thread model: posix
gcc version 4.4.0 20080625 (experimental) (GCC)
[EMAIL PROTECTED] tmp31]$ cat small.c
typedef int int32_t;
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
static inline
--- Comment #17 from doko at cs dot tu-berlin dot de 2008-06-25 22:16
---
Subject: Re: [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2
-funroll-loops) on ia64
mkuvyrkov at gcc dot gnu dot org writes:
Anyway, can you help me reproduce the issue, so I can take a
--- Comment #3 from pault at gcc dot gnu dot org 2008-06-25 23:05 ---
Subject: Bug 36526
Author: pault
Date: Wed Jun 25 23:04:33 2008
New Revision: 137125
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137125
Log:
2008-06-25 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #24 from aoliva at gcc dot gnu dot org 2008-06-26 00:33 ---
It's not just the result type that changed. You actually changed the type of
the variable created to hold the group of bit fields, out of which we further
extract members that were not mapped to separate variables.
Starting program:
/xxx/gnu/gcc/objdir/gcc/testsuite/ada/acats/tests/c3/c34008a/c34008a
,.,. C34008A ACATS 2.5 08-06-25 20:53:12
C34008A CHECK THAT THE REQUIRED PREDEFINED OPERATIONS ARE DECLARED
(IMPLICITLY) FOR DERIVED TASK TYPES.
C34008A PASSED
This is originally derived from code from Linux, in which the physical address
of a structure is passed to an asm statement as an integral type, causing the
initializer of the structure to be optimized away.
int main() { int i = 0x12345678; long j = (long)i; asm (# %0 : : r (j)); }
int main() {
This is correct as you are just using the address and not the contents
itself. This is how inline-asm is documented to work also.
-- Andrew Pinski
Sent from my iPhone
On Jun 25, 2008, at 19:08, aoliva at gcc dot gnu dot org [EMAIL PROTECTED]
wrote:
This is originally derived from code
--- Comment #1 from pinskia at gmail dot com 2008-06-26 03:46 ---
Subject: Re: New: pointer referenced in asm statement not regarded as VUSE
This is correct as you are just using the address and not the contents
itself. This is how inline-asm is documented to work also.
-- Andrew
--- Comment #2 from aoliva at gcc dot gnu dot org 2008-06-26 05:12 ---
It is indeed documented that way, but one gets to wonder if that's desirable.
Consider that in the original testcase the pointer is converted to a physical
address (integral type) that must not be dereferenced, and
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-26 05:50 ---
Fails here with 4.2 and 4.3. However, works with gfortran 4.4, which is e.g.
available from http://gcc.gnu.org/wiki/GFortranBinaries
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36632
68 matches
Mail list logo
