--- Additional Comments From pcarlini at suse dot de 2005-05-22 09:15
---
Gaby, can you have a look? It seems to me that we should use the same approach
used in std_cmath.h for fpclassify co. In particular, when _GLIBCXX_USE_C99
is defined - that explicitly checks for llabs and lldiv -
--- Additional Comments From pcarlini at suse dot de 2005-05-22 09:32
---
Same for strt* and the other functions. Also we should remember to add to the
acinclude check for c99_stdlib the functions strtoll and strtoull, currently
missing.
(PS. In the meanwhile, done a minimal check that
--- Additional Comments From pcarlini at suse dot de 2005-05-22 10:21
---
Yes, in my opinion too, in Download - Releases should be present info strictly
about the Download of Releases ;), therefore, probably, immediately the list of
mirrors, or a link to it and, probably, some minimal
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-22 10:32 ---
Subject: Re: call of overloaded `llabs(int)' is ambiguous
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| Gaby, can you have a look?
Yup. Just woke up and many people are awaiting in the TODO
--- Additional Comments From pcarlini at suse dot de 2005-05-22 10:33
---
Another thought: maybe we want to keep the Timeline, and all the interesting
info about each release, easily reachable from the download info. In that case
we could consider linking the Timeline, that, as I said
--- Additional Comments From irar at il dot ibm dot com 2005-05-22 11:42
---
The problem is in vect-none.c itself. This patch fixes the problem
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02124.html (waiting for ok).
--
What|Removed |Added
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-05-22
11:42 ---
Also fixed in GCC 4.0.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13830
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-05-22
11:43 ---
Also fixed in GCC 4.0.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15453
Please do not use MAXPATHLEN, it is a arbitrary limit, and is not
defined on GNU. Currently gcc 4.0.0 is unbuildable on GNU since
[gcc]/gcc/tlink.c assumes that MAXPATHLEN is defined. Please do not
use these kind of limits in GNU programs.
Suggested fix is to declare initial_cwd as:
char
--
What|Removed |Added
CC||schwinge-bugzilla-gcc dot
||gnu dot org at nic-nac-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
14:04 ---
What about using PATH_MAX which is part of the POSIX standard?
--
What|Removed |Added
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13830
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15453
--
What|Removed |Added
GCC host triplet|x86_64-unknown-linux-gnu|
GCC target triplet||x86_64-unknown-linux-gnu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
14:13 ---
Fixed in 4.0.0 and above.
--
What|Removed |Added
Status|UNCONFIRMED
when running the testsuite
(http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01434.html)
g++.old-deja/g++.jason/thunk3.C contains syntax error
in target selector xfail rs6000-*-* powerpc-*-eabi
m68k-*-coff mn10300-*-* v850-*-* sh-*-* sh64-*-*
h8*-*-* xtensa-*-* m32r*-* for dg-do 1 run { xfail
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
14:50 ---
Confirmed, see the whole thread:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01937.html.
--
What|Removed |Added
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-22 15:35 ---
Subject: Re: MAXPATHLEN usage in [gcc]/gcc/tlink.c
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| What about using PATH_MAX which is part of the POSIX standard?
I think the point was
--- Additional Comments From schwab at suse dot de 2005-05-22 15:36 ---
Like most POSIX limits PATH_MAX may not be defined if the actual limit is not
fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21706
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-22
15:46 ---
Testing patch (from thread
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01937.html)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21707
gfortran.dg/dev_null.f90 fails to run. It appears that the
implementation of READ(..., end=100) does not properly check
for EOF. For discussion see,
http://gcc.gnu.org/ml/fortran/2005-05/msg00147.html
This problem affects FreeBSD, Darwin, and I suspect also
OpenBSD and NetBSD due to their
[ forwarded from http://bugs.debian.org/305344 ]
[EMAIL PROTECTED]:/tmp% cat test.c
double _Complex f(void) { return 1.0iF / 0.0; }
[EMAIL PROTECTED]:/tmp% gcc-3.4 -c test.c
test.c: In function `f':
test.c:1: internal compiler error: Segmentation fault
Problem not present in 4.0.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
16:08 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-22
16:26 ---
I think the problem here is that the applet calls
setBounds on the buttons in question. But maybe this is
valid as it explicitly asks for a certain size font?
FWIW the contents of the buttons do look
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-22
17:01 ---
Subject: Bug 21683
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-22 17:01:03
Modified files:
fixincludes: ChangeLog fixincl.c
Log message:
--- Additional Comments From gdr at gcc dot gnu dot org 2005-05-22 17:06
---
Patch applied.
--
What|Removed |Added
Status|NEW |RESOLVED
--
What|Removed |Added
Summary|[Regression] build failure |[4.1 Regression] build
|on i386-mingw (sys/wait.h |failure on i386-mingw
--
What|Removed |Added
BugsThisDependsOn||18373
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21582
--
What|Removed |Added
BugsThisDependsOn||18373
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21076
--
What|Removed |Added
BugsThisDependsOn||18373
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21348
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-05-22 18:10 ---
Subject: Re: COMPLEX function returns incompatible with
g77
Tobias Schlüter wrote:
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-10
22:23 ---
Fixed on
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-22
18:19 ---
*** This bug has been marked as a duplicate of 21593 ***
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-22
18:19 ---
*** Bug 21708 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-22
18:20 ---
From PR21708: This problem affects FreeBSD, Darwin, and I suspect also
OpenBSD and NetBSD due to their common legacy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21593
/*
* gcc3_arm_bug.c
* Written by Mikael Pettersson, [EMAIL PROTECTED], 2005-05-22.
* Adapted from glibc-2.3.5/sysdeps/generic/s_fmax.c
*
* gcc-3.4.4 configured for arm-unknown-linux gets an
* internal compiler error when compiling this program
* with optimisation enabled:
*
*
[EMAIL PROTECTED] mysys]# gcc -v -save-temps -
DDEFAULT_BASEDIR=\/usr/local/mysql\ -DDATADIR=\/usr/local/mysql/var\ -
DDEFAULT_CHARSET_HOME=\/usr/local/mysql\ -
DSHAREDIR=\/usr/local/mysql/share/mysql\ -DHAVE_CONFIG_H -I. -I. -I.. -
I../include -I.-O3 -DDBUG_OFF-MT default.o -MD -MP -
MF
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-22
18:35 ---
Patch submitted for review.
--
What|Removed |Added
URL|
--- Additional Comments From terry-palmer at btconnect dot com 2005-05-22
18:37 ---
Created an attachment (id=8948)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8948action=view)
pre-processed output as requested
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21711
--
What|Removed |Added
Component|c |rtl-optimization
Keywords||ice-on-valid-code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
18:47 ---
*** Bug 21710 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
18:47 ---
*** This bug has been marked as a duplicate of 15068 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
18:47 ---
*** This bug has been marked as a duplicate of 21173 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
18:47 ---
*** Bug 21711 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-22
18:55 ---
Subject: Re: FRE does not eliminate a
redundant pure call.
On Sun, 2005-05-22 at 13:42 +, kazu at cs dot umass dot edu wrote:
A patch was sent to kazu privately that bootstrapped and
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-22
19:06 ---
Kazuhiro Inaoka's patch
(http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01937.html) resolves this problem
Test summary available at
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01442.html
--
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-22
19:11 ---
(In reply to comment #3)
The problem is in vect-none.c itself. This patch fixes the problem
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02124.html (waiting for ok).
FYI I have regression tested this
gcc -v
Lecture des spécification à partir de /usr/lib/gcc-lib/powerpc-linux/3.3.6/specs
Configuré avec: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
19:24 ---
Confirmed.
--
What|Removed |Added
CC||rakdver
--- Additional Comments From roger at eyesopen dot com 2005-05-22 19:25
---
I posted a patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01956.html
to implement this in the RTL optimizers. Better to get it linked to the PR,
than slip through the cracks. The proposed change to
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-22
19:26 ---
There is no segfault any more:
$ gfc pr18923.f90
In file pr18923.f90:3
subroutine foo(i)
1
Error: PROGRAM attribute conflicts with PROCEDURE attribute at (1)
In file pr18923.f90:4
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-22
19:36 ---
Because do_something does not have to return, therefore
get_type2 does not necessarily have to be executed.
In this case we cannot move the call to get_type2 from
the loop (since do_something could for
--- Additional Comments From TazForEver at dlfp dot org 2005-05-22 19:54
---
quoteconst
Many functions do not examine any values except their arguments, and have no
effects except the return value. Basically this is just slightly more strict
class than the pure attribute below,
On Sun, 2005-05-22 at 19:36 +, rakdver at gcc dot gnu dot org wrote:
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-22
19:36 ---
Because do_something does not have to return, therefore
get_type2 does not necessarily have to be executed.
In this case we
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-22
19:54 ---
Subject: Re: missed optimization due with
const function and pulling out of loops
On Sun, 2005-05-22 at 19:36 +, rakdver at gcc dot gnu dot org wrote:
--- Additional Comments From rakdver
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 19:56 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
Because do_something does not have to return, therefore
get_type2 does not necessarily have to
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 20:01 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
quoteconst
Many functions do not examine any values except their arguments, and have
no
class index {};
int main (){
index i;
}
gets you:
foo.cc: In function `int main()':
foo.cc:3: error: `index' undeclared (first use this function)
foo.cc:3: error: (Each undeclared identifier is reported only once for each
function it appears in.)
foo.cc:3: error: expected `;' before i
--
--- Additional Comments From TazForEver at dlfp dot org 2005-05-22 20:12
---
OK, I understand :/
Thanks for you quick explanations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21712
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
20:14 ---
index is a POSIX function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21713
--- Additional Comments From igodard at pacbell dot net 2005-05-22 20:24
---
The test doesn't #include any posix functions. The problem seems to be a partial
hide of the name, because a simple declaration works:
int index;
int main (){
index = 0;
}
gives no errors. Interestingly,
--
What|Removed |Added
Keywords||rejects-valid
Known to fail||3.3.3 3.0.4 3.2.3 3.4.0
Known to work|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
20:30 ---
Confirmed, fixed in 4.0.0 at least but a regression from 2.95.3.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
20:38 ---
Fixed in 3.4.4 and above at least.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
20:43 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
20:43 ---
Mark as a dup of bug 15862.
*** This bug has been marked as a duplicate of 15862 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
20:43 ---
*** Bug 21713 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
20:59 ---
Fixed for 3.4.4 so closing as such.
--
What|Removed |Added
Status|ASSIGNED
--
Bug 20407 depends on bug 18327, which changed state.
Bug 18327 Summary: [3.3 Regression] ICE while compiling valid c code with g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18327
What|Old Value |New Value
--- Additional Comments From gerald at pfeifer dot com 2005-05-22 21:00
---
I just committed the following patch.
PR web/21679
Add links to the Releases and Snapshots pages near the top of the
navigation bar (the former replacing the current Timline link) and
remove these links from
--
What|Removed |Added
Summary|[3.3/3.4 Regression] Bug|[3.4 Regression] Bug box,
|box, verify_flow_info failed|verify_flow_info failed when
--
What|Removed |Added
Summary|[3.3/3.4 Regression] bad|[3.4 Regression] bad debug
|debug info for static nested|info for static nested
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-22 21:06 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED
.
Nevertheless, even if we are very strict with the definition, moving
get_type2 out of the loop is not a good idea, since get_type2 might
potentially be very expensive (and we have no way how to determine
that this is not the case), thus we would lose in case get_type2
should be never
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-22
21:10 ---
Subject: Re: missed optimization due with
const function and pulling out of loops
.
Nevertheless, even if we are very strict with the definition, moving
get_type2 out of the loop is not a
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 21:13 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
Nevertheless, even if we are very strict with the definition, moving
get_type2 out of the loop
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-22
21:17 ---
Subject: Bug 21376
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-22 21:17:43
Modified files:
libgfortran: ChangeLog
libgfortran/io :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-22
21:17 ---
Subject: Bug 21376
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-22 21:17:43
Modified files:
libgfortran: ChangeLog
libgfortran/io :
On Sun, 2005-05-22 at 21:13 +, rakdver at atrey dot karlin dot mff
dot cuni dot cz wrote:
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 21:13 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
--- Additional Comments From pcarlini at suse dot de 2005-05-22 21:20
---
Actually, I have a much better idea, that I'm testing right now: no need for
complex template-based tricks (in this case, at variance with the case of
classification macros, we *know* the type of the arguments!):
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-22
21:20 ---
Subject: Re: missed optimization due with
const function and pulling out of loops
On Sun, 2005-05-22 at 21:13 +, rakdver at atrey dot karlin dot mff
dot cuni dot cz wrote:
--- Additional
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-22
21:21 ---
Fixed. Thanks for reporting!
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 21:23 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
Nevertheless, even if we are very strict with the definition, moving
get_type2 out of the
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-22
21:25 ---
This is not invalid, we have no good reason to move get_type1 out of the loop
but not get_type2.
We can't cost either of them, yet we move one out of the loop, and not the
other.
Maybe you should actually
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-22
21:29 ---
G you should first try to understand what is happening, and then
reopen the bug.
get_type1 is always executed when the loop is entered, therefore moving it
out of the loop is always a win.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
21:32 ---
No this should happen.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-22
21:32 ---
OK, let's try it again. The facts are the following:
1. there is no mechanism in gfortran to issue warnings at runtime when those
depend on compilation flags
2. the meaning of $ as an edit descriptor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
21:34 ---
Then if you say it is expensive, why do we move the divide above the loop:
#define CONST __attribute__((const))
int get_type1(void) CONST;
int get_type2(void) CONST;
void* cast(void*, int) CONST;
void
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-22
21:36 ---
Do you still believe we should move gettype2 out of the loop???
#define CONST __attribute__((const))
int get_type1(void) CONST;
int get_type2(void) CONST;
void* cast(void*, int) CONST;
void
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-22 21:39 ---
Confirmed, reduced testcase:
char c; void f () { c /= 10; }
--
What|Removed |Added
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-22
21:41 ---
As for why we move the division -- most of the time, the behavior described
below will not happen. So if we have a reasonable estimate on how long the
moved calculation may take (which we have with
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22
21:43 ---
const is different from pure, const cannot read from memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21712
Bootstrapping gcc 4.1.0 20050521 (experimental) fails when compiling libjava:
java/lang/natConcreteProcess.cc:25:21: error: pthread.h: No such file or
directory
java/lang/natConcreteProcess.cc: In member function 'void
java::lang::ConcreteProcess$ProcessManager::init()':
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 21:50 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
const is different from pure, const cannot read from memory.
this is something that have been
--
What|Removed |Added
Component|java|libgcj
Keywords||build
On Sun, 2005-05-22 at 21:36 +, rakdver at gcc dot gnu dot org wrote:
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-22
21:36 ---
Do you still believe we should move gettype2 out of the loop???
Okay, let's compromise.
If i move cgraph do noreturn and infinite
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-22
21:56 ---
Subject: Re: missed optimization due with
const function and pulling out of loops
On Sun, 2005-05-22 at 21:36 +, rakdver at gcc dot gnu dot org wrote:
--- Additional Comments From rakdver
On Sun, 2005-05-22 at 21:51 +, rakdver at atrey dot karlin dot mff
dot cuni dot cz wrote:
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 21:50 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 22:05 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-22
21:36 ---
Do
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-22
22:05 ---
Subject: Re: missed optimization due with
const function and pulling out of loops
On Sun, 2005-05-22 at 21:51 +, rakdver at atrey dot karlin dot mff
dot cuni dot cz wrote:
--- Additional
1 - 100 of 109 matches
Mail list logo
