The patterns for PUT/GET were
; Scalar Put instruction.
(define_insn commsPut
[(unspec_volatile [(match_operand:HI 0 const_int_operand )
(match_operand:SI 1 register_operand r)]
UNSPEC_PUT)]
PUT %R1,%0\t// PORT(%0) := %R1
[(set_attr type comms)
Hi,
I am trying to add the soft-fp support to a new target. I have
checked the implementation done in rs6000 port, and done the
similar modifications to our port. I have made the following
changes.
(1) Added the following files
t-fprules-softfp
sfp-machine.h
(2) Modified
Hari,
Here are some patterns similar to yours.
(define_insn putbx
[(set (reg:BXBC R_BX) (unspec:BXBC [(match_operand:QI 0 firepath_register
vr)] UNSPEC_BXM))
(unspec:BXBC [(reg:BXBC R_BX)] UNSPEC_BX)] --- Important to avoid some
wrong optimization (Maybe DCE, I couldn't remember
On Thu, May 13, 2010 at 7:10 AM, Rathish C rathis...@kpitcummins.com wrote:
Hi,
I am trying to add the soft-fp support to a new target. I have
checked the implementation done in rs6000 port, and done the
similar modifications to our port. I have made the following
changes.
(1) Added the
Ian Lance Taylor schrieb:
Eggenmüller Bernd egg...@gmx.de writes:
Ian Lance Taylor schrieb:
Eggenmüller Bernd egg...@gmx.de writes:
is it possible to translate the libgcc2 when i only have 4 registers
which are 32 bits long.
One of the four Registers is defined as
On Thu, May 13, 2010 at 8:46 AM, Eggenmüller Bernd egg...@gmx.de wrote:
Is there any implementation with less registers like this.
libgcc2 is written in C; so if it fails to compile you need to fix up
your backend. There might need some middle-end fixes too with this
small number of registers
Andrew Pinski schrieb:
On Thu, May 13, 2010 at 8:46 AM, Eggenmüller Bernd egg...@gmx.de wrote:
Is there any implementation with less registers like this.
libgcc2 is written in C; so if it fails to compile you need to fix up
your backend. There might need some middle-end fixes too
DJ Delorie wrote:
I discovered that if you build a plain arm-elf toolchain, the default
float-abis for gcc and gas don't match. I added this patch locally to
make it just work but it seems to me it would be better to have the
defaults match, although I'm not sure how to enforce that.
Amker.Cheng amker.ch...@gmail.com writes:
Hi:
as to page http://gcc.gnu.org/ml/gcc/2010-05/msg00091.html,
If the fpu register can not copied to/from memory directly, I have
to use intermediate GPR registers.
In fact, I return GP_REGS if copying x to a register in class FP_REGS
in any
On 5/10/10 10:31 , Kevin Williams wrote:
1. What is the correct behaviour for a FE in terms of setting the
global variables cfun and current_function_declaration?
They should be set to the current function being parsed. These will be
set to NULL when the compiler is working in IPA mode.
2.
On 5/6/10 10:24 , Richard Guenther wrote:
Any comments or objections?
I agree. It sounds useful. It's a bit confusing in that I don't know
whether it means 'compile very fast' or 'make my code run very fast'.
I've seen it mean the latter in most places, so I guess that's fine.
Allowing
On 5/4/10 15:11 , Wolfgang kaifler wrote:
(gdb) p browse_tree (current_function_decl)
No symbol browse_tree in current context.
(gdb)
What i'm doing wrong? Any ideas?
The tree browser code has bitrotted to the point that I think it should
be removed, unfortunately. It's a great candidate
Snapshot gcc-4.5-20100513 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100513/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Your FAQ at the below URLS conflicts as to which autoconf should be used. one
says 2.13 th other says 2.64. 2.65 is currently available.
http://gcc.gnu.org/faq.html#generated_files
http://gcc.gnu.org/install/prerequisites.html
The symptoms are that for some inputs, my C++ program gets stuck after a
`throw' and before the corresponding `catch', with CPU running. With an
appropriate DYLD_LIBRARY_PATH, the problem disappears.
The problem comes IMHO from libgcc/config/t-slibgcc-darwin (lines 29-35) where
--- Comment #6 from jay dot krell at cornell dot edu 2010-05-13 07:56
---
Another I didn't understand from the other mail thread: why not always output
;?
In particular, the warning that would be disabled -- that is for hand written
assembly only, right? Is it disable for the entire
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-13 08:41
---
Mike, can you have a look?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #18 from pluto at agmk dot net 2010-05-13 09:13 ---
(In reply to comment #17)
Not a bug, you need to configure libstdc++ and stlport the same if you want
them to work together.
__thread/pthread in eh_globals.cc is an implemetation detail.
how this could conflicts with
--- Comment #10 from sebastian dot huber at embedded-brains dot de
2010-05-13 09:42 ---
Binary search through trunk revisions yield:
r159321 BROKEN
r15 BROKEN
r14 BROKEN
r135000 BROKEN
r132500 BROKEN
r131024 BROKEN
r130512 BROKEN
r130256 BROKEN
r130128 BROKEN
r130064 BROKEN
--- Comment #11 from sebastian dot huber at embedded-brains dot de
2010-05-13 09:50 ---
Created an attachment (id=20654)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20654action=view)
Difference between bdbuf.s in revsions 130051 and 130052
This clearly shows how the frame usage
--- Comment #4 from tkoenig at gcc dot gnu dot org 2010-05-13 09:58 ---
This works now.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2010-05-13 10:08 ---
Confirmed . I think this is a result of DSE not being able to remove this
because the prologue rtx pattern doesn't show the writes of the actual
registers.
Ramana
--
ramana at gcc dot gnu dot org changed:
--- Comment #19 from redi at gcc dot gnu dot org 2010-05-13 10:24 ---
(In reply to comment #15)
the problematic is eh_globals.o which was merged into libstlport.a.
If stlport imports files which are implementation details, then it depends on
those implementation details. isn't that
--- Comment #12 from mikpe at it dot uu dot se 2010-05-13 10:28 ---
r130052 is a generic scheduling tweak originally described here:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01814.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-13 10:31 ---
Initial patch (trans-decl.c, trans.io.c) here:
http://gcc.gnu.org/ml/fortran/2010-05/msg00124.html
Mapping formal arguments to fnspec should be doable, but I'm experienced enough
in tree-things to continue.
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-13 10:41 ---
Subject: Bug 43983
Author: jakub
Date: Thu May 13 10:40:51 2010
New Revision: 159357
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159357
Log:
PR debug/43983
* var-tracking.c (track_expr_p):
--- Comment #20 from pluto at agmk dot net 2010-05-13 10:46 ---
(In reply to comment #19)
(In reply to comment #15)
the problematic is eh_globals.o which was merged into libstlport.a.
If stlport imports files which are implementation details, then it depends on
those
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-13 10:53 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
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=44104
Like PR c/43981, but still happening with 4.6.0 20100513 (Last Changed Rev:
159356
), which is why I copied and editted the title.
In case a const variable is used for array sizing it is not considered to be
read whereas a non-const variable would be considered to be read. It does NOT
happen when
--- Comment #1 from rubidium at openttd dot org 2010-05-13 11:04 ---
Created an attachment (id=20655)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20655action=view)
Simple testcase
Compile with g++ -Wunused-but-set-variable testcase.cpp
--
Built/installed gcc under openSUSE 11.1 with:
../configure --prefix=$pre --enable-languages=c,java
Test program AssertionTest.java:
class AssertionTest {
static public void main( String args[] ) {
assert false: test assertion;
System.out.println(Hello World!);
}
}
At r159354 I see the following new failures in the testsuite:
FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/proc_ptr_25.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/proc_ptr_comp_9.f90 -O3 -g (test for excess errors)
They give errors like
--- Comment #1 from pkeller at globalphasing dot com 2010-05-13 11:14
---
Created an attachment (id=20656)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20656action=view)
Output from compile/link step of test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44109
--- Comment #2 from pkeller at globalphasing dot com 2010-05-13 11:15
---
Created an attachment (id=20657)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20657action=view)
Preprocessor output from compiling test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44109
--- Comment #21 from redi at gcc dot gnu dot org 2010-05-13 11:29 ---
(In reply to comment #20)
stlport includes some gcc archives in libstlport.a for simplier linking
for some definition of simpler :)
Either don't use static linking or rebuild libstlport.a with the gcc version
Bootstrap failure for powerpc-apple-darwin9 from revision 159339:
...
/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/lib/ -isystem
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-13 11:54 ---
Fixed by revision 159359, see
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00932.html .
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #11 from jakub at gcc dot gnu dot org 2010-05-13 12:03 ---
Subject: Bug 44036
Author: jakub
Date: Thu May 13 12:02:50 2010
New Revision: 159361
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159361
Log:
PR fortran/44036
* openmp.c
--
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=44108
--
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=44103
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-13 12:30 ---
Patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00130.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-13 12:30 ---
Suggested patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00116.html
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-13 12:31 ---
Suggested patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00109.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44055
--- Comment #12 from jakub at gcc dot gnu dot org 2010-05-13 12:36 ---
Subject: Bug 44036
Author: jakub
Date: Thu May 13 12:35:52 2010
New Revision: 159363
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159363
Log:
PR fortran/44036
* openmp.c
--- Comment #13 from jakub at gcc dot gnu dot org 2010-05-13 12:39 ---
Subject: Bug 44036
Author: jakub
Date: Thu May 13 12:39:17 2010
New Revision: 159365
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159365
Log:
PR fortran/44036
* openmp.c
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-05-13
13:02 ---
Also seen on powerpc-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44103
Revision 159354:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00406.html
caused:
FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/proc_ptr_25.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/proc_ptr_comp_9.f90 -O3 -g (test for excess errors)
--
--- Comment #2 from steve dot chapel at a2pg dot com 2010-05-13 13:15
---
Excellent! The new warning is far more understandable than the old.
X'R IN CALL RANDOM MAY NOT BE USED OUTSIDE THE BLOCK CONTAINING T
1
Warning: Initialization string starting at (1) was truncated
--- Comment #14 from jakub at gcc dot gnu dot org 2010-05-13 13:22 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-13 13:26 ---
That's easily doable. Alternative patch for data.c below gives:
$ gfortran-svn pr38404.f
pr38404.f:5.7:
X'R IN CALL RANDOM MAY NOT BE USED OUTSIDE THE BLOCK CONTAINING T
1
Warning: Initialization
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-13 13:39 ---
*** This bug has been marked as a duplicate of 44112 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-13 13:39 ---
*** Bug 44110 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
With gdb 7.1 / gcc 4.5.0 I noticed that unrolled loops have very poor
debugging information. The body cannot be single stepped, but a next
in gdb jumps over the whole iteration space.
For example:
main()
{
int i;
for (i = 0; i 10; i++)
printf(%d\n,i );
}
--- Comment #1 from andi-gcc at firstfloor dot org 2010-05-13 13:44 ---
Hmm sorry actually it stepped over everything except the last iteration.
Still unexpected
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-13 13:50 ---
This (a) didn't turn out as much of an issue and (b) the general problem is
known. Closing this specific incarnation as WONTFIX.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-13 13:50 ---
This (a) didn't turn out as much of an issue and (b) the general problem is
known. Closing this specific incarnation as WONTFIX.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-13 13:51 ---
It is caused by revision 159315:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00367.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-13 14:08 ---
Subject: Bug 35779
Author: dfranke
Date: Thu May 13 14:08:05 2010
New Revision: 159366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159366
Log:
gcc/fortran/:
2010-05-13 Daniel Franke
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-05-13 14:09 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
COLLECT_LTO_WRAPPER=/home/ig25/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../trunk/configure --prefix=/home/ig25
--enable-languages=all,ada --with-mpc=/usr/local/
Thread model: posix
gcc version 4.6.0 20100513 (experimental) (GCC
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44114
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-13 14:18 ---
I'm fairly sure I have regtested the patch with lto and these failures didn't
appear, so I guess only some concurrent lto/cgraph changes yesterday made this
trigger. The fix is to add mod_type_die check, will commit
On Linux/x86-64, revision 159357 gave
FAIL: gcc.dg/guality/sra-1.c -O1 line 20 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O1 line 20 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O2 line 20 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O2 line 20 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O2 -flto line
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-05-13 14:22
---
*** This bug has been marked as a duplicate of 38644 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-05-13 14:22
---
*** Bug 44091 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-13 14:24 ---
Subject: Bug 44104
Author: jakub
Date: Thu May 13 14:24:36 2010
New Revision: 159367
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159367
Log:
PR debug/44104
* dwarf2out.c (modified_type_die):
--- Comment #8 from dominiq at lps dot ens dot fr 2010-05-13 14:25 ---
*** This bug has been marked as a duplicate of 44114 ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-13 14:25 ---
*** Bug 43924 has been marked as a duplicate of this bug. ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-05-13 14:28
---
Indeed, fixed for 4.6.0 by the patch which fixed PR34491.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2010-05-13 14:31 ---
Reopen. This bug report has more info than PR 44114.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-13 14:31 ---
*** This bug has been marked as a duplicate of 43924 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #10 from hjl dot tools at gmail dot com 2010-05-13 14:31
---
*** Bug 44114 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-13 14:34 ---
Buggy gdb, see http://bugzilla.redhat.com/589467
The lto/whopr issues are LTO bugs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44115
FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors)
WARNING: gfortran.dg/proc_ptr_23.f90 -O3 -g compilation failed to produce
executable
FAIL: gfortran.dg/proc_ptr_25.f90 -O3 -g (test for excess errors)
WARNING: gfortran.dg/proc_ptr_25.f90 -O3 -g compilation failed to produce
On multi-TB storage array with XFS filesystem I have to enable 64bit inodes
recently (inode64 mount option). Having test.c with:
int main(void){
return 0;
}
compiles fine for one file, but if i copy it to another one (several times till
it got the right inode number) it produces:
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-05-13 14:37 ---
Depends on both -O3 and -g:
i...@linux-fd1f:/tmp gfortran proc_ptr_23.f90
i...@linux-fd1f:/tmp gfortran -O3 proc_ptr_23.f90
i...@linux-fd1f:/tmp gfortran -O3 -g proc_ptr_23.f90
/tmp/ccALU2k0.o:(.debug_info+0x81):
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 14:44 ---
*** This bug has been marked as a duplicate of 44110 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 14:44 ---
*** Bug 44117 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-05-13 14:46
---
r...@matylda1: /mnt/data/kasparek# LC_ALL=C gcc -o test.o test-10356.c
cc1: error: test-10356.c: Value too large for defined data type
The first this I need to help with is how to
check if the code that
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-13 14:47 ---
(In reply to comment #0)
fff.f90:26:0: internal compiler error: in gfc_conv_structure, at
fortran/trans-expr.c:4390
It turns out this ICE is actually due to the NULL() initialization of the class
pointer and has
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 14:49 ---
Fix posted: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00960.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-13 14:55 ---
When removing the NULL initialization in comment #3, the dump shows:
static struct .class.parent.p this = {.$data=0B};
Zeroing the $data pointer is probably not needed without NULL initialization.
With NULL
Tested revisions:
r159305 - crash (after pr34491 fix)
4.5 r158978 - crash
4.4 r158133 - crash
Compiler output:
$ /mnt/svn/gcc-trunk/binary-159305-lto-fortran/bin/g++ testcase.C
testcase.C:2:30: error: template parameters not used in partial specialization:
testcase.C:2:30: error:
--- Comment #1 from zsojka at seznam dot cz 2010-05-13 15:11 ---
Created an attachment (id=20658)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20658action=view)
reduced testcase
$ g++ pr44118.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44118
--with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r159348-install
--program-prefix=r159348- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100513 (experimental) (GCC)
[reg...@gamow tmp413]$ current-gcc -O2 -c small.c
small.c: In function 'func_96
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-13 15:27 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:27 ---
The PRE change again.
--
rguenth 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=44112
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:31 ---
This is know. GCC does not use LFS and thus fails. A patch to fix that
was once applied but broke AIX and thus was reverted.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:33 ---
We throw away DECL_DEBUG_EXPR in free-lang-data (and do not try to stream it).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:36 ---
Well, you step to the next line-number and only lines #5 are remaining, so
I think you just get what you asked for. I don't know if we could (or should)
signal to gdb that there are multiple lines #5 now. Jakub?
I imagine this will affect all targets.
dpd -I../libdecnumber/GCC/gcc-live-trunk/gcc/objc/objc-act.c \
-o objcp/objcp-act.o
/GCC/gcc-live-trunk/gcc/objc/objc-act.c: In function
build_typed_selector_reference:
/GCC/gcc-live-trunk/gcc/objc/objc-act.c:2709:8: error: too few
--- Comment #3 from andi-gcc at firstfloor dot org 2010-05-13 16:16 ---
I think it should describe multiple lines.
next is expected to iterate through loops, not skip them.
If I wanted to skip I would use until
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
--- Comment #8 from paolo dot carlini at oracle dot com 2010-05-13 16:21
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from steve dot chapel at a2pg dot com 2010-05-13 16:28
---
:)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38404
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-13 16:45 ---
Patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00135.html
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-13 16:48 ---
Created an attachment (id=20659)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20659action=view)
fix PR44120
this is a quick-fix,
FWIW we seem to be getting an ever-increasing number of #ifdef OBJCPLUS - I
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-05-13 16:58
---
I have a revised patch that handles default integer and negative error codes.
It is testing and I will submit when I get an opportunity.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-13 17:02 ---
Related to PR 43630.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to
1 - 100 of 156 matches
Mail list logo
