--- Comment #27 from howarth at nitro dot med dot uc dot edu 2009-10-02
05:44 ---
I should note that with the proposed change in Comment 25, the 2 unsupported
tests properly show up in g++.log as...
cc1plus: note: -freorder-blocks-and-partition does not work with exceptions on
this arc
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2009-10-02
05:40 ---
I should note that if I don't wrapper the line ...
&& (USING_SJLJ_EXCEPTIONS
with the #if !defined(__MACH__), I get the following results...
=== g++ tests ===
Schedule of
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2009-10-02
05:34 ---
The following change achieves the same test results as in Comment 24...
--- /Users/howarth/gcc/gcc/opts.c 2009-09-28 19:33:18.0 -0400
+++ opts.c 2009-10-02 01:30:48.0 -0400
@@ -
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2009-10-02
05:11 ---
Oh, I didn't regress out all of the changes from...
http://gcc.gnu.org/viewcvs/trunk/gcc/opts.c?r1=150553&r2=150552&view=patch&pathrev=150553
when I do that, the tree-prof tests pass fine...
Native conf
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2009-10-02
05:00 ---
Oddly...
Index: config/darwin.c
===
--- config/darwin.c (revision 152389)
+++ config/darwin.c (working copy)
@@ -1697,6 +1697,9 @@
--- Comment #32 from ghazi at gcc dot gnu dot org 2009-10-02 03:52 ---
Subject: Bug 33197
Author: ghazi
Date: Fri Oct 2 03:52:05 2009
New Revision: 152394
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152394
Log:
PR fortran/33197
* gfortran.h (HAVE_mpc_arc): De
On Linux/ia32, I got
FAIL: gcc.dg/tree-ssa/ipa-cp-1.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/ipa-cp-1.c scan-tree-dump-times optimized
"very_long_function.clone.0 \(\)" 3: dump file does not exist
FAIL: gcc.dg/tree-ssa/ipa-cp-1.c scan-tree-dump-times optimized
"very_long_function.clone.0 \
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-02 02:46 ---
DR 696 is talking about a different case.
The issue here is that you use Test::A / Test::B and define them. You use them
in a non constant expression location so the compiler does not have to
subsitute them at all.
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2009-10-02
02:44 ---
This change came from...
Author: jakub
Date: Fri Aug 7 06:23:42 2009
New Revision: 150553
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150553
Log:
* dwarf2out.c (output_fde): When doing
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2009-10-02
02:36 ---
We seemed to have changed the original code from gcc 4.2.1...
/* If user requested unwind info, then turn off the partitioning
optimization. */
if (flag_unwind_tables && ! targetm.unwind_tables
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-10-02 02:32
---
Reply to comment #10: Thanks for the input and references. The perspective of
rounding before conversion to binary representation is interesting. I will
think on that a bit.
Reply to comment #11: Thanks for t
--- Comment #20 from mrs at apple dot com 2009-10-02 02:03 ---
flag_reorder_blocks_and_partition was the complete name of the variable last I
looked. If flag_unwind_tables is true and this variable is true, that's the
bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
When using the conditional operator (?:), it takes the address of its operands
when they are constant values.
Compilation Output:
-- Start --
[r...@casper ~]# g++ -v -save-temps bug.cpp
Using built-in specs.
Target: i586-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/
--- Comment #9 from hutchinsonandy at gcc dot gnu dot org 2009-10-02 00:30
---
Checked earlier version. They all insert on edge before RTL is expanded.
Making this 4.5 regression.
--
hutchinsonandy at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2009-10-01
23:54 ---
I'm not sure that hot_cold=0 would work as a grep of gcc trunk doesn't show any
thing matching hot_cold. I did find the original commit of the problematic
code...
http://gcc.gnu.org/ml/gcc/2004-02/msg0082
--- Comment #2 from cfairles at gcc dot gnu dot org 2009-10-01 22:52
---
(In reply to comment #1)
> Thanks for the PR and the patch, which indeed makes sense to me (also regtests
> fine). Before committing the change, let's wait a bit in case Chris F has some
> comments...
>
Looks goo
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-01 22:21 ---
"r" is a constraint for a general register, you need to use a proper constraint
here. Refer to the architecture specific constraint documentaiton.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41538
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Broken var location info|[4.5 Regression] Broken var
|after scheduling
The documentation for the -dM -E option states that
"Instead of the normal output, generate a list of `#define' directives for
all the macros defined during the execution of the preprocessor, including
predefined macros. This gives you a way of finding out what is predefined
in your versio
The following program compiles with ifort and with NAG f95 but fails with
gfortran with:
call qsort(A,tmp)
1
Error: Rank mismatch in argument 'a' at (1) (0 and 1)
( The program was motivated by
http://groups.google.com/group/comp.lang.fortran/msg/cde7f6104f6c29c7 )
module m_qsor
--- Comment #8 from burnus at gcc dot gnu dot org 2009-10-01 21:21 ---
Minimal test case:
program main
type :: container_t
integer, allocatable :: entry
end type container_t
type(container_t), dimension(1) :: a1, a2
allocate (a1(1)%entry, a2(1)%entry)
a2(1)%entry = 1
a1(1:1) = pack (a
Trying to peg C intrinsic variables (for ARM/NEON) to a specific 128-bit
register (e.g. q0-q15) does not work at all. For example,
register int16x8_t v0 asm ("q0"); // q0=d0-d1
register int16x8_t v1 asm ("q1"); // q1=d2-d3
is totally ignored yet compiles without warning. If I try the fr
--- Comment #11 from ubizjak at gmail dot com 2009-10-01 20:51 ---
None of the testcases fail anymore with GCC: (GNU) 4.5.0 20091001
(experimental) [trunk revision 152374].
The testcase from #7 produces:
foo:
pushl %ebp
movl%esp, %ebp
pushl %ebx
--- Comment #11 from dominiq at lps dot ens dot fr 2009-10-01 20:18 ---
There is probably a bug with round to nearest for values below 1:
print '(RN, 4F10.3)', 0.0625, 0.1875
print '(RN, 4F10.2)', 0.125, 0.375, 1.125, 1.375
print '(RN, 4F10.1)', 0.25, 0.75, 1.25, 1.75
print '(RN, 4F10.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-01 20:04 ---
This is a valid variable array definition in GNU C90.
It creates an array that is zero sized called funcA.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
A function was defined incorrectly as below:
float funcA [] = { } ;
However, we did not get any message for this syntax error when it is compiled.
--
Summary: A syntax error for function defination
Product: gcc
Version: 3.2.3
Status: UNCONFIRMED
--- Comment #6 from ubizjak at gmail dot com 2009-10-01 19:57 ---
Confirmed, regression.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCON
--- Comment #5 from lucier at math dot purdue dot edu 2009-10-01 19:43
---
No ICE with 4.3.3, either, but there is an ICE with
Target: ppc64-redhat-linux
gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176
--- Comment #10 from laurent at guerby dot net 2009-10-01 19:37 ---
Starting with
$ /tmp/gcc-4.4.1-install/bin/gcc -v
Using built-in specs.
Target: armv5tel-unknown-linux-gnueabi
Configured with: /home/mikpe/gcc-4.4.1/configure
--prefix=/tmp/gcc-4.4.1-install --with-arch=armv5te --with-
--- Comment #4 from lucier at math dot purdue dot edu 2009-10-01 19:37
---
There is no ICE when compiling thread.i with gcc-4.2.4:
[luc...@lambda-head ~/Desktop]$
/pkgs/gcc-4.2.4/libexec/gcc/powerpc64-unknown-linux-gnu/4.2.4/cc1
-fpreprocessed thread.i -quiet -mcpu=970 -m64 -O1 -Wno-un
--- Comment #58 from mrs at apple dot com 2009-10-01 19:18 ---
Seems reasonable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
--- Comment #18 from mrs at apple dot com 2009-10-01 19:14 ---
Yes. If someone wants to propose a better solution, they will...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
--- Comment #9 from armin76 at gentoo dot org 2009-10-01 18:01 ---
(In reply to comment #8)
> Next: Try with debian
>
Ok, installed a squeeze chroot, installed gcc-4.4 with apt-get install gcc-4.4,
built gcc-4.4.1 with the same configure line and stuff, and it also fails.
Tell me if yo
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-10-01 17:46 ---
DECL_DISREGARD_INLINE_LIMITS (clone) = DECL_DISREGARD_INLINE_LIMITS (fn);
needs to be done too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41536
--- Comment #5 from kargl at gcc dot gnu dot org 2009-10-01 17:25 ---
A backport to 4.4 revealed a problem within the dejagnu test
framework. gfortran.dg/empty_label.f would fail for no
apparent/reported reason. So, no backport from me.
--
kargl at gcc dot gnu dot org changed:
--- Comment #4 from kargl at gcc dot gnu dot org 2009-10-01 17:30 ---
(In reply to comment #2)
> Subject: Re: Segmentation fault calling DGETRF from
> gfortran
>
> Well, that's an embarrassing mistake. My apologies. For some reason the
> example
> code does run correctly for G95.
>
--- Comment #1 from kargl at gcc dot gnu dot org 2009-10-01 17:28 ---
This looks like a middle-end or target specific problem.
Changed component from libfortran to target.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #57 from developer at sandoe-acoustics dot co dot uk
2009-10-01 17:22 ---
(In reply to comment #56)
> Okay. So no problem. What do you think is the best way to default on
> libgcc-ext? Just using...
I'm reg-testing on powerpc-apple-d8, i686-apple-d9 and x86_64-apple-d10
wit
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-01 17:04 ---
Here is the fix I am working for:
Index: optimize.c
===
--- optimize.c (revision 152380)
+++ optimize.c (working copy)
@@ -199,6 +199,7 @@ maybe_clone
--- Comment #5 from ubizjak at gmail dot com 2009-10-01 16:59 ---
(In reply to comment #3)
> This is not the same problem as 24319. Vlad thinks he fixed 24319, and indeed
> the problem in this bug report from 4.4 is gone. The reported problem in 4.5
> is different.
Oh, I have noticed
--- Comment #3 from burnus at gcc dot gnu dot org 2009-10-01 16:43 ---
> I wonder why it uses the extra temporary - that shouldn't be necessary.
The big question is only: Are there cases where one needs to call
gfc_evaluate_now?
* * *
For completeness, that part was added by the comm
--- Comment #3 from ubizjak at gmail dot com 2009-10-01 16:39 ---
Can you check if this problem is a regression from 4.2+? Although ICEs are not
welcomed, regression status would put more weight on the PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176
--- Comment #8 from armin76 at gentoo dot org 2009-10-01 16:33 ---
Created an attachment (id=18690)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18690&action=view)
build.log
And the build log.
So, i ran this:
../gcc-4.4.1/configure --enable-languages=c,c++,fortran --with-float=s
--- Comment #7 from armin76 at gentoo dot org 2009-10-01 16:28 ---
Created an attachment (id=18689)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18689&action=view)
config.log from buildir
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41500
--- Comment #4 from ubizjak at gmail dot com 2009-10-01 16:28 ---
(In reply to comment #3)
> This is not the same problem as 24319. Vlad thinks he fixed 24319, and indeed
> the problem in this bug report from 4.4 is gone. The reported problem in 4.5
> is different.
>
> Don't turn 2343
--- Comment #6 from armin76 at gentoo dot org 2009-10-01 16:26 ---
Created an attachment (id=18688)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18688&action=view)
config.log
config.log from build/armv5tel-unknown-linux-gnueabi/libgcc
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #5 from armin76 at gentoo dot org 2009-10-01 16:22 ---
(In reply to comment #4)
> ATM i'm trying this:
> -build gcc-4.4 using STAGE1_CFLAGS=-O2 with gcc-4.3, then build gcc-4.4 with
> newly-built gcc-4.4 with STAGE1_CFLAGS=-O
>
> Will let you know, i'll attach the full build
The following testcase fails:
// { dg-do compile }
struct f
{
inline f(void);
inline void f1(void);
int a;
};
inline __attribute__((always_inline)) f::f(void)
{
a++;
}
inline __attribute__((always_inline)) void f::f1(void)
{
a++;
}
void g(void)
{
f a, b, c, d;
a.f1();
}
// f::f(
--- Comment #7 from burnus at gcc dot gnu dot org 2009-10-01 16:12 ---
FIXED for GCC 4.5 (trunk), 4.4 and 4.3.
Thanks for the bugreport!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2009-10-01 16:11 ---
Subject: Bug 41515
Author: burnus
Date: Thu Oct 1 16:10:49 2009
New Revision: 152379
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152379
Log:
2009-10-01 Tobias Burnus
PR fortran/41515
*
--- Comment #5 from burnus at gcc dot gnu dot org 2009-10-01 16:09 ---
Subject: Bug 41515
Author: burnus
Date: Thu Oct 1 16:09:13 2009
New Revision: 152378
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152378
Log:
2009-10-01 Tobias Burnus
PR fortran/41515
*
--- Comment #4 from burnus at gcc dot gnu dot org 2009-10-01 16:06 ---
Subject: Bug 41515
Author: burnus
Date: Thu Oct 1 16:05:48 2009
New Revision: 152377
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152377
Log:
2009-10-01 Tobias Burnus
PR fortran/41515
*
--- Comment #1 from krebbel at gcc dot gnu dot org 2009-10-01 15:58 ---
Created an attachment (id=18687)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18687&action=view)
Testcase
Compile with -O2 -fPIC -g
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41535
On s390x I see broken debug info generated for the attached C++
testcase (compile with -O2 -g -fPIC).
The debug info contains a symbol reference with a @GOTENT modifier
what should not happen (and is not accepted by gas):
.LLST3:
.8byte .LVL3-.Ltext0
.8byte .LVL4-.Ltext0
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2009-10-01
15:55 ---
(In reply to comment #15)
> Yeah, the patch in #11 is about the right for half the problem (darwin10), if
> it weren't for ld's warning message. I don't know quite why it is doing that,
> so guess we'll j
--- Comment #5 from jakub at gcc dot gnu dot org 2009-10-01 15:44 ---
http://sources.redhat.com/ml/binutils/2009-10/msg00028.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2009-10-01
15:41 ---
It looks like this problem isn't strictly target specific (although we are
the only target currently impacted). If TARGET_ASM_EMIT_UNWIND_LABEL as defined
needs to support passing SECOND, both the defau
--- Comment #45 from jamborm at gcc dot gnu dot org 2009-10-01 14:47
---
Right, so I belieive all problems that were reported here (and were
indeed relevant to IPA-SRA) are now dealt with. x86_64 and i386
bootstraps and checks nicely with both "yes" and "release" checking,
alpha bootst
--- Comment #56 from howarth at nitro dot med dot uc dot edu 2009-10-01
13:59 ---
Okay. So no problem. What do you think is the best way to default on
libgcc-ext? Just using...
Index: gcc/config/darwin.h
===
--- gcc/config
--- Comment #3 from lucier at math dot purdue dot edu 2009-10-01 13:19
---
This is not the same problem as 24319. Vlad thinks he fixed 24319, and indeed
the problem in this bug report from 4.4 is gone. The reported problem in 4.5
is different.
Don't turn 234319 into a grab bag of any
--- Comment #29 from jamborm at gcc dot gnu dot org 2009-10-01 11:48
---
Subject: Bug 12392
Author: jamborm
Date: Thu Oct 1 11:48:24 2009
New Revision: 152368
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152368
Log:
2009-10-01 Martin Jambor
PR middle-end/12392
The C++ FE insists on giving TYPE_NAMEs to things like anonymous unions. This
confuses type compatibility checks in LTO which now needs to workaround this
duplicating the ANON_AGGRNAME_FORMAT logic from cp/cp-tree.h
Maybe the C++ FE should free those names in the free_lang_data langhook.
What do
--- Comment #44 from jamborm at gcc dot gnu dot org 2009-10-01 11:30
---
Subject: Bug 41395
Author: jamborm
Date: Thu Oct 1 11:30:12 2009
New Revision: 152366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152366
Log:
2009-10-01 Martin Jambor
PR bootstrap/41395
--- Comment #7 from kirill at shutemov dot name 2009-10-01 11:08 ---
Looks ok for me.
I'll test it, but it takes some time. I'll report results tomorrow.
This patch also fixes #40521, I guess.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
--- Comment #6 from ramana at gcc dot gnu dot org 2009-10-01 10:54 ---
(In reply to comment #5)
> Ok. If .eh_frame should not be generated on ARM, we should to modify
> dwarf2out_do_cfi_asm() to always return false on ARM. Right?
>
Look at this patch submitted here. Can you try this to
--- Comment #5 from kirill at shutemov dot name 2009-10-01 10:07 ---
Ok. If .eh_frame should not be generated on ARM, we should to modify
dwarf2out_do_cfi_asm() to always return false on ARM. Right?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-10-01 09:31 ---
Subject: Bug 41503
Author: jamborm
Date: Thu Oct 1 09:31:08 2009
New Revision: 152365
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152365
Log:
2009-10-01 Martin Jambor
PR c++/41503
* c
--- Comment #4 from ramana at gcc dot gnu dot org 2009-10-01 09:02 ---
Is it correct to generate .eh_frame for the arm-linux-gnueabi target ?
Shouldn't this rather be the ARM EABI exception handling tables instead ?
-fno-dwarf2-cfi-asm might be a workaround. I've seen a couple of bug r
--- Comment #3 from jakub at gcc dot gnu dot org 2009-10-01 08:37 ---
AFAIK arm*-*-linux*eabi uses its own unwinding format, so it shouldn't be using
.cfi_* directives at all. It should force -fno-dwarf2-cfi-asm...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
--- Comment #55 from developer at sandoe-acoustics dot co dot uk
2009-10-01 08:36 ---
(In reply to comment #54)
> The new libgcc_s.dylib appears to be only of the native target architecture...
it's best thought of not as "new" but "different" - it's the target for the
Makefile libgcc_s
--- Comment #26 from david dot kirkby at onetel dot net 2009-10-01 08:34
---
I should have added this some time back, but Sun have confirmed this is a bug.
I should have a IDR from Sun myself in a couple of weeks, and a patch will be
on sunsolve some time after that. It will be fixed in
--- Comment #2 from ubizjak at gmail dot com 2009-10-01 08:21 ---
Patches should be posted to gcc-patches mailing list.
BTW: Where is the bug in your PR submission?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
--- Comment #1 from kirill at shutemov dot name 2009-10-01 08:02 ---
Created an attachment (id=18686)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18686&action=view)
Implement ASM_PREFERRED_EH_DATA_FORMAT macros for ARM
This macro chooses the encoding of pointers embedded in the
This macro chooses the encoding of pointers embedded in the exception handling
sections.
It needed to generate correct .cfi_personality derective. Without it we always
have TEXTREL in C++ shared libraries and PIE, if it compiled with exceptions.
--
Summary: ASM_PREFERRED_EH_DATA_FORM
--- Comment #3 from carrot at google dot com 2009-10-01 07:37 ---
(In reply to comment #2)
> Where does it come from? (Remember: option -dAP, then look at .s file)
>
The first several instructions and corresponding rtl patterns are:
cmp r0, #63
beq .L3
--- Comment #10 from burnus at gcc dot gnu dot org 2009-10-01 07:35 ---
(In reply to comment #9)
> Rounding modes are now implemented for formatted WRITE operations. I do not
> have a clear enough idea of what the rounding modes really mean for READ
> operations. For example:
>
> "Rou
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41524
--- Comment #1 from ramana at gcc dot gnu dot org 2009-10-01 07:03 ---
confirmed with trunk.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Sta
78 matches
Mail list logo
