--- Comment #6 from manu at gcc dot gnu dot org 2007-01-22 08:28 ---
(In reply to comment #5)
> (In reply to comment #1)
> > "1000" is a signed integer constant, so b*1000 is a signed integer too. I
> > guess the warning is ok, then.
>
> That is only true for unsigned multiplication and
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-22 08:47 ---
> For what it's worth, the Intel and Sun compilers have the behaviour you
> expect, but the Portland compiler and g95 both have the same behaviour as
> gfortran.
NAG f95 and pathscale 2.4 have: -128.
> If I underst
--- Comment #9 from manu at gcc dot gnu dot org 2007-01-22 08:52 ---
In my opinion the patch is too old, now we have other mechanism for handling
options, and it lacks documentation updates and testcases. Also, it is a
standards conformance warning, so perhaps it should be just moved to
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-22 08:58 ---
Is this really a bug in GCC? Eclipse should run GCC with a locale it can
understand. Then, if it wants to support other languages, it has to support
them also in the parser.
Or we go for the XML output? That would be k
--- Comment #2 from sfilippone at uniroma2 dot it 2007-01-22 09:18 ---
Created an attachment (id=12930)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12930&action=view)
test case
Sorry for the delay, there was something wrong with my browser yesterday
evening.
It's cleared now.
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-01-22 10:02
---
(In reply to comment #1)
> Or, even better, the memmove/memcpy could be ommitted completely,
> by using the variable directly as the target.
The string_repeat() function could be generated directly by the front-e
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-22 10:16
---
Slightly reduced testcase below. It's all about allocatable components and
intent(out). Remove one or the other, and it's gone. Adding Erik Edeelman and
Paul Thomas (although he does not have time now) to the CC l
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-01-22 11:11
---
Subject: Bug 30038
Author: rguenth
Date: Mon Jan 22 11:11:00 2007
New Revision: 121052
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121052
Log:
2007-01-22 Richard Guenther <[EMAIL PROTECTED]>
http://gcc.gnu.org/onlinedocs/libgomp.pdf
2.1 omp_get_dynamic Dynamic teams setting
etc.
Here, the default value is not documented; it can be found in
"3 Environment Variables" ("If undefined, dynamic adjustment is disabled by
default."), but this is not obvious. Especially, since the omp_get_*
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-01-22 11:12
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-01-22 12:04
---
The reduced testcase also ices on a native i386 build. The problem seems to
crop up somewhere in t81.ivopts pass where a switch statement variable is
transformed from an integral calculation into a cast of a void*
--- Comment #43 from felix-gcc at fefe dot de 2007-01-22 13:02 ---
No, it WAS about the security. Now that you made me check and I saw that the
optimization also doesn't give any actual speed increase, I want it removed on
that grounds, too. And I want it removed for reasons of sanity.
CC="gcc-4.1" GNATMAKE="gnatmake-4.1" ../configure --enable-languages=ada
...
checking whether gcc-4.1 accepts -g... yes
checking for gnatbind... gnatbind-4.1
checking whether compiler driver understands Ada... yes
...
(everything ok until)
gcc-4.1 -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECK
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-22 14:24 ---
whoops
CC="gcc-4.1" GNATBIND="gnatbind-4.1" ../configure --enable-languages=ada
of course...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
Not sure if this is a bug, or I'm just missing some option or other, but I
appear to be missing "uninitialized variable" warnings (in some cases, but not
others) when compiling C such as the following:
#include
int
main(void)
{
int foo;
int i;
i = 1;
while (i) {
if (i ==
--- Comment #1 from david dot cuthbert at gmail dot com 2007-01-22 14:31
---
Created an attachment (id=12931)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12931&action=view)
foo.i file
Adding foo.i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30542
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-22 14:33 ---
removing the offending line from ada/Make-lang.in leaves GNATBIND empty, so we
are
not passing it down from (where?).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30541
--- Comment #4 from sfilippone at uniroma2 dot it 2007-01-22 14:43 ---
(In reply to comment #3)
> Slightly reduced testcase below. It's all about allocatable components and
> intent(out). Remove one or the other, and it's gone. Adding Erik Edeelman and
> Paul Thomas (although he does not
--- Comment #3 from schwab at suse dot de 2007-01-22 14:51 ---
See *_FLAGS_TO_PASS in toplevel makefile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30541
--- Comment #3 from dcb314 at hotmail dot com 2007-01-22 15:51 ---
(In reply to comment #2)
> I think this was already fixed a while back.
> Can you try again?
I tried again, and it seems fixed to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30333
--- Comment #9 from tromey at gcc dot gnu dot org 2007-01-22 16:12 ---
Some kind of machine-readable output is necessary for use by an IDE.
Eclipse can't translate the messages after they have been emitted by GCC.
So, it should run GCC in the user's locale.
However, then it would like to
--- Comment #1 from sebor at roguewave dot com 2007-01-22 16:25 ---
Even better, this works too:
template <> void X<1>::X<2>::X<3>::X<4>::f();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30539
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-22 16:37 ---
Created an attachment (id=12932)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12932&action=view)
patch
During the build we still call (and require) a 'gnatmake' in $PATH like for
(cd ada/bldtools/nmake_b;
--- Comment #5 from bonzini at gnu dot org 2007-01-22 16:48 ---
> During the build we still call (and require) a 'gnatmake' in $PATH like for
>
> (cd ada/bldtools/nmake_b; gnatmake -q xnmake ; ./xnmake -b ../../nmake.adb )
>
> but at least gnatbind is used as specified at configure
Hi,
I wonder why gcc does not move the constant exp() call from the inner loop to
the outer loop. Should I use different optimization settings?
Georg
Checked with g++ -O3 -S t.cpp; emacs t.S
t.cpp:
#include
#include
int main()
{
for (int i=0; i<10;++i)
{
for (int j=0; j<2;++j)
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-01-22 17:02 ---
I was able to reproduce this under powerpc-darwin myself.
Running the command which failed during the build manually, still failed.
Adding -save-temps to that command made it pass.
I have not looked at what is diffe
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-22 17:05 ---
PR 23572 has a better description of the problem and the current status.
*** This bug has been marked as a duplicate of 23572 ***
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-22 17:05 ---
*** Bug 20764 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #44 from pinskia at gcc dot gnu dot org 2007-01-22 17:14
---
Again this really has nothing to do with security except for the fact some
developers wrote security checking code that depends on overflow being defined
as wrapping which is not what the C standard says and what G
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-22 17:17 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-22 17:24 ---
exp can set errno as defined by the C/C++ standard so it cannot be pulled out
of the loop.
you can work around this by using -fmath-errno which says the math builtins
don't set errno.
--
pinskia at gcc dot gnu do
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-22 17:27 ---
*** Bug 30542 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-22 17:27 ---
*** This bug has been marked as a duplicate of 22456 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-01-22 17:27 ---
Note that doing this for GNATMAKE also will make us run into PR29127 (gnatbind
seems to be unaffected by this bug). Ada people generally don't seem to care
about the FSF way to build/install gcc, so I don't expect t
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-22 17:35 ---
I have a simple fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Assign
While it was bootstrapping fine on 2006-10-21, mainline now fails to build on
my mingw setup because libgomp wants to run makeinfo, which I don't have. It
says make can be buggy, but it's not (it's GNU make 3.79.1).
if /home/coudert/trunk/missing makeinfo --split-size=500 -I
../../../trunk/li
--- Comment #7 from bonzini at gnu dot org 2007-01-22 17:37 ---
However, fixing GNATBIND/GNATLINK/GNATMAKE would allow you to e.g. install 4.1
in /opt/gcc-4.1/ and then configure with GNATMAKE=/opt/gcc-4.1/bin/gnatmake.
So there is still a point in fixing this bug.
If you start from 4.
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-22 18:11 ---
(In reply to comment #1)
> So you have "-Wextra -Wno-unused-parameter -Wall" so the -Wno-unused-parameter
> does not have an effect as it is not turned on by -Wextra but instead by
> -Wall.
>
Humm, I disagree. -Wext
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-22 18:20 ---
>From http://gcc.gnu.org/install/prerequisites.html
Texinfo version 4.4 (or later)
Necessary to build GCC documentation during development because the
generated output files are not included in the SVN repository
--- Comment #45 from steven at gcc dot gnu dot org 2007-01-22 18:26 ---
Marking this as WONTFIX leaves the impression that here is a bug here at all.
This should have been closed as INVALID.
First commandment of using C: "Thou shall not rely on undefined behavior."
--
http://gcc.g
--- Comment #3 from s__nakayama at infoseek dot jp 2007-01-22 18:28 ---
(In reply to comment #1)
> I only have the C99 standard, and there I read in 6.3.1.1 p2 that only
> those variables are promoted to int that are of smaller size.
>
> Similarly, in 6.3.1.8, integer promotion rules ar
--- Comment #46 from pinskia at gcc dot gnu dot org 2007-01-22 18:33
---
> PS: Mr Simon, that link to a how-to that says "btw this doesn't work for this
> special input", is that supposed to impress anyone? It certainly does not
> impress me very much, really.
yes and the special inpu
--- Comment #47 from andreas at andreas dot org 2007-01-22 18:36 ---
It was suggested to me that this issue should be discussed on the mailing list.
If you have an opinion, come there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
http://pastebin.ca/324404
http://pastebin.ca/324405
Regards
--
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-01-22 19:18 ---
(In reply to comment #2)
scriptors (10.2.1).
>
> The following patch allows the test case in #1 to compile:
Looks good (and I agree with the reasoning).
Will you submit the patch?
Thomas
--
tkoenig at
--- Comment #10 from geir at cray dot com 2007-01-22 19:24 ---
Here is a Fortran test case:
$ cat bug2737.f90
PROGRAM get_tst_inc_complex
implicit none
external subrrg, checkrr
complex :: vrr, trr
vrr=cmplx(1.,2.);
call subrr ( )
contains
su
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-22 19:30
---
(In reply to comment #10)
> Here is a Fortran test case:
I think that Fortran issue is something unrelated to this bug.
In fact that Fortran testcase was fixed for 4.1.2 by PR 27889.
--
http://gcc.gnu.org/bugz
The following program never ends, after the string has been displayed the
program eats 75% of CPU forever:
--8<-8<-8<-8<-8<---
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
procedure Bug is
type A_1 is array(1..1) of Unbounded_String;
--- Comment #48 from felix-gcc at fefe dot de 2007-01-22 19:50 ---
Oh wow, another wise cracking newbie who comments without actually
understanding the issue. I AM NOT RELYING ON UNDEFINED BEHAVIOR. On the
contrary. gcc is fine to assign 23 instead of a negative number. But if it
doe
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-01-22 20:16 ---
Subject: Re: MAXVAL() incorrect for zero-size int arrays, and for -HUGE-1
maximum values.
>
>- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-22 07:56 ---
> I don't think it's a bu
--- Comment #49 from ian at airs dot com 2007-01-22 20:16 ---
In the C language standard "undefined behaviour" meants that the compiler can
do anything at all. It means that the program is specifically undefined.
When you say that the compiler should not eliminate the test because the
--- Comment #4 from patchapp at dberlin dot org 2007-01-22 20:35 ---
Subject: Bug number PR 30389
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01808.html
--
http://gcc.gnu.org/bugzilla/s
Only the first message is relevant. The parser seems to think that it is in an
expression and "<" is a relational operator rather than the bracket in front of
a template parameter for the member template function "MMIOize". Note that if
the expression is broken in two (the previous two lines) then
--- Comment #1 from igodard at pacbell dot net 2007-01-22 20:40 ---
Created an attachment (id=12933)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12933&action=view)
compiler output -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30548
--- Comment #2 from igodard at pacbell dot net 2007-01-22 20:41 ---
Created an attachment (id=12934)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12934&action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30548
--- Comment #3 from igodard at pacbell dot net 2007-01-22 20:44 ---
p.s. if the disambiguator "template" is inserted in front of the call (i.e.
"... .template MMIOize< ..." the the compiler complains that a disambiguating
template keyword can only be used in a template.
--
http://gc
--- Comment #2 from pault at gcc dot gnu dot org 2007-01-22 21:05 ---
This fixes the PR but I have not yet determined if it is standard conforming
behaviour:
Index: gcc/fortran/array.c
===
*** gcc/fortran/array.c (revision
--- Comment #4 from igodard at pacbell dot net 2007-01-22 21:20 ---
p.p.s. The error depends on the kind of primary in front of the selection and
call. If the primary is a variable then no error, as shown in the previous
line. However, you can also make the error go away by wrapping the
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-22 21:28
---
(In reply to comment #2)
> This fixes the PR but I have not yet determined if it is standard conforming
> behaviour
I'm almost sure it is. Usually, we need to take care of the case for negative
stride, but here o
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #5 from igodard at pacbell dot net 2007-01-22 21:53 ---
OK, found the source of the problem: there's a template function in the base
class and a non-template function of the same name in the derived class, and
the parse is resolving the call to the non-template even though th
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-01-22 22:02
---
cbrt is now available in the front-end (among others), thanks again to Richard!
Closing this PR, as the optimization appears to be working fully:
$ cat a.f90
REAL*8 :: a(6),b(6)
read(*,*) a(:)
b(1)=a(1)**(1.D0/
The compiler warns that in the function "resolve_function" of resolve.c:, the
variable "name" might be used unintialized. I think gcc is right.
Name is initialized with:
if (!pure_function (expr, &name) && name)
and later used without extra if(name) in:
if (expr->value.function.esym && !expr
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-22 22:14 ---
Can you try after:
http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00765.html
?
>and later used without extra if(name) in:
No, that means it is used possiable as null.
You need to check inside pure_function to see if ther
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-22 22:17 ---
> This fixes the PR but I have not yet determined if it is standard conforming
> behaviour
See 5.1.2.5.1 Explicit-shape array:
"If the upper bound is less than the lower bound, the range is empty, the
extent in that
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-22 22:25 ---
> No, that means it is used possiable as null.
> You need to check inside pure_function to see if there is a way that the
> second argument does not get initialized.
There is:
if (e->symtree != NULL
&& e->
--- Comment #50 from pinskia at gcc dot gnu dot org 2007-01-22 22:27
---
There is no nothing special about signed integer overflow in C, it is just
undefined behavior at runtime. I had forgot to mention the SPEC results
because I don't feel SPEC CPU or any benchmark is a good way to me
--- Comment #7 from sje at cup dot hp dot com 2007-01-22 22:45 ---
So I can see things going wrong in expand_call but I still don't know why.
With the FORTRAN example (comment #3) expand_call sets num_actuals to 2 and
n_named_args to 1. If I write the calling code in C, num_actuals is
--- Comment #6 from andreast at gcc dot gnu dot org 2007-01-22 22:54
---
I undef'ed the sun in gcj/array.h since this was the only header I found useful
for the moment. Having done this led me to the mentioned problem with
write/read_barrier which is not implemented for sparc. Adding th
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-22 23:04 ---
Subject: Bug 29812
Author: tromey
Date: Mon Jan 22 23:04:16 2007
New Revision: 121064
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121064
Log:
PR java/29812:
* testsuite/libjava.jni/pr29812.
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2007-01-22 23:06
---
Created an attachment (id=12935)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12935&action=view)
updated updated updated patch
--
Ralf dot Wildenhues at gmx dot de changed:
What|Removed
--- Comment #51 from andreas at andreas dot org 2007-01-22 23:10 ---
Sure, new security checks can be written in a compliant manner.
But what plan do you suggest to find instances of non-compliant overflow
checking in the existing body? Think something like a whole Linux
distribution.
I downloaded ecj.jar with contrib/download_ecj. During bootstrap, I
got
/export/build/gnu/gcc/build-ia64-linux/./gcc/xgcc -shared-libgcc
-B/export/build/gnu/gcc/build-ia64-linux/./gcc -nostdinc++
-L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src
-L/export/build/gnu/
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-22 23:20 ---
Subject: Bug 29812
Author: tromey
Date: Mon Jan 22 23:20:18 2007
New Revision: 121065
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121065
Log:
PR java/29812:
* testsuite/libjava.jni/pr29812.
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-22 23:33 ---
Subject: Bug 29812
Author: tromey
Date: Mon Jan 22 23:33:24 2007
New Revision: 121066
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121066
Log:
PR java/29812:
* java/lang/natRuntime.cc (_load
--- Comment #7 from tromey at gcc dot gnu dot org 2007-01-22 23:33 ---
Fixed in 4.2, 4.3.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-22 23:47 ---
Does it happen with any other option apart from
-Wimplicit-function-declaration?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26494
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-22
23:53 ---
Subject: Re: [4.3 Regression]
classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for
class gnu.javRO
> Running the command which failed during the build manually, still failed.
> A
--- Comment #15 from tg at mirbsd dot de 2007-01-22 23:54 ---
Subject: Re: Integer Overflow detection code optimised away,
-fwrapv broken
pinskia at gcc dot gnu dot org dixit:
>fold-const.c changed a lot, etc.
>Actually there are two different code, one I wrote which is does
>foldin
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-22 23:54
---
The code that triggers the ICE enters gfc_resolve with
gfc_current_ns->cl_list->length that is:
$12 = {expr_type = 0, ts = {type = BT_UNKNOWN, kind = 0, derived = 0x0,
cl = 0x0}, rank = 0, shape = 0x0, symtr
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:01 ---
The testcase given is not valid any more. Could you think in any other
testcase?
In stmt.c (expand_asm_operands) there is:
warning (0, "use of memory input without lvalue in "
"asm o
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:03 ---
If this is confirmed as a bug, why don't you submit the patch to gcc-patches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14737
--- Comment #3 from truedfx at gentoo dot org 2007-01-23 00:05 ---
-Wendif-labels and -Wimplicit-int don't turn errors into warnings, so probably,
yes. I did notice something else of interest while testing, though:
int main(char a) {}
gcc bug.c -ansi -pedantic
compiles this without any
--- Comment #4 from truedfx at gentoo dot org 2007-01-23 00:08 ---
(In reply to comment #3)
> -Wendif-labels and -Wimplicit-int don't turn errors into warnings, so
> probably,
> yes.
So probably, no, it does not happen with any other option. Sorry, I read your
question wrong.
--
h
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-23 00:10 ---
Open a new bug report, please. I am going to submit a patch to fix this one and
reviewers don't like patches that do many things and the same time.
Add me to the CC list of the new report and I will look at it as soon
--- Comment #5 from hpa at zytor dot com 2007-01-23 00:15 ---
Subject: Re: -Wno-deprecated needed also for C
manu at gcc dot gnu dot org wrote:
> --- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:01 ---
> The testcase given is not valid any more. Could you think in
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-23 00:20 ---
Hey, don't look at me. I am not sure what that means, I was just looking for
something deprecated in C front-end to make a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
Noticed while doing a test for bug #26494:
int main(char a) {}
gcc bug.c -ansi -pedantic
compiles this without any error or warning.
gcc bug.c -ansi -pedantic -Wmain
reports
bug.c:1: warning: first argument of ‘main’ should be
‘int’
bug.c:1: warning: ‘main’ takes only zero or two arguments
and c
--- Comment #6 from truedfx at gentoo dot org 2007-01-23 00:23 ---
Thank you, and done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26494
--- Comment #7 from hpa at zytor dot com 2007-01-23 00:24 ---
Subject: Re: -Wno-deprecated needed also for C
manu at gcc dot gnu dot org wrote:
> --- Comment #6 from manu at gcc dot gnu dot org 2007-01-23 00:20 ---
> Hey, don't look at me. I am not sure what that means, I was
> manu at gcc dot gnu dot org wrote:
> > --- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:01
> > ---
> > The testcase given is not valid any more. Could you think in any other
> > testcase?
> >
> > In stmt.c (expand_asm_operands) there is:
> >
> > warning (0, "u
--- Comment #8 from pinskia at physics dot uc dot edu 2007-01-23 00:29
---
Subject: Re: -Wno-deprecated needed also for C
> manu at gcc dot gnu dot org wrote:
> > --- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:01
> > ---
> > The testcase given is not valid any
--- Comment #4 from aldyh at gcc dot gnu dot org 2007-01-23 00:43 ---
I'll look at this.
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #52 from kargl at gcc dot gnu dot org 2007-01-23 00:45 ---
(In reply to comment #51)
> Sure, new security checks can be written in a compliant manner.
>
> But what plan do you suggest to find instances of non-compliant overflow
> checking in the existing body? Think somethi
gcc crashed when compile the following example , and report "internal compiler
error: Segmentation fault".
//comandline: gcc -c a.c
/* a.c */
int main()
{
void fun(a)
int a[({void h(){}2;})];
{
}
return 0;
}
--
Summary: gcc crashed when compiling an example
Pro
1 - 100 of 126 matches
Mail list logo
