On 5/12/06, D. Ensign [EMAIL PROTECTED] wrote:
I'd like to tell gcc to quit when a warning is encountered
(or even if a specific warning is encountered). Is there a way to do
this?
Yes. -Werror. If you can tell us why you weren't able to find it in
the documentation, perhaps we can
Hello,
the docs for -fno-function-cse says:
`-fno-function-cse'
Do not put function addresses in registers; make each instruction
that calls a constant function contain the function's address
explicitly.
This option results in less efficient code, but some strange hacks
On Fri, May 12, 2006 at 08:40:07PM +0200, Etienne Lorrain wrote:
But when I tried (replacing in Gujin some calll by lcallw based on which
function
is called) it did not work as I expected it. For instance, -fno-function-cse
seem
ignored here:
What are you expecting to happen here? The
Snapshot gcc-4.1-20060512 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060512/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-12 08:27 ---
f is marked addressable and assigned a stack slot. That the stores are not
optimized away later is probably due to aliasing issues - an open-coded memcpy
must behave like the -fno-strict-aliasing case, so I guess
#include iostream
int main()
{
//std::cout Hello! std::endl;
std::wcout LWello! std::endl;
std::cout Hello! std::endl;
return 0;
}
//
$ g++ test.cpp
$ ./a.out
Wello!
There is no output from std::cout, but if first
ICE in get_attr_usegp, at config/alpha/alpha.md:171 using gcc 4.2.0 20060508:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O1 mini.c
mini.c: In function 'r7to_double':
mini.c:36: error: unrecognizable insn:
(jump_insn 50 49 51 (addr_diff_vec:SI (label_ref:DI 49)
[
--- Comment #1 from tbm at cyrius dot com 2006-05-12 08:47 ---
Created an attachment (id=11441)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11441action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27571
--- Comment #1 from pcarlini at suse dot de 2006-05-12 08:51 ---
This is a (new) feature, not a bug, see libstdc++/11705 and in general search
about stream orientation in the C standard (C99, 7.19.2). In a nutshell you
cannot mix byte oriented and wide oriented I/O. For now, due to the
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-05-12
09:23 ---
I find this to be surprising:
$ cat pr24168.f90;rm a.exe;/irun/bin/gfortran -fdump-tree-original pr24168.f90;
./a
program bug
implicit none
integer, parameter :: nx=2,ny=2
real, dimension(nx,ny) :: f
The C++ frontend currently chokes on invalid typedefs in parameter
declarations for both functions and templates.
One can generate ICEs in many different places like the following
examples show:
==
void foo(typedef) {}
==
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot
|dot org
--- Comment #1 from patchapp at dberlin dot org 2006-05-12 09:47 ---
Subject: Bug number PR c++/27572
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/2006-05/msg00502.html
--
--- Comment #4 from jakub at gcc dot gnu dot org 2006-05-12 11:27 ---
-fbounds-check is completely useless option, it is so buggy that you can't use
it for anything real.
E.g. it doesn't handle assumed size or allocatable arrays.
Try running make check-gfortran
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-05-12
11:42 ---
Created an attachment (id=11442)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11442action=view)
Patch to effect compile time checking
Thomas,
The attached patch corrects the problem and is
--- Comment #5 from guilloteau at obs dot u-bordeaux1 dot fr 2006-05-12
13:05 ---
Created an attachment (id=11443)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11443action=view)
A simple program showing that initialization of BOZ constants fails in modules.
The test program
--- Comment #30 from karol at mikronika dot com dot pl 2006-05-12 13:40
---
Strange... I don't know why 3.3.x will not be updated. Currently line 3.3.x is
used in many stable/production environments like stable: Debian (sarge),
Slackware 10, Suse 10.
--
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-05-12 13:42
---
The patch from comment #14 is not really useful as it f.i. warns for
int sink;
void bar()
{
int j;
sink = j;
}
t.c: In function 'bar':
t.c:5: warning: 'j' is used uninitialized in this function
t.c:4:
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-05-12
13:45 ---
Created an attachment (id=11444)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11444action=view)
Corrected version of patch
This version of the patch survives regtesting!
--
paul dot richard
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-05-12 14:00
---
This looks related to PR26726 as IVOPTs produces now
bb 2:
i = minLen + 1;
D.1588 = (int *) (unsigned int) (i * 4);
ivtmp.34 = limit + D.1588 - 4B;
ivtmp.40 = base + D.1588;
goto bb 4 (L1);
L0:;
gfortran-4.2-HEAD -fopenmp -fprofile-generate -c
/src/gfc-4.2/libgomp/testsuite/libgomp.fortran/omp_parse1.f90
omp_parse1.f90:3: internal compiler error: in expand_omp_parallel, at
omp-low.c:2396
smallish testcase:
program test_omp
implicit none
integer
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-05-12 14:46 ---
Can also be reproduced on i686.
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00511.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-12
14:50 ---
Created an attachment (id=11445)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11445action=view)
Patch for bug (not regtested)
The problem turned out to be less severe than I imagined. The
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-12 14:53
---
Here's a shorter testcase:
==
templatetemplatetypename class struct A;
templateint struct B
{
templatetypename T void foo(T);
};
--- Comment #10 from eweddington at cso dot atmel dot com 2006-05-12 15:10
---
Subject: Re: Wrong code generation when cross compile for
attiny2313
p dot mateja at sh dot cvut dot cz wrote:
In other words: Is there any way how to say to gcc that const arrays shoud
stay
just in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27571
--- Comment #15 from bdavis at gcc dot gnu dot org 2006-05-12 16:05 ---
looks like there is agreement that the problem is fixed.
--
bdavis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sebor at roguewave dot com 2006-05-12 16:27 ---
EDG points out to me that both the original test case and the one from comment
#1 are ambiguous because only the declaration of the signature of the function
(and thus only the declaration of its return type and its
--- Comment #3 from sebor at roguewave dot com 2006-05-12 16:30 ---
Created an attachment (id=11446)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11446action=view)
Corrected test program exercising SFINAE.
After modifying the test program from comment #1 to correct these problems
Compilation with -O0 -g no longer creates debug information for all variables.
--
Summary: MIssing debug info at -O0
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
This program writes one word and then reads two words. g77 finds the error but
gfortran does not -
[dranta:~/tests/gfortran-D] dir% gfortran -o read01 read01.f
[dranta:~/tests/gfortran-D] dir% read01
[dranta:~/tests/gfortran-D] dir% cat read01.f
program test
integer i1,i2
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-05-12 16:58 ---
Created an attachment (id=11447)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11447action=view)
test case
Compiled for either sh-elf or i686-pc-linux-gnu, currrent mainline cc1plus does
not generate any debug
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-05-12 17:02 ---
Created an attachment (id=11448)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11448action=view)
With the translation result for this file, the testcase can be linked
This file provides a definition of main
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-12 17:04 ---
The exact same problem as PR rtl-optmization/27538 is happening.
*** This bug has been marked as a duplicate of 27538 ***
--
kazu at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from kazu at gcc dot gnu dot org 2006-05-12 17:04 ---
*** Bug 27539 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27538
--- Comment #6 from kazu at gcc dot gnu dot org 2006-05-12 17:05 ---
Note that the same bug is causing
FAIL: gcc.c-torture/execute/941014-2.c execution, -O1
FAIL: gcc.c-torture/execute/941014-2.c execution, -O2
FAIL: gcc.c-torture/execute/941014-2.c execution, -Os
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-12 17:11 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
In gcc/unwind-dw2-fde.h
/* The first few fields of a CIE. The CIE_id field is 0 for a CIE,
to distinguish it from a valid FDE. FDEs are aligned to an addressing
unit boundary, but the fields within are unaligned. */
struct dwarf_cie
{
uword length;
sword CIE_id;
ubyte version;
--- Comment #6 from patchapp at dberlin dot org 2006-05-12 17:36 ---
Subject: Bug number PR 27548
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/2006-05/msg00511.html
--
--- Comment #6 from kargl at gcc dot gnu dot org 2006-05-12 17:43 ---
(In reply to comment #5)
Created an attachment (id=11443)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11443action=view) [edit]
A simple program showing that initialization of BOZ constants
fails in modules.
At least on x86 and x86_64 the following program crashes
8--
#include string
std::string foo()
{
}
int main()
{
foo();
}
8--
When one compiles this snipplet with warnings turned on, then this warning
shows up:g++ -Wall m.c
m.c: In function
This problem started somewhere between april 17, and april 20. Afftects 4.2
only.
Here is the -v output of the compilation terminated with ICE:
/local/gnu_toolchain/build_area/obj_gcc-trunk_7450/./gcc/xgcc -shared-libgcc
-B/local/gnu_toolchain/build_area/obj_gcc-trunk_7450/./gcc -nostdinc++
--- Comment #1 from edmar at freescale dot com 2006-05-12 18:42 ---
Created an attachment (id=11449)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11449action=view)
File generated with --save-temps
This is the .ii file that causes ICE.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-12 18:47 ---
I cannot remember if the C++ standard allows this to be an error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27577
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-12 18:52 ---
I can also reproduce this on a cross compiler to powerpc-linux-gnu. and it is
a front-end issue. Reducing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-12 18:59 ---
extern ssize_t readv (int __fd, __const struct iovec
*__attribute__((altivec(vector__))), int __count);
That is invalid code.
Hmm, I wonder if someone uses __vector somewhere.
--
pinskia at gcc dot gnu dot org
As a solution to bug 3181, integral overloads of many math functions (like
sqrt) were introduced. Would it be possible to add a warning when such
overloads are instantiated? I don't know how to do that with g++ (if it is not
possible, then it would be a nice feature to add). It would help people
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-12 19:08 ---
(In reply to comment #3)
Reduced testcase:
void readv (int *__attribute__((altivec(vector__))) );
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-12 19:13 ---
Actually this is any attribute on the pointer in the function prototype:
void readv (int *__attribute__((aligned(16) )) );
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-05-12 19:27
---
Hmm, don't we now violate the C++ standard by providing these overloads?
(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#213).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3181
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #1 from pcarlini at suse dot de 2006-05-12 20:12 ---
Really, there is no point in trying to implement that warning, given the
ongoing developments of the C++ standard: those overloads are already part of
the current draft of the next (C++0x) standard (and are also in TR1).
--- Comment #6 from janis at gcc dot gnu dot org 2006-05-12 20:38 ---
A regression hunt on powerpc-linux using the testcase from comment #5
identified this patch:
http://gcc.gnu.org/viewcvs?view=revrev=113081
r113081 | mmitchel | 2006-04-19 16:58:23 + (Wed, 19 Apr 2006)
--- Comment #2 from schwab at suse dot de 2006-05-12 21:13 ---
Yes, I am fully aware, that my snipplet is buggy, however an ignored warning
should not cause a crash in the program.
There are many ways an ignored warning can cause a program to crash.
--
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-12 21:18
---
Well, the testcase is valid F2003 but not valid F95. We have to get it working
(for F2003 mode), which probably means adding a simplification function for
MAXLOC. And the same is true for all the intrinsics
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-12 21:19 ---
(In reply to comment #0)
Yes, I am fully aware, that my snipplet is buggy, however an ignored warning
should not cause a crash in the program.
Code that invokes undefined behavior at runtime cannot be turned into
--- Comment #2 from gdr at integrable-solutions dot net 2006-05-12 21:47
---
Subject: Re: New: no warning for the non-standard integral overloads of math
functions
marc dot glisse at normalesup dot org [EMAIL PROTECTED] writes:
| As a solution to bug 3181, integral overloads of
The following invalid testcase triggers an ICE since GCC 3.4.0:
===
struct A
{
templateint static void foo();
static void bar() { this-A::foo0(); }
};
===
bug.cc: In static member function 'static void
The following invalid testcase triggers an ICE since GCC 3.4.0:
===
struct A
{
templateint void foo();
};
templateint N, void (A::*)() = A::fooN struct B {};
Bint b;
===
bug.cc:8: error: type/value
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27582
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.1 |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27582
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27581
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-13 03:52 ---
Confirmed,
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-13 04:08 ---
I can confirm this, trying to figure out to reduce this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-13 04:25 ---
Fixed on trunk and 4.1 - see #5
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-13 04:59 ---
The label comes from a switch table.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
67 matches
Mail list logo
