--- Comment #15 from andi-gcc at firstfloor dot org 2010-07-27 06:56
---
I'm working on a solution for the lost code problem. It will require
-ffunction/data-sections so that it can be undone section by section.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
--- Comment #4 from dominiq at lps dot ens dot fr 2010-07-27 06:56 ---
> It also regresses (diagnostics) in gfortran.dg/transfer_simplify_2.f90 /
> gfortran.dg/transfer_simplify_7.f90.
I also see a regression for gfortran.dg/parameter_array_section_1.f90
[macbook] f90/bug% gfc
/opt/gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|function names in error |[4.5/4.6 Regression]
|message |
--- Comment #7 from kargl at gcc dot gnu dot org 2010-07-27 06:15 ---
(In reply to comment #5)
> From the error location it looks like a duplicate of PR 44857.
>
Yes, I think you're right. I've reduced it further in
comment #6. The code compiles if the array constructor is
changed.
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-27 06:11 ---
Here's an even shorter testcase.
MODULE FunctionTypes
IMPLICIT NONE
integer, parameter :: OpconNameLength = 4
TYPE, PUBLIC :: TTermDefinition
CHARACTER (OpconNameLength) :: termName(2)
END TYPE TTer
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-27 06:08 ---
>From the error location it looks like a duplicate of PR 44857.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-27 06:04 ---
(In reply to comment #2)
> Untested patch.
> + return (e->symtree->n.sym->attr.flavour == FL_PARAMETER);
s/flavour/flavor/
It also regresses (diagnostics) in gfortran.dg/transfer_simplify_2.f90 /
gfortran.dg/tra
--- Comment #4 from kargl at gcc dot gnu dot org 2010-07-27 04:54 ---
Reset severity to normal. Fortran bugs are rarely anything but
normal.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from kargl at gcc dot gnu dot org 2010-07-27 04:53 ---
Created an attachment (id=21323)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21323&action=view)
Reduced testcase
Here's a reduced testcase.
--
kargl at gcc dot gnu dot org changed:
What|R
--- Comment #1 from clerman at fuse dot net 2010-07-26 23:29 ---
Subject: gfortran bug 45092
Hello,
Attached is the file, bug8.tar.gz needed to recreate the problem described in
bug 45092.
Norm Clerman
--- Comment #2 from clerman at fuse dot net 2010-07-26 23:29 ---
Creat
Hello,
I am e-mailing to gcc-bugzi...@gcc.gnu.org file bug8.tar.gz. Please unpack it
and then invoke the shell script bug8.sh (the name of the compiler I'm
symbolically linked to is gfortran-trunk). The following message appears
compiling file functiontypeM.f90 (see file functiontypesM.xyz):
n
--- Comment #43 from rth at gcc dot gnu dot org 2010-07-26 22:58 ---
Emutls now re-written in a way that should support LTO.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #42 from rth at gcc dot gnu dot org 2010-07-26 22:54 ---
Subject: Bug 44132
Author: rth
Date: Mon Jul 26 22:53:50 2010
New Revision: 162549
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162549
Log:
PR target/44132
Emulated TLS rewrite.
Added:
trunk/gcc/testsuit
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-07-26 22:05 ---
6.3.1.4 says: If the value of the integral part cannot be represented by
the integer type, the behavior is undefined.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-26 22:04 ---
Well considering 2^50 is outside the range of unsigned, this code does not have
a specified value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45091
The following test case will produce 0 when compile without compiler
optimizations, and 255 with optimizations:
=
#include
#include
int main()
{
double d = pow(2.0, 50.0);
std::cout << static_cast(static_cast(d)) << std::endl;
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-26 21:24 ---
I think this is correct behavior dealing with how x86_64 ABI describes struct
passing and almost all registers are volatile.
Oh on the trunk test3 gets compiled into a simple loop without any struct being
saved and
--- Comment #8 from hubicka at gcc dot gnu dot org 2010-07-26 21:16 ---
I fixed number of similar problems on Mozilla build recently. Can you, please,
re-try with current mainline? Otherwise we will need to get some testcase for
this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
I am running 4.5.0, built locally from a gcc.gnu.org distribution, on Ubuntu
10.04.
When switching from -m32 to -m64 a dispatch loop in my code gets noticeably
slower (20% slower in 4.3.4 and 4.4.3, 10% slower in 4.5.0).
Investigation of the generated assembly shows that register-resident struct
--- Comment #5 from hubicka at gcc dot gnu dot org 2010-07-26 21:14 ---
I fixed similar problem on mainline (it was bogus visibility handling for
external symbols). Can you re-try?
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from hubicka at gcc dot gnu dot org 2010-07-26 21:09
---
Hmm, hard to tell. The assembler .o files are not LTO and they will be
incrementally linked into non-LTO part of GCC produced fat .o files during
incremental linking and I guess it is hard to undo?
--
http://
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-26 21:04 ---
Created an attachment (id=21321)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21321&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45089
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-26 21:03 ---
Looking at the reduced test case for gas_dyn.f90, it looks like a duplicate of
PR 44945:
module ints
INTERFACE
SUBROUTINE NOZZLE()
END SUBROUTINE NOZZLE
END INTERFACE
end module ints
SUBROUTI
This is introduced by the new type merging code
j...@evans:~> /abuild/jh/trunk-install/bin/g++ -r -nostdlib -Os -g ~/d?.ii
-fwhopr
In file included from ../../../dist/include/nsThreadUtils.h:49:0,
from
/abuild/jh/mozilla-central/accessible/src/base/a11yGeneric.h:42,
--- Comment #26 from dominiq at lps dot ens dot fr 2010-07-26 21:00 ---
The patch in comment #25 fixes the ICE for PR 31867 comment 6, but causes also
several regressions with "... must have an explicit interface" errors:
FAIL: gfortran.dg/allocatable_function_1.f90 (test for excess er
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-26 20:19 ---
Untested patch.
Index: expr.c
===
--- expr.c (Revision 162542)
+++ expr.c
@@ -913,7 +913,7 @@ gfc_is_constant_expr (gfc_expr *e)
--- Comment #1 from sje at cup dot hp dot com 2010-07-26 20:07 ---
It doesn't result in any loads, just stores. This code is storing the first
part of the structure argument which was passed (partially) in registers into
memory. Obviously it doesn't need to do this since the argument i
I'm using r162345 on x86 Fedora 13.
This test case comes from the gdb test suite.
struct A
{
virtual ~A ();
int a1;
};
A::~A()
{
a1 = 800;
}
struct B : public A
{
virtual ~B ();
int b1;
int b2;
};
B::~B()
{
a1 = 900;
b1 = 901;
b2 = 902;
}
struct C : public B
{
A *c1;
A *
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-26 19:17 ---
Related - the original version of gfortran.dg/char_result_4.f90 shows:
pure elemental function double (x)
1
Error: ELEMENTAL procedure 'double' at (1) must have an explicit interface
Expected: This message i
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-26 19:16 ---
Created an attachment (id=21320)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21320&action=view)
gcc46-pr45083.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45083
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-07-26 18:55 ---
Confirmed, this was working in 4.2.4:
t.c: In function âtestâ:
t.c:9: warning: âcs[0u].bâ is used uninitialized in this function
t.c:8: note: âcs[0u].bâ was declared here
t.c:13: warning: âcs[0u].aâ i
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-26 18:50 ---
Reduced testcase:
/* { dg-do compile } */
/* { dg-options "-O2 -Wuninitialized" } */
struct S { char *a; unsigned b; unsigned c; };
extern int foo (const char *);
extern void bar (int, int);
static void
baz (void)
{
--- Comment #5 from hjl dot tools at gmail dot com 2010-07-26 18:41 ---
It is a valgrind bug. I opened:
https://bugzilla.redhat.com/show_bug.cgi?id=618360
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Severity|normal |major
GCC target triplet||avr
--- Comment #11 from eric dot weddington at atmel dot com 2010-07-26 17:37
---
Anitha, can you please check 4.5.x and HEAD?
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|ICE in |[4.3
Follow up to PR 40873.
There are still some -fwhole-program issues left; for instance: The polyhedron
tests gas_dyn.f90 and test_fpu.f90 do not link
--
Summary: -fwhole-program: Miscompiled due to wrong decls
Product: gcc
Version: 4.6.0
Status: UNCO
--- Comment #2 from mikpe at it dot uu dot se 2010-07-26 17:10 ---
Fixed by Eric's patch for PR44707.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
--- Comment #25 from burnus at gcc dot gnu dot org 2010-07-26 17:03 ---
(In reply to comment #23)
> Created an attachment (id=21315)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21315&action=view) [edit]
> New trans-decl.c patch - seems to work well
Dominique has found a failure
--- Comment #24 from dominiq at lps dot ens dot fr 2010-07-26 17:02 ---
With the patch in comment #23, the polyhedron tests gas_dyn.f90 and
test_fpu.f90 do not link and compiling the test in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867#c6 gives an ICE (Segmentation
fault). Otherwise
The check should be done in resolve_global_procedure.
NAG has:
Error: fjkff.f90: Inconsistent INTERFACE block for procedure FOO from $main$
Argument X (no. 1) should be an assumed-shape array
g95 has:
Error: Passing array at (1) to assumed-shape actual argument at (2) via an
implicit int
--- Comment #1 from spop at gcc dot gnu dot org 2010-07-26 16:45 ---
This looks like a duplicate of a binutils bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=6957
I fail to see how this is related to Graphite: you may find
other codes that are padded with NOPL that are triggering
th
--- Comment #4 from redi at gcc dot gnu dot org 2010-07-26 16:37 ---
(In reply to comment #3)
>
> If you only want it to be used as an integral constant, don't use it in a
> context that requires a variable (e.g. reference binding)
e.g.
funky((int)myclass::BUFF_SIZE);
This means th
--- Comment #3 from redi at gcc dot gnu dot org 2010-07-26 16:32 ---
(In reply to comment #2)
> The bug/feature may be that re-typing BUFF_SIZE to static const unsigned int
> allows the compiler to not report a problem.
You're not "re-typing" it, you're providing a definition for a vari
--- Comment #5 from justin dot lebar+bug at gmail dot com 2010-07-26 16:20
---
FWIW, it seems that MSVC is perfectly happy to compile code with intrinsics
inside a file which doesn't have any special flags. It would be awesome if
there were some way to do the same with GCC, even if it
--- Comment #1 from tromey at gcc dot gnu dot org 2010-07-26 16:12 ---
Created an attachment (id=21319)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21319&action=view)
compressed .i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45085
I'm using a relatively recent svn trunk gcc on an x86 Fedora 13 machine.
I'm trying to compile gdb with it. I got this error:
../../archer/gdb/remote.c: In function remote_wait:
../../archer/gdb/remote.c:5561:10: error: event_ptid.tid may be used
uninitialized in this function [-Werror=uninit
Use binutils 2.20.1.
Configure gcc:
../configure --prefix=/usr/local/m68k-elf \
--enable-interwork \
--enable-multilib \
--without-headers \
--disable-shared \
--disable-libssp \
--enable-languages=c,c++ \
--verbose \
--with-newlib \
--program-prefix=m68k-elf- \
--with-as=/usr/local/m68k-elf/bin/
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-07-26 16:02
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-07-26 16:02
---
Subject: Bug 43784
Author: rguenth
Date: Mon Jul 26 16:01:55 2010
New Revision: 162539
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162539
Log:
2010-07-26 Richard Guenther
PR tree-optimizatio
--- Comment #2 from tromey at gcc dot gnu dot org 2010-07-26 15:59 ---
Forgot some info:
opsy. gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/space/tromey/Trunk/install/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: .
--- Comment #2 from rwitmer at xmission dot com 2010-07-26 15:59 ---
I agree with your assessment. Adding const int myclass::BUFF_SIZE; resolves
the issue.
The bug/feature may be that re-typing BUFF_SIZE to static const unsigned int
allows the compiler to not report a problem. It doe
--- Comment #1 from tromey at gcc dot gnu dot org 2010-07-26 15:53 ---
Created an attachment (id=21318)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21318&action=view)
compressed .i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45083
While compiling gdb with a relatively recent svn trunk gcc, I saw:
gcc -g -O2 -I. -I../../archer/gdb -I../../archer/gdb/common
-I../../archer/gdb/config
-DLOCALEDIR="\"/home/tromey/gnu/archer/install/share/locale\"" -DHAVE_CONFIG_H
-I../../archer/gdb/../include/opcode -I../../archer/gdb/../opcod
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-26 15:32 ---
This is not valid C++. See [class.static.data]/4:
If a static data member is of const integral or const enumeration type, its
declaration in the class definition can specify a constant-initializer which
shall be an in
A class that has a static const signed int data member when passed to a
function as a const int& parameter will cause the data member to be an
undefined symbol. If the static const signed int data member is re-typed as
const unsigned int the error goes away. I've verified this on g++ 3.4.6 and
4.
--- Comment #1 from dominiq at lps dot ens dot fr 2010-07-26 15:22 ---
Confirmed as a regression: it compiles with 4.2.4 (ppc-darwin), gives an ICE
with 4.3.4, 4.4.2, 4.5.0 and trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081
compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:4208
in
GNU Fortran (GCC) 4.6.0 20100726 (experimental)
The code compiles with the NAG compiler, as it should. gfortran also compiles
the equivalent code for INTEGERS instead of the derived type.
Maybe there is a relation to
--- Comment #9 from matz at gcc dot gnu dot org 2010-07-26 15:06 ---
Here's a testcase (nicer in the sense of not requiring inlining) that shows
the current compiler botching the nrv <-> retslot optimizations:
struct S {int x, y, makemelarge[5];};
S __attribute__((noinline)) f (S &s) {
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-26 14:49 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-26 14:49 ---
Subject: Bug 45073
Author: rguenth
Date: Mon Jul 26 14:48:43 2010
New Revision: 162537
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162537
Log:
2010-07-26 Richard Guenther
PR middle-end/45073
--- Comment #7 from rakdver at gcc dot gnu dot org 2010-07-26 14:47 ---
By the time the code reaches ivopts, it looks (modulo SSA form) this way:
signed char x = -128, tmp;
for (;;)
{
tmp = -x;
foo ((int) x, (int) tmp, x==-128);
...
if (x == 127)
break;
x++;
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-26 14:47 ---
Created an attachment (id=21317)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21317&action=view)
gcc46-pr45079.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #25 from jiez at gcc dot gnu dot org 2010-07-26 14:37 ---
Ramana, I will ask for permission to commit it on 4.5 branch when it's
unfrozen.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
--- Comment #1 from piotr dot rak at gmail dot com 2010-07-26 14:21 ---
Created an attachment (id=21316)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21316&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45080
cat lambda-convX.C
// { dg-options -std=c++0x }
typedef void(*pfn)();
template
void f1 ()
{
pfn fn = []{};
}
template
void f2()
{
pfn fn = []{};
}
void test()
{
f1<>();
f2<>();
}
[p...@a tmp] g++-trunk -v lambda-convX.C -c -std=c++0x
Using built-in specs.
4.4 doesn't print the function names in the error message, while 4.5 and 4.6 do
so:
$ cat foo.c
void foo(const char *p, int cond, int a, int b)
{
p[cond ? a : b] = '\0';
}
$ gcc-4.4 -c foo.c
foo.c: In function 'foo':
foo.c:3: error: assignment of read-only location '*(p + (cond != 0 ? (l
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-26 14:15 ---
The reassoc issue is caused by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159189
BTW, the C++ FE uses T instead of unsigned type for values in the ctor and thus
the testcase works there.
--
jakub at gcc dot
dehydra fails to build with the following error:
/usr/bin/gcc-4.5 -MD -g3 -Wall -fPIC -DXP_UNIX -DIN_GCC -DPLUGIN_NO_POISON
-DHAVE_CONFIG_H -I/usr/lib/gcc/sparc-linux-gnu/4.5.1/plugin/include
-I/usr/include/mozjs -I/usr/lib -I//home/buildd/local/include/js/ -g -O2 -c
dehydra_plugin.c
In file inc
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-26 13:56 ---
struct class$field_p
struct class$field_p
looks more like a frontend issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from dominiq at lps dot ens dot fr 2010-07-26 13:45 ---
(In reply to comment #10)
> > Note that since revision 162531 (-fwhole-file is now the default) the tests
> > in
> > this pr no longer give ICEs. However these ICEs reappear when the tests are
> > compiled with -fno
--- Comment #10 from burnus at gcc dot gnu dot org 2010-07-26 13:31 ---
(In reply to comment #9)
> Note that since revision 162531 (-fwhole-file is now the default) the tests in
> this pr no longer give ICEs. However these ICEs reappear when the tests are
> compiled with -fno-whole-file.
--- Comment #7 from dominiq at lps dot ens dot fr 2010-07-26 13:30 ---
This pr looks like a duplicate of pr37744, or at least the ICEs disappear with
-fwhole-file (now the default: see
http://gcc.gnu.org/ml/gcc-bugs/2010-07/msg02853.html#c9 ).
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-26 13:29 ---
Subject: Bug 45056
Author: rguenth
Date: Mon Jul 26 13:29:14 2010
New Revision: 162536
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162536
Log:
2010-07-26 Richard Guenther
PR middle-end/45056
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-07-26 13:29 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-26 13:26 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #23 from burnus at gcc dot gnu dot org 2010-07-26 13:25 ---
Created an attachment (id=21315)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21315&action=view)
New trans-decl.c patch - seems to work well
New patch. Found the problem with the help of Jakub (thanks!); not
--- Comment #9 from dominiq at lps dot ens dot fr 2010-07-26 13:25 ---
Note that since revision 162531 (-fwhole-file is now the default) the tests in
this pr no longer give ICEs. However these ICEs reappear when the tests are
compiled with -fno-whole-file.
--
http://gcc.gnu.org/bugz
--- Comment #72 from burnus at gcc dot gnu dot org 2010-07-26 13:15 ---
(In reply to comment #70)
> With the patch of PR 40873 comment 18 applied [...]
There is now a new patch which fixes tons of issues including the test case of
comment 0 number 4, but not the one from comment 47.
>
+++ This bug was initially created as a clone of Bug #40011 +++
The program of PR 40011 comment 47 (attachment 18427) works -fno-whole-file
but fails otherwise with an ICE in fold_convert_loc, at fold-const.c:2021.
--
Summary: ICE with -fwhole-file in fold_convert_loc, at fold-
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-26 12:58 ---
Works if b[] has unsigned int type instead of T.
Sounds like a type mismatch.
The VAR_DECL b has ARRAY_TYPE with T element type and b's CONSTRUCTOR has the
same type, but the values in the constructor doesn't have T ty
Command line:
$ gfortran -O[0123] -fprofile-generate dynamic_dispatch_6.f03
$ rm dynamic_dispatch_6.gcda
$ ./a.out
$ gfortran -O[0123] -fprofile-use dynamic_dispatch_6.f03
Compiler output:
$ gfortran -fprofile-generate dynamic_dispatch_6.f03
$ rm dynamic_dispatch_6.gcda
$ ./a.out
$ gfortran -fprof
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-26 12:49 ---
Subject: Bug 45071
Author: rguenth
Date: Mon Jul 26 12:48:37 2010
New Revision: 162534
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162534
Log:
2010-07-26 Richard Guenther
PR tree-optimization/
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-26 12:48 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-07-26 12:45
---
Mine again (only for restoring the pre-MEM_REF behavior).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-07-26 12:45
---
Created an attachment (id=21314)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21314&action=view)
patch
Please check whether the attached patch fixes the testcase this bug is about.
--
http://gcc.gnu.or
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-26 12:39 ---
Simplified testcase:
typedef unsigned int T;
extern void foo (unsigned char *, int);
static signed char a;
static T b[1] = { -1 };
static unsigned char c;
static inline short int
bar (short v)
{
c |= a < b[0];
r
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-07-26 12:21
---
One of the issues is
/* For a MEM rtx, the alignment in bits. We can use the alignment of the
mode as a default when STRICT_ALIGNMENT, but not if not. */
#define MEM_ALIGN(RTX)
--- Comment #8 from jakub at gcc dot gnu dot org 2010-07-26 11:51 ---
Isn't this dup of PR45075?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44997
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-26 11:47 ---
This is caused also by
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00577.html
but likely unrelated to the other PR, this is in C FE, that one is in C++ FE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45062
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-26 11:34 ---
Introduced by r161655 aka MEM-REF merge.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-26 11:00 ---
Invalid MEMs in debug-insns (invalid as in not folded). Why does the
scheduler query the alias oracle about them?
(debug_insn 49 48 50 7 t.cc:22 (var_location:DI D#3 (mem/s/f/j:DI (plus:DI
(reg/f:DI 54 virtual-stac
--- Comment #3 from bernds at gcc dot gnu dot org 2010-07-26 11:00 ---
Vlad intends to remove flag_ira_coalesce anyway, so there's probably not too
much point investigating this.
--
bernds at gcc dot gnu dot org changed:
What|Removed |Added
---
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45073
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45072
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-26 10:33 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #10 from burnus at gcc dot gnu dot org 2010-07-26 10:32 ---
(In reply to comment #8)
> I wonder how many other issues this patch fixes.
Seemingly none of those -fwhole-file/-fwhole-program issues which I wanted to
see fixed :-(
Well, at least this PR is now FIXED. Thanks fo
--- Comment #9 from burnus at gcc dot gnu dot org 2010-07-26 10:31 ---
Subject: Bug 45066
Author: burnus
Date: Mon Jul 26 10:30:45 2010
New Revision: 162532
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162532
Log:
2010-07-26 Tobias Burnus
PR fortran/45066
*
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
--- Comment #14 from borntraeger at de dot ibm dot com 2010-07-26 10:13
---
I have seen the original problem only with bitfields.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
1 - 100 of 118 matches
Mail list logo
