--- Comment #28 from mikpe at it dot uu dot se 2010-04-21 07:52 ---
(In reply to comment #27)
> I think this broke gcc/testsuite/gcc.target/arm/sibcall-1.c. I noticed it
> first
> when my 4.5-based gcc regressed on this test, and found evidence that trunk
> regressed similary between r1
--- Comment #29 from rguenther at suse dot de 2010-04-21 08:48 ---
Subject: Re: [4.5 Regression] FAIL:
gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
On Tue, 20 Apr 2010, mikpe at it dot uu dot se wrote:
> --- Comment #27 from mikpe at it dot uu dot se 2010
--- Comment #12 from redi at gcc dot gnu dot org 2010-04-21 09:23 ---
(In reply to comment #8)
> By the way, there's no warning with -Wall or even -Wextra. Is there a flag
> -Wabsolutely_all_warnings_we_promise that I have missed and that would really
> enable *all* warnings ?
No, sorr
It would be very nice if gcc emitted debug information that allowed profilers
and debuggers the option to extract a stack trace which included calls to
inlined functions. This would allow developers much greater insight into the
behavior of optimized code.
C++ programs would benefit disproportion
--- Comment #1 from scovich at gmail dot com 2010-04-21 09:29 ---
(In reply to comment #0)
One more way debugging would improve: it would become possible to set
breakpoints in inlined functions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43828
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-21 09:29 ---
They are feasible, but they do need a very strict specification to be usable.
With 4.6 you can check the -alias dumps when building with -flto -fipa-pta
to see if the compiler maybe can already analyze the situation
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org
|dot org
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-21 09:40 ---
Right, this is a GNU extension used to implement the library, which was later
standardised. We also support 'long long' in C++03 mode.
GCC is not intended to be a strict ANSI C++ verification tool, so doesn't
reject all
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fabien dot chene at gmail
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-21 10:01 ---
It works for me on x86_64-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43823
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-21 10:03 ---
GCC already emits that (and emits that for quite some time already).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-21 10:31 ---
BTW, gcc stopped emitting with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129882
- PR10220 commit.
Unfortunately that change isn't even mentioned in the ChangeLog entry nor I
could find any discussions about it
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2010-04-21 10:38
---
(In reply to comment #10)
> Unfortunately that change isn't even mentioned in the ChangeLog entry nor I
> could find any discussions about it on the mailing list from that time.
In the bugzilla PR you reference,
--- Comment #12 from jakub at gcc dot gnu dot org 2010-04-21 10:43 ---
Yeah, that's exactly the hunk I'm referring to. The gdb patch Jan provided
relies on DW_AT_MIPS_linkage_name (or DW_AT_linkage_name hopefully for DWARF4)
to be provided. While for most normal Fortran identifiers whe
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2010-04-21 10:46
---
I have googled the gcc.gnu.org domain for my name and DW_AT_MIPS_linkage_name,
and came up with nothing relevant. So, I never proposed or sought to get this
part approved, which confirms it's probably just human
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-04-21 10:47
---
There are two problems here:
1. The immediate problem is that "movsi_m68k" doesn't allow (const) to be moved
to data register (see last alternative if movsi_m68k).
2. For reason, which I have not yet investigated
--- Comment #8 from irar at il dot ibm dot com 2010-04-21 11:33 ---
Yes, it's possible to add this to SLP. But I don't understand how
D.3154_3 = COMPLEX_EXPR ;
should be vectorized. D.3154_3 is complex and the rhs will be a vector
{D.3163_8, D.3164_9} (btw, we have to change float to do
--- Comment #9 from rguenther at suse dot de 2010-04-21 11:44 ---
Subject: Re: C complex numbers, amd64 SSE, missed
optimization opportunity
On Wed, 21 Apr 2010, irar at il dot ibm dot com wrote:
> --- Comment #8 from irar at il dot ibm dot com 2010-04-21 11:33 ---
> Yes, it
--- Comment #6 from oberlaender at fzi dot de 2010-04-21 11:48 ---
A test with a g++-4.4.2 I built myself has the same problem:
$ g++-4.4.2 -c -o bugtest.out -O2 bugtest.ii
projects/odete/bugtest.cpp: In member function bool
tBspTree2D::Intersect(const tVec2f&, const tVec2f&, tVec2f&,
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-21 11:49 ---
(In reply to comment #4)
> Subject: Re: [4.5 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal
> compiler error)
>
> > Can you bisect the few commits that happened inbetween? Like reverting
> > the fixes fo
--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-21 11:58 ---
Subject: Bug 43570
Author: jakub
Date: Wed Apr 21 11:57:42 2010
New Revision: 158594
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158594
Log:
PR middle-end/43570
* omp-low.c (scan_sharing_cla
465.tonto in one of its hot loops does essentially what the following reduced
testcase does:
subroutine make_esss(esss,Ix,Iyz,e_x,ii_ivec)
real(kind=kind(1.0d0)), dimension(:), intent(inout) :: esss
real(kind=kind(1.0d0)), dimension(:,:), pointer :: Ix,Iyz
integer(kind=kind(1)), dimension(:)
--- Comment #12 from burnus at gcc dot gnu dot org 2010-04-21 12:25 ---
Close as FIXED. If someone feels strong about allowing -fcheck=recursion with
-fopenmp, please reopen. (I think as fopenmp implies -frecursive, it does not
make much sense.)
--
burnus at gcc dot gnu dot org chang
--- Comment #7 from oberlaender at fzi dot de 2010-04-21 12:40 ---
4.4.3 gives me the same problem, I'm starting to think I'm really doing
something wrong.
$ g++-4.4.3 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../gcc-4.4.3/configure
--prefix=/home/oberlaen/local/s
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-21 12:51 ---
Scalarization is just difficult...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-21 13:08 ---
Wade-through-the-code dump:
gfc_trans_assignment_1 gets
make_esss:esss(:)
(+ make_esss:esss(:) _gfortran_sum_r8[[(((* make_esss:ix(: ,
__convert_i4_i8[[((make_esss:e_x(FULL)))]]) make_esss:iyz(: ,
__convert_i4_
--- Comment #4 from schwab at linux-m68k dot org 2010-04-21 13:22 ---
Introduced in r27576. Presumably the first alternative is supposed to catch
this case, through T+g, but T does not match if flag_pic, contrary to its
documentation (introduced in r120961).
--
http://gcc.gnu.org/b
On Linux/x86, revision 158589 gave:
FAIL: gcc.dg/torture/builtin-cproj-3.c -O0 execution test
FAIL: gcc.dg/torture/builtin-cproj-3.c -O1 execution test
FAIL: gcc.dg/torture/builtin-cproj-3.c -O2 execution test
FAIL: gcc.dg/torture/builtin-cproj-3.c -O2 -flto execution test
FAIL: gcc.dg/tor
The following code reproduces the Example in n3092 (FCD) 5.1.2/8, complete with
the comments given there:
14:36:12 Paul bibbi...@jijou
/cygdrive/d/CPPProjects/nano/gcc_bugs $cat _5_1_2_8.cpp
// file: _5_1_2_8.cpp
struct S2 { void f(int i); };
void S2::f(int i) {
[&, i]{ }; // OK
[&, &i]
--- Comment #8 from oberlaender at fzi dot de 2010-04-21 13:42 ---
Just tested 4.5.0, which did not crash.
$ g++-4.5.0 -c -o bugtest.out -O2 bugtest.ii
$ g++-4.5.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.5.0
COLLECT_LTO_WRAPPER=/home/oberlaen/local/stow/gcc-4.5.0/libexec/gcc/i486-li
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-21 13:43 ---
It will always fail on glibc older than 2.12, which hasn't been
released yet.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
An OPEN statement needs to either have a unit number in the first
item in the list, or have a UNIT= (or NEWUNIT= in F2008) keyword
somewhere else. Here is an example where the unit number is not
specified, yet gfortran does not issue an error:
subroutine openit
implicit none
open (file='x')
--- Comment #4 from jakub at gcc dot gnu dot org 2010-04-21 13:59 ---
Subject: Bug 43569
Author: jakub
Date: Wed Apr 21 13:58:49 2010
New Revision: 158598
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158598
Log:
PR libgomp/43569
* sections.c (gomp_sections_init
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-21 13:59 ---
Subject: Bug 43569
Author: jakub
Date: Wed Apr 21 13:58:59 2010
New Revision: 158599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158599
Log:
PR libgomp/43569
* sections.c (gomp_sections_init
--- Comment #9 from jakub at gcc dot gnu dot org 2010-04-21 14:00 ---
Subject: Bug 43706
Author: jakub
Date: Wed Apr 21 13:59:39 2010
New Revision: 158600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158600
Log:
PR libgomp/43706
* config/linux/affinity.c (gomp_
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-21 14:01 ---
Subject: Bug 43706
Author: jakub
Date: Wed Apr 21 14:00:10 2010
New Revision: 158601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158601
Log:
PR libgomp/43706
* config/linux/affinity.c (gomp
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-21 14:01 ---
Subject: Bug 43570
Author: jakub
Date: Wed Apr 21 14:01:30 2010
New Revision: 158602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158602
Log:
PR middle-end/43570
* omp-low.c (scan_sharing_cla
--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-21 14:02 ---
Subject: Bug 43570
Author: jakub
Date: Wed Apr 21 14:02:39 2010
New Revision: 158603
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158603
Log:
PR middle-end/43570
* omp-low.c (scan_sharing_cla
--- Comment #1 from w6ws at earthlink dot net 2010-04-21 14:05 ---
An additional test: with just an OPEN statement with no list, gfortran issues:
In file miniopen.f90:4
open ()
1
Error: Syntax error in OPEN statement at (1)
While the message is technically correct, it would
--- Comment #6 from jakub at gcc dot gnu dot org 2010-04-21 14:05 ---
Fixed for 4.4.4/4.5.1/4.6.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jakub at gcc dot gnu dot org 2010-04-21 14:05 ---
GOMP_CPU_AFFINITY vs. throttling fixed for 4.4.4/4.5.1/4.6.0.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from jakub at gcc dot gnu dot org 2010-04-21 14:06 ---
Fixed for 4.4.4/4.5.1/4.6.0.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43569
--- Comment #1 from ro at gcc dot gnu dot org 2010-04-21 14:08 ---
This bug is long gone.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-21 14:09 ---
Fortran 2008 (almost FDIS version) has:
C904 (R904) If the NEWUNIT= specifier does not appear, a file-unit-number shall
be speci ed; if
the optional characters UNIT= are omitted, the file-unit-number
shal
$ cat t.c
extern unsigned char data[5];
unsigned char
foo (char *str)
{
int i, j;
unsigned char c = 0;
for (i = 0; i < 8; i++)
{
j = i * 5;
if ((j % 8) > 3)
c |= data[(j / 8) + 1];
}
return c;
}
$ gcc t.c -O3 -Wall -c
t.c: In function foo:
t.c:13:11: warning
--- Comment #2 from ro at gcc dot gnu dot org 2010-04-21 14:11 ---
Mine.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc do
Hi,
I'm experiencing problems when statically linking using particular GCC supplied
with XCode 3.2.2: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build
5659) on Mac OS X 10.6.2. Computations become incorrect.
My application consists of main in C and computational code in Fortran (NETLIB
--- Comment #1 from alexander dot v dot kobotov at intel dot com
2010-04-21 14:18 ---
Created an attachment (id=20452)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20452&action=view)
Object files and good output and bad output.
File linked correctly is in a.out.good
File with er
--- Comment #12 from mika dot fischer at kit dot edu 2010-04-21 14:23
---
Just to make it clear, this patch most probably does not fix the issue we're
having, since it can be triggered without using GOMP_CPU_AFFINITY.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-21
14:24 ---
Subject: Re: stabs debug info fails onIRIX 5.3
I don't think this is a gcc bug. While the native IRIX 5 tools use
ECOFF debugging info embedded in ELF (mdebug), they don't know about
Stabs-in-ECOFF/mdebug
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-21 14:26 ---
subroutine test0(esss,Ix, e_x)
real(kind=kind(1.0d0)), dimension(:), intent(out) :: esss
real(kind=kind(1.0d0)), dimension(:) :: Ix
integer(kind=kind(1)), dimension(:) :: e_x
esss = Ix(e_x)
end subroutine
wh
--- Comment #9 from pault at gcc dot gnu dot org 2010-04-21 14:29 ---
Created an attachment (id=20453)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20453&action=view)
Version of fix for fortran-dev
This hasn been fully bootstrapped but runs gfortran.dg/dynamic*, proc* and
class*
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-21 14:37 ---
Report it to Apple. The version Apple ships does not resemble anything like
an FSF release that would still be supported.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from jiez at gcc dot gnu dot org 2010-04-21 14:48 ---
The patch:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01304.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43833
The testcase I'm attaching shortly will be miscompiled by IPA-SRA.
The problem is, that SRA splits the pointer argument 'c' of mark_cell into
two new parameters, one being a pointer itself, and another int param. But it
doesn't rewrite the attribute list of the fndecl, hence the nonnull attributes
--- Comment #1 from matz at gcc dot gnu dot org 2010-04-21 15:08 ---
Created an attachment (id=20454)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20454&action=view)
testcase
# gcc -O2 sra-nonnull.c && ./a.out
Segmentation fault
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
d with: /data03/vondele/gcc_4_4_branch/gcc/configure
--prefix=/data03/vondele/gcc_4_4_branch/build
--with-ppl=/data03/vondele/gcc_trunk/build/
--with-cloog=/data03/vondele/gcc_trunk/build/ --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
gcc version 4.4.4 20100421 (prerelease) [g
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-21 15:30 ---
4.3.1 ([gcc-4_3-branch revision 135036]) does not fail, so marking as
regression.
4.5.0 works as well
with 4.4.4 I have this backtrace:
(gdb) bt
#0 bitmap_element_allocate (head=0x10284c0) at
/data03/vondele/gcc_4_4_b
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43836
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-21 15:51 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-04-21 16:04 ---
Mine
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #9 from redi at gcc dot gnu dot org 2010-04-21 16:08 ---
I've just been bitten by this on Solaris 10, and I think lots more people will
be now that gcc 4.5.0 has been released.
The problem is made worse if libstdc++ (or libgomp etc.) is built with symbol
versioning enabled b
--- Comment #10 from redi at gcc dot gnu dot org 2010-04-21 16:13 ---
P.S. the workaround is a hack and not ideal, because it adds RPATH=$ORIGIN to
every binary object that gets built including the front-end drivers, cc1plus,
collect2 etc. but it is only needed by shared libs that depen
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-04-21 16:21 ---
I have submitted a fix to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01315.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43812
--- Comment #9 from redi at gcc dot gnu dot org 2010-04-21 16:24 ---
I tested on an x86_64 box (with -m32 because your preprocessed source was made
on a 32bit box so it was necessary) so I definitely have a lot more memory
available
I'm still thinking it's a problem with running out of
--- Comment #6 from sje at cup dot hp dot com 2010-04-21 16:27 ---
This looks like what I see on ia64-debian-linux-gnu as well.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--
--- Comment #8 from steven at gcc dot gnu dot org 2010-04-21 16:31 ---
How can this possibly be a regression in 4.5 if -fwhole-program is new there?
Regression means "worked in an earlier release" and there is no earlier release
with this feature.
--
steven at gcc dot gnu dot org cha
--- Comment #39 from aph at gcc dot gnu dot org 2010-04-21 16:34 ---
Subject: Bug 40860
Author: aph
Date: Wed Apr 21 16:34:01 2010
New Revision: 158611
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158611
Log:
2010-04-19 Andrew Haley
PR libgcj/40860
* config
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-04-21 16:43 ---
-fwhole-program is old.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-04-21 16:43
---
Created an attachment (id=20455)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20455&action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43341
--- Comment #7 from amonakov at gcc dot gnu dot org 2010-04-21 16:45
---
*** This bug has been marked as a duplicate of 43341 ***
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from amonakov at gcc dot gnu dot org 2010-04-21 16:45
---
*** Bug 43825 has been marked as a duplicate of this bug. ***
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from amonakov at gcc dot gnu dot org 2010-04-21 16:48
---
Taras, to avoid triggering the problem from firefox you can search for the file
(as I remember there is only one in xulrunner) with #pragma pack(1) and does
not reset it, and add #pragma pack() in the end of that f
--- Comment #14 from jakub at gcc dot gnu dot org 2010-04-21 16:49 ---
Subject: Bug 40040
Author: jakub
Date: Wed Apr 21 16:48:41 2010
New Revision: 158612
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158612
Log:
PR debug/40040
* dwarf2out.c (add_name_and_src_c
--- Comment #10 from pault at gcc dot gnu dot org 2010-04-21 16:50 ---
Subject: Bug 43326
Author: pault
Date: Wed Apr 21 16:49:28 2010
New Revision: 158613
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158613
Log:
2010-04-21 Paul Thomas
PR fortran/43326
* re
--- Comment #11 from pault at gcc dot gnu dot org 2010-04-21 16:51 ---
Fixed on fortran-dev.
Thanks, as usual, for the report, Janus, and thanks for the reminder, Dominique
:-)
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-21 16:54 ---
(In reply to comment #2)
> Right, this is a GNU extension used to implement the library, which was later
> standardised. We also support 'long long' in C++03 mode.
Yes but with -pedantic we do warn about long long:
--- Comment #3 from amonakov at gcc dot gnu dot org 2010-04-21 16:54
---
(In reply to comment #1)
> Created an attachment (id=20455)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20455&action=view) [edit]
> proposed patch
>
GCC generates gcov structures at runtime, and #pragma p
--
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 paolo dot carlini at oracle dot com 2010-04-21 17:04
---
static_asserts are fine, of course. Otherwise, if the real issue is that errors
coming from system headers are suppressed and shouldn't, sometimes, from the
user point of view, that is a **front-end** issue, a
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-21 17:04 ---
good point
then #pragma GCC system_header must disable the warning, so we can use inline
namespaces and variadic templates in the standard library
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43824
--- Comment #40 from aph at gcc dot gnu dot org 2010-04-21 17:05 ---
Subject: Bug 40860
Author: aph
Date: Wed Apr 21 17:04:42 2010
New Revision: 158614
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158614
Log:
2010-04-19 Andrew Haley
PR libgcj/40860
* config
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-21 17:09 ---
> thanks for the reminder, Dominique
You're welcome!-)
Just another one: modulo spaces(?)
gcc/testsuite/gfortran.dg/dynamic_dispatch_7.f03 in trunk and
gcc/testsuite/gfortran.dg/dynamic_dispatch_9.f03 in fortran-de
--- Comment #14 from paolo dot carlini at oracle dot com 2010-04-21 17:11
---
Forgot: before doing anything about those diagnostic issues, we should double
check what other compilers do with / without our library, thus, say current ICC
/ something else (even among those available online
--- Comment #15 from redi at gcc dot gnu dot org 2010-04-21 17:41 ---
Comeau warns on the auto_ptr case. boost::shared_ptr refuses to compile if the
type is incomplete
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
Follow up to PR 43836 and http://gcc.gnu.org/ml/fortran/2010-04/msg00222.html
> It would be good to set TREE_NOTHROW also on libgfortran library calls
> that are known not to throw exceptions (I guess most of them, except
> those that do IO).
POSIX lists which libc functions have to and can thr
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-21 17:48 ---
See patch at http://gcc.gnu.org/ml/fortran/2010-04/msg00222.html and follow up
at PR 43837
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43836
--- Comment #9 from tglek at mozilla dot com 2010-04-21 17:48 ---
(In reply to comment #8)
> Taras, to avoid triggering the problem from firefox you can search for the
> file
> (as I remember there is only one in xulrunner) with #pragma pack(1) and does
> not reset it, and add #pragma p
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-21 17:53 ---
(In reply to comment #2)
> See patch at http://gcc.gnu.org/ml/fortran/2010-04/msg00222.html and follow up
> at PR 43837
beats the speed of light... thanks.
A very practical question. Is Fortran code compiled with -fexc
g++ -v:
Using built-in specs.
Target: i686-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-z
--- Comment #1 from slawomir at ezono dot com 2010-04-21 18:15 ---
Created an attachment (id=20456)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20456&action=view)
Preprocessed source of example program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
--- Comment #16 from paolo dot carlini at oracle dot com 2010-04-21 18:18
---
Note I'm traveling, thus I have limited capabilities. I strongly recommend
digging out that conversation about the pragma itself, with Ian too involved,
and trying to put to good use static_asserts and any oth
--- Comment #17 from redi at gcc dot gnu dot org 2010-04-21 18:26 ---
ok, thanks for the pointers, I'll hunt for the discussion
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
--- Comment #10 from irar at il dot ibm dot com 2010-04-21 18:33 ---
Thanks. So, it is not always profitable and requires a cost model.
I am now working on cost model for basic block vectorization, I can look at
this once we have one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
libjava doesn't link libgcj with -liconv during build when
--with-libiconv-prefix=/opt/local is used, and no corresponding -L for the
-liconv is issued on the link line when running the libjava testsuite (jni.exp)
for the FAIL: PR16923 run testcase:
Executing on host: /Users/mrs/net/gcc-java/gcc/x
--- Comment #2 from mrs at gcc dot gnu dot org 2010-04-21 18:39 ---
When I run it by hand, I get:
$ /Users/mrs/net/gcc-java/gcc/xgcc -B/Users/mrs/net/gcc-java/gcc/
/Users/mrs/net/gcc/libjava/testsuite/libjava.jni/invocation/PR16923.c
-bind_at_load -multiply_defined suppress -I. -I..
-
--- Comment #1 from mrs at gcc dot gnu dot org 2010-04-21 18:44 ---
I think this is the root cause of PR43086.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43839
--- Comment #18 from paolo dot carlini at oracle dot com 2010-04-21 18:48
---
c++/43167 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
1 - 100 of 152 matches
Mail list logo
