--- Comment #3 from Thomas dot Koenig at online dot de 2007-01-13 08:42
---
Subject: Re: Strange syntax error with high-value character
jvdelisle at gcc dot gnu dot org wrote:
Turns out that the character 254 which is Hex FE is also the 2's complement
representation of -2 which is
Salute Man
Don't tell me why your schlong is so small,
I will better help you to make it really Bigger!
Why bigger? Because over 74% of all women need a longer
one-eyed monster to satisfy their desire!
Go there and get your solution: http://www.nattiaho.com
It'll really help you!
We will
--- Comment #4 from Thomas dot Koenig at online dot de 2007-01-13 11:51
---
Subject: Re: Strange syntax error with high-value character
jvdelisle at gcc dot gnu dot org wrote:
Turns out that the character 254 which is Hex FE is also the 2's complement
representation of -2 which is
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #2 from paolo at gcc dot gnu dot org 2007-01-13 12:24 ---
Subject: Bug 14991
Author: paolo
Date: Sat Jan 13 12:24:02 2007
New Revision: 120749
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120749
Log:
2007-01-13 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from paolo at gcc dot gnu dot org 2007-01-13 12:24 ---
Subject: Bug 14991
Author: paolo
Date: Sat Jan 13 12:24:20 2007
New Revision: 120750
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120750
Log:
2007-01-13 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from pcarlini at suse dot de 2007-01-13 12:25 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from Bil dot Kleb at NASA dot gov 2007-01-13 12:35 ---
I've just tried to duplicate the compile time difference with -Wall and found
that the -Wall was a red herring -- it always takes 169 minutes to compile our
code with gfortran, -Wall or not.
This is about 8 times
--- Comment #11 from danglin at gcc dot gnu dot org 2007-01-13 16:01
---
The problem reported in the PR is fixed in 4.0. Other issues that
prevented building libstdc++-v3 using HP as are fixed in 4.0.4 by
these two changes:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01060.html
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-01-13 17:08
---
This seems to be a duplicate of PR29573, as it was fixed by the same patch.
*** This bug has been marked as a duplicate of 29573 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-01-13 17:08
---
*** Bug 28451 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29573
--- Comment #24 from dominiq at lps dot ens dot fr 2007-01-13 17:09 ---
I have applied the change to the latest snapshot (4.3.0 20070112) and the tests
compile now without error on OSX 10.3.9.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406
--- Comment #4 from kargl at troutmask dot apl dot washington dot edu
2007-01-13 17:23 ---
Subject: Re: gfortran compile times excessive with
-Wall
Bil dot Kleb at NASA dot gov wrote:
Gfortran's compilation time is mainly due to a three routines that take on the
order of 1/2
--- Comment #1 from h dot b dot furuseth at usit dot uio dot no 2007-01-13
18:40 ---
The warning is a bit misleading,
function might be possible candidate for 'printf' format attribute
means the _calling_ function might be such a candidate, not the function
being called on the line
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-01-13 18:45
---
Assuming this regression tests OK, I think this is an obvious and simple
Thanks :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
It seems that tgmath.h is not available on Darwin:
$ gcc-dp-4.2 -std=gnu99 -Wall -o complex complex.c
complex.c:3:20: error: tgmath.h: No such file or directory
$ gcc-dp-4.2 --version
gcc-dp-4.2 (GCC) 4.2.0 20060729 (experimental)
There is no file tgmath.h provided with the compiler that could
Here is some undefined behavior which it would be nice if gcc
warned about, since stdarg is such a hairy part of the standard:
#include stdarg.h
void foo(register short paramN, ...)
{
va_list ap;
va_start(ap, paramN); // Undefined by C99 7.15.1.4p4 (va_start):
// If the parameter parmN is
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-13 18:58 ---
tgmath.h is not required to be provided by a freestanding compiler so we don't
include it.
Read: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00921.html
Which is the follow up by JSM on this matter.
We will not
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-01-13 19:08
---
Subject: Bug 30435
Author: jvdelisle
Date: Sat Jan 13 19:08:40 2007
New Revision: 120755
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120755
Log:
2007-01-13 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-01-13 19:11
---
Subject: Bug 30435
Author: jvdelisle
Date: Sat Jan 13 19:11:02 2007
New Revision: 120756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120756
Log:
2007-01-13 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-01-13 19:43 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01146.html
Confirm that it cures the testcase on a vax would be nice...
--
ghazi at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-01-13 21:00
---
Subject: Bug 30435
Author: jvdelisle
Date: Sat Jan 13 21:00:31 2007
New Revision: 120758
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120758
Log:
2007-01-13 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-01-13 21:03
---
Subject: Bug 30435
Author: jvdelisle
Date: Sat Jan 13 21:03:17 2007
New Revision: 120759
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120759
Log:
2007-01-13 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-01-13 21:05
---
Fixed on 4.1, 4.2, and 4.3
Drew, thanks for reporting this bug.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from Bil dot Kleb at NASA dot gov 2007-01-13 21:11 ---
Created an attachment (id=12896)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12896action=view)
Entire compilation log with -fmem-report -ftime-report turned on
The trouble routines are part of the Adjoint
--- Comment #8 from jasonmbechtel at gmail dot com 2007-01-13 21:11 ---
I filed the bug with Ubuntu. It is bug #79132:
https://launchpad.net/ubuntu/+source/gcc-defaults/+bug/79132
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
--- Comment #6 from Bil dot Kleb at NASA dot gov 2007-01-13 21:12 ---
Created an attachment (id=12897)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12897action=view)
Lakos-style use associations for residual_turbpart.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
--- Comment #9 from jasonmbechtel at gmail dot com 2007-01-13 21:12 ---
I also noticed while recreating the bug for the Ubuntu submission that I made a
mistake in my original bug report here. It should be
cd Situs_2.2.1/src
make all
(Note the /src.)
--
--- Comment #7 from Bil dot Kleb at NASA dot gov 2007-01-13 21:13 ---
Created an attachment (id=12898)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12898action=view)
Lakos-style use associations for residual_turbulent.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
--- Comment #8 from Bil dot Kleb at NASA dot gov 2007-01-13 21:13 ---
Created an attachment (id=12899)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12899action=view)
Lakos-style use associations for precond_turbpart.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
--- Comment #9 from Bil dot Kleb at NASA dot gov 2007-01-13 21:14 ---
Created an attachment (id=12900)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12900action=view)
Lakos-style use associations for precond_turbulent.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
--- Comment #10 from Bil dot Kleb at NASA dot gov 2007-01-13 21:17 ---
Based on the Lakos-style analysis of the dependencies for these particular
routines, it /might/ be possible to supply self-contained source; but it will
take a while to check with the powers that be.
--
I just tried to compile Suse Linux package bzflag-2.0.8-22
with the new GNU C compiler version 4.3 snapshot 20070112.
The compiler said
TimeBomb.cxx: In function 'bool timeBombBoom()':
TimeBomb.cxx:23: error: address taken, but ADDRESSABLE bit not set
timeBomb
TimeBomb.cxx:23: internal compiler
--- Comment #1 from dcb314 at hotmail dot com 2007-01-13 21:22 ---
Created an attachment (id=12901)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12901action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30458
--- Comment #11 from Bil dot Kleb at NASA dot gov 2007-01-13 21:28 ---
Created an attachment (id=12902)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12902action=view)
An excerpt from precond_turbulent.f90
Here's an excerpt from one of the offenders. Note: the module only has a
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-13 21:29
---
global alloc :2249.91 (100%) usr 0.28 (76%) sys2250.16 (100%) wall
3897 kB (13%) ggc
flow 2: 0.04 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall
447 kB ( 2%) ggc
reg stack
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-13 21:33 ---
Can you try after:
http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00460.html
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30458
--- Comment #3 from dcb314 at hotmail dot com 2007-01-13 21:38 ---
(In reply to comment #2)
Can you try after:
http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00460.html
I can't process this until the next snapshot, due 20070119.
Is that soon enough ?
--
--- Comment #13 from Bil dot Kleb at NASA dot gov 2007-01-13 21:47 ---
Unfortunately, I am working from a binary release I got from
http://gcc.gnu.org/wiki/GFortranBinaries.
Specifically, I have the 03-Jan-2007 the 32-bit binary from:
--- Comment #1 from pault at gcc dot gnu dot org 2007-01-13 22:12 ---
This looks quite easy:
pure integer function bar (n)
integer, intent(in) :: n
bar = n
end function bar
works. Somebody has forgotten to transfer the result typespec to that of the
specification
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2007-01-13 22:13
---
The binaries will be rebuilt in a few days.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-01-13 23:02
---
The patch fixed the freefem memory regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
--- Comment #1 from ubizjak at gmail dot com 2007-01-13 23:27 ---
Addition (addl) operates in CCGOCmode and is not compatible with requested
CCZmode. Following that, test insn will be eliminated in this example:
int add_zf(int *x, int y, int a, int b)
{
if ((*x + y) 0)
--- Comment #2 from ubizjak at gmail dot com 2007-01-13 23:43 ---
(In reply to comment #1)
Combine pass then creates:
(insn 15 14 16 2 (parallel [
(set (reg:SI 58 [ temp.27 ])
(plus:SI (reg/v:SI 62 [ y ])
(mem:SI (reg/v/f:DI 61 [
--- Comment #2 from danglin at gcc dot gnu dot org 2007-01-14 00:30 ---
This is still present in 4.1.2 20070111 (prerelease) on hppa1.1-hp-hpux10.20.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26649
Executing on host: /xxx/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/xxx/gnu/gc
c/objdir/gcc/testsuite/g++/../../
/xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64-
2.C -nostdinc++
-I/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/include
/hppa1.1-hp-hpux10.20
--- Comment #2 from danglin at gcc dot gnu dot org 2007-01-14 00:50 ---
Also present in 4.1.2 20070111 (prerelease).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25223
--- Comment #5 from jbuck at gcc dot gnu dot org 2007-01-14 00:51 ---
I do not see this crash with gcc 4.1.1. Is it still present?
I did see it with 3.4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10127
--- Comment #5 from arekm at pld-linux dot org 2007-01-14 00:54 ---
-O0 passes
-O0 -fdefer-pop -fdelayed-branch -fguess-branch-probability -fcprop-registers
-fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce -ftree-dominator-opts
-ftree-dse -ftree-ter -ftree-lrs -ftree-sra
okay, i'll update changelog, submit and commit.
On 13 Jan 2007 23:02:13 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-01-13 23:02
---
The patch fixed the freefem memory regression.
--
--- Comment #22 from dberlin at gcc dot gnu dot org 2007-01-14 01:22
---
Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory
okay, i'll update changelog, submit and commit.
On 13 Jan 2007 23:02:13 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED]
asm_debug is not initialized in gcc.c. This can lead to a sigsegv when using a
custom specs file that does not overwrite asm_debug but other predefined spec
values.
Example:
---
*invoke_as:
%{!S:-o %|.s |
nesc-as %(asm_options) %m.s %A }
---
--
Summary: asm_debug is not
--- Comment #1 from rschiele at uni-mannheim dot de 2007-01-14 01:56
---
Created an attachment (id=12903)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12903action=view)
Fix for the problem.
BTW: This is also true for 4.2.x and 4.1.x. I have not looked into older
releases.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-14 02:10 ---
actually asm_debug is initialized in init_spec, with the following comment:
/* Initialize here, not in definition. The IRIX 6 O32 cc sometimes chokes
on ?: in file-scope variable initializations. */
--- Comment #3 from rschiele at gmail dot com 2007-01-14 02:21 ---
Andrew, it does not help to initialize in init_spec() because init_spec() is
only called when there is _no_ spec file found.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30460
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||3.3.3 3.4.0 4.0.0 4.1.0
|
--- Comment #4 from rschiele at gmail dot com 2007-01-14 03:12 ---
What about just calling init_spec() _allways_ _before_ reading the default
specs file instead of calling it only when there is no default specs file?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30460
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-14 03:44 ---
This also happens on powerpc-darwin8.5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-14 04:39 ---
The specific wording in the C++ standard:
15.4/3
If a virtual function has an exception-specification, all declarations,
including the definition, of any function that overrides that virtual function
in any dirived
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-14 04:46 ---
Since in this case we have:
struct a1
struct a2
both of which have virtualfunction with no exception-specification
and then we have
struct b : a1
struct c: a2
which have virtutalfunction with an
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-14 04:56 ---
#include ... search starts here:
/home/cbs/local/include
.
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include
/usr/include
Are you sure you don't have any of the following env variables set
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|libjava failed to build |[4.3
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-14 05:01 ---
This is a bit complex, we could use a loop reroller to roll this into a loop
and then transform that loop into memset for test1.
For test2 it is simple and a patch was presented at last year's gcc summit (and
I
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-14 05:02 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-14 05:09 ---
The variable is set but not read from.
There is another bug about this for the C/C++ front-ends and a new option for
this case instead of just using -Wunused.
I would considered t in comment #1 as being used as it
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-14 05:11 ---
I have not seen this before in my buildings.
How did you configure gcc?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-14 05:21 ---
I don't see why the attr type matters here as we always split it. Can you
describe the case where something goes because of attr having the wrong type?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30451
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-14 05:28 ---
Hmmm, I wonder if ia64 is broken for the following C case:
TU1.c:
int f();
int g(int a, double c, int d)
{
return f(a, d);
}
TU2.c:
int f(int a, double b)
{
return b;
}
the named agrument is defined by:
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-14 05:36 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from dkwan at transmeta dot com 2007-01-14 05:47 ---
There is additional code for the CELL PPU to adjust the latencies of data and
address operands of integer stores. The code requires accurate load/store
attributes. I guess there is nothing in the main-line gcc that
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-14 05:49 ---
This is actually caused by fortran/lang.opt which differs from c.opt in that it
RejectNegative's.
So if someone configures without fortran (Apple or you in this case), you will
get -Wno-all but if you configure
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-14 05:58 ---
I think this was already fixed by:
r120577 | hubicka | 2007-01-08 03:18:40 -0800 (Mon, 08 Jan 2007) | 7 lines
* cgraphunit.c (cgraph_process_new_functions): Reset reachable flag.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-14 06:02 ---
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-01-14 06:05 ---
(In reply to comment #8)
Just like PR 27668, I cannot confirm this bug for 4.1.1 or the 4.1 branch; it
passes for me.
Unless something changed between 20061204 and now, I can reproduce this on the
4.1 branch:
--- Comment #3 from chris dot pickett at mail dot mcgill dot ca 2007-01-14
06:06 ---
I don't think that's the right explanation.
cc1: error: unrecognized command line option -Wno-all
...
--enable-languages=c
...
gcc version 4.3.0 20070110 (experimental)
Although fortran may have a
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-01-14 06:07
---
*** This bug has been marked as a duplicate of 28545 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-01-14 06:07
---
*** Bug 30440 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-14 06:13 ---
(In reply to comment #3)
Although fortran may have a RejectNegative---in this case it's being rejected
without fortran---so it's a separate bug that fortran rejects -Wno-all, IMO.
Not really. 4.0.4 fails the same
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-14 06:16 ---
In my mind this is a minor issue because the way you are using the specs file
is wrong, you are using the defaults spec file and not using the overriding
one.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from cnovikov at pacbell dot net 2007-01-14 06:17 ---
(In reply to comment #1)
Confirmed, not a regression.
You set keywords to ice-on-invalid-code. In my opinion, the code is valid. %z
is supposed to add an appropriate data width IA-32 insn suffix: l for dwords, w
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-14 06:34 ---
(In reply to comment #2)
(In reply to comment #1)
Confirmed, not a regression.
You set keywords to ice-on-invalid-code.
Maybe you are correct but I don't think %zN is documented anywhere.
--
pinskia
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30423
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-01-14 07:34
---
I do not see this crash with gcc 4.1.1. Is it still present?
I did see it with 3.4.2.
-fstack-check doesn't work on Linux/x86 and Linux/x86-64 without runtime
support.
Only the Ada compiler currently
83 matches
Mail list logo
