--- Comment #2 from monaka at monami-software dot com 2010-01-18 08:01
---
There has a similar issue under h8300-elf target.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42787
--- Comment #3 from laurent at guerby dot net 2010-01-18 08:41 ---
Same result for me with 4.4.3 RC1. backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x004ca580 in copy_virtual_operands ()
Current language: auto; currently asm
(gdb) bt
#0 0x004ca580 in copy_virtual_ope
--- Comment #10 from ubizjak at gmail dot com 2010-01-18 08:42 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00958.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from singler at kit dot edu 2010-01-18 09:08 ---
Paolo, you were right, it was just the fallback switch missing for this case.
And since this specific test issues many thousands of calls with very small
input, the overhead was very noticeable. Patch upcoming...
--
h
When I try to compile the program that
ueses boost, for sh4 target, I am getting
the undefined reference errors.
I'll attach the test-case for that, you
just type "make" to see the errors.
The makefile greps the output because there
are much more undefined references to the
other components of the
--- Comment #1 from stsp at users dot sourceforge dot net 2010-01-18 09:10
---
Created an attachment (id=19645)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19645&action=view)
test-case
untar and type "make"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42789
--- Comment #2 from stsp at users dot sourceforge dot net 2010-01-18 09:15
---
boost is 1.39.0, other versions may not trigger
that problem is seems...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42789
--- Comment #8 from pault at gcc dot gnu dot org 2010-01-18 09:54 ---
This PR has me somewhat flummoxed. I have changed the title to reflect the
fact that it does not matter if the component is allocatable or a pointer.
Also, a component reference of an allocatable array of derived type
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-18 09:57 ---
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-01-18 09:57 ---
Subject: Bug 42781
Author: rguenth
Date: Mon Jan 18 09:57:11 2010
New Revision: 156006
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156006
Log:
2010-01-18 Richard Guenther
PR tree-optimization/
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-01-18 10:07
---
I'm running into this as well, but with code that clearly compiled fine with
gcc 4.4. So maybe it's a slightly different issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-18 10:13 ---
Reproduced. Works with -fno-var-tracking-assignments, and looks to be a
var-tracking.c problem - the testcase doesn't contain (and doesn't need to
contain) any DEBUG_INSNs.
--
jakub at gcc dot gnu dot org changed:
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-18 10:20
---
First, try with a current, maintained GCC, gcc4.3.x or better, gcc.4.4.x. If
the problem persists to these days, we need a self-contained reproducer.
Thanks.
--
paolo dot carlini at oracle dot com changed:
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-18 10:21 ---
You certainly want to report this to redhat instead.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-18 10:23 ---
It rather seems you do not have proper target headers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42787
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Known to fail|4.3.4 4.4.3 |4.3.4 4.4.
$ cc1 -msx _muldi3.i -g
__muldi3
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
Assembling functions:
__muldi3
../../../../../../../libgcc/../gcc/libgcc2.c: In function e__muldi3f:
../../../../../../../libgcc/../gcc/libgcc2.c:562:1: internal compiler e
--- Comment #11 from paolo dot carlini at oracle dot com 2010-01-18 10:46
---
If I understand correctly (thanks Richard for the quick and detailed analysis)
there is nothing C++0x specific in this target/optimization issue. Thus, I'm
removing the marker from the Summary and cleaning it.
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-18 10:47
---
It may cause *anything*, in any case inappropriate at this stabilization Stage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42697
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-18 10:57 ---
The problem is that dataflow_set_preserve_mem_locs and/or
dataflow_set_remove_mem_locs removes all MEMs (with the exception of those
referring to decl with 0 MEM_OFFSET in the first function) upon encountering a
CALL.
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2010-01-18
11:02 ---
(In reply to comment #1)
> work in progress patch
This seems to cause "*** No rule to make target `lto/@lto_binary_rea...@.o',
needed by `lto1'." error when build = host = target = i686-pc-linux-gnu
--
--- Comment #4 from davek at gcc dot gnu dot org 2010-01-18 11:05 ---
(In reply to comment #3)
> (In reply to comment #1)
>
> > work in progress patch
>
> This seems to cause "*** No rule to make target `lto/@lto_binary_rea...@.o',
> needed by `lto1'." error when build = host = target
--- Comment #27 from rguenth at gcc dot gnu dot org 2010-01-18 11:12
---
Testing a patch to do minimal surgery to restore previous behavior (thus, fix
this regression but not the fundamental frontend / middle-end problem).
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-18 11:21
---
Excellent. If possible, I would suggest removing my temporary hack from the
testcase together with the parallel-mode patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42712
--- Comment #2 from jwakely dot gcc at gmail dot com 2010-01-18 11:23
---
N.B. the Host/Target/Target fields are meant for the "host triplet" such as
i686-pc-cygwin
Feel free to include the snapshot date and OS details in the main report, but
putting them in the Host field just makes i
--- Comment #28 from rguenth at gcc dot gnu dot org 2010-01-18 11:24
---
Btw, get_pointer_alignment should get passed an access type to put it into
context. For alignment of say INDIRECT_REFs it would be the pointed-to type
but for function arguments in general it needs to be 'char' if
--- Comment #11 from dodji at gcc dot gnu dot org 2010-01-18 11:24 ---
It looks like the fix for PR42761 made the previous fix for this one (the one I
reverted) acceptable now.
I am waiting for Jason's comment at
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00964.html
--
http://gc
--- Comment #13 from dodji at gcc dot gnu dot org 2010-01-18 11:25 ---
Subject: Re: ice-on-legal-code: template class template
function local objects
> Ah, I see. So the reason it is not fixed in 4.5 is that it may cause new
> regressions?
Yes.
--
http://gcc.gnu.org/bugzilla/sho
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #5 from d dot g dot gorbachev at gmail dot com 2010-01-18
11:51 ---
> did you run autoconf?
Forgot to run it, to my disgrace. :) Sorry, false alarm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-01-18 11:43
---
(In reply to comment #28)
> Btw, get_pointer_alignment should get passed an access type to put it into
> context. For alignment of say INDIRECT_REFs it would be the pointed-to type
> but for function arguments in
Hello,
i posted a problem against boost::serialization.
(http://article.gmane.org/gmane.comp.lib.boost.user/54935).
But now i could track it down to boost::spirit.
I have extracted boost::serialization stuff , which is dealing with boost
spirit, in a mini demo program
(will attach tar file next).
--- Comment #13 from irar at il dot ibm dot com 2010-01-18 12:17 ---
Does something like this make sense? (With this patch we will never use peeling
for function parameters, unless the builtin returns OK to peel for packed
types).
Index: tree-vect-data-refs.c
==
--- Comment #1 from FBergemann at web dot de 2010-01-18 12:18 ---
Created an attachment (id=19646)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19646&action=view)
tar file with mini program sources & Makefile
Pls change the optimization level in Makefile to see the differences.
T
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-18
12:20 ---
Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks
Ada bootstrap
> --- Comment #16 from hubicka at gcc dot gnu dot org 2010-01-16 14:54
> ---
> Created an attachment (i
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-18 12:27
---
Please, try to reproduce the problem for a currently maintained GCC, thuse
either 4.3.x or, better, 4.4.x. In case, please provide a self-contained
reproducer in the form of a pre-processed file. For details se
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot
|dot org
--- Comment #6 from davek at gcc dot gnu dot org 2010-01-18 12:54 ---
(In reply to comment #5)
> > did you run autoconf?
>
> Forgot to run it, to my disgrace. :) Sorry, false alarm.
>
No need to apologise, thanks for testing on linux for me!
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #3 from FBergemann at web dot de 2010-01-18 12:55 ---
Hi Paolo,
i tested again with
1) gcc-4.1.2 package delivered from HP
(installed at /opt/hp-gcc-4.1.2/)
-> it works (no such problem)
But there were some warning for compilation
/var/tmp//ccgkYSFL.s: Assembler message
--- Comment #20 from hubicka at ucw dot cz 2010-01-18 12:57 ---
Subject: Re: [4.5 regression] ICE in
function_and_variable_visibility breaks Ada bootstrap
> This is really messy: maybe I'll have some more luck with a cross
> compiler.
Indeed it is. I will try, but I had proble
--- Comment #30 from rguenth at gcc dot gnu dot org 2010-01-18 12:59
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #31 from rguenth at gcc dot gnu dot org 2010-01-18 13:00
---
Subject: Bug 39954
Author: rguenth
Date: Mon Jan 18 12:59:50 2010
New Revision: 156008
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156008
Log:
2010-01-18 Richard Guenther
PR middle-end/39954
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-18 13:03 ---
This is a fwprop.c bug. In particular, that the
797 /* If target_insn comes right after def_insn, which is very common
798 for addresses, we can use a quicker test. */
799 if (NEXT_INSN (def_insn) == target_ins
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-18 13:05
---
Excellent that it works fine with current GCCs. Frankly, I'm thinking that as
far as GCC is concerned the issue can be closed here, maybe you should consider
pointing out to the spirit project the little tweak
--- Comment #10 from carlr at freemail dot gr 2010-01-18 13:14 ---
Please note that computed gotos are factored out because "they are a hell to
deal with" in tree-cfg.c:build_gimple_cfg(). This means that they MUST be
unfactored out as promised in the comment without leaving this to anot
--- Comment #5 from FBergemann at web dot de 2010-01-18 13:31 ---
Hi Paolo,
well switching to more recent version might be a solution
- but unfortunately not that easy to implement for me.
It's a big project i am working in.
Switching the compiler means invoking our release management t
--- Comment #6 from paolo dot carlini at oracle dot com 2010-01-18 13:38
---
Very hard to answer all those questions and for an architecture which I don't
know well, and for an application which I don't know (of course). For sure
here, in the FSF GCC community, 3.4.x is considered a ver
--- Comment #5 from janus at gcc dot gnu dot org 2010-01-18 13:46 ---
(In reply to comment #3)
> Here is a simple patch for setting the parent component accessibility:
> [...]
> This is probably not enough, since the access. specification of the parent
> type
> may come after the daught
--- Comment #7 from FBergemann at web dot de 2010-01-18 14:16 ---
Hi Paolo,
shouldn't it be WONTFIX then?
(as it is against 3.4.4)
best rgds,
Frank
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
--- Comment #8 from paolo dot carlini at oracle dot com 2010-01-18 14:25
---
Whatever you prefer. As a matter of fact, now, a PR vs 3.4.4 should be invalid,
essentially.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-18 14:36 ---
(In reply to comment #5)
> It sets the accessibility at resolution time and makes the following variant
> of comment #2 work:
That variant works for me already with the trunk, i.e. it is not rejected which
is (for m
--- Comment #7 from burnus at gcc dot gnu dot org 2010-01-18 14:39 ---
(In reply to comment #6)
> > It sets the accessibility at resolution time and makes the following
> > variant
> > of comment #2 work:
>
> That variant works for me already with the trunk, i.e. it is not rejected
>
--- Comment #11 from jv244 at cam dot ac dot uk 2010-01-18 14:41 ---
after the previous comment, marking this as a regression, confirm it, and set
P1 as suggest by Ian on the list.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
---
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
--- Comment #7 from dodji at gcc dot gnu dot org 2010-01-18 14:55 ---
A candidate patch was posted to
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00974.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-01-18 15:16
---
And a fix along comment #14 would be (untested, but of course fixes the
testcase):
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 1560
--- Comment #21 from hubicka at gcc dot gnu dot org 2010-01-18 15:42
---
Subject: Bug 42068
Author: hubicka
Date: Mon Jan 18 15:42:05 2010
New Revision: 156010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156010
Log:
PR middle-end/42068
(create_var_decl_1): Do
--- Comment #22 from hubicka at gcc dot gnu dot org 2010-01-18 15:47
---
No longer bootstrap issue, but still ICE on valid.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-01-18 15:48
---
If it's now middle-end then we need to adjust the priority.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #7 from steven at gcc dot gnu dot org 2010-01-18 16:18 ---
Should we perhaps rename all the lto_elf_ stuff to something else, if all of
this also Just Works with COFF?
Can we use a similar approach for Mach-O?
Big kudos for Dave, btw, for working on this.
--
steven at g
I downloaded a fresh 4.4.2 source distribution and configured and build
for x86_64-redhat-linux I'll attach a full build log, but basically
the GCC build fails trying to link cc1-dummy with many, many undefined
symbols.
I've built local copies of GMP, MPFR, MPC in /usr/local (using -fPIC)
and did
--- Comment #1 from David dot Biesack at sas dot com 2010-01-18 16:21
---
Created an attachment (id=19647)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19647&action=view)
build log for gcc 4.4.2
build log showing environment, configure, make, and make errors linking
cc1-dummy
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-01-18 16:29 ---
Patch restoring the 4.4 behavior posted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00976.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42585
--- Comment #8 from davek at gcc dot gnu dot org 2010-01-18 16:35 ---
(In reply to comment #7)
> Should we perhaps rename all the lto_elf_ stuff to something else, if all of
> this also Just Works with COFF?
As I said, WIP; I was certainly thinking of renaming it all to
lto_objfile_xx
--- Comment #4 from steven at gcc dot gnu dot org 2010-01-18 16:57 ---
I think this is fixed now, with Alexandre's patch. Could the OP confirm that
please?
On to the next -fcompare-debug failure :-)
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from steven at gcc dot gnu dot org 2010-01-18 17:00 ---
This still fails, even with Alexandre's patch for bug 42631.
With -fno-web the failure disappears. So this is probably another issue in the
webizer.
Investigating -> mine for now.
--
steven at gcc dot gnu dot or
--- Comment #11 from uros at gcc dot gnu dot org 2010-01-18 17:04 ---
Subject: Bug 42774
Author: uros
Date: Mon Jan 18 17:04:29 2010
New Revision: 156014
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156014
Log:
PR target/42774
* config/alpha/predicates.md (alig
--- Comment #24 from hubicka at gcc dot gnu dot org 2010-01-18 17:19
---
Subject: Bug 42068
Author: hubicka
Date: Mon Jan 18 17:19:13 2010
New Revision: 156016
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156016
Log:
PR middle-end/42068
* gcc-interface/utils.
--- Comment #2 from pault at gcc dot gnu dot org 2010-01-18 17:31 ---
Confirmed.
A weird and wonderful feature of this bug is that it disappears for -O2 and
higher :-)
The problem comes about because fsym->backend_decl is being used, which is
incorrect if the argument is missing becaus
--- Comment #9 from pault at gcc dot gnu dot org 2010-01-18 17:32 ---
Have posted a fix on the list today.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from zsojka at seznam dot cz 2010-01-18 17:45 ---
$ /mnt/svn/gcc-trunk/binary-155984-lto/bin/g++ -O1 -fpeel-loops -fcompare-debug
pr42642.cpp -c
g++: pr42642.cpp: -fcompare-debug failure
r155984 still fails for me
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42642
--- Comment #12 from uros at gcc dot gnu dot org 2010-01-18 17:46 ---
Subject: Bug 42774
Author: uros
Date: Mon Jan 18 17:46:17 2010
New Revision: 156017
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156017
Log:
PR target/42774
* config/alpha/predicates.md (alig
$ gnatchop unchopped.adb
$ gnatmake protocol.adb
+===GNAT BUG DETECTED==+
| 4.4.0 (x86_64-unknown-freebsd8.0) Storage_Error stack overflow or erroneous
memory access|
| Error detected at serial_io.adb:560:3 [protocol.ads:32:3]|
|
--- Comment #1 from gcc at coreland dot ath dot cx 2010-01-18 18:13 ---
I'm attempting to submit the repro case as an attachment but bugzilla keeps
suffering internal errors. Admin contacted...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42793
--- Comment #2 from gcc at coreland dot ath dot cx 2010-01-18 18:14 ---
Created an attachment (id=19648)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19648&action=view)
Repro case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42793
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2010-01-07 07:17:23 |2010-01-18 18:31:1
--- Comment #15 from d dot g dot gorbachev at gmail dot com 2010-01-18
18:48 ---
Created an attachment (id=19649)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19649&action=view)
Simple patch
It leaves -plugin-opt in LINK_COMMAND_SPEC, but I think it is not quite right,
as LIBGCC
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-18 18:48 ---
This is a bug in boost and not GCC. Not all targets define the __sync_*
functions. There is a define for each one saying which one is available.
--
pinskia at gcc dot gnu dot org changed:
What|R
--- Comment #8 from dodji at gcc dot gnu dot org 2010-01-18 19:11 ---
Subject: Bug 42766
Author: dodji
Date: Mon Jan 18 19:11:24 2010
New Revision: 156020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156020
Log:
Fix PR c++/42766
gcc/cp/ChangeLog:
PR c++/42766
--- Comment #5 from steven at gcc dot gnu dot org 2010-01-18 19:16 ---
Register number differences appear - again - because a USE operand of a
DEBUG_INSN ends up in a web of its own:
--- R1web/pr42685-2.c.167r.web 2010-01-18 11:11:38.0 -0800
+++ R2web/pr42685-2.c.167r.web 2010
--- Comment #9 from dodji at gcc dot gnu dot org 2010-01-18 19:17 ---
Fixed in 4.5
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-18 19:19 ---
Same issue: web renaming a single-USE "web".
*** This bug has been marked as a duplicate of 42685 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-18 19:19 ---
*** Bug 42642 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42685
--- Comment #5 from pault at gcc dot gnu dot org 2010-01-18 19:55 ---
Index: gcc/fortran/trans-decl.c
===
*** gcc/fortran/trans-decl.c(revision 155875)
--- gcc/fortran/trans-decl.c(working copy)
*** gfc_g
--- Comment #25 from simon at pushface dot org 2010-01-18 20:41 ---
OK on i86_64-apple-darwin10.2, powerpc-wrs-vxworks (hosted on
i366-apple-darwin10.2).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
--- Comment #26 from simon at pushface dot org 2010-01-18 20:54 ---
(In reply to comment #22)
> No longer bootstrap issue, but still ICE on valid.
The problem is that the ICE-on-valid occurs while building the Ada RTS, and
that is a bootstrap issue for Ada (what I mean is, a build confi
--- Comment #12 from dodji at gcc dot gnu dot org 2010-01-18 21:19 ---
Subject: Bug 42634
Author: dodji
Date: Mon Jan 18 21:18:49 2010
New Revision: 156022
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156022
Log:
Fix PR c++/42634
gcc/cp/ChangeLog:
PR c++/42634
* error
--- Comment #13 from uros at gcc dot gnu dot org 2010-01-18 21:44 ---
Subject: Bug 42774
Author: uros
Date: Mon Jan 18 21:44:32 2010
New Revision: 156024
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156024
Log:
PR target/42774
* config/alpha/predicates.md (alig
--- Comment #14 from ubizjak at gmail dot com 2010-01-18 21:48 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from monaka at monami-software dot com 2010-01-18 22:07
---
Created an attachment (id=19650)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19650&action=view)
Preprocessed source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42790
--- Comment #21 from anlauf at gmx dot de 2010-01-18 22:18 ---
(In reply to comment #19)
> > Regressions on fortran-dev branch fixed.
>
> Due to the patch in
>
> http://gcc.gnu.org/ml/fortran/2009-12/msg00232.html
Jerry,
is this patch supposed to be complete for fortran-dev?
I still
--- Comment #7 from chris2553 at googlemail dot com 2010-01-18 22:24
---
I can confirm that the patch at comment 4 has fixed the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42773
--- Comment #3 from gcc at coreland dot ath dot cx 2010-01-18 22:46 ---
Created an attachment (id=19651)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19651&action=view)
Another repro
This appears to be the same bug but giving a slightly more interesting
crash message:
$ gnatchop
--- Comment #23 from gcc at coreland dot ath dot cx 2010-01-18 22:51
---
Created an attachment (id=19652)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19652&action=view)
Another repro
A smaller, simpler piece of code that triggers this:
$ gnatmake p.adb
p.adb:8:70: wrong type f
--- Comment #24 from gcc at coreland dot ath dot cx 2010-01-18 22:53
---
Created an attachment (id=19653)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19653&action=view)
A smaller repro for the "_master conflicts with declaration" error
$ gnatmake arc_dir_003.adb
gcc -c arc_dir_
--- Comment #13 from dodji at gcc dot gnu dot org 2010-01-18 23:14 ---
Subject: Bug 42634
Author: dodji
Date: Mon Jan 18 23:14:01 2010
New Revision: 156026
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156026
Log:
Revert fix of PR c++/
gcc/cp/ChangeLog:
* error.c (dump
--- Comment #4 from monaka at monami-software dot com 2010-01-18 23:21
---
(In reply to comment #3)
> It rather seems you do not have proper target headers.
What's "proper target headers"?
If it's t-m32r.h, I have it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42787
--- Comment #2 from monaka at monami-software dot com 2010-01-18 23:29
---
(In reply to comment #1)
> If you use -arch ppc, then the host/build is really powerpc-apple-darwin so
> obviously you are configuring GCC incorrectly and the error message is correct
> as that is x86 inline-asm
The following (reduced) code:
typedef enum {
TYPE_NON_IDR,
TYPE_IDR,
} NAL_UNIT_TYPE;
typedef struct recordTag
{
} Record;
typedef struct {
unsigned int ActualSize;
unsigned short *Slice;
}Info;
typedef struct {
} Params;
typedef struct {
NAL_UNIT_TYPE unit_type;
} NAL_UNIT;
u
1 - 100 of 122 matches
Mail list logo
