--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-01-28 08:09
---
Correction: upper and lower
@@ -1041,6 +1042,12 @@ find_array_element (gfc_constructor *con
goto depart;
}
+ /* Make sure we are dealing with constants. */
+ if
--
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 #6 from jvdelisle at gcc dot gnu dot org 2008-01-28 08:02
---
Found the problem. We are trying to treat an EXPR_FUNCTION as if its an
EXPR_CONSTANT. I doubt the compilation is correct for any platform. Segfault
occurs here at 1053. I tried using gfc_simplify_expr with
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-01-28 08:44
---
With this test program derived from the original test case and the patch,
gfortran compiles but does not get the results right:
module abuse_mod
implicit none
integer i
character(8), parameter :: HEX1 =
--- Comment #14 from dominiq at lps dot ens dot fr 2008-01-28 09:20 ---
At rev. 131891, the test gives the same ICE on ppc/Intel Darwin9, 32 and 64
modes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-01-28 09:16
---
Working on a patch.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-28 09:09 ---
Without the patch gfortran gives correct results on x86-64 and segfaults on
compilation on ppc64.
Without the patch, gfortran compiles gfortran.dg/parameter_array_init_3.f90
and gives the correct results for the
When compiled with -O3 -mips16 -EL -mabi=o64 -funroll-loops,
gcc.c-torture/compile/pr34856.c ICEs with:
pr34856.c:16: error: insn does not satisfy its constraints:
(insn 47 44 278 2
/scratch/richard/gcc/HEAD/gcc/gcc/testsuite/gcc.c-torture/compile/pr34856.c:12
(set (reg:DI 2 $2)
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-28 10:06 ---
Hm, isn't it even 'correct' to propagate a DECL_NO_TBAA_P pointer into uses
of a non-DECL_NO_TBAA_P pointer? Of course this shouldn't happen, as then the
IL would be wrong. I suppose we can even enforce this via
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Summary|[4.3 regression] MIPS16 ICE |[4.3 Regression]
--- Comment #2 from jakub at gcc dot gnu dot org 2008-01-28 09:52 ---
Fix:
2008-01-28 Jakub Jelinek [EMAIL PROTECTED]
PR middle-end/34969
* tree-inline.c (fold_marked_statements): Update resp. remove
cgraph edges if a call statement has been folded.
*
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-28 09:56 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from roebel at ircam dot fr 2008-01-28 10:00 ---
For completeness :
I now use this function that was proposed in
PR 323. It seems to solve my issue. Thanks for the pointer!
inline
void set_math_double_precision() {
fpu_control_t fpu_control ;
--- Comment #9 from jakub at gcc dot gnu dot org 2008-01-28 10:25 ---
Ian, the testcase would be new16.C after removing CHANGE_DYNAMIC_TYPE_EXPR
stuff
(to fix this PR). Or do you propose to keep CHANGE_DYNAMIC_TYPE_EXPR in 4.3
(which looks redundant with PR33407) and just hack it up to
--- Comment #9 from manu at gcc dot gnu dot org 2008-01-28 10:45 ---
Christoph, we need a testcase to be able to reproduce the bug, otherwise, we
cannot fix it.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from manu at gcc dot gnu dot org 2008-01-28 10:51 ---
(In reply to comment #8)
(In reply to comment #6)
But shouldn't -Wno-strict-aliasing suppress the warning?
Yes if you actually have -Wno-strict-aliasing after -Wall.
Andrew, note that this is not longer true in
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-28 11:11 ---
I suppose a simpler fix for 4.3 would be to not fold call stmts here.
Otherwise
moving the cgraph adjustment to a helper function in cgraph.c would look
nicer.
--
--- Comment #8 from burnus at gcc dot gnu dot org 2008-01-28 11:09 ---
Created an attachment (id=15033)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15033action=view) [edit]
A patch for this regression
I have just put this on to bootstrap and regtest whilst I sleep. Since it
--- Comment #26 from ubizjak at gmail dot com 2008-01-28 12:04 ---
*** Bug 34995 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2008-01-28 12:04 ---
*** This bug has been marked as a duplicate of 34856 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-28 12:25 ---
My tests have not been as exhaustive as the Tobias' ones, but the patch worked
as advertised without regression on ppc/intel Darwin9, 32 and 64 bit modes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34975
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-28 12:39 ---
No, I mean providing something like cgraph_update_edges_for_call_stmt (tree
old, tree new); or alternatively cgraph_remove_edge_from_call_stmt () and
cgraph_add_edge_from_call_stmt () and call those two
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-28 12:34 ---
Not folding CALL_EXPRs would introduce a regression on g++.dg/opt/devirt1.C,
after all fold_marked_statements has been added exactly to fix that regression:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00165.html
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-01-28 14:40
---
Testing a patch.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dominiq at lps dot ens dot fr 2008-01-28 14:33 ---
The polyhedron test aermod.f90 fails with:
aermod.f90: In function 'wake_dfsn2':
aermod.f90:37741: error: unrecognizable insn:
(insn 574 3142 575 38 (parallel [
(set (reg:V4SF 188 [ vect_cst_.30783 ])
--- Comment #6 from jason at gcc dot gnu dot org 2008-01-28 15:38 ---
Not going to bother fixing on other branches.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.3.0
I run built-in-setjmp.c testcase (taken from gcc.c-torture/execute dir);
first with -fprofile-generate -freorder-blocks-and-partition
and then with -fprofile-use -freorder-blocks-and-partition
under x86_64 and ppc64-linux with r131883 mainline and I get the ICE:
This seems to be a common vendor extension. Example:
REAL*4 PLT$C_HOUSTPIX
INTEGER PLT$C_COMMAND
PARAMETER (PLT$B_OPC=0)
common /abc$def/ PLT$C_HOUSTPIX, PLT$C_COMMAND
end
This compiles using NAG f95 (with the warning Extension: Name contains $
character) and with
--- Comment #13 from jason at gcc dot gnu dot org 2008-01-28 16:28 ---
Subject: Bug 33959
Author: jason
Date: Mon Jan 28 16:27:17 2008
New Revision: 131907
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131907
Log:
PR c++/27177
* class.c (build_base_path): Fix
--- Comment #14 from jason at gcc dot gnu dot org 2008-01-28 16:28 ---
Fixed in all open branches.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from jason at gcc dot gnu dot org 2008-01-28 16:19 ---
Subject: Bug 27177
Author: jason
Date: Mon Jan 28 16:18:56 2008
New Revision: 131905
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131905
Log:
PR c++/27177
* class.c (build_base_path): Fix
--- Comment #1 from eres at il dot ibm dot com 2008-01-28 15:22 ---
Created an attachment (id=15037)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15037action=view)
the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
--- Comment #30 from jason at gcc dot gnu dot org 2008-01-28 16:28 ---
Subject: Bug 27177
Author: jason
Date: Mon Jan 28 16:27:17 2008
New Revision: 131907
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131907
Log:
PR c++/27177
* class.c (build_base_path): Fix
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-28 17:09 ---
Thanks for the pointer. I think we need in general to update some of the error
message to point to the relevant option. (For the most common, namely
-fno-range-check we do so already; for -std=f* related ones we
--- Comment #4 from aldot at gcc dot gnu dot org 2008-01-28 17:30 ---
Invalid code should be diagnosed. Since this particular case even has a flag to
accept the invalid code, the hard error is fine IMHO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34997
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-01-28 14:45 ---
Confirmed.
Interestingly:
$ cat pr31463.f90
FUNCTION test() RESULT(f)
REAL :: f ! removed DIMENSION statement
END FUNCTION test
$ gfortran-svn -g -Wall -c pr31463.f90
pr31463.f90:1.25:
gcc.c-torture/execute/20040709-1.c fails for -EL -mips16 -O3 with:
20040709-1.c:93: internal compiler error: in insert_save, at caller-save.c:745
This is due to the new subreg liveness checking. We have a bb with:
A: call
...
B: set of (subreg:HI (reg:SI foo))
...
C: use of
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-28 16:34 ---
See also
http://gcc.gnu.org/ml/fortran/2007-01/msg00060.html
specifically the PS ... -fdollar-ok there.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rsandifo at gcc dot gnu dot org 2008-01-28 13:43
---
This isn't the same thing as PR34856.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from froydnj at gcc dot gnu dot org 2008-01-28 18:32 ---
Subject: Bug 31535
Author: froydnj
Date: Mon Jan 28 18:31:19 2008
New Revision: 131914
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131914
Log:
gcc/
PR 31535
* config/rs6000/rs6000.c
When including a system header in a namespace followed by another system header
seems to prevent declarations being recognized in the headers or some such.
Even happens when the headers are both the same.
Example code:
#ifndef APP_H
#define APP_H
namespace win
{
#include string
}
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-01-28 19:03 ---
Subject: Bug 34980
Author: tkoenig
Date: Mon Jan 28 19:02:47 2008
New Revision: 131915
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131915
Log:
2008-01-27 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-28 17:26 ---
Subject: Bug 34980
Author: burnus
Date: Mon Jan 28 17:25:55 2008
New Revision: 131913
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131913
Log:
2008-01-28 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #11 from ian at gcc dot gnu dot org 2008-01-28 19:44 ---
Subject: Bug 34862
Author: ian
Date: Mon Jan 28 19:43:51 2008
New Revision: 131916
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131916
Log:
PR c++/34862
PR c++/33407
*
--- Comment #18 from aldot at gcc dot gnu dot org 2008-01-28 17:59 ---
Created an attachment (id=15038)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15038action=view)
use conditional $(BUILD_INFO) variable for prerequs of info and install-info
targets
Use the variable
--- Comment #6 from hubicka at ucw dot cz 2008-01-28 20:51 ---
Subject: Re: [4.3 regression] ICE with -fipa-cp -ffast-math
No, I mean providing something like cgraph_update_edges_for_call_stmt (tree
old, tree new); or alternatively cgraph_remove_edge_from_call_stmt () and
--- Comment #20 from aldot at gcc dot gnu dot org 2008-01-28 20:43 ---
(In reply to comment #19)
In your patch, why does install-info still need doc and installdirs
dependencies when BUILD_INFO is not set? If those things still need to
happen,
shouldn't they be dependencies of
Part of original report:
I have recently had the chance to compile some code using -Wconversion and a
loop that may iterate more than 2.2 billion times. There is a compiler warning
of this sort which I cannot resolve:
nell:~/work/bit barnes$ gfortran -Wconversion -o t.x testcase.f
--- Comment #10 from ian at airs dot com 2008-01-28 18:12 ---
I'm not proposing to remove CHANGE_DYNAMIC_TYPE_EXPR from 4.3 at this point.
We have some experience with it in, and I don't think we should take it out.
I haven't looked at the actual bug here yet, I was responding to your
--- Comment #19 from mmitchel at gcc dot gnu dot org 2008-01-28 18:12
---
In your patch, why does install-info still need doc and installdirs
dependencies when BUILD_INFO is not set? If those things still need to happen,
shouldn't they be dependencies of some other target? Logically,
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-28 18:09 ---
I think the size is simply calculated as:
ubound[n] + 1 - lbound[n];
which means:
5+1-8 = -2
At some point the variable is regarded as unsigned which means (for 8 byte
variables): 18446744073709551614, which is
--- Comment #15 from dgregor at gcc dot gnu dot org 2008-01-28 21:35
---
Thanks everyone; I can reproduce this on i686-pc-linux-gnu. Patch in the works.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from burnus at gcc dot gnu dot org 2008-01-28 17:39 ---
The commit fixed the SHAPE(scalar) problem in the front end. For the library to
do:
a) The following should print 1 0 but it prints 1 -8:
integer :: i,j, a(10,10),res(2)
j = 1
i = 10
res = shape(a(1:1,i:j:1))
print
test.h:
struct Base
{
virtual int getX() const=0;
};
template typename ThisType class Derived1: public Base
{
protected:
static const int X;
public:
virtual int getX() const{ return X; }
};
templateint id class Derived2 : public
--- Comment #7 from jason at gcc dot gnu dot org 2008-01-28 16:33 ---
The version with class is also valid.
14.6p5: A qualified name used as the name in a mem-initializer-id, a
base-specifier, or an elaborated-type-specifier is implicitly assumed to name a
type, without the use of the
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-28 21:47 ---
Confirmed.
Also wrong:
gcc/ipa-struct-reorg.c:sum_counts (d_str str, gcov_type *hotest)
gcc/ipa-struct-reorg.c: if (str-count *hotest)
gcc/ipa-struct-reorg.c:*hotest = str-count;
gcc/ipa-struct-reorg.c:
--- Comment #12 from ian at airs dot com 2008-01-28 21:52 ---
Created an attachment (id=15039)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15039action=view)
Possible patch
Here is a very ugly patch which appears to fix the problem in mainline. I
haven't tested it, though. Any
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-01-28 21:52 ---
This is fixed on the trunk. Marking it as such...
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from ian at gcc dot gnu dot org 2008-01-28 19:44 ---
Subject: Bug 33407
Author: ian
Date: Mon Jan 28 19:43:51 2008
New Revision: 131916
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131916
Log:
PR c++/34862
PR c++/33407
*
--- Comment #7 from dgregor at gcc dot gnu dot org 2008-01-28 22:05 ---
Darn! Mine again.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-01-28 21:58 ---
Yep, we should be diagnosing but this error but we aren't. I'm on it.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-01-28 19:07 ---
Fixed on trunk.
Closing (so we're one regression down).
(In reply to comment #7)
The commit fixed the SHAPE(scalar) problem in the front end.
a) The following should print 1 0 but it prints 1 -8:
integer ::
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
Last reconfirmed|2008-01-28 09:16:56 |2008-01-28
--- Comment #4 from jason at gcc dot gnu dot org 2008-01-28 16:34 ---
As explained in 32029, this code is valid. Fixed by the patch for 33959.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dgregor at gcc dot gnu dot org 2008-01-28 21:59 ---
Confirmed. This is mine.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
In gcc/params.def there is a message
The threshold ratio between current and hotest structure counts
Unless I'm mistaken, the correct spelling is hottest.
--
Summary: Incorrect spelling of hottest
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-28 19:02 ---
This is working as designed. Why are you doing #include inside a namespace
anyways?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from danglin at gcc dot gnu dot org 2008-01-28 22:19 ---
This was introduced by the addition of generic TLS support.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
From PR 34980, comment#7 by Tobias Burnus:
a) The following should print 1 0 but it prints 1 -8:
integer :: i,j, a(10,10),res(2)
j = 1
i = 10
res = shape(a(1:1,i:j:1))
print *, res
res = shape(a(1:1,j:i:-1))
print *, res
end
Not a regression.
--
Summary: shape for negative sizes
--- Comment #7 from aesok at gcc dot gnu dot org 2008-01-28 22:49 ---
Fixed in HEAD (4.3)
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jason at gcc dot gnu dot org 2008-01-28 22:01 ---
changed target milestone.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #19 from dorit at gcc dot gnu dot org 2008-01-28 13:20 ---
Fixed?
In a way, yes. The problem is avoided by generating too conservative code.
AFAIU, a better solution may be expected in 4.4 from the stack alignment
branch. In any case this segfault PR can be closed, and
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-28 22:08 ---
This one's mine.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from aesok at gcc dot gnu dot org 2008-01-28 22:40 ---
Subject: Bug 34412
Author: aesok
Date: Mon Jan 28 22:39:11 2008
New Revision: 131923
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131923
Log:
PR target/34412
* config/avr/avr.c
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-28 17:21 ---
I always wonder if a hard error is really necessary for such cases? would not a
warning be sufficient? I think there is a flag to change warnings to errors if
necessary (-Werror?).
--
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-28 23:40 ---
There are some problems with the example code. For example, the expression
maxT, Params does not expand the parameter pack Params. The compiler should
have warned you about this, both in this case and in the
--- Comment #2 from tbm at cyrius dot com 2008-01-29 00:18 ---
Created an attachment (id=15042)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15042action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35006
--- Comment #1 from tbm at cyrius dot com 2008-01-29 00:17 ---
Program received signal SIGSEGV, Segmentation fault.
remove_unused_locals () at gcc/tree-ssa-live.c:587
587 var_ann (t)-used = false;
(gdb) where
#0 remove_unused_locals () at gcc/tree-ssa-live.c:587
#1
With trunk:
(sid)4409:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -O3
~/grub2-cmdline.i
/home/tbm/src/grub2-1.95+20080128/normal/cmdline.c: In function
'grub_cmdline_get':
/home/tbm/src/grub2-1.95+20080128/normal/cmdline.c:216: internal compiler
error: Segmentation fault
Please submit
--- Comment #2 from michael dot meissner at amd dot com 2008-01-29 00:10
---
Created an attachment (id=15041)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15041action=view)
Traceback for 35005
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35004
If I add 4 more tree codes to tree.def, it causes a segmentation violation in
building libstdc++ pre-compiled header files.
Here is the patch to add 4 more tree codes:
--- gcc/tree.def.~1~2007-11-01 11:59:47.0 -0400
+++ gcc/tree.def2008-01-28 16:01:36.0 -0500
@@ -682,6
--- Comment #1 from michael dot meissner at amd dot com 2008-01-29 00:04
---
Created an attachment (id=15040)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15040action=view)
Preprocessed file from the build of the libstdc++ pre-compiled headers
File is bzip2'ed -9.
--
The new testcase execute/20071211-1.c assumes 32 bit integers and fails on
machines with 16 bit integers.
--
Summary: New testcase execute/20071211-1.c assumes 32 bit
integers
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-29 00:15 ---
I think this is the same as PR 34397 really.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-01-29 00:17 ---
I think this is basically fixed with the pointer plus work I did.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16187
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-01-29 00:19 ---
With the trunk we get:
return *(data + (long unsigned int) j * 4);
Which is much better. The cast is still needed though.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from michael dot meissner at amd dot com 2008-01-29 00:39
---
Created an attachment (id=15043)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15043action=view)
Proposed patch to fix the problem
The problem is cp/cp-tree.h stores the tree_code in 8 bits, but the tree
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-29 00:48 ---
Here is a reduced testcase:
typedef unsigned long grub_uint64_t;
typedef grub_uint64_t grub_size_t;
grub_cmdline_get (
unsigned max_len,
int echo_char
)
{
unsigned xpos, ypos, ystart;
grub_size_t lpos, llen;
This is a very latent regression at most introduced under 48 hours. I will
attach preprocessed file.
--
Summary: [4.3 Regression] Firefox fails to build with
affentry.cpp:94: error: ISO C++ forbids subscripting
non-lvalue array
--- Comment #1 from ismail at pardus dot org dot tr 2008-01-29 01:04
---
Created an attachment (id=15044)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15044action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35007
--- Comment #3 from ismail at pardus dot org dot tr 2008-01-29 01:07
---
Compilation line is :
c++ -o affentry.o -c -I../../../../dist/include/system_wrappers -include
../../../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM
-DEXPORT_XPT_API -DEXPORT_XPTC_API
--- Comment #7 from roger at eyesopen dot com 2008-01-29 01:12 ---
I'm also seeing this same failure with make profiledbootstrap on
x86_64-unknown-linux-gnu. A make bootstrap on the same machine completes and
regression tests fine (14 unexpected failures in gcc). I suspect that the
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-01-29 01:26 ---
Mine. For patch, see URL above.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
20080128 [trunk revision 131899] (Pardus Linux)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35007
--- Comment #5 from ismail at pardus dot org dot tr 2008-01-29 02:11
---
Yes it works if you revert c++/27177 fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35007
--- Comment #4 from pcarlini at suse dot de 2008-01-29 02:05 ---
This is a reduced snippet (-pedantic). I suspect the problem may have to do
with the fix for c++/27177, let's CC Jason...
struct AffEntry
{
union {
char base[256];
} conds;
};
struct PfxEntry
: public AffEntry
{
1 - 100 of 114 matches
Mail list logo
