Getting the following exception with the gcj4.3.0
The code is not using any nio - but Jessie is and due to which I am getting
this exception. The same code does work with openjdk.
error pre-initialising SSL for JNDI connection: javax.naming.NamingException:
error pre-initialising SSL for JNDI con
--- Comment #24 from jvdelisle at verizon dot net 2007-12-02 02:05 ---
Subject: Re: access="stream",form="unformatted" doesn't
buffer
> m = where + s->active;
>
> if (s->physical_offset != m && lseek (s->fd, m, SEEK_SET) < 0)
> return NULL;
>
> I don't think this is correct.
m = where + s->active;
if (s->physical_offset != m && lseek (s->fd, m, SEEK_SET) < 0)
return NULL;
I don't think this is correct.
You are dead on, I have fixed this and have a patch regression testing now. The
above did not break backspace_6.f90, but it broke some other things. Stay
--- Comment #1 from christophe at saout dot de 2007-12-01 23:19 ---
Created an attachment (id=14679)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14679&action=view)
preprocessed source file
gunzip breaks.i.gz; g++ -o breaks.o -c breaks.i -O2 -march=pentium-m -fPIC
--
http://
I get this with the gcc 4.3 snapshot from 20071130 when compiling thunderbird:
leto:/home/chtephan > LANG=C g++ -o breaks.o -c breaks.i -O2 -march=pentium-m
-fPIC
nsUnicodeToJamoTTF.cpp: In function const JamoNormMap*
JamoClusterSearch(JamoNormMap, const JamoNormMap*, PRInt16):
nsUnicodeToJamoTT
--- Comment #6 from rask at gcc dot gnu dot org 2007-12-01 22:39 ---
Created an attachment (id=14678)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14678&action=view)
patch v2
The first patch caused build failure on sh and arm, this one fixes that.
--
rask at gcc dot gnu dot o
--- Comment #23 from tkoenig at gcc dot gnu dot org 2007-12-01 22:19
---
I'm studying why we get a regression in backspace_6.f, and
I'm confused by fd_alloc_r_at:
gfc_offset m;
if (where == -1)
where = s->logical_offset;
...
What happens if where != -1 (if we use salloc_r_a
The following libffi tests are regressed under powerpc-apple-darwin9...
AIL: libffi.call/nested_struct5.c -O0 -W -Wall execution test
FAIL: libffi.call/nested_struct5.c -O2 execution test
FAIL: libffi.call/nested_struct5.c -O3 execution test
FAIL: libffi.call/nested_struct5.c -Os execution test
T
--- Comment #22 from kargl at gcc dot gnu dot org 2007-12-01 22:08 ---
(In reply to comment #19)
> I don't see the "Are we lucky and avoid syscall?" hack in the fd_seek
> routine from unix.c of the gcc 4.0 branch. So one could argue that it was a
> performance regression introduced
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2007-12-01 22:07
---
Reply to comment #18, Thomas, A particular reason I do not recall. Have you
tested without it? It seems from the description of the alloc scheme in the
comments we should only have to free the stream (sfree).
--- Comment #4 from haubi at gentoo dot org 2007-12-01 22:04 ---
Same here with gcc-4.2.2 and powerpc-ibm-aix5.3.0.0.
Some diagnostics what happens when _LARGE_FILES (and _LARGE_FILE_API) is
defined:
/* would both be 'long' without _LARGE_FILES: */
typedef long long fpos_t;
typedef l
--- Comment #20 from tkoenig at gcc dot gnu dot org 2007-12-01 21:53
---
(In reply to comment #19)
> I don't see the "Are we lucky and avoid syscall?" hack in the fd_seek
> routine from unix.c of the gcc 4.0 branch. So one could argue that it was a
> performance regression introdu
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2007-12-01
21:50 ---
I don't see the "Are we lucky and avoid syscall?" hack in the fd_seek
routine from unix.c of the gcc 4.0 branch. So one could argue that it was a
performance regression introduced in gcc 4.1.
--
--- Comment #18 from tkoenig at gcc dot gnu dot org 2007-12-01 21:30
---
(In reply to comment #13)
> Created an attachment (id=14676)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14676&action=view) [edit]
HI Jerry,
what is the reason why you still flush for formatted
stream i/o
--- Comment #3 from dominiq at lps dot ens dot fr 2007-12-01 21:21 ---
Subject: Re: misprinting of derived types
> I get the same results with Sun F95 and Ifort
So do g95 and Portland Group Fortran. And I think I understand
now that it is not a bug. What is printed is pts(1)%x, pts(1)
--- Comment #8 from andreast at gcc dot gnu dot org 2007-12-01 21:02
---
Implemented. Hopefully it will be of some use to others :)
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from andreast at gcc dot gnu dot org 2007-12-01 21:00
---
Subject: Bug 31937
Author: andreast
Date: Sat Dec 1 21:00:04 2007
New Revision: 130559
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130559
Log:
2007-12-01 Andreas Tobler <[EMAIL PROTECTED]>
P
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-12-01 20:43
---
I get the same results with Sun F95 and Ifort
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34306
When built under Darwin9, the objc testsuite exhibits a number of regressions
compared to Darwin8 due to compilation errors of "expected ';' before
'__attribute__'". These new failures include...
objc/execute/bycopy-1.m compilation
objc/execute/bycopy-2.m compilation
objc/execute/bycopy-3.m compil
--- Comment #19 from lucier at math dot purdue dot edu 2007-12-01 18:59
---
Subject: Re: [4.3 Regression] 22% performance slowdown from 4.2.2 to 4.3.0 in
floating-point code
On Nov 30, 2007, at 9:58 AM, bonzini at gnu dot org wrote:
> -fno-forward-propagate
I don't know how to debu
--- Comment #6 from schwab at suse dot de 2007-12-01 17:21 ---
Looks good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34302
--- Comment #1 from rbuergel at web dot de 2007-12-01 16:15 ---
I forgot to mention, that gcc works correctly, if the header is not
precompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34309
this is an "enhanced" version of bug 24389.
The bug is still present, if the template variable is defined in a precompiled
header.
Testcase:
== header.h ==
#include
== 1.cpp ==
#include "header.h"
== 2.cpp ==
#include "header.h"
int main(){}
compiling them:
g++ -c header.h
g++ 1.cpp 2
--- Comment #26 from pcarlini at suse dot de 2007-12-01 15:00 ---
Hi Paolo, any chance you can comment on this PR / review the patches in
Comments 20 - 23 ? Thanks in advance.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from pcarlini at suse dot de 2007-12-01 14:52 ---
After almost a year, feedback is definitely not forthcoming...
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from zadeck at naturalbridge dot com 2007-12-01 13:55
---
Created an attachment (id=14677)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14677&action=view)
possible patch to fix this
andreas,
would you try this patch? I will try to make a small test case if this
--- Comment #5 from pcarlini at suse dot de 2007-12-01 13:54 ---
Unassigning, likely other can fix it much easily than me
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #3 from pcarlini at suse dot de 2007-12-01 12:12 ---
Yes, and active branches are all fine.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from sam at gcc dot gnu dot org 2007-12-01 12:04 ---
The patch has been committed in SVN trunk and in the 4.2 branch.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from sam at gcc dot gnu dot org 2007-12-01 12:03 ---
Subject: Bug 33722
Author: sam
Date: Sat Dec 1 12:03:42 2007
New Revision: 130556
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130556
Log:
2007-12-01 Kostik Belousov <[EMAIL PROTECTED]>
gcc/ada/
--- Comment #3 from sam at gcc dot gnu dot org 2007-12-01 11:52 ---
Subject: Bug 33722
Author: sam
Date: Sat Dec 1 11:52:42 2007
New Revision: 130555
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130555
Log:
2007-12-01 Kostik Belousov <[EMAIL PROTECTED]>
gcc/ada/
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-01 11:38 ---
This is just the standard recursive decendent parser issue. if you have a lot
of levels, it will crash at some point. I don't think this bug can be fixed.
Try increasing the stack size and you will see it no longe
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-01 11:33 ---
Hop::Hop(string):msg(msg)
{}
Does not reference msg the argument here since there is no such thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34307
--- Comment #9 from aaw at gcc dot gnu dot org 2007-12-01 09:08 ---
Fixed by revision 130554.
--
aaw at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #8 from aaw at gcc dot gnu dot org 2007-12-01 08:57 ---
Subject: Bug 8171
Author: aaw
Date: Sat Dec 1 08:56:55 2007
New Revision: 130554
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130554
Log:
PR c++/8171
gcc/cp/
* typeck.c (build_binary_
gcc gives an internal error when compiling a source
file which contains _lots_ of stars '*' (pointer of pointer
of pointer etc.) The source file looks admitedly silly but
it should not cause gcc to segfault.
This bug was filed in Ubuntu bug database:
https://bugs.launchpad.net/ubuntu/+source/g
37 matches
Mail list logo
