--- Comment #27 from spop at gcc dot gnu dot org 2010-02-03 06:20 ---
Right. On trunk both the reduced testcase and the original testcase pass
without ICE. I forgot to take 4.5 out of the summary, thanks for reminding me.
--
spop at gcc dot gnu dot org changed:
What
--
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 #2 from jvdelisle at gcc dot gnu dot org 2010-02-03 04:20
---
Patch submitted for approval:
http://gcc.gnu.org/ml/fortran/2010-02/msg00017.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42901
--- Comment #2 from amodra at gmail dot com 2010-02-03 03:39 ---
extract from 064t.phiprop
D.1963_1 = __errno_location ();
*D.1963_1 = 0;
p_2 = malloc (0x0);
D.1963_3 = __errno_location ();
save_4 = *D.1963_3;
corresponding bits from 065t.fre
D.1963_1 = __errno_locat
--- Comment #1 from amodra at gmail dot com 2010-02-03 03:35 ---
Created an attachment (id=19793)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19793&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42944
tst-malloc from glibc testsuite fails with 4.5.0 20100129, reporting "Error:
errno is not set correctly". Examination of object files shows that gcc is
assuming that "save" in the following is always zero.
errno = 0;
p = malloc (-1);
save = errno;
errno is defined as (*__errno_location)() w
--- Comment #42 from howarth at nitro dot med dot uc dot edu 2010-02-03
03:33 ---
Fixed on *-apple-darwin10. The gcj failures on intel darwin9 are due to a
different unwinder bug. Leaving open for darwin9.
--
howarth at nitro dot med dot uc dot edu changed:
What|Remo
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-03 03:30
---
As far as I can tell, we are already implementing correctly the resolution of
DR 539, I went through it one month ago or so:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539
If you disagree,
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-02-03
03:30 ---
Fixed for gcc 4.5 with...
Author: andreast
Date: Tue Feb 2 08:18:08 2010
New Revision: 156444
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156444
Log:
2010-02-02 Jack Howarth
PR java
std::partial_sum( first, last, result, binary_op ) (ยง26.4.2) is defined as
binary_op(binary_op(..., binary_op(*first, *(first + 1)),...),
*(first + (i - result)))
Ambiguity notwithstanding (what is the first value??), the result of each
application is clearly supposed to be forwarded to the n
--- Comment #34 from fejj at novell dot com 2010-02-03 02:16 ---
just an FYI, but if you take my original list.c attachment and uncomment the
second loop (the one that prints the values of each node after the creation
loop), even if you use `gcc -Wall -g -O2 -o list list.c`, the list wil
--- Comment #7 from jason at gcc dot gnu dot org 2010-02-03 01:14 ---
The testcase now works, but a variant that uses virtual inheritance does not:
int i;
struct A { A() {} };
struct C: virtual A
{
C();
};
C::C()
{
static void *labelref = &&label;
goto *labelref;
label: i = 1;
}
--- Comment #6 from jason at gcc dot gnu dot org 2010-02-03 00:08 ---
Subject: Bug 41090
Author: jason
Date: Wed Feb 3 00:07:49 2010
New Revision: 156455
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156455
Log:
PR c++/41090
* decl.c (cp_finish_decl): Add local
--- Comment #25 from jason at gcc dot gnu dot org 2010-02-03 00:01 ---
In fact the debug info is currently OK, at least for this testcase, because we
generate debug info for the signature of X::func at the end of the definition
of X, well before we start optimizing X::func.
But here's a
For this test code:
> cat test.f90
! derived from OpenMP test omp3f/F03_3_2_6_1a.f90
! alsoomp3c/c03_3_2_6_1a.c
! and omp3C/c03_3_2_6_1a.cpp
! REFERENCES
! OpenMP 2.5, p. 97, lines 13-15
! OpenMP 3.0, p. 116, lines 18-20
program F03_3_2_6_1a
--- Comment #12 from jingyu at google dot com 2010-02-02 23:57 ---
Subject: Re: Problematic condition
simplification logic at unswitch-loops pass
Zdenek,
I did dejagnu tests on your patch. It gave no regression on
"--target_board=arm-sim/thumb".
Do you think this patch will b
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2010-02-02
22:55 ---
Building gcc trunk with...
Index: configure
===
--- configure (revision 156440)
+++ configure (working copy)
@@ -7292,7 +7292,7 @@
--- Comment #27 from kkojima at gcc dot gnu dot org 2010-02-02 22:16
---
Created an attachment (id=19792)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19792&action=view)
A patch
Indeed! I've tested the attached patch and confirmed that
it doesn't regress with the top level "mak
--- Comment #1 from zsojka at seznam dot cz 2010-02-02 21:32 ---
Created an attachment (id=19791)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19791&action=view)
valgrind output for less trivial testcase
Generally, compiling any non-trivial file gives similiar output.
With --mall
Command line:
gcc -fsched-pressure -fschedule-insns -c testcase.c
Tested revisions:
r156367 - fail
--- testcase.c
int foo(void)
{
return 0;
}
---
Output:
$ valgrind --track-origins=yes
/mnt/svn/gcc-trunk/binary-156367-lto/libexec/gcc/x86_64-unknown-li
--- Comment #7 from wlodzimierz dot lipert+gcc at gmail dot com 2010-02-02
21:28 ---
Created an attachment (id=19790)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19790&action=view)
assembler
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42940
--- Comment #6 from wlodzimierz dot lipert+gcc at gmail dot com 2010-02-02
21:28 ---
Created an attachment (id=19789)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19789&action=view)
assembler
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42940
--- Comment #5 from wlodzimierz dot lipert+gcc at gmail dot com 2010-02-02
21:27 ---
Created an attachment (id=19788)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19788&action=view)
preprocessed libgcc2.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42940
--- Comment #9 from jason at gcc dot gnu dot org 2010-02-02 21:26 ---
Suspending pending resolution of issue 225.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from jason at gcc dot gnu dot org 2010-02-02 21:26 ---
That example does not match the text of the standard, and was fixed by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#197
However, the standard might change to say what you expect, depending on the
resol
--- Comment #10 from simon at pushface dot org 2010-02-02 21:25 ---
(In reply to comment #7)
> Why not remove the duplicate linkage of s-secsta.o in gnatlink and gnatmake?
> There is no reason to link it in a second time since it is already in
> libgnat.a.
I agree we could tidy up ada/g
--- Comment #4 from wlodzimierz dot lipert+gcc at gmail dot com 2010-02-02
21:13 ---
Created an attachment (id=19787)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19787&action=view)
makefile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42940
--- Comment #3 from wlodzimierz dot lipert+gcc at gmail dot com 2010-02-02
21:13 ---
Created an attachment (id=19786)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19786&action=view)
config status
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42940
--- Comment #7 from paolo dot carlini at oracle dot com 2010-02-02 21:12
---
Jason, shall we complete the triage of this rather old PR? Thanks in advance
for any help...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #2 from wlodzimierz dot lipert+gcc at gmail dot com 2010-02-02
21:12 ---
Created an attachment (id=19785)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19785&action=view)
config log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42940
--- Comment #1 from wlodzimierz dot lipert+gcc at gmail dot com 2010-02-02
21:12 ---
Created an attachment (id=19784)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19784&action=view)
includes
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42940
#
xgcc -v
Using built-in specs.
Target: m68hc12-elf
Configured with: ../gcc/configure --prefix=/home/vlad/CPU12
--enable-languages=c --with-newlib --target=m68hc12-elf
--with-sysroot=/home/vlad/CPU12/
Thread model: single
gcc
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-02 21:02
---
Did you check for DRs filed and resolved after C++03? As an additional data
point, the behavior with the current Intel compiler is exactly the same as GCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31
FAIL: gcc (GCC) 4.5.0 20100202 (experimental)
FAIL: gcc-4.4.3-4.fc12.x86_64
<2>: Abbrev Number: 8 (DW_TAG_variable)
DW_AT_name: x
DW_AT_location: 0x92 (location list)
0092 00400509 0040050f (DW_OP_reg0)
0092 00
--- Comment #5 from gael dot guennebaud at gmail dot com 2010-02-02 20:44
---
I hit the same issue, and according to c++ standard, here we have a _dependent_
lookup, and so the qHash(int*) overloads should be found.
Here is an example directly taken from the C++ standard (14.6, #9):
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42938
--- Comment #3 from mat at lcs dot mit dot edu 2010-02-02 19:38 ---
Sorry, I will ping the patches list again in a week or so, and otherwise strive
to follow the contribution directions better. Thanks for pointing this out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42937
--- Comment #1 from manuel dot montezelo at gmail dot com 2010-02-02 19:30
---
Sorry! The correct link for previous version of the package which compiled on
Debian farm (OpenSceneGraph 2.8.1, GCC 4.3.3, MIPS) is this one:
https://buildd.debian.org/fetch.cgi?pkg=openscenegraph;ver=2.8.1
--- Comment #2 from mat at lcs dot mit dot edu 2010-02-02 19:24 ---
I posted this to gcc-patches last week and got no responses, so to make sure
the bug did not get dropped I filed this ticket.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42937
The package OpenSceneGraph v2.8.2 fails to build with gcc 4.4.2 in the Debian
farm, for MIPS architecture:
https://buildd.debian.org/fetch.cgi?&pkg=openscenegraph&ver=2.8.2-1&arch=mips&stamp=1264018410&file=log
The error line:
.../osgmultitexturecontrol/osgmultitexturecontrol.cpp: In function 'T*
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2010-02-02
19:14 ---
Subject: Re: [4.5 Regression] pex-unix.c:589:1: internal compiler error:
output_operand
> rtx x = delegitimize_mem_from_attrs (orig_x);
>
> if (GET_CODE (x) == LO_SUM
> && GET_CODE (XEXP (x, 1))
--- Comment #1 from ubizjak at gmail dot com 2010-02-02 19:12 ---
Please post patches to gcc-patc...@gcc.gnu.org mailing list, as explained in
great detail in [1].
[1] http://gcc.gnu.org/contribute.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42937
--- Comment #26 from steven at gcc dot gnu dot org 2010-02-02 18:06 ---
Re. comment #25:
So does that mean this is not a 4.5 regression anymore? If so, please adjust
the summary also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319
--- Comment #25 from spop at gcc dot gnu dot org 2010-02-02 18:02 ---
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg3.html
was committed to trunk
http://gcc.gnu.org/viewcvs?view=revision&revision=151348
--
spop at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from sje at cup dot hp dot com 2010-02-02 17:49 ---
Using test case from comment #7, I compared r156291 and r156292 (plus the patch
from comment #6). I compiled with -O1 and it looks like we go wrong during
common sub expression elimination.
r156291 has x.c.150r.cse1 wit
--- Comment #7 from sje at cup dot hp dot com 2010-02-02 17:29 ---
If you apply the patch from comment #6 the following test case generates bad
code at -O1 or higher optimization. Instead of loading 0 to initialize v it is
loading the contents of memory location 0 to do the initializati
--- Comment #6 from sje at cup dot hp dot com 2010-02-02 17:25 ---
Jakub Jelinek suggested this patch to pa.c which fixes the compilation failure
but causes bad code generation.
static rtx pa_delegitimize_address (rtx);
#undef TARGET_DELEGITIMIZE_ADDRESS
#define TARGET_DELEGITIMIZE_ADDR
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-02 17:22 ---
Patch: http://gcc.gnu.org/ml/fortran/2010-02/msg00014.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from sje at cup dot hp dot com 2010-02-02 17:18 ---
Here is a cutdown version of pex-unix.i that fails to compile with -O2 -g.
extern char **environ;
pex_unix_exec_child ()
{
int pid;
volatile int sleep_interval;
volatile int retries;
char **save_environ = environ
I am porting gcc-4.4.3 to TILE-Gx, a straightforward 64-bit VLIW RISC. TILE-Gx,
like MIPS, maintains the invariant that an SI value in a register is always
sign extended (to DI), even if the value is unsigned.
I noticed that the default bswap32 implementation, which essentially produces
(uint32_t)
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-02 14:27 ---
FIXED on the trunk (4.5) and 4.4 branch.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from burnus at gcc dot gnu dot org 2010-02-02 14:27 ---
Subject: Bug 42650
Author: burnus
Date: Tue Feb 2 14:27:24 2010
New Revision: 156450
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156450
Log:
2010-02-02 Tobias Burnus
PR fortran/42650
*
--- Comment #3 from zsojka at seznam dot cz 2010-02-02 14:07 ---
> ice-on-invalid-code
I believe the code is valid, or at least can be made valid by adding a return
statement. The ICE happens when parser gets to '{', even this fails:
...
A::B A::B::foo() {
the actual content of function
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-02 13:59 ---
typedef unsigned int u_int8_t __attribute__ ((__mode__ (__QI__)));
typedef unsigned int u_int32_t __attribute__ ((__mode__ (__SI__)));
typedef enum { READ_SHARED = 0, WRITE_EXCLUSIVE = 1,
READ_EXCLUSIVE = 2, EXCL
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42897
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42896
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P1
http:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42893
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-02 13:38 ---
Confirmed. Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
S
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Priority|P3 |P1
http://gcc
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-02 13:35 ---
After all this is more an enhancement request and not really a bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42917
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42916
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-checking, ice-on-
|
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-02 13:33 ---
The ICE is
t.c: In function 'find_sad_16x16':
t.c:1:5: error: missing definition
for SSA_NAME: current_intra_sad_2_12 in statement:
# DEBUG current_intra_sad_2 => current_intra_sad_2_12
t.c:1:5: internal compiler er
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42898
--- Comment #9 from simon at pushface dot org 2010-02-02 13:10 ---
I've traced where the 'ranlib -c' switch was introduced: at
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg01183.html .
The original purpose of this patch was to fix g77 regressions, and we now pass
check-fortran without i
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-02 13:06 ---
Subject: Bug 42650
Author: burnus
Date: Tue Feb 2 13:05:50 2010
New Revision: 156449
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156449
Log:
2010-02-02 Tobias Burnus
PR fortran/42650
*
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-02 12:58 ---
Confirmed (no regression).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisD
> gfortran --version
GNU Fortran (GCC) 4.5.0 20100128 (experimental)
Copyright (C) 2010 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more informat
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-02 10:28 ---
Test case:
gfortran -flto bind_c_coms_driver.c bind_c_coms.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
It is a beginer bug, but it would be nice to get a warning in:
#include
unsigned val1 = 0x1000, val2 = 0x100;
int main(int argc, char **argv)
{
unsigned long long val3 = val1 * val2;
printf ("val1 = 0x%X, val2 = 0x%X, val3 = 0x%llX, val1*val2 = 0x%llX\n",
val1, val2, val3, (un
--- Comment #19 from burnus at gcc dot gnu dot org 2010-02-02 10:00 ---
Really close the PR.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #18 from burnus at gcc dot gnu dot org 2010-02-02 10:00 ---
CLOSE as FIXED.
Regarding comment 10: See newly opened PR 42934.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41777
(Follow up from 41777, comment 10)
The following variable_check in check.c does not make much sense:
if ((e->expr_type == EXPR_VARIABLE
&& e->symtree->n.sym->attr.flavor != FL_PARAMETER)
|| (e->expr_type == EXPR_FUNCTION
&& e->symtree->n.sym->result == e->symtree->n.sym))
--- Comment #41 from andreast at gcc dot gnu dot org 2010-02-02 08:19
---
Subject: Bug 41991
Author: andreast
Date: Tue Feb 2 08:19:26 2010
New Revision: 156446
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156446
Log:
2010-02-02 Jack Howarth
PR java/41991
--- Comment #40 from andreast at gcc dot gnu dot org 2010-02-02 08:19
---
Subject: Bug 41991
Author: andreast
Date: Tue Feb 2 08:18:48 2010
New Revision: 156445
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156445
Log:
2010-02-02 Jack Howarth
PR java/41991
--- Comment #39 from andreast at gcc dot gnu dot org 2010-02-02 08:18
---
Subject: Bug 41991
Author: andreast
Date: Tue Feb 2 08:18:08 2010
New Revision: 156444
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156444
Log:
2010-02-02 Jack Howarth
PR java/41991
80 matches
Mail list logo
