I'm writing a decoder using a meta programming techniques alla
boost::mpl and I'd like to know if I'm asking too much of the compiler.
Basically I've got lots of packet types with different ids. The
classical way to write these would be a switch case
int id;
switch(id){
On Wed, Jul 28, 2010 at 4:37 PM, Hite, Christopher
christopher.h...@partner.commerzbank.com wrote:
I'm writing a decoder using a meta programming techniques alla
boost::mpl and I'd like to know if I'm asking too much of the compiler.
Basically I've got lots of packet types with different
On 07/28/10 09:37, Hite, Christopher wrote:
[snip]
I'm tring to use the template compiler to generate equivalent code. I
have a mpl::list of packet descriptions like this:
struct Packet1{
static const int id=1;
void decode();
};
I then use
Mark Mitchell wrote:
As before, feel free to put questions that you would like to ask on this
Wiki page:
I failed to include the URL.
It is:
http://gcc.gnu.org/wiki/Release%20Manager%20Q%26A
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Generally without knowing the compiler version you are using
it is hard to tell.
I'll use whatever's best. Right now I'm still on 4.4.3. I'll probably
upgrade soon to 4.5.
The same is true without a complete compilable testcase.
I didn't want to make a test case that depends on boost::mpl.
On 07/28/10 10:53, Hite, Christopher wrote:
[snip]
struct DecodeContext;
struct M1{
static const int id=1;
static void decode(DecodeContext ){}
};
struct M2{
static const int id=2;
static void decode(DecodeContext ){}
};
struct M3{
static const int
Hi,
2010/7/28 Hite, Christopher christopher.h...@partner.commerzbank.com:
Generally without knowing the compiler version you are using
it is hard to tell.
I'll use whatever's best. Right now I'm still on 4.4.3. I'll probably
upgrade soon to 4.5.
The same is true without a complete
On 07/28/10 13:16, Piotr Rak wrote:
[snip]
Or you could just initialize static array of pointers, like that
(please note, that I never compiled code below):
[snip]
Piotr, something similar was proposed here:
On Tue, Jul 27, 2010 at 10:25 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Why not just ignore RMS and the license issues and simply do what we
think suits us and the project. Let the FSF deal with the legal consequences,
they put us in this messy situation, they deal with it.
It
Steven Bosscher wrote:
Why not just ignore RMS and the license issues and simply do what we
think suits us and the project. Let the FSF deal with the legal
consequences,
they put us in this messy situation, they deal with it.
It seems to me that escalating the issue is more helpful. GCC
On Wed, Jul 28, 2010 at 11:17 PM, Mark Mitchell m...@codesourcery.com wrote:
Steven Bosscher wrote:
Why not just ignore RMS and the license issues and simply do what we
think suits us and the project. Let the FSF deal with the legal
consequences,
they put us in this messy situation, they
On Thu, Jul 29, 2010 at 12:08 AM, Steven Bosscher stevenb@gmail.com wrote:
On Wed, Jul 28, 2010 at 11:17 PM, Mark Mitchell m...@codesourcery.com wrote:
Steven Bosscher wrote:
Why not just ignore RMS and the license issues and simply do what we
think suits us and the project. Let the FSF
WinAVR needs register r10 (among others) for certain mathematical operations of
the long long data type, e.g. when calling __muldi3.
The user may declare r10 to be assigned to a register variable.
When this combination occurs, code will not execute correctly.
This is specifically an issue when the
--- Comment #13 from ubizjak at gmail dot com 2010-07-28 06:24 ---
Reopened.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #4 from siarhei dot siamashka at gmail dot com 2010-07-28
07:16 ---
Could not reproduce the problem with gcc 4.3.5
Disassembly of pr45070.o:
000c next:
c: e92d401fpush{r0, r1, r2, r3, r4, lr}
10: e89cldm r0, {r2, r3}
14:
--- Comment #5 from siarhei dot siamashka at gmail dot com 2010-07-28
07:18 ---
The disassembly chunk from the comment above was from gcc 4.5.0, using '-Os
-match=armv5te' options.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
--- Comment #2 from kazuhiro dot inaoka dot ud at renesas dot com
2010-07-28 07:19 ---
(In reply to comment #1)
Hi Nick
Thank you for your reply.
Your example is OK.
But I'm not clear.
extension being performed. Eg:
int bar (int a) { return a func(); }
If the func() is
--- Comment #26 from burnus at gcc dot gnu dot org 2010-07-28 07:41 ---
I expect a similar problem for derived types from modules which are external -
in that case the place to modify would be gfc_get_derived_type -- cf. PR 45077.
Also here, the proper gsym will not be available if the
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-28 07:43 ---
Patch. Note: It still fails if one moves module iso_red into a separate file.
Cf. PR 44945. The reason is that then gsym will come up as NULL and every
module user uses a different decl.
Index: trans-types.c
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-07-28 07:44
---
Subject: Bug 44993
Author: ebotcazou
Date: Wed Jul 28 07:44:34 2010
New Revision: 162618
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162618
Log:
PR middle-end/44790
PR middle-end/44993
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-07-28 07:44
---
Subject: Bug 44790
Author: ebotcazou
Date: Wed Jul 28 07:44:34 2010
New Revision: 162618
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162618
Log:
PR middle-end/44790
PR middle-end/44993
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-07-28 07:47
---
Thanks for reporting the problem.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ramana at gcc dot gnu dot org 2010-07-28 08:03 ---
I've been looking at this with respect to trunk bootstrapping on armv7a-linux
platforms.
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02102.html
See if the patches in that trail fix your bug.
--
ramana at gcc
gcc version:
ma...@pc-31c:~/TTT/GccTestcaseReduction gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/marco/local/gcc-4.5.0/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-threads=posix
--- Comment #1 from morandini at aero dot polimi dot it 2010-07-28 08:07
---
Created an attachment (id=21329)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21329action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45100
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 08:11
---
Ramana,
I confirmed that your patch fixes this PR moments before you posted you
comment. It's a dup of 45067.
*** This bug has been marked as a duplicate of 45067 ***
--
mkuvyrkov at gcc dot gnu dot org
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 08:11
---
*** Bug 45097 has been marked as a duplicate of this bug. ***
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-07-28 08:16
---
Fixing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-28 08:23 ---
Can't reproduce with current 4.5 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45100
Command line:
$ gcc O[123s] -fgcse -fgcse-las testcase.c
Compiler output:
$ gcc -O -fgcse -fgcse-las testcase.c
testcase.c: In function 'foo':
testcase.c:11:1: internal compiler error: in insert_expr_in_table, at
gcse.c:1213
Please submit a full bug report,
with preprocessed source if
--- Comment #1 from zsojka at seznam dot cz 2010-07-28 08:28 ---
Created an attachment (id=21330)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21330action=view)
reduced testcase
Most of the files I tested crash with -fgcse-las.
--
--- Comment #6 from siarhei dot siamashka at gmail dot com 2010-07-28
08:37 ---
'arm_size_return_regs()' returns 2 when generating epilogue for 'next' function
here. And as a result, return value not registered in the mask, causing it to
be clobbered.
Would the following patch be the
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-28 08:44 ---
Subject: Bug 45077
Author: burnus
Date: Wed Jul 28 08:44:29 2010
New Revision: 162619
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162619
Log:
2010-07-28 Tobias Burnus bur...@net-b.de
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-28 08:47 ---
Fixed for the unmodified example in comment 1 - and also for PR 40011 comment
47.
However, the following remains to be done: It still fails if one moves module
iso_red into a separate file (cf. PR 44945). The reason
--- Comment #7 from ramana at gcc dot gnu dot org 2010-07-28 09:01 ---
Thanks for the analysis, yes that appears to be the nub of the problem with the
result being removed . I see the same problem on trunk -
Patches should however be submitted to gcc-patc...@gcc.gnu.org after
the gcc version, system type, and options given when GCC configured/built:
ycw...@ycwang-laptop:/home/my_codes/Android/linux-2.6$ arm-eabi-gcc -v
Using built-in specs.
Target: arm-eabi
Configured with:
/home/jingyu/projects/gcc/android-toolchain/gcc-4.4.0/configure
--prefix=/usr/local
--- Comment #8 from ramana at gcc dot gnu dot org 2010-07-28 09:22 ---
(In reply to comment #7)
Thanks for the analysis, yes that appears to be the nub of the problem with
the
result being removed . I see the same problem on trunk -
I just realized that this is a packed
--- Comment #1 from ubizjak at gmail dot com 2010-07-28 09:25 ---
Please attach preprocessed source, see [1] for detailed instructions.
[1] http://gcc.gnu.org/bugs/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45102
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-28 09:32 ---
Patch. It fixes also test_fpu.f90 - however, for gas_dyn.f90 it causes a
segfault:
==24597== Invalid read of size 8
==24597==at 0x5A8DF3: ggc_set_mark (ggc-page.c:600)
==24597==by 0x73CD54:
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-07-28 09:32
---
I suppose that
uy = -ux;
is really
uy = (unsigned char) -(int) ux;
as unsigned char promotes to int. We then incorrectly
narrow this to -(signed char) ux.
We do this again in convert_to_integer. Our
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-28 09:34 ---
Can reproduce with 4.5.0, fixed for 4.5.1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-07-28 09:34
---
(In reply to comment #8)
I just realized that this is a packed structure and probably need to look up
the semantics of this in the AAPCS. IIRC the AAPCS states that it doesn't
support packed structures or
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu dot
|
--- Comment #10 from mikpe at it dot uu dot se 2010-07-28 09:45 ---
(In reply to comment #8)
I just realized that this is a packed structure and probably need to look up
the semantics of this in the AAPCS. IIRC the AAPCS states that it doesn't
support packed structures or bitfields
Use -g -O2.
DW_OP_reg5 is there valid for each PC, despite there si a `call' and reg5 is
caller-saved register. Its value therefore gets corrupted in the callee.
FAIL all these:
gcc (GCC) 4.6.0 20100724 (experimental)
gcc (GCC) 4.5.1 20100728 (prerelease)
gcc (GCC) 4.4.5 20100724 (prerelease
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-07-28 09:54
---
Created an attachment (id=21331)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21331action=view)
.s files for x86_64-unknown-linux-gnu.
GDB bug (probably invalid):
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 10:03
---
This is due to a silly mistake of mine. I got operand ordering of
insert_expr_in_table() wrong for -fgcse-las case. Will check in an obvious
patch in several minutes.
--
mkuvyrkov at gcc dot gnu dot org
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-07-28 10:03
---
Subject: Bug 44885
Author: ebotcazou
Date: Wed Jul 28 10:03:00 2010
New Revision: 162621
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162621
Log:
PR tree-optimization/44885
* tree-sra.c
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-28 10:03 ---
Created an attachment (id=21332)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21332action=view)
gcc46-pr45103.patch
For noreturn calls that end the function we were ignoring even
NOTE_DURING_CALL_P notes,
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-07-28 10:04
---
Schedule of variations:
unix/-m32
Running target unix/-m32
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 10:10
---
Subject: Bug 45101
Author: mkuvyrkov
Date: Wed Jul 28 10:09:53 2010
New Revision: 162622
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162622
Log:
PR rtl-optimization/45101
* gcse.c
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 10:14
---
Should be fixed by the above patch.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-28 10:17 ---
Could you please commit the testcase too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45101
At revision 162617, bootstrap fails with:
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/cp/decl.o differs
make[2]: ***
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 10:32
---
Done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45101
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 10:32
---
Subject: Bug 45101
Author: mkuvyrkov
Date: Wed Jul 28 10:32:10 2010
New Revision: 162623
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162623
Log:
PR rtl-optimization/45101
*
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-07-28 10:33
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-07-28 10:33
---
Subject: Bug 44903
Author: rguenth
Date: Wed Jul 28 10:32:54 2010
New Revision: 162624
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162624
Log:
2010-07-28 Richard Guenther rguent...@suse.de
PR
Compiler output:
$ gcc -Os -fcompare-debug testcase.c
gcc: error: testcase.c: -fcompare-debug failure
Tested revisions:
r162618 - fail
r162456 - OK
--
Summary: [4.6 Regression] -fcompare-debug failure at -Os
Product: gcc
Version: 4.6.0
Status:
--- Comment #1 from zsojka at seznam dot cz 2010-07-28 10:41 ---
Created an attachment (id=21333)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21333action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45105
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-28 11:41 ---
Created an attachment (id=21334)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21334action=view)
gcc46-pr43912.patch
Untested proof of concept patch (which handles just non-templates though).
The captured vars
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-28 11:43 ---
Reproduced and works with -fno-var-tracking-assignments. Looking into it.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Casting a variadic function pointer to normal function pointer (with adequate
number and type of arguments) causes a segfault, when the function is called.
Vice versa (casting normal function pointer to variadic function) works fine.
The problem only occurs for 64bit builds. Casting works nice in
--- Comment #1 from robert dot haschke at uni-bielefeld dot de 2010-07-28
11:52 ---
Created an attachment (id=21335)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21335action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45106
--- Comment #2 from robert dot haschke at uni-bielefeld dot de 2010-07-28
11:53 ---
Created an attachment (id=21336)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21336action=view)
original .c file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45106
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-28 11:57 ---
Don't do it, it is not valid.
The x86-64 ABI requires that for varargs the %al register contains number of
SSE regs that need saving, while for non-varargs functions that register is
undefined.
--
jakub at gcc dot
--- Comment #4 from rhaschke at techfak dot uni-bielefeld dot de
2010-07-28 12:04 ---
Subject: Re: casting of variadic function pointers to normal
function pointers causes segfaults on 64bit systems
I was afraid of this answer.
However in my application, I have no clue which type of
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-07-28 12:23
---
Works.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from schwab at linux-m68k dot org 2010-07-28 12:26 ---
Calling a function with a different signature than declared is undefined in any
case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45106
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-28 12:35 ---
Minimal test case, compile with:
gfortran --param ggc-min-expand=0 --param ggc-min-heapsize=0
module INTS
interface
subroutine NEXT
end subroutine NEXT
subroutine VALUE()
end subroutine VALUE
--- Comment #13 from mikael at gcc dot gnu dot org 2010-07-28 12:45 ---
(In reply to comment #12)
It seems a namespace is freed to soon.
Reminder to self: symbol.c's build_formal_args creates a namespace for
c_f_pointer and c_f_proc_pointer. May be related.
--
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-28 13:14 ---
(In reply to comment #3)
Minimal test case, compile with:
gfortran --param ggc-min-expand=0 --param ggc-min-heapsize=0
The problems seems to be that one tries to free the NEXT twice - once for the
symbol in
--- Comment #1 from dominiq at lps dot ens dot fr 2010-07-28 13:15 ---
Narrower window: revision 162585 bootstraps, 162601 fails.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45104
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-28 13:36 ---
Created an attachment (id=21337)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21337action=view)
gcc46-pr45105-1.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45105
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-28 13:51 ---
(In reply to comment #3)
Minimal test case, compile with:
There is something odd: If one has the order
subroutine VALUE()
subroutine NEXT
it actually works; one then goes
gfc_create_function_decl for
--- Comment #3 from nickc at redhat dot com 2010-07-28 13:55 ---
Created an attachment (id=21338)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21338action=view)
Force functions that return small unsigned values to use zero-extension
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-28 14:01 ---
(In reply to comment #4)
Subject: Re: casting of variadic function pointers to normal
function pointers causes segfaults on 64bit systems
I was afraid of this answer.
However in my application, I have no
--
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=45104
--- Comment #4 from nickc at redhat dot com 2010-07-28 14:05 ---
Hi Kazuhiro-san,
If the func() is external function, output code is the following.
bsr_func
mouv.B r1, r1
If the return value is zero exteneded,
movu.B r1, r1 code can be removed.
Not really. The problem is
--
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 #13 from mikpe at it dot uu dot se 2010-07-28 14:13 ---
I've bootstrapped and regtested Richard's proposed fix
(http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02161.html) on top of a recent
4.5 snapshot, and it fixed the test case (and the original code it was based
on) with
This is in r162622, after fixing PR45101.
Compiler output:
$ gcc -Os -fgcse-las testcase.c
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: in insert_expr_in_table, at
gcse.c:1213
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #1 from zsojka at seznam dot cz 2010-07-28 14:18 ---
Created an attachment (id=21339)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21339action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45107
--
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=45107
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 14:25
---
Mine.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-28 14:32 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-28 14:43 ---
This seems fixed, just the optimizations in question are already performed
partly by FRE but one,
test2 (struct foo2 * x)
{
...
bb 2:
D.2745_3 = BIT_FIELD_REF *x_2(D), 8, 0;
D.2746_4 = D.2745_3 1;
if
gfortran simply continues (with a warning) if one has a wrong namelist in
STDIN.
If one has an IOSTAT variable, it prints the warning but continues with an
IOSTAT == 0.
Using any other means of input (internal unit, external unit) works as
expected, i.e. run-time error - or a non-zero return
--- Comment #5 from danglin at gcc dot gnu dot org 2010-07-28 15:00 ---
(In reply to comment #4)
While the ICE nominally results from a hash lookup failure, replacing
libiberty.a with the stage1 version makes no difference. Thus, it
doesn't appear that the problem is with the hash
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-28 15:01 ---
That seemingly goes back to implementing support for:
+/* If the namelist read is from stdin, output the current state of the
+ namelist to stdout. This is used to implement the non-standard query
+ features, ?
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-28 15:07 ---
See also: http://gcc.gnu.org/onlinedocs/gfortran/Extensions-to-namelist.html
I understand the support of ? and =?, but why can't one give a proper error is
one returns? If one starts a dialog with ? / =?, one stays
--- Comment #6 from danglin at gcc dot gnu dot org 2010-07-28 15:15 ---
2609 assumption = simplify_gen_relational (NE, SImode, mode, tmp,
const0_rtx);
For some reason, 0 is being passed instead of const0_rtx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45063
--- Comment #7 from danglin at gcc dot gnu dot org 2010-07-28 15:33 ---
0x00317ea8 find_simple_exit+5636: ldw -cc(sp),r19
0x00317eac find_simple_exit+5640: copy ret0,r23
0x00317eb0 find_simple_exit+5644: stw r19,-34(sp)
0x00317eb4 find_simple_exit+5648: copy r5,r24
--- Comment #14 from mikpe at it dot uu dot se 2010-07-28 15:38 ---
If I apply Richard's patch to gcc-4.4-20100727 and bootstrap/regtest the new
test case works but I get a single regression in the old ones:
FAIL: gcc.dg/vect/vect-22.c scan-tree-dump-times vect vectorized 4 loops 1
--- Comment #8 from bernds at gcc dot gnu dot org 2010-07-28 15:46 ---
It sounds like the compiler is being miscompiled? If so, it's probably not
helpful trying to debug the miscompiled compiler binary. The best way to debug
this would be to produce one working build and one failing
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-28 15:51 ---
Bootstrap fails also at revision 162600. I also tried revisions 162592 and
162593, but they fails earlier with:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 16:01
---
Can you please try the latest trunk with the patch in
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02185.html applied?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45104
--- Comment #4 from dominiq at lps dot ens dot fr 2010-07-28 16:04 ---
Can you please try the latest trunk with the patch in
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02185.html applied?
This is what I am trying right now. Allow for 45 minutes to have an answer.
--
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 16:14
---
Patch posted in http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02192.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45107
--- Comment #5 from dominiq at lps dot ens dot fr 2010-07-28 16:47 ---
Can you please try the latest trunk with the patch in
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02185.html applied?
This is what I am trying right now. Allow for 45 minutes to have an answer.
At revision
1 - 100 of 154 matches
Mail list logo
