[Bug rtl-optimization/47138] backport r158175: replace dominated uses in loop-invariant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47138 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org, jakub at gcc dot ||gnu.org --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-01 08:47:45 UTC --- This is 2010-04-09 Eric Botcazou ebotca...@adacore.com Bernd Schmidt ber...@codesourcery.com * loop-invariant.c (replace_uses): New static function. (move_invariant_reg): Use it to ensure we can replace the uses. We would need a testcase though. RMs, what do you think?
[Bug rtl-optimization/47138] backport r158175: replace dominated uses in loop-invariant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47138 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.01 08:48:35 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1
[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47136 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.01 10:57:51 Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2011-01-01 10:57:51 UTC --- Confirmed. This may be related to PR42769 (see comment #24/25). Possibly due to module loading.
[Bug target/38662] __fastcall confuses a function's throw() specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38662 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org 2011-01-01 11:05:45 UTC --- Author: ktietz Date: Sat Jan 1 11:05:41 2011 New Revision: 168389 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168389 Log: ChangeLog gcc/ 2011-01-01 Kai Tietz kai.ti...@onevision.com PR target/38662 * tree.c (type_hash_eq): Call language hook for METHOD_TYPEs, too. ChangeLog gcc/cp 2011-01-01 Kai Tietz kai.ti...@onevision.com PR target/38662 * tree.c (cxx_type_hash_eq): Allow METHOD_TYPE, too. ChangeLog gcc/testsuite 2011-01-01 Kai Tietz kai.ti...@onevision.com PR target/38662 * g++.dg/eh/pr38662.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/eh/pr38662.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug target/38662] __fastcall confuses a function's throw() specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38662 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2011-01-01 11:20:15 UTC --- I don't intend to back-merge this patch to 4.5.x branch. So bug closed.
[Bug c/47143] warning about const multidimensional array as function parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47143 Igor rogi at linuxmail dot org changed: What|Removed |Added Severity|minor |normal
[Bug c/47139] ice in process_use, at tree-vect-stmts.c:290
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47139
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.01.01 11:36:12
CC||jakub at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-01
11:36:12 UTC ---
Simplified testcase:
int d;
void
foo ()
{
int a = 0;
unsigned char b;
for (b = 1; b; b++)
{
d = a;
a |= b;
}
}
[Bug c/47143] warning about const multidimensional array as function parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47143 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-01-01 12:02:28 UTC --- Not a bug. The function parameters are of type pointer to array[4] of const double because const on an array type applies to the element type, recursively, and then the outermost array type, only, of a parameter of array type decays to a pointer, and the arguments passed are of type pointer to array[4] of double after array-to-pointer decay, and the only case where qualifiers are permitted to be added in assignment, argument passing etc. is qualifiers on the immediate pointer target, not those nested more deeply.
[Bug libobjc/47031] libobjc uses mutexes for properties
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031 --- Comment #3 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2011-01-01 12:06:56 UTC --- The problem is that property accessors are basically general purpose routines that may be used in the most varied situations. It does not matter very much in which situation a property is used. To chose which type of lock you use, it's only important what is done while the lock is held. In this case, no call to the kernel-space is made at all and only a small operation is done. Switching to kernel-space for a mutex is already way more complex than what we do in the lock. If I'd have to guess, I'd say switching to kernel-space is at least 100 times more expensive than what we do. So, we have very little control or knowledge over when and how they are used -- Which we don't care about at all. * we don't know how many CPUs or cores the user has Does not really matter. If we have two cores, the spinlock can give control to another thread after 10 spins using sched_yield(). So, if we only have one core and one thread spins because it waits for another core to release the lock, then we waste at maximum 10 tries. This is the worst-case scenario. If we have more than one core, we most likely have another thread releasing the lock before it even spinned 10 times. So, no matter how many cores, it does not perform worse than a mutex (at least not in a measurable way), while on systems with many cores, it's a huge improvement. Plus changing a property is something that's so fast that we most likely will never encounter a locked spinlock. That'd only happen if the scheduler gave control to another thread before the property was changed. So, with spinlocks, in 99% of the cases, it's not even measurable. With mutexes, in 100% of the cases, it IS measurable. * we don't know how many threads the user is starting * we don't know how many threads are sharing a CPU or core We don't really care about them, I think. * we don't know how intensively the user is using the property accessors So, because we don't know how intensively the user is using properties, we will make them slow on purpose? Spinlocks are appropriate when certain conditions are met; but in this case, it seems impossible to be confident that these are met. Which conditions are not met in your opinion? Please list the conditions that you think are not met, as Apple clearly thinks they are all met. And so do I. A user may write a program with 3 or 4 threads running on his 1 CPU/core machine, which constantly read/write an atomic synthesized property to synchronize between themselves. Why not; but then, spinlocks would actually degrade performance instead of improving it. This is actually why you call sched_yield() after 10 spins. It prevents a thread from being stuck spinning while another thread could release the lock. Traditional locks may be slower if you a low contention case, but work consistently OK in all conditions. Yes, they are the same in all conditions because they are always more complex and slower ;). * spinlocks are better/faster if there is low contention and very little chance that two threads enter the critical region (inside the accessors) at the same time. This is the case here. * the difference in performance between mutexes and spinlocks only matters in the program performance if the accessors are called very often. If you init a lot of objects and those initialize let's say 30 variables using properties, then this means that 30 locks are retained and released, although no other thread could possibly access it. But still you do 30 userland-kernelspace-switches. For a single object! Now create 1000 objects. With spinlocks, there won't be a single userland-kernelspace-switch! Just to demonstrate that we are talking about something which really can make a huge difference… I think the percentages you list cannot be used at all, as we don't have applications just doing some math calculations and then quitting. We don't want something slow just because it might only be a small part of the program. We want everything to be as fast as possible. Otherwise it sums up and makes a crappy user experience for interactive applications. Apple demonstrated this quite well if you compare how crappy it felt a few years ago and how well it feels now that they started optimizing the small stuff as well. The only case where spinlocks really help is if the program spends lots of time calling accessors, and is not multi-threaded. In which case, the programmer could get a huge speed-up by simply declaring the properties non-atomic. Even in a threaded environment, it would make a huge difference. It's unlikely the lock is held. Only if it is held, you need some CPU time. But with Mutexes, each time you only check if the lock is held, you already switch to kernel-space. Would using spinlocks make accessors 2x faster ? 10x faster ? 10% faster ? My
[Bug tree-optimization/47139] [4.6 Regression] ice in process_use, at tree-vect-stmts.c:290
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47139 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.5.2 Target Milestone|--- |4.6.0 Summary|ice in process_use, at |[4.6 Regression] ice in |tree-vect-stmts.c:290 |process_use, at ||tree-vect-stmts.c:290 Known to fail||4.6.0 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-01 12:28:45 UTC --- Introduced by http://gcc.gnu.org/viewcvs?root=gccview=revrev=158018
[Bug c/47143] warning about const multidimensional array as function parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47143 Igor rogi at linuxmail dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #2 from Igor rogi at linuxmail dot org 2011-01-01 13:02:09 UTC --- And is it possible to write function definitions that avoid this while maintaining my precious a[i][j] accesibility inside functions?
[Bug c/47143] warning about const multidimensional array as function parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47143 --- Comment #3 from Igor rogi at linuxmail dot org 2011-01-01 13:16:39 UTC --- (In reply to comment #1) Not a bug. The function parameters are of type pointer to array[4] of const double because const on an array type applies to the element type, recursively, and then the outermost array type, only, of a parameter of array type decays to a pointer, and the arguments passed are of type pointer to array[4] of double after array-to-pointer decay, and the only case where qualifiers are permitted to be added in assignment, argument passing etc. is qualifiers on the immediate pointer target, not those nested more deeply. This was somewhat confusing to me. Did you mean that funcion expects: pointer to array[4] of const doubles and I am passing pointer to const array[4] of doubles instead? This really seems pretty much teh same to me. Correct me if I'm wrong please.
[Bug middle-end/47033] loop distribution has problems on sane testcases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47033 --- Comment #4 from Jan Hubicka hubicka at ucw dot cz 2011-01-01 13:29:47 UTC --- I at least checked in the fix for uninitialized var. It would indeed be nice to know why the generated code is worse than before. Honza
[Bug tree-optimization/47141] [4.6 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47141
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||ice-on-valid-code
Last reconfirmed||2011.01.01 13:36:34
Component|c |tree-optimization
CC||hubicka at gcc dot gnu.org,
||jakub at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|segfault|[4.6 Regression] segfault
Target Milestone|--- |4.6.0
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-01
13:36:34 UTC ---
Caused by partial inlining. Smaller testcase:
int
foo (__UINTPTR_TYPE__ x)
{
int a = 6;
int *b = a;
if (x)
for (a = 0; a; a++)
;
return a;
}
void
bar (void)
{
foo ((__UINTPTR_TYPE__) foo);
}
[Bug tree-optimization/47140] [4.6 Regression] error: conversion of register to a different size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47140
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.5.2
Keywords||ice-on-valid-code
Last reconfirmed||2011.01.01 14:33:23
CC||jakub at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|error: conversion of|[4.6 Regression] error:
|register to a different |conversion of register to a
|size|different size
Target Milestone|--- |4.6.0
Known to fail||4.6.0
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-01
14:33:23 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=162943
Smaller testcase:
static int
foo (int x, short y)
{
return y == 0 ? x : x + y;
}
static unsigned short
bar (unsigned short x, unsigned char y)
{
return x - y;
}
int w;
int baz (void);
int
test (void)
{
for (;;)
w = foo ((unsigned char) (1 + baz ()) = bar (0, 1), 0);
}
[Bug c/47143] warning about const multidimensional array as function parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47143 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-01-01 15:06:34 UTC --- If you want to use const here only on the callee side then you will need to use casts. I meant what I said: you are passing pointer to array[4] of double, with no const in there, to a function expecting pointer to array[4] of const double, and this is not a case permitted by C99 6.5.16.1#1. C does not have a type pointer to const array[4] of double.
[Bug libstdc++/47145] New: cross-compilation fails with cannot check for file existence when cross compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 Summary: cross-compilation fails with cannot check for file existence when cross compiling Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: john.tyt...@aaug.net Cross-compilation of gcc 4.6 trunk r168391 (target: arm-unknown-eabi) fails in libstdc++ with in its config.log file: --8-- configure:58588: $? = 0 configure:58596: result: yes configure:58604: visibility supported: yes configure:58964: checking for makeinfo configure:58991: result: makeinfo --split-size=500 configure:59001: checking for modern makeinfo configure:59016: result: yes configure:59037: checking for doxygen configure:59053: found /usr/bin/doxygen configure:59065: result: yes configure:59075: checking for dot configure:59103: result: no configure:59115: checking for xsltproc configure:59131: found /usr/bin/xsltproc configure:59143: result: yes configure:59153: checking for xmllint configure:59169: found /usr/bin/xmllint configure:59181: result: yes configure:59189: checking for /usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION configure:59195: error: cannot check for file existence when cross compiling --8-- I believe this is because of recent change: --8-- r168382 | bkoz | 2010-12-31 23:20:22 +0100 (Fri, 31 Dec 2010) | 31 lines 2010-12-31 Benjamin Kosnik b...@redhat.com * scripts/run_doxygen: Allow doxygen 1.7.1 again. * doc/xml/manual/build_hacking.xml: Update. * doc/xml/images/confdeps.dot: Same. * doc/xml/images/confdeps.png: Same. * configure.ac: Define BUILD_INFO, BUILD_XML, BUILD_HTML, BUILD_MAN, BUILD_PDF, BUILD_EPUB conditionally. * Makefile.am (xml, html, pdf, man, info, pd, dvi, epub): Define, and install rules. * doc/Makefile.am: Same. Add stamp rules. (doc-epub-docbook): Add. (stamp-xml-single-docbook): Make set too. * configure: Regenerate. * Makefile.in: Same. * doc/Makefile.in: Same. * include/Makefile.in: Same. * libsupc++/Makefile.in: Same. * po/Makefile.in: Same. * python/Makefile.in: Same. * src/Makefile.in: Same. * testsuite/Makefile.in: Same. * aclocal.m4: Same. 2010-12-31 Benjamin Kosnik b...@redhat.com * doc/doxygen/user.cfg.in: Disable PDF_HYPERLINKS. --8--
[Bug tree-optimization/47140] [4.6 Regression] error: conversion of register to a different size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47140 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-01 15:26:01 UTC --- Created attachment 22877 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22877 gcc46-pr47140.patch Untested fix.
[Bug c/47146] New: Floating point to integer conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47146
Summary: Floating point to integer conversions
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: babel...@yahoo.com
#include stdio.h
#include stdlib.h
//-
int32_t main(int argc, char **argv)
//-
{
float elapsed = 0.3894949;
fprintf( stdout, Float 0.3894949=%f\n, elapsed );
fprintf( stdout, Float 0.3894949 * 100.0=%f\n, elapsed * 100.0 );
fprintf( stdout, Integer Cast 0.3894949 * 100.0=%d\n, (int32_t) (elapsed
* 100.0) );
elapsed = 0.3894949 * 100;
int32_t ielapsed = 0.3894949 * 100;
fprintf( stdout, Float=%f\n, elapsed );
fprintf( stdout, Integer=%d\n, ielapsed );
fprintf( stdout, --\n );
elapsed = 0.39;
fprintf( stdout, Float 0.39=%f\n, elapsed );
fprintf( stdout, Float 0.39 * 100.0=%f\n, elapsed * 100.0 );
fprintf( stdout, Integer Cast 0.39 * 100.0=%d\n, (int32_t) (elapsed *
100.0) );
elapsed = 0.39 * 100;
ielapsed = 0.39 * 100;
fprintf( stdout, Float=%f\n, elapsed );
fprintf( stdout, Integer=%d\n, ielapsed );
exit( 0 );
}
The above code generates the following:
Float 0.3894949=0.389495
Float 0.3894949 * 100.0=38.949490
Integer Cast 0.3894949 * 100.0=38
Float=38.949490
Integer=38
--
Float 0.39=0.39
Float 0.39 * 100.0=38.99
Integer Cast 0.39 * 100.0=38
Float=39.00
Integer=39
Casting and rounding seems to be a problem.
The compiler build options are:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --with-tune=generic --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.4 (Debian 4.3.4-6)
The system is;
Linux devel 2.6.30-2-686 #1 SMP Sat Sep 26 01:16:22 UTC 2009 i686 GNU/Linux
The processor is:
processor: 0
vendor_id: AuthenticAMD
cpu family: 15
model: 107
model name: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
stepping: 2
cpu MHz: 2712.740
cache size: 512 KB
[Bug c/47143] warning about const multidimensional array as function parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47143 Igor rogi at linuxmail dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #5 from Igor rogi at linuxmail dot org 2011-01-01 15:42:34 UTC --- (In reply to comment #4) If you want to use const here only on the callee side then you will need to use casts. I meant what I said: you are passing pointer to array[4] of double, with no const in there, to a function expecting pointer to array[4] of const double, and this is not a case permitted by C99 6.5.16.1#1. C does not have a type pointer to const array[4] of double. Let me see if I understood. const double a[4][4] will become a pointer to array of consts. So when i call my function passing a pointer to array, teh conversion fails since it's only allowed to apply teh qualifier (const) to teh _pointer type_, which is an array, and not to it's elements as teh function was expecting. Correct me if I'm wrong again please and thanks for your patience.
[Bug c/47143] warning about const multidimensional array as function parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47143 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-01 16:36:27 UTC --- Please stop reopening the PR, there is no bug on the gcc side.
[Bug tree-optimization/47141] [4.6 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47141 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-01-01 17:08:59 UTC --- It is caused by revision 161433: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01351.html
[Bug bootstrap/47147] New: gcc 4.6 fails to compile on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147 Summary: gcc 4.6 fails to compile on NetBSD Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: js-...@webkeks.org /home/js/gcc-build/./prev-gcc/xgcc -B/home/js/gcc-build/./prev-gcc/ -B/usr/local/x86_64-unknown-netbsd5.1./bin/ -B/usr/local/x86_64-unknown-netbsd5.1./bin/ -B/usr/local/x86_64-unknown-netbsd5.1./lib/ -isystem /usr/local/x86_64-unknown-netbsd5.1./include -isystem /usr/local/x86_64-unknown-netbsd5.1./sys-include-c -DHAVE_CONFIG_H -g -O2 -gtoggle -I. -I/home/js/gcc-trunk/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fpic /home/js/gcc-trunk/libiberty/mempcpy.c -o pic/mempcpy.o; \ else true; fi /home/js/gcc-trunk/libiberty/mempcpy.c:35:36: error: unknown type name ‘size_t’ /home/js/gcc-trunk/libiberty/mempcpy.c:38:34: error: unknown type name ‘size_t’ Looking at the file, it includes stddef.h, which does define size_t on NetBSD: webkeks:/tmp$ cat test.c #include stddef.h size_t foo; webkeks:/tmp$ gcc -c test.c webkeks:/tmp$ So it seems that uding the build process, different headers are used which are broken.
[Bug c++/47144] [4.5 Regression] Doesn't reject attempt to define type in template argument; results in weird parse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47144 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.01 18:05:20 Known to work||4.4.5 Summary|Doesn't reject attempt to |[4.5 Regression] Doesn't |define type in template |reject attempt to define |argument; results in weird |type in template argument; |parse |results in weird parse Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-01 18:05:20 UTC --- 4.4 rejects it: inv.cc:1: error: expected class-name before ‘int’ inv.cc:1: error: expected ‘(’ before ‘int’ 4.5 accepts it without error current 4.6 rejects it with the following inv.cc:1:48: error: expected ‘;’ after struct definition inv.cc:1:48: error: expected template-argument before ‘;’ token inv.cc:1:48: error: expected ‘’ before ‘;’ token inv.cc:1:48: error: expected ‘::’ before ‘;’ token inv.cc:1:48: error: expected unqualified-id before ‘;’ token inv.cc:1:48: error: declaration does not declare anything [-fpermissive] inv.cc:1:50: error: expected unqualified-id before ‘’ token what 4.6.0 version are you using?
[Bug c++/47144] [4.5 Regression] Doesn't reject attempt to define type in template argument; results in weird parse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47144
--- Comment #2 from Johannes Schaub schaub.johannes at googlemail dot com
2011-01-01 18:11:27 UTC ---
(In reply to comment #1)
4.4 rejects it:
inv.cc:1: error: expected class-name before ‘int’
inv.cc:1: error: expected ‘(’ before ‘int’
4.5 accepts it without error
current 4.6 rejects it with the following
inv.cc:1:48: error: expected ‘;’ after struct definition
inv.cc:1:48: error: expected template-argument before ‘;’ token
inv.cc:1:48: error: expected ‘’ before ‘;’ token
inv.cc:1:48: error: expected ‘::’ before ‘;’ token
inv.cc:1:48: error: expected unqualified-id before ‘;’ token
inv.cc:1:48: error: declaration does not declare anything [-fpermissive]
inv.cc:1:50: error: expected unqualified-id before ‘’ token
what 4.6.0 version are you using?
Hmm, 4.6.0 20101113 (experimental). I found the following does not error out
on 4.1.2:
templatetypename T struct A { };
templatetypename T
struct C {
typename A struct B { } ::A x;
};
Cint c;
Maybe it also works on 4.4. Note that this relies on typename X::Y to ignore
non-type names, which I think is not according to the spec. See
http://stackoverflow.com/questions/4420828/another-bug-in-g-clang-c-templates-are-fun
and http://llvm.org/bugs/show_bug.cgi?id=8263 .
[Bug c/47146] Floating point to integer conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47146 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-01 18:21:01 UTC --- (In reply to comment #0) Casting and rounding seems to be a problem. Please be more specific. Do you understand how floating point works? Do you know that 0.39 * 100 has type double, not float, so has more precision (and a different value) than (float)0.39 * 100 ? If you use doubles, or consistently use floats (not a mix of floats and doubles) then you get consistent results
[Bug c++/47144] [4.5 Regression] Doesn't reject attempt to define type in template argument; results in weird parse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47144
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-01
18:24:42 UTC ---
(In reply to comment #2)
what 4.6.0 version are you using?
Hmm, 4.6.0 20101113 (experimental).
Ah, maybe that accepted it, but current 4.6 rejects it.
I assume it was changed by Nathan Froyd's recent changes to diagnostics about
missing ';' after a class definition.
I found the following does not error out
on 4.1.2:
templatetypename T struct A { };
templatetypename T
struct C {
typename A struct B { } ::A x;
};
Cint c;
This is accepted by 4.4 and 4.5 but rejected by 4.6
(noone cares about 4.1, it's been unmaintained for some time)
Maybe it also works on 4.4. Note that this relies on typename X::Y to ignore
non-type names, which I think is not according to the spec. See
http://stackoverflow.com/questions/4420828/another-bug-in-g-clang-c-templates-are-fun
and http://llvm.org/bugs/show_bug.cgi?id=8263 .
[Bug c/47148] New: likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47148
Summary: likely wrong code bug
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
[reg...@gamow tmp436]$ current-gcc -O1 small.c -o small
[reg...@gamow tmp436]$ ./small
0
[reg...@gamow tmp436]$ current-gcc -O2 small.c -o small
[reg...@gamow tmp436]$ ./small
1
[reg...@gamow tmp436]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r168380-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r168380-install
--program-prefix=r168380- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20101231 (experimental) (GCC)
[reg...@gamow tmp436]$ cat small.c
int printf(const char *format, ...);
static unsigned div(unsigned p1, unsigned p2)
{
return p1 / p2;
}
static unsigned rshift (unsigned p1, unsigned p2)
{
if (p2 = 32)
return p1;
else
return p1 p2;
}
static unsigned g_26 = 1;
static unsigned g_78 = 1;
static void func_28 (unsigned char p_30, unsigned p_31)
{
if (p_31) {
unsigned l1 = div (0x7000, p_30-2) ^ g_26;
unsigned l2 = rshift (g_26, g_26);
unsigned l4 = g_26 - l2;
g_78 = (l4 (g_26-1)) + l1;
}
}
static void func_2 (void)
{
func_28 (1, 1);
}
int main(void)
{
func_2();
func_28 (-1, 1);
printf(%d\n, g_78);
return 0;
}
[Bug c++/47144] [4.5 Regression] Doesn't reject attempt to define type in template argument; results in weird parse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47144
--- Comment #4 from Johannes Schaub schaub.johannes at googlemail dot com
2011-01-01 18:41:53 UTC ---
(In reply to comment #3)
(In reply to comment #2)
what 4.6.0 version are you using?
Hmm, 4.6.0 20101113 (experimental).
Ah, maybe that accepted it, but current 4.6 rejects it.
I assume it was changed by Nathan Froyd's recent changes to diagnostics about
missing ';' after a class definition.
Ah I see. Have you found any combination of this that fails on trunk? Could be
worth putting it here. Maybe adding declarators prevents it from wanting to see
a semicolon?
templatetypename struct A { }; A struct B { }* ::SomeNonSense int y;
Thanks!
[Bug c++/47144] [4.5, 4.6 Regression] Doesn't reject attempt to define type in template argument; results in weird parse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47144
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.5 Regression] Doesn't|[4.5, 4.6 Regression]
|reject attempt to define|Doesn't reject attempt to
|type in template argument; |define type in template
|results in weird parse |argument; results in weird
||parse
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-01
19:23:50 UTC ---
(In reply to comment #4)
Ah I see. Have you found any combination of this that fails on trunk? Could be
worth putting it here. Maybe adding declarators prevents it from wanting to
see
a semicolon?
templatetypename struct A { }; A struct B { }* ::SomeNonSense int y;
Good thinking - that is rejected by 4.4 but accepted by 4.5 and 4.6
I've added 4.6 to the subject
[Bug tree-optimization/47148] [4.6 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47148
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||wrong-code
Last reconfirmed||2011.01.01 20:07:21
Component|c |tree-optimization
CC||hubicka at gcc dot gnu.org,
||jakub at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|likely wrong code bug |[4.6 Regression] likely
||wrong code bug
Target Milestone|--- |4.6.0
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-01
20:07:21 UTC ---
/* PR tree-optimization/47148 */
static inline unsigned
bar (unsigned x, unsigned y)
{
if (y = 32)
return x;
else
return x y;
}
static unsigned a = 1, b = 1;
static inline void
foo (unsigned char x, unsigned y)
{
if (!y)
return;
unsigned c = (0x7000U / (x - 2)) ^ a;
unsigned d = bar (a, a);
b = ((a - d) (a - 1)) + c;
}
int
main (void)
{
foo (1, 1);
foo (-1, 1);
if (b ((unsigned char) -1) == 255)
__builtin_abort ();
return 0;
}
Indeed, seems to be caused by partial inlining. With -fno-partial-inlining it
works fine.
[Bug c++/47144] [4.5, 4.6 Regression] Doesn't reject attempt to define type in template argument; results in weird parse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47144
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||jason at redhat dot com
Target Milestone|--- |4.5.3
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2011-01-01 20:11:07
UTC ---
(In reply to comment #5)
(In reply to comment #4)
Ah I see. Have you found any combination of this that fails on trunk? Could
be
worth putting it here. Maybe adding declarators prevents it from wanting to
see
a semicolon?
templatetypename struct A { }; A struct B { }* ::SomeNonSense int y;
Good thinking - that is rejected by 4.4 but accepted by 4.5 and 4.6
I've added 4.6 to the subject
It is caused by revision 154403:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00624.html
[Bug tree-optimization/47148] [4.6 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47148 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-01-01 20:17:26 UTC --- It is caused by revision 161433: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01351.html
[Bug target/47148] [4.6 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47148
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-01
20:53:39 UTC ---
It seems this is very much related to the PR46942 ABI screw up.
Apparently sometimes on x86_64 we actually rely on the sign/zero extensions
done by the caller, not to DImode, but just to SImode, not by setting
SUBREG_PROMOTED_P bit in the subregs, but at least in combine.c's
setup_incoming_promotions and thus the zero extension is optimized away.
Normally, e.g. when compiling
static unsigned a = 1, b = 1;
static __attribute__((noinline)) void
foo (unsigned char x)
{
unsigned c = (0x7000U / (x - 2)) ^ 1;
b = c;
}
int
main (void)
{
foo (1);
foo (-1);
if (b ((unsigned char) -1) == 255)
__builtin_abort ();
return 0;
}
the caller indeed does the needed promotions, as CALL_EXPR's argument has int
type rather than unsigned char. But when calling the artificial foo.part.0,
the
argument passed to it is unsigned char 255 rather than int 255 and it sets a
QImode %rdi register to -1 (i.e. 255) instead of setting SImode %rdi register
to 255, which means it is incorrectly sign extended instead of zero extended.
[Bug target/47148] [4.6 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47148 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-01-01 21:03:08 UTC --- (In reply to comment #3) the caller indeed does the needed promotions, as CALL_EXPR's argument has int type rather than unsigned char. But when calling the artificial foo.part.0, the argument passed to it is unsigned char 255 rather than int 255 and it sets a QImode %rdi register to -1 (i.e. 255) instead of setting SImode %rdi register to 255, which means it is incorrectly sign extended instead of zero extended. I proposed to update x86-64 psABI to --- When a value of type _Bool is returned in a register, bit 0 contains the truth value and bits 1 to 7 shall be zero. When an argument of type _Bool is passed in a register or on the stack, bit 0 contains the truth value and bits 1 to 31 shall be zero. When a value of type signed/unsigned char or short is returned in a register, bits 0 to 7 for char and bits 0 to 15 for short contain the value and other bits are left unspecified. When an argument of signed/unsigned type char or short is passed in a register or on the stack, it shall be sign/zero extended to signed/unsigned int. --- http://gcc.gnu.org/ml/gcc/2010-12/msg00525.html
[Bug target/47148] [4.6 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47148 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-01 21:08:40 UTC --- Maybe it is fnsplit fault, it might want to look at DECL_ARG_TYPE of the PARM_DECL in question (partial inlining means it always has a fndecl, so can look at its DECL_ARGUMENTS to find that type) and use that type instead of the type in TYPE_ARG_TYPES.
[Bug c/47146] Floating point to integer conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47146
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||kargl at gcc dot gnu.org
Resolution||INVALID
--- Comment #2 from kargl at gcc dot gnu.org 2011-01-01 21:15:30 UTC ---
(In reply to comment #0)
#include stdio.h
#include stdlib.h
//-
int32_t main(int argc, char **argv)
//-
{
float elapsed = 0.3894949;
fprintf( stdout, Float 0.3894949=%f\n, elapsed );
fprintf( stdout, Float 0.3894949 * 100.0=%f\n, elapsed * 100.0 );
fprintf( stdout, Integer Cast 0.3894949 * 100.0=%d\n, (int32_t) (elapsed
* 100.0) );
If you change all your floating point constants to include a f
suffix (e.g., 100.0f, 0.3894949f, etc), then you get
laptop:kargl[149] cc -o z a.c -ffloat-store ./z
Float 0.3894949=0.389495
Float 0.3894949 * 100.0=38.949490
Integer Cast 0.3894949 * 100.0=38
Float=38.949490
Integer=38
--
Float 0.39=0.39
Float 0.39 * 100.0=39.00
Integer Cast 0.39 * 100.0=39
Float=39.00
Integer=39
which looks like the desired output. As Jonathan mentions, you
have several intermediate results that are double not float.
Add the fact that 0.39 is not exactly representable, which
your output of Float 0.39 * 100.0=38.99 clearly shows,
you've miss interpreted your results.
[Bug other/47149] New: failing build: execvp: /bin/sh: Argument list too long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47149 Summary: failing build: execvp: /bin/sh: Argument list too long Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: o.kullm...@swansea.ac.uk When building libgfortran a long line with around 600 entries of the form .libs/maxloc0_16_r16.o is created, which due to these 600 entries has already around 11000 characters, which for older Linux systems makes the build fail. I have discussed this on the mailing list, and was encouraged to submit this as a bug. The error message and the context: /bin/sh ./libtool --tag=CC --mode=link /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.2_build/./gcc/xgcc -B/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.2_build/./gcc/ -B/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.5.2/x86_64-unknown-linux-gnu/bin/ -B/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.5.2/x86_64-unknown-linux-gnu/lib/ -isystem /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.5.2/x86_64-unknown-linux-gnu/include -isystem /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.5.2/x86_64-unknown-linux-gnu/sys-include -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -o libgfortran.la -version-info `grep -v '^#' /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.2/libgfortran/libtool-version` -no-undefined -bindir /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.5.2/bin -lm -Wl,--version-script=/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.2/libgfortran/gfortran.map -rpath /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.5.2/lib/../lib64 backtrace.lo bounds.lo compile_options.lo convert_char.lo environ.lo error.lo fpu.lo main.lo memory.lo pause.lo stop.lo string.lo select.lo all_l1.lo all_l2.lo all_l4.lo all_l8.lo all_l16.lo any_l1.lo any_l2.lo any_l4.lo XXX many more of these XXX make[4]: execvp: /bin/sh: Argument list too long make[4]: *** [libgfortran.la] Error 127
[Bug c/47150] New: 4.5.1/4.5.2 ICE in gimplify_expr, at gimplify.c:7146/7153 on fairly simple complex expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150 Summary: 4.5.1/4.5.2 ICE in gimplify_expr, at gimplify.c:7146/7153 on fairly simple complex expression Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ewlea...@comcast.net Created attachment 22878 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22878 gcc -v -save-temps -c gimplify_bug.c output with gimplify_bug.i for both the Fedora system gcc 4.5.1 and local build of 4.5.2, [4.5.1/4.5.2 Regression from 4.4.5] ICE in gimplify_expr, at gimplify.c:7146/7153 on fairly simple complex expression. Test system: Fedora 14 x86_64 Test fails at gimplify.c:7146 on 4.5.1 and at gimplify.c:7153 on 4.5.2 Test passes on 4.4.5 4.5.1 is the Fedora 14 system /usr/bin/gcc 4.4.5 and 4.5.2 were downloaded from the gcc.gnu.org mirrors and compiled with ../configure --prefix=/usr/local/gcc/gcc-4.4.5 \ --with-gmp-include=/usr/include --with-gmp-lib=/usr/lib64 \ --with-mpfr-include=/usr/include --with-mpfr-lib=/usr/lib64 \ --with-mpc-include=/usr/include --with-mpc-lib=/usr/lib64 \ --enable-languages=c,c++,fortran I've attached the requested gcc -v -save-temps -c gimplify_bug.c output with gimplify_bug.i for both the Fedora system 4.5.1 and my local build of 4.5.2, in the single file gimplify_bug.txt. Thanks.
[Bug fortran/46017] Reject ALLOCATE(a, a%b) as a%b depends on the allocation status of a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46017 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||tkoenig at gcc dot gnu.org AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-01 22:26:13 UTC --- I have a patch.
[Bug c/47150] 4.5.1/4.5.2 ICE in gimplify_expr, at gimplify.c:7146/7153 on fairly simple complex expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.01 22:52:36 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-01-01 22:52:36 UTC --- Please only upload the output of gcc -E gimplify_bug.c and tell us how to reproduce it.
[Bug c/47150] [4.5/4.6 Regression] ICE in gimplify_expr at gimplify.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|WAITING |NEW
Target Milestone|--- |4.5.3
Summary|4.5.1/4.5.2 ICE in |[4.5/4.6 Regression] ICE in
|gimplify_expr, at |gimplify_expr at gimplify.c
|gimplify.c:7146/7153 on |
|fairly simple complex |
|expression |
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-01-01 22:57:44
UTC ---
[...@gnu-35 rrs]$ cat pr47150.c
float _Complex cmplx(float re, float im);
void bad_test(){
float w = 2;
float _Complex b;
b = 0.5*(cmplx(0,w)+cmplx(1,w)/w);
}
[...@gnu-35 rrs]$ /export/gnu/import/rrs/147281/usr/bin/gcc -S pr47150.c
pr47150.c: In function \u2018bad_test\u2019:
pr47150.c:5: internal compiler error: in gimplify_expr, at gimplify.c:7045
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[...@gnu-35 rrs]$
[Bug c/47150] [4.5/4.6 Regression] ICE in gimplify_expr at gimplify.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-01-01 22:59:41 UTC --- It is caused by revision 147281: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00255.html
[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with cannot check for file existence when cross compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 Summary|cross-compilation fails |[4.6 Regression] |with cannot check for file |cross-compilation fails |existence when cross|with cannot check for file |compiling |existence when cross ||compiling --- Comment #1 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-01-02 00:32:34 UTC --- I'd like to remind libstdc++ maintainers that they need to be very cautious about any substantial changes (such as this rework of documentation build and configuration) at this development stage.
