[Bug middle-end/11492] Unsigned char promoted to signed int in for loop test for gpp but not gcc
--- 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 signed when overflow is > undefined (-fno-wrapv which is default for C and C++). > But in the example shown, it is true always, since b == 2 at compile time. Can't we detect that? I know that there is no dataflow solving in the front-ends. But as you said, tree_expr_nonnegative_p is part of the middle-end. Perhaps we should have dataflow info at the front-end. It will make our warnings much smarter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11492
[Bug fortran/30512] MAXVAL() incorrect for zero-size int arrays, and for -HUGE-1 maximum values.
--- 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 understand the standard correctly, -huge()-1, although being > representible by the hardware you have, is not "within the representation" > of this integer kind, because the range of the representation of an integer > kind is supposed to > be symmetric. Might be, but on the otherhand, if I have the following program: integer(1) :: a(2) a = -128 print *, maxval(a) I would expect that it prints "-128" and not "-127". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
[Bug preprocessor/14331] please add option to suppress warning message "no newline at end of file"
--- 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 -pedantic (if you look at the code, it is already a pedantic warning, it is just enabled all the time). This will avoid adding yet another warning option. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
[Bug other/19165] (Natural) language independent error / warning classification
--- 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 kind of interesting... -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
[Bug fortran/30531] ICE in fold_convert
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
[Bug fortran/30398] memmove for string operations
--- 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-end,
because it's really simple code:
void
string_repeat (char * dest, GFC_INTEGER_4 slen,
const char * src, GFC_INTEGER_4 ncopies)
{
int i;
/* See if ncopies is valid. */
if (ncopies < 0)
{
/* The error is already reported. */
runtime_error ("Augument NCOPIES is negative.");
}
/* Copy characters. */
for (i = 0; i < ncopies; i++)
{
memmove (dest + (i * slen), src, slen);
}
}
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-01-22 10:02:53
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30398
[Bug fortran/29876] ICE on bad operator in ONLY clause of USE statement
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-22 10:05:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29876
[Bug fortran/30531] allocatable component and intent(out) yield ICE in fold_convert
--- 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 list. $ cat a.f90 module foo_type_mod type foo_type integer, allocatable :: md(:) end type foo_type end module foo_type_mod module foo_mod interface subroutine foo_initvg(foo_a) use foo_type_mod Type(foo_type), intent(out) :: foo_a end subroutine foo_initvg end interface contains subroutine foo_ext(foo_a) use foo_type_mod Type(foo_type) :: foo_a call foo_initvg(foo_a) end subroutine foo_ext end module foo_mod $ gfortran a.f90 -c a.f90: In function foo_ext: a.f90:18: internal compiler error: in fold_convert, at fold-const.c:2154 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-22 10:16:38 date|| Summary|ICE in fold_convert|allocatable component and ||intent(out) yield ICE in ||fold_convert http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
[Bug tree-optimization/30038] Call to sin(x), cos(x) should be transformed to sincos(x)
--- 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]> PR tree-optimization/30038 * tree-ssa-math-opts.c (maybe_record_sincos): New static helper function. (execute_cse_sincos_1): Likewise. (execute_cse_sincos): Likewise. (gate_cse_sincos): Likewise. (pass_cse_sincos): New pass CSEing sin() and cos() calls using the cexpi() canonicalization of sincos(). * tree-pass.h (pass_cse_sincos): Declare. * passes.c (init_optimization_passes): New pass pas_cse_sincos. * gcc.dg/builtins-62.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/builtins-62.c Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-pass.h trunk/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
[Bug libgomp/30540] New: Document default value of implementation-dependent OpenMP settings
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_* functions
only link to omp_set_* and not to the OMP_* environment variables.
And OMP_NUM_THREADS's default setting is completely undefined; does it use by
default one or the maximal number of available processors?
--
Summary: Document default value of implementation-dependent
OpenMP settings
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30540
[Bug tree-optimization/30038] Call to sin(x), cos(x) should be transformed to sincos(x)
--- 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 |enhancement Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
[Bug tree-optimization/29686] [4.1 Regression] ICE when expanding recursive function containing switch
--- 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* pointer to an integral expression. Further simplification then removes that cast and thus causes an invalid type to be passed to the switch expander. This then crashes because the pointer type has no 'min value'. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Component|target |tree-optimization GCC target triplet|arm-linux | Summary|[4.1 Regression] ICE when |[4.1 Regression] ICE when |building the kernel on ARM |expanding recursive function ||containing switch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29686
[Bug c/30475] assert(int+100 > int) optimized away
--- 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. The compiler must never give me a negative value but then not take the "if (a<0)" branch. That is utterly unacceptable. -- felix-gcc at fefe dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug bootstrap/30541] New: Ada bootstrap fails, stage1 binding does not honor GNATMAKE
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_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include -o build/gencheck.o ../../gcc/gencheck.c gnatbind -C -I- -I. -Iada -I../../gcc/ada -o ada/b_gnat1.c -n ada/gnat1drv.ali fatal error: file gnat1drv.ali is incorrectly formatted make sure you are using consistent versions of gcc/gnatbind 9. | make[2]: *** [ada/b_gnat1.c] Error 4 make[2]: *** Waiting for unfinished jobs rm gcov.pod fsf-funding.pod gfdl.pod cpp.pod gcc.pod gpl.pod make[2]: Leaving directory `/usr/src/packages/BUILD/gcc-4.1.2-20070115/obj-i586-suse-linux/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/usr/src/packages/BUILD/gcc-4.1.2-20070115/obj-i586-suse-linux/gcc' because in ada/Make-lang.in we have GNATBIND = $(STAGE_PREFIX)gnatbind -- Summary: Ada bootstrap fails, stage1 binding does not honor GNATMAKE Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30541
[Bug bootstrap/30541] Ada bootstrap fails, stage1 binding does not honor GNATBIND
--- 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 Summary|Ada bootstrap fails, stage1 |Ada bootstrap fails, stage1 |binding does not honor |binding does not honor |GNATMAKE|GNATBIND http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30541
[Bug c/30542] New: gcc 4.1.1 missing uninitialized variable warnings
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 == 10) {
foo = 50;
}
/* Uncomment this block and warnings miraculously appear
if (i == 15) {
foo = 52;
}
*/
if (foo) {
printf("%d\n", foo);
}
++i;
if (i > 20) {
break;
}
}
return 0;
}
I'm using the following to compile (which gives no output from gcc):
- /usr/bin/gcc -Wall -W -ansi -pedantic -O2 -o foo foo.c
And output from gcc -v gives this:
: gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/gcc-4.1.1-r3/work/gcc-4.1.1/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.1
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-libunwind-exceptions
--disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj
--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.1 (Gentoo 4.1.1-r3)
Someone also tried the same code on 4.1.2 and got the same results (if that
helps).
--
Summary: gcc 4.1.1 missing uninitialized variable warnings
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot cuthbert at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30542
[Bug c/30542] gcc 4.1.1 missing uninitialized variable warnings
--- 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
[Bug bootstrap/30541] Ada bootstrap fails, stage1 binding does not honor GNATBIND
--- 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
[Bug fortran/30531] allocatable component and intent(out) yield ICE in fold_convert
--- 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 have time now) to the CC list. > Intent(out) was also the ultimate source of PR 30202...is this related? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
[Bug bootstrap/30541] Ada bootstrap fails, stage1 binding does not honor GNATBIND
--- 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
[Bug middle-end/30333] [4.3 Regression] Segmentation fault for -O2 on legal code
--- 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
[Bug other/19165] (Natural) language independent error / warning classification
--- 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 differentiate between warnings and errors. There's no way to do that without knowing all the ways that GCC might translate the words "warning" and "error" (running in a locale Eclipse thinks it understands is not a good option because GCC may change its choices of translation...). It would be friendlier if GCC provided this information. XML, or anything machine-readable, would be fine. So, yes, this is a GCC bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
[Bug c++/30539] Accepts invalid explicit specialization declaration
--- 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
[Bug bootstrap/30541] Ada bootstrap fails, stage1 binding does not honor GNATBIND
--- 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; gnatmake -q xnmake ; ./xnmake -b ../../nmake.adb ) but at least gnatbind is used as specified at configure time (for building stage1). Somebody might want to fix gnatmake in a similar way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30541
[Bug bootstrap/30541] Top-level should pass GNATBIND, GNATLINK and GNATMAKE variables down
--- 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 time (for building
> stage1). Somebody might want to fix gnatmake in a similar way.
Hi Richard.
Here's a quick patch review. First of all, the changes need to affect also
GNATBIND and GNATLINK.
Second, it's better if you add a line like this:
flags_to_pass = { flag= GNATBIND ; };
in Makefile.def rather than modifying EXTRA_GCC_FLAGS in Makefile.tpl.
Third, for 4.3, the gcc/Makefile.in changes are not necessary. This patch is
not a regression, so ask the Ada maintainers if they want it in 4.1 and 4.2
after one or two weeks in 4.3.
Finally, the only appearance of gnatbind/gnatmake/gnatlink (instead of the
variables) is the one you found in ada/Make-lang.in, and it makes sense to fix
it too.
Thanks for the work,
--
bonzini at gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-01-22 16:48:47
date||
Summary|Ada bootstrap fails, stage1 |Top-level should pass
|binding does not honor |GNATBIND, GNATLINK and
|GNATBIND|GNATMAKE variables down
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30541
[Bug rtl-optimization/30545] New: Why does optimizer not move exp() out of loop
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)
{
// this is constant for both runs of this loop
double res=exp(i);
std::cout<<"exp("
[Bug libgcj/30454] [4.3 Regression] classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi
--- 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 different between the two invocations yet to figure out why -save-temps would make a difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30454
[Bug c/20764] value won't fit in type
--- 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 |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20764
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- 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 CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug c/30475] assert(int+100 > int) optimized away
--- 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 GCC decided a while back (1992 or so) to be undefined. So in reality you have not proved why people can't audit their code like they did in the first place to place the undefined code in there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug middle-end/30333] [4.3 Regression] Segmentation fault for -O2 on legal code
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30333
[Bug rtl-optimization/30545] Why does optimizer not move exp() out of loop
--- 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 dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30545
[Bug middle-end/22456] [4.1/4.2/4.3 regression] missing "is used uninitialized" warning
--- 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 CC||david dot cuthbert at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22456
[Bug c/30542] gcc 4.1.1 missing uninitialized variable warnings
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30542
[Bug bootstrap/30541] Top-level should pass GNATBIND, GNATLINK and GNATMAKE variables down
--- 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 this to be ever fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30541
[Bug objc/27438] [4.1/4.2/4.3 Regression] [unit-at-a-time] '_OBJC_INSTANCE_0' defined but not used warning
--- 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 AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27438
[Bug libgomp/30546] New: [4.3 regression] build fail in libgomp because makeinfo is missing
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/libgomp/../gcc/doc/include -I ../../../trunk/libgomp \ -o libgomp.info `test -f 'libgomp.texi' || echo '../../../trunk/libgomp/'`libgomp.texi; \ then \ rc=0; \ else \ rc=$?; \ $restore $backupdir/* `echo "./libgomp.info" | sed 's|[^/]*$||'`; \ fi; \ rm -rf $backupdir; exit $rc WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. make[2]: *** [libgomp.info] Error 1 make[2]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/libgomp' -- Summary: [4.3 regression] build fail in libgomp because makeinfo is missing Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: i386-pc-mingw32 GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug bootstrap/30541] Top-level should pass GNATBIND, GNATLINK and GNATMAKE variables down
--- 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.3, I will approve the patch for 4.1-4.2 also after a prolonged enough silence from the Ada people. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30541
[Bug c/28875] "-Wextra -Wno-unused-parameter -Wall" doesn't work as expected
--- 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. -Wextra enables the warning, if -Wno-unused-parameter is given then it should disable it and Wall should not interfere with it unless you give again -Wextra or -Wunused-parameter. Don't we have policy about this? The manual is not very clear here about the effect of -Wno-*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28875
[Bug libgomp/30546] [4.3 regression] build fail in libgomp because makeinfo is missing
--- 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. They are included in releases. h, now building documentation != building gcc, I think -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug c/30475] assert(int+100 > int) optimized away
--- 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.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c++/30277] bit-field: wrong overload resolution
--- 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 are specified, and they > specify that types in binary operations are always converted to the type > with the greater range. In your case, this would be signed long. Do > you disagree with this rationale? C++03 4.5 p3 | An rvalue for an integral bit-field (9.6) can be converted | to an rvalue of type int if int can represent all the values ^^^ | of the bit-field; otherwise, it can be converted to unsigned | int if unsigned int can represent all the values of the | bit-field. If the bit-field is larger yet, no integral promotion | applies to it. If the bit-field has an enumerated type, it is | treated as any other value of that type for promotion purposes. 32bit bit-fields and int has the same range of value. The bit-field shall be converted to int, because int can represent all the values of 32bit bit-fields. -- s__nakayama at infoseek dot jp changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277
[Bug c/30475] assert(int+100 > int) optimized away
--- 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 input is one value which is easy to add a check for input == INT_MIN. The reason why INT_MIN is "special" is because signed integer in C does not have to be symetric. Now if you take Fortran on the other hand, integers are always symetric. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 > int) optimized away
--- 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
Gcj-4.3 builds fail
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/)
[Bug fortran/30532] ^Z as EOF?
--- 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 gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-22 19:18:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30532
[Bug middle-end/30132] [4.1/4.2/4.3 Regression] ICE in find_lattice_value, at tree-complex.c:133
--- 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 subroutine subrr () trr=vrr-(1.0,0.0) call checkrr (trr) return end subroutine subrr END $ gfortran --version GNU Fortran 95 (GCC) 4.1.1 20060524 (rpm:5) Copyright (C) 2006 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ gfortran -c -O0 bug2737.f90 $ gfortran -c -O1 bug2737.f90 bug2737.f90: In function 'MAIN__': bug2737.f90:1: internal compiler error: in find_lattice_value, at tree-complex.c:133 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. $ -- geir at cray dot com changed: What|Removed |Added CC||geir at cray dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30132
[Bug middle-end/30132] [4.1/4.2/4.3 Regression] ICE in find_lattice_value, at tree-complex.c:133
--- 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/bugzilla/show_bug.cgi?id=30132
[Bug ada/30547] New: Never ending program initializing an array of array of Unbounded_String.
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;
type A_2 is array(1..1) of A_1;
type Rec is
record
f: A_2 := (others => (others => Null_Unbounded_String));
end record;
var: Rec;
begin
Put_Line("Hello");
end Bug;
--8<-8<-8<-8<-8<---
The program works fine if the initialization is moved into the procedure's
body:
--8<-8<-8<-8<-8<---
[...]
type Rec is
record
f: A_2;
end record;
var: Rec;
begin
var.f := (others => (others => Null_Unbounded_String));
[...]
--8<-8<-8<-8<-8<---
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
This problem seems rather old, it has been observed using GNAT 3.15p.
--
Summary: Never ending program initializing an array of array of
Unbounded_String.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kafka dot fr at laposte dot net
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30547
[Bug c/30475] assert(int+100 > int) optimized away
--- 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 does assign a negative number (as it does), I want "if (a<0)" to trigger. That part is not undefined. But never mind the security issue here, which is apparently too complicated for you guys to understand. This optimization actually makes code SLOWER. AND it makes people mad when they find out about it. So, uh, which part of that don't you understand? There is an optimization that makes the code slower, not faster. Turn it off already. -- felix-gcc at fefe dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug fortran/30512] MAXVAL() incorrect for zero-size int arrays, and for -HUGE-1 maximum values.
--- 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 bug, since "the negative number with the largest > magnitude possible within the representation" is not -huge()-1, but -huge(). > > If I understand the standard correctly, -huge()-1, although being > representible by the hardware you have, is not "within the representation" > of this integer kind, because the range of the representation of an > integer kind is supposed to be symmetric. > > 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. > > Steve might have an idea on that, IIRC he's the one who implemented the > -frange-check option. Otherwise, a question to comp.lang.fortran would be a > good thing. > I fixed the range checking from [-huge()-1: 2*huge()] to [-huge()-1: huge()]. The old upper limited would allow people to write integer(1) i i = -128_1 ! This should be -huge(i) - 1_1 end because the 128_1 was not flagged as overflowing a integer(1). Note, -128_1 is a unary minus operating on the 128_1. When I changed the range checking or shortly after, jerryd introduced the -f[no]-range-check option. For the case at hand, the integers do not need to be symmetric, and so minval and maxval should properly handle -huge()-1. As pointed out by Tobias, integer(1) a(2) a = -huge(a) - 1 print *, minval(a), maxval(a) end should print "-128 -128" Now, where the symmetry of the integers becomes a problem is integer(1) i i = - huge() - 1 i = abs(i)! This is invalid. end The above is prohibited in 13.14: The types and type parameters of intrinsic procedure arguments and function results are determined by these specifications. A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
[Bug c/30475] assert(int+100 > int) optimized away
--- 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 value does turn out to be negative, you appear to be assuming that signed overflow is actually "implementation defined behaviour." That would have the property that you are after. When you say that -fwrapv makes the code faster, I don't know which benchmarks you are relying on. Other people have demonstrated that -fwrapv slows down the well-known SPEC benchmark. I've written some comments in the appropriate place: the gcc mailing list: http://gcc.gnu.org/ml/gcc/2007-01/msg00885.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug fortran/30389] ACHAR() intrinsic gives erroneous errors in constant-folding.
--- 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/show_bug.cgi?id=30389
[Bug c++/30548] New: parse error
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 it parses OK. I've tried to write something short that mimics the problem but no luck. -- Summary: parse error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30548
[Bug c++/30548] parse error
--- 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
[Bug c++/30548] parse error
--- 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
[Bug c++/30548] parse error
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=30548
[Bug fortran/30514] zero-sized array wrongly rejected: integer :: i(1:-1)
--- 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 120859)
--- gcc/fortran/array.c (working copy)
*** match_array_element_spec (gfc_array_spec
*** 319,324
--- 319,333
if (m == MATCH_NO)
return AS_ASSUMED_SHAPE;
+ /* If the size is negative in this dimension, set it to zero. */
+ if ((*lower)->expr_type == EXPR_CONSTANT
+ && (*upper)->expr_type == EXPR_CONSTANT
+ && mpz_cmp ((*upper)->value.integer, (*lower)->value.integer) < 0)
+ {
+ gfc_free_expr (*upper);
+ *upper = gfc_copy_expr (*lower);
+ mpz_sub_ui ((*upper)->value.integer, (*upper)->value.integer, 1);
+ }
return AS_EXPLICIT;
}
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-01-20 17:19:49 |2007-01-22 21:05:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30514
[Bug c++/30548] parse error
--- 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 primary in a cast: component* z = static_cast(&serialNumber3003::instance)->MMIOize(); gives no error, but: component* z = (&serialNumber3003::instance)->MMIOize(); shows the bug. Seems bizarre to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30548
[Bug fortran/30514] zero-sized array wrongly rejected: integer :: i(1:-1)
--- 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 obviously it's not a problem :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30514
[Bug fortran/30146] Redefining do-variable in excecution cycle
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-22 21:29:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146
[Bug libfortran/30533] minval, maxval missing for kind=1 and kind=2
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-22 21:30:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30533
[Bug fortran/29800] -fbounds-check: For derived types, write not also compound name
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-22 21:32:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800
[Bug fortran/30073] Array out of bounds gives name of RHS array not LHS array
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-22 21:32:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30073
[Bug fortran/30522] Host-/use-associated VOLATILE variable: volatile scope, redundent attributes
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-22 21:34:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30522
[Bug c++/30548] parse error
--- 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 there is an
explicit template argument ("<...>") present. Is this correct?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30548
[Bug fortran/25620] Missed optimization with power
--- 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/3.D0) b(2)=a(2)**(1/3.D0) b(3)=a(3)**(2.D0/3.D0) b(4)=a(4)**(1/2.D0) b(5)=a(5)**(1.D0/2.D0) b(6)=a(6)**(3.D0/2.D0) write(*,*) b END $ gfortran -O2 -ffast-math a.f90 -S $ grep -c pow a.s 0 $ grep -c cbrt a.s 3 $ grep -c sqrt a.s 3 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25620
[Bug fortran/30549] New: compiler warning in resolve.c: possibly uninitialized use of name
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->value.function.esym->attr.recursive)
{
gfc_symbol *esym, *proc;
esym = expr->value.function.esym;
proc = gfc_current_ns->proc_name;
if (esym == proc)
{
gfc_error ("Function '%s' at %L cannot call itself, as it is not "
"RECURSIVE", name, &expr->where);
t = FAILURE;
}
if (esym->attr.entry && esym->ns->entries && proc->ns->entries
&& esym->ns->entries->sym == proc->ns->entries->sym)
{
gfc_error ("Call to ENTRY '%s' at %L is recursive, but function "
"'%s' is not declared as RECURSIVE",
esym->name, &expr->where, esym->ns->entries->sym->name);
t = FAILURE;
}
}
--
Summary: compiler warning in resolve.c: possibly uninitialized
use of name
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30549
[Bug fortran/30549] compiler warning in resolve.c: possibly uninitialized use of name
--- 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 there is a way that the second argument does not get initialized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30549
[Bug fortran/30514] zero-sized array wrongly rejected: integer :: i(1:-1)
--- 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 dimension is zero, and the array is of zero size." > Usually, we need to take care of the case for negative stride, but here > obviously it's not a problem :) ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30514
[Bug fortran/30549] compiler warning in resolve.c: possibly uninitialized use of name
--- 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->symtree->n.sym != NULL && e->symtree->n.sym->attr.proc == PROC_ST_FUNCTION) return 1; One could thus either add a line in pure_function or in "resolve_function" to set name to null. Or in both. Having it in "resolve_function" means we get rid of this warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30549
[Bug c/30475] assert(int+100 > int) optimized away
--- 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 measure your own code. And with -fwrapv being default, you punish people who write valid and well defined C programs which causes those people to get up set and we already get more of those complaints than getting complaints about signed integer being undefined in C. If you really want to make a difference, raise an issue with the C standards committee (just a word of cation, they might laugh at you and tell you to go away) with a very very good reason to make signed integer overflow as implementation defined; plain out security checks is not a good reason as you can check for the issues before they can happen as already mentioned. I would agree with your idea of turning on -fwrapv if there was no way to check for overflow before they happened but there are ways. Yes we are going to break code which was written using the assumtion that signed integer overflow is defined as wrapping but that is a cost which we can take, I think. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL
--- 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 2 and n_named_args is 3. Because (in FORTRAN) num_actuals > n_named_args, I pass the floating point value in a general register (like varags) instead of in a floating point register like when I have a regular named argument. n_named_args seems to be set based on list_length(type_arg_types) and for some reason this is 3 for C and 1 for Fortran. I think the fortran type_arg_types list is wrong but I don't know why it is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30432
[Bug libgcj/30513] [4.3 Regression] Bootstrap failure with libgcj on sparc-sun-solaris2.10
--- 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 this missing stuff leads to a complete build for sparc-solaris8 multilib. Unfortunatley I fail with boehm-gc warnings which disturbs the test output. I'm too tired atm to follow this. Attached the barriers. You might have more luck. Next I try is to add -ansi in CXX_FLAGS in Makefile.am Andreas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
[Bug java/29812] env->klass value is not updated during the native calls
--- 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.java: New file.
* testsuite/libjava.jni/pr29812_injar.java: New file.
* testsuite/libjava.jni/pr29812_injar.jar: New file.
* testsuite/libjava.jni/pr29812.out: New file.
* testsuite/libjava.jni/pr29812_injar.c: New file.
* testsuite/libjava.jni/pr29812_injar.h: New file.
* testsuite/libjava.jni/pr29812.jar: New file.
* testsuite/libjava.jni/pr29812.c: New file.
* testsuite/libjava.jni/pr29812.h: New file.
* testsuite/libjava.jni/jni.exp (gcj_jni_get_cxxflags_invocation):
New proc.
(gcj_jni_invocation_test_one): Use it.
(gcj_jni_pr29812): New proc.
(gcj_jni_run): Use it.
* java/lang/natRuntime.cc (_load): Push a new system frame before
calling JNI_OnLoad.
* include/jvm.h (_Jv_JNI_PopSystemFrame): Declare.
(_Jv_GetJNIEnvNewFrameWithLoader): Likewise.
* jni.cc (struct _Jv_JNI_LocalFrame) : Now unsigned char.
: Now bool.
: New field.
(_Jv_JNI_EnsureLocalCapacity): Updated.
(_Jv_JNI_NewLocalRef): Likewise.
(_Jv_JNI_NewLocalRef): Likewise.
(_Jv_JNI_PopLocalFrame): Likewise.
(_Jv_JNI_FindClass): Likewise.
(_Jv_GetJNIEnvNewFrame): Likewise.
(_Jv_JNI_AttachCurrentThread): Likewise.
(_Jv_GetJNIEnvNewFrameWithLoader): New function.
(_Jv_GetJNIEnvNewFrame): Use it.
* include/jni_md.h (_CLASSPATH_JNIENV_CONTENTS): Removed 'klass'.
Added:
trunk/libjava/testsuite/libjava.jni/pr29812.c
trunk/libjava/testsuite/libjava.jni/pr29812.h
trunk/libjava/testsuite/libjava.jni/pr29812.jar (with props)
trunk/libjava/testsuite/libjava.jni/pr29812.java
trunk/libjava/testsuite/libjava.jni/pr29812.out
trunk/libjava/testsuite/libjava.jni/pr29812_injar.c
trunk/libjava/testsuite/libjava.jni/pr29812_injar.h
trunk/libjava/testsuite/libjava.jni/pr29812_injar.jar (with props)
trunk/libjava/testsuite/libjava.jni/pr29812_injar.java
Modified:
trunk/libjava/ChangeLog
trunk/libjava/include/jni_md.h
trunk/libjava/include/jvm.h
trunk/libjava/java/lang/natRuntime.cc
trunk/libjava/jni.cc
trunk/libjava/testsuite/libjava.jni/jni.exp
Propchange: trunk/libjava/testsuite/libjava.jni/pr29812.jar
('svn:mime-type' added)
Propchange: trunk/libjava/testsuite/libjava.jni/pr29812_injar.jar
('svn:mime-type' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29812
[Bug other/29972] typos in the manual
--- 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 |Added Attachment #12685|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29972
[Bug c/30475] assert(int+100 > int) optimized away
--- 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. Something in the order of 15000 packages. Dozens of millions of lines of code. Any suggestion? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug libgcj/30550] New: Missing dependencies for ecjx target
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/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/gcc-4.3/ia64-unknown-linux-gnu/bin/ -B/usr/gcc-4.3/ia64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.3/ia64-unknown-linux-gnu/include -isystem /usr/gcc-4.3/ia64-unknown-linux-gnu/sys-include -shared -nostdlib /usr/lib/crti.o /export/build/gnu/gcc/build-ia64-linux/./gcc/crtbeginS.o .libs/libgcj_bc.o -Wl,--rpath -Wl,/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libjava/.libs -Wl,--rpath -Wl,/usr/gcc-4.3/lib -L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src -L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libjava ./.libs/libgcj.so -L/usr/lib -L/export/build/gnu/gcc/build-ia64-linux/./gcc -lgcc_s -lc -lgcc_s /usr/lib/libunwind.so /export/build/gnu/gcc/build-ia64-linux/./gcc/crtendS.o /usr/lib/crtn.o -Wl,-Bsymbolic-functions -Wl,-soname -Wl,libgcj_bc.so.1 -o .libs/libgcj_bc.so.1.0.0 /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/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/gcc-4.3/ia64-unknown-linux-gnu/bin/ -B/usr/gcc-4.3/ia64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.3/ia64-unknown-linux-gnu/include -isystem /usr/gcc-4.3/ia64-unknown-linux-gnu/sys-include -shared -nostdlib /usr/lib/crti.o /export/build/gnu/gcc/build-ia64-linux/./gcc/crtbeginS.o .libs/jni-libjvm.o -Wl,--rpath -Wl,/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libjava/.libs -Wl,--rpath -Wl,/usr/gcc-4.3/lib -L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src -L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libjava/.libs ./.libs/libgcj.so -L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libjava -L/usr/lib -L/export/build/gnu/gcc/build-ia64-linux/./gcc -lgcc_s -lc -lgcc_s /usr/lib/libunwind.so /export/build/gnu/gcc/build-ia64-linux/./gcc/crtendS.o /usr/lib/crtn.o -Wl,-Bsymbolic -Wl,-soname -Wl,libjvm.so -o .libs/libjvm.so /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/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/gcc-4.3/ia64-unknown-linux-gnu/bin/ -B/usr/gcc-4.3/ia64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.3/ia64-unknown-linux-gnu/include -isystem /usr/gcc-4.3/ia64-unknown-linux-gnu/sys-include -shared -nostdlib /usr/lib/crti.o /export/build/gnu/gcc/build-ia64-linux/./gcc/crtbeginS.o .libs/gij.o -Wl,--rpath -Wl,/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libjava/.libs -Wl,--rpath -Wl,/usr/gcc-4.3/lib -L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src -L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libjava/.libs ./.libs/libgcj.so -L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libjava -L/usr/lib -L/export/build/gnu/gcc/build-ia64-linux/./gcc -lgcc_s -lc -lgcc_s /usr/lib/libunwind.so /export/build/gnu/gcc/build-ia64-linux/./gcc/crtendS.o /usr/lib/crtn.o -Wl,-Bsymbolic -Wl,-soname -Wl,libgij.so.9 -o .libs/libgij.so.9.0.0 /usr/local/bin/ld: cannot find -lgcj_bc collect2: ld returned 1 exit status make[5]: *** [ecjx] Error 1 make[5]: *** Waiting for unfinished jobs (cd .libs && rm -f libgcj-tools.so.9 && ln -s libgcj-tools.so.9.0.0 libgcj-tools.so.9) (cd .libs && rm -f libgcj-tools.so && ln -s libgcj-tools.so.9.0.0 libgcj-tools.so) ar rc .libs/libgcj-tools.a classpath/tools/libgcj_tools_la-tools.o ranlib .libs/libgcj-tools.a creating libgcj-tools.la (cd .libs && rm -f libgcj-tools.la && ln -s ../libgcj-tools.la libgcj-tools.la) ar rc .libs/libjvm.a jni-libjvm.o ranlib .libs/libjvm.a creating libjvm.la (cd .libs && rm -f libgcj_bc.so.1 && ln -s libgcj_bc.so.1.0.0 libgcj_bc.so.1) (cd .libs && rm -f libjvm.la && ln -s ../libjvm.la libjvm.la) (cd .libs && rm -f libgcj_bc.so && ln -s libgcj_bc.so.1.0.0 libgcj_bc.so) ar rc .libs/libgcj_bc.a libgcj_bc.o ranlib .libs/libgcj_bc.a creating libgcj_bc.la (cd .libs && rm -f libgcj_bc.la && ln -s ../libgcj_bc.la libgcj_bc.la) creating jv-convert (cd .libs && rm -f libgij.so.9 && ln -s libgij.so.9.0.0 libgij.so.9) (cd .libs && rm -f libgij.so && ln -s
[Bug java/29812] env->klass value is not updated during the native calls
--- 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.java: New file. * testsuite/libjava.jni/pr29812_injar.java: New file. * testsuite/libjava.jni/pr29812_injar.jar: New file. * testsuite/libjava.jni/pr29812.out: New file. * testsuite/libjava.jni/pr29812_injar.c: New file. * testsuite/libjava.jni/pr29812_injar.h: New file. * testsuite/libjava.jni/pr29812.jar: New file. * testsuite/libjava.jni/pr29812.c: New file. * testsuite/libjava.jni/pr29812.h: New file. * testsuite/libjava.jni/jni.exp (gcj_jni_get_cxxflags_invocation): New proc. (gcj_jni_invocation_test_one): Use it. (gcj_jni_pr29812): New proc. (gcj_jni_run): Use it. * java/lang/natRuntime.cc (_load): Push a new system frame before calling JNI_OnLoad. * include/jvm.h (_Jv_JNI_PopSystemFrame): Declare. (_Jv_GetJNIEnvNewFrameWithLoader): Likewise. * jni.cc (struct _Jv_JNI_LocalFrame) : Now unsigned char. : Now bool. : New field. (_Jv_JNI_EnsureLocalCapacity): Updated. (_Jv_JNI_NewLocalRef): Likewise. (_Jv_JNI_NewLocalRef): Likewise. (_Jv_JNI_PopLocalFrame): Likewise. (_Jv_JNI_FindClass): Likewise. (_Jv_GetJNIEnvNewFrame): Likewise. (_Jv_JNI_AttachCurrentThread): Likewise. (_Jv_GetJNIEnvNewFrameWithLoader): New function. (_Jv_GetJNIEnvNewFrame): Use it. * include/jni_md.h (_CLASSPATH_JNIENV_CONTENTS): Removed 'klass'. Added: branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/testsuite/libjava.jni/pr29812.c - copied unchanged from r121064, trunk/libjava/testsuite/libjava.jni/pr29812.c branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/testsuite/libjava.jni/pr29812.h - copied unchanged from r121064, trunk/libjava/testsuite/libjava.jni/pr29812.h branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/testsuite/libjava.jni/pr29812.jar - copied unchanged from r121064, trunk/libjava/testsuite/libjava.jni/pr29812.jar branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/testsuite/libjava.jni/pr29812.java - copied unchanged from r121064, trunk/libjava/testsuite/libjava.jni/pr29812.java branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/testsuite/libjava.jni/pr29812.out - copied unchanged from r121064, trunk/libjava/testsuite/libjava.jni/pr29812.out branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/testsuite/libjava.jni/pr29812_injar.c - copied unchanged from r121064, trunk/libjava/testsuite/libjava.jni/pr29812_injar.c branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/testsuite/libjava.jni/pr29812_injar.h - copied unchanged from r121064, trunk/libjava/testsuite/libjava.jni/pr29812_injar.h branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/testsuite/libjava.jni/pr29812_injar.jar - copied unchanged from r121064, trunk/libjava/testsuite/libjava.jni/pr29812_injar.jar branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/testsuite/libjava.jni/pr29812_injar.java - copied unchanged from r121064, trunk/libjava/testsuite/libjava.jni/pr29812_injar.java Modified: branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/ChangeLog branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/include/jni_md.h branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/include/jvm.h branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/java/lang/natRuntime.cc branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/jni.cc branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/testsuite/libjava.jni/jni.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29812
[Bug java/29812] env->klass value is not updated during the native calls
--- 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): Push a new system frame before calling JNI_OnLoad. * include/jvm.h (_Jv_JNI_PopSystemFrame): Declare. (_Jv_GetJNIEnvNewFrameWithLoader): Likewise. * jni.cc (struct _Jv_JNI_LocalFrame) : Now unsigned char. : Now bool. : New field. (_Jv_JNI_EnsureLocalCapacity): Updated. (_Jv_JNI_NewLocalRef): Likewise. (_Jv_JNI_NewLocalRef): Likewise. (_Jv_JNI_PopLocalFrame): Likewise. (_Jv_JNI_FindClass): Likewise. (_Jv_GetJNIEnvNewFrame): Likewise. (_Jv_JNI_AttachCurrentThread): Likewise. (_Jv_GetJNIEnvNewFrameWithLoader): New function. (_Jv_GetJNIEnvNewFrame): Use it. * include/jni_md.h (_CLASSPATH_JNIENV_CONTENTS): Removed 'klass'. Modified: branches/gcc-4_2-branch/libjava/ChangeLog branches/gcc-4_2-branch/libjava/include/jni_md.h branches/gcc-4_2-branch/libjava/include/jvm.h branches/gcc-4_2-branch/libjava/java/lang/natRuntime.cc branches/gcc-4_2-branch/libjava/jni.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29812
[Bug java/29812] env->klass value is not updated during the native calls
--- 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|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29812
[Bug c/26494] -pedantic-errors can be overridden by -W*
--- 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
[Bug libgcj/30454] [4.3 Regression] classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi
--- 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. > Adding -save-temps to that command made it pass. Adding -save-temps also works on hppa2.0w-hp-hpux11.11. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30454
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- 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 >folding of a-10 > 0 into a>10 and other code which folds a-10>a into true, >I wrote the first one. I found the second one in CVSweb, and it's not the cause for this unsafe "optimisation". I even changed fold-const.c to have some wrapper around fold() which debug_tree()s me the input and output, and the '100' stays in (at -O1, which does exhibit the faulty behaviour already): [â¦] arg 1 > arg 1 > Now I don't know any gcc internals, but I suppose this isn't done in fold-const.c⦠thanks to fprintf, my beloved debugger ;) bye, //mirabile -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug fortran/30319] internal error in gfc_resolve_expr() for character parameter
--- 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, symtree = 0x0, ref = 0x0, where = {
nextc = 0x0, lb = 0x0}, from_H = 0, inline_noncopying_intrinsic = 0,
con_by_offset = 0x0, value = {logical = 0, integer = {{_mp_alloc = 0,
_mp_size = 0, _mp_d = 0x0}}, real = {{_mpfr_prec = 0, _mpfr_sign = 0,
_mpfr_exp = 0, _mpfr_d = 0x0}}, complex = {r = {{_mpfr_prec = 0,
_mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}, i = {{
_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}},
op = {operator = GFC_INTRINSIC_BEGIN, uop = 0x0, op1 = 0x0, op2 = 0x0},
function = {actual = 0x0, name = 0x0, isym = 0x0, esym = 0x0},
character = {length = 0, string = 0x0}, constructor = 0x0}}
while for the working code (separated on two different lines), it is:
$9 = {expr_type = EXPR_CONSTANT, ts = {type = BT_INTEGER, kind = 4,
derived = 0x0, cl = 0x0}, rank = 0, shape = 0x0, symtree = 0x0, ref = 0x0,
where = {nextc = 0x87ef431 "1), parameter :: bb(1) = (/ aa /)",
lb = 0x87ef410}, from_H = 0, inline_noncopying_intrinsic = 0,
con_by_offset = 0x0, value = {logical = 2, integer = {{_mp_alloc = 2,
_mp_size = 1, _mp_d = 0x880d358}}, real = {{_mpfr_prec = 2,
_mpfr_sign = 1, _mpfr_exp = 142660440, _mpfr_d = 0x0}}, complex = {
r = {{_mpfr_prec = 2, _mpfr_sign = 1, _mpfr_exp = 142660440,
_mpfr_d = 0x0}}, i = {{_mpfr_prec = 0, _mpfr_sign = 0,
_mpfr_exp = 0, _mpfr_d = 0x0}}}, op = {operator = INTRINSIC_PLUS,
uop = 0x1, op1 = 0x880d358, op2 = 0x0}, function = {actual = 0x2,
name = 0x1 , isym = 0x880d358, esym = 0x0},
character = {length = 2, string = 0x1 },
constructor = 0x2}}
I think Paul T. worked on something similar, something like a year ago. We used
to fail on these multiple declarations per line already.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||paulthomas2 at wanadoo dot
||fr
Last reconfirmed|2006-12-28 19:19:40 |2007-01-22 23:54:20
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30319
[Bug c/11051] -Wno-deprecated needed also for C
--- 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 operand %d is deprecated", i + noutputs); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
[Bug rtl-optimization/14737] Purge political statement from -ffast-math docs
--- 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
[Bug c/26494] -pedantic-errors can be overridden by -W*
--- 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 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 compiles this.
gcc bug.c -ansi -pedantic-errors
compiles this without any error or warning.
gcc bug.c -ansi -pedantic-errors -Wmain
reports
bug.c:1: error: first argument of ‘main’ should be
‘int’
bug.c:1: error: ‘main’ takes only zero or two arguments
and does not compile this.
Is that close enough to be covered by this bug report, should I report that as
a new bug, or should I not report that at all?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26494
[Bug c/26494] -pedantic-errors can be overridden by -W*
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26494
[Bug c/26494] -pedantic-errors can be overridden by -W*
--- 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 as I can. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26494
[Bug c/11051] -Wno-deprecated needed also for C
--- 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 any other > testcase? > > In stmt.c (expand_asm_operands) there is: > > warning (0, "use of memory input without lvalue in " >"asm operand %d is deprecated", i + noutputs); > > Hang on, hang on... WTF?! Using an rvalue in an assembly input that may contain "m" is something that is highly useful, and it will break metric tons of code. -Wno-deprecated or no -Wno-deprecated, deprecating this particular construct is a major mistake. -hpa -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
[Bug c/11051] -Wno-deprecated needed also for C
--- 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
[Bug c/30551] New: -pedantic does not include -Wmain, but -pedantic-errors does make -Wmain cause error messages
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 compiles this.
gcc bug.c -ansi -pedantic-errors
compiles this without any error or warning.
gcc bug.c -ansi -pedantic-errors -Wmain
reports
bug.c:1: error: first argument of ‘main’ should be
‘int’
bug.c:1: error: ‘main’ takes only zero or two arguments
and does not compile this.
gcc --version:
gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
Summary: -pedantic does not include -Wmain, but -pedantic-errors
does make -Wmain cause error messages
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30551
[Bug c/26494] -pedantic-errors can be overridden by -W*
--- 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
[Bug c/11051] -Wno-deprecated needed also for C
--- 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 just looking for
> something deprecated in C front-end to make a testcase.
It looks like it's deprecating the following code:
void foo(int bar)
{
asm volatile("" : : "m" (bar+1));
}
This type of constructions are actually quite common (although with a
real instruction, and usually something like "rm" or "abdSm" in the
constraints box.)
-hpa
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
Re: [Bug c/11051] -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 any other
> > testcase?
> >
> > In stmt.c (expand_asm_operands) there is:
> >
> > warning (0, "use of memory input without lvalue in "
> >"asm operand %d is deprecated", i + noutputs);
> >
> >
>
> Hang on, hang on...
>
> WTF?! Using an rvalue in an assembly input that may contain "m" is
> something that is highly useful, and it will break metric tons of code.
> -Wno-deprecated or no -Wno-deprecated, deprecating this particular
> construct is a major mistake.
This has been true since 3.3.3 and in fact, this was made an error in 4.0.0,
even though the warning remains. Also what is deprecated/removed is not may
contain a memory constraint but an input which only contains memory constraints.
So:
float f(float a)
{
asm(""::"mo"((double)a));
return a;
}
Fails but:
float f(float a)
{
asm(""::"mr"((double)a));
return a;
}
Works.
-- Pinski
[Bug c/11051] -Wno-deprecated needed also for C
--- 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 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 operand %d is deprecated", i + noutputs);
> >
> >
>
> Hang on, hang on...
>
> WTF?! Using an rvalue in an assembly input that may contain "m" is
> something that is highly useful, and it will break metric tons of code.
> -Wno-deprecated or no -Wno-deprecated, deprecating this particular
> construct is a major mistake.
This has been true since 3.3.3 and in fact, this was made an error in 4.0.0,
even though the warning remains. Also what is deprecated/removed is not may
contain a memory constraint but an input which only contains memory
constraints.
So:
float f(float a)
{
asm(""::"mo"((double)a));
return a;
}
Fails but:
float f(float a)
{
asm(""::"mr"((double)a));
return a;
}
Works.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
[Bug middle-end/30391] [4.3 regression] ICE at -O1 with conditional expressions and GIMPLE_MODIFY_STMT
--- 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|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-01-20 13:14:29 |2007-01-23 00:43:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30391
[Bug c/30475] assert(int+100 > int) optimized away
--- 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 something like a whole Linux > distribution. Something in the order of 15000 packages. Dozens of millions of > lines of code. Any suggestion? > How about http://scan.coverity.com/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30552] New: gcc crashed when compiling an example
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
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chenwj at gcrj dot com
GCC build triplet: Kernel 2.6.11-1.1369_FC4 on an i686
GCC host triplet: Kernel 2.6.11-1.1369_FC4 on an i686
GCC target triplet: Kernel 2.6.11-1.1369_FC4 on an i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30552
