[Bug fortran/32238] [4.3 Regression] ICE in gfc_conv_constant (where() with complex arrays)
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|386-pc-linux-gnu| GCC target triplet|i386-pc-linux-gnu | Keywords||ice-on-valid-code Known to fail||4.3.0 Known to work||4.1.3 4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-06-07 06:33:31 date|| Summary|ICE in gfc_conv_constant|[4.3 Regression] ICE in |(where with complex arrays) |gfc_conv_constant (where() ||with complex arrays) Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32238
[Bug c++/32240] New: wstring::length() does not work properly with --short-wchar
wstring::length() does not work properly with --short-wchar
I'm not sure if this bug is in gcc or glibc. It could be that gcc does not
properly set a certain variable with --short-wchar, or, it could be that glibc
does not properly implement wstring, always assuming a 4-byte wchar_t.
Here is a sample:
// tmp2.cpp
#include iostream
int main(int argc, char ** argv)
{
std::wstring wstr = LHello, World!;
std::wcout wstr.length() std::endl;
return 0;
}
$ g++ -o tmp tmp2.cpp
$ ./tmp
13
$ g++ -o tmp tmp2.cpp --short-wchar
$ ./tmp
19
They should both say 13. ymmv, but the length value given is usually wrong. How
wrong may vary.
--
Summary: wstring::length() does not work properly with --short-
wchar
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jigglypuff at spambob dot com
GCC build triplet: ?
GCC host triplet: i686-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32240
[Bug ada/32234] Default pointer initialization not occuring - due to the use of
--- Comment #7 from baldrick at gcc dot gnu dot org 2007-06-07 07:07 --- Valgrind is helful only if there is a crash (segmentation fault). This is completely wrong. Valgrind detects problems that *may* cause a crash. The fact that crashes occur rarely doesn't mean there isn't something wrong. I already explained that you can't expect to get a segmentation fault on a small program. So for a testcase I either had to provide the large (300k/loc) original program which showed the segmentation fault systematically, or a small program which basically never shows a segmentation fault. i.e. testcases become less and less deterministic as you make them smaller. However there is a way to keep things deterministic: run under a tool such as valgrind. Valgrind detects the same problem every time no matter how big or small the testcase. This makes it feasible to submit a minimal testcase which captures the essential problem, even though when run normally (i.e. not under valgrind) it executes fine. In fact you will never get a segmentation fault with the testcase I submitted because it doesn't ever dereference the uninitialized pointer - but that doesn't matter because valgrind notices that it contains an uninitialized value when the if compares it with null. i.e. the testcase is good enough for debugging the compiler problem. Let me say it again: when run on the small testcase valgrind shows the presence of an uninitialized value that doesn't cause any problems when the small testcase is run - it causes problems on the large program from which this testcase was reduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #106 from tbm at cyrius dot com 2007-06-07 07:21 --- (In reply to comment #101) current gcc (i.e. after the fix for PR32018) still ICEs as described in comment #100 I independently reported a bug yesterday that has a very similar traceback as what you posted in comment #100. This got fixed, see PR32231. Can you please test whether your testcase works now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/32176] [4.3 Regression] ICE tree-type mismatch: expected integer_cst, have plus_expr in int_cst_value, at tree.c:7720
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-07 08:39 --- Compilation works for me with: gcc-Version 4.3.0 20070607 x86_64-unknown-linux-gnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32176
[Bug c++/32240] wstring::length() does not work properly with --short-wchar
--- Comment #1 from pcarlini at suse dot de 2007-06-07 08:51 --- (In reply to comment #0) std::wstring wstr = LHello, World!; A couple of clarifications. First, your way of using --short-wchar cannot work in principle, because std::string functions are exported from the installed .so, which is built *without* --short-wchar. At minimum, for consistency, the library itself should be rebuilt at installation time with that switch. In the specific case above, where you are using the constructor taking a C string, it forwards to the underlying glibc wcslen in order to compute the length of the initializer C string, which is computing the length incorrectly: we alredy knew that, glibc doesn't work completely fine together with --short-wchar: the docs are pretty clear that on GNU systems a wchar_t is always assumed to be 32 bits. I don't think there is a way to deal portably with such issues within C++03: the new C++0x will include char16_t and char23_t types and everything will be straightforward. In the meanwhile, as far as I know, most of the library has chances to work fine if you provide replacement std::char_traits not forwarding to underlying C functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32240
[Bug libgcj/32227] [4.3 Regression] ../gcc/libjava/classpath/include/config-int.h:7:20: error: stdint.h: No such file or directory
--- Comment #2 from andreast at gcc dot gnu dot org 2007-06-07 09:09 --- removed on sparc and build succeeds :) -- andreast 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-06-07 09:09:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32227
[Bug c++/32240] wstring::length() does not work properly with --short-wchar
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-07 09:14 --- This is neither a GCC bug or a glibc bug as -fshort-wchar changes the ABI. The documentation already mentions this: Warning: the -fshort-wchar switch causes GCC to generate code that is not binary compatible with code generated without that switch. Use it to conform to a non-default application binary interface. -- 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=32240
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #107 from jv244 at cam dot ac dot uk 2007-06-07 09:25 --- (In reply to comment #106) (In reply to comment #101) current gcc (i.e. after the fix for PR32018) still ICEs as described in comment #100 I independently reported a bug yesterday that has a very similar traceback as what you posted in comment #100. This got fixed, see PR32231. Can you please test whether your testcase works now? Great... the bug reported in comment #100 is indeed fixed after the fix for PR32231. I actually had problems to reproduce the problem, the '--param ggc-min-expand=0 --param ggc-min-heapsize=0' is a useful trick though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/32176] [4.3 Regression] ICE tree-type mismatch: expected integer_cst, have plus_expr in int_cst_value, at tree.c:7720
--- Comment #5 from jv244 at cam dot ac dot uk 2007-06-07 09:32 --- (In reply to comment #4) Compilation works for me with: gcc-Version 4.3.0 20070607 x86_64-unknown-linux-gnu still failing for me with a compiler a few minutes old: [EMAIL PROTECTED]:~/g95 cat /scratch/vondele/gcc_trunk/gcc/LAST_UPDATED Thu Jun 7 10:12:05 CEST 2007 Thu Jun 7 08:12:05 UTC 2007 (revision 125521) [EMAIL PROTECTED]:~/g95 gfortran -fprefetch-loop-arrays -O2 test.f90 test.f90: In function polint: test.f90:1: internal compiler error: tree check: expected integer_cst, have plus_expr in int_cst_value, at tree.c:7720 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED]:~/g95 gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /scratch/vondele/gcc_trunk/gcc/configure --prefix=/scratch/vondele/gcc_trunk/build --with-mpfr_include=/scratch/vondele/mpfr-2.2.0/ --with-mpfr_lib=/scratch/vondele/mpfr-2.2.0/ --with-gmp=/users/vondele/ --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070607 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32176
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #108 from jv244 at cam dot ac dot uk 2007-06-07 09:34 --- Unfortunately the newly updated compiler ICEs now at -O0 gfortran -O0 pw_types.f90 /scratch/vondele/clean/cp2k/src/../src/pw_types.F: In function pw_integral_a2b: /scratch/vondele/clean/cp2k/src/../src/pw_types.F:3776: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:386 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-06-07 09:55 --- How is it that this tester can build on this target, and not you? http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00309.html I don't see a mention of AIX limitations for sed here: http://gcc.gnu.org/install/specific.html#x-ibm-aix -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug libstdc++/32092] Can't create directory link when build libstdc++ (gcc-4.2.0)
--- Comment #3 from bkoz at gcc dot gnu dot org 2007-06-07 10:00 --- When I build gcc-g++ 4.2.0 in Mingw32 in Windows XP, when it compile libstdc++ , it want to create directory link of $GCC_SRC_ROOT\libstdc++-v3\include\ext\pb_ds\detail but in mingw32 , It can't create it. Why not? What's the exact error from the build? To change 'ln -s' to 'cp -r' you would need to change the LN_S variable in the suitable Makefile. However, if this is not working routinely for mingw32, this should be changed across the board, not just for libstdc++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32092
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #3 from joerg dot richter at pdv-fs dot de 2007-06-07 10:03 --- Well, $ which sed /usr/bin/sed $ /usr/bin/sed -e '' sed: 0602-429 No editing script was provided. Usage: sed [-n] Script [File ...] sed [-n] [-e Script] ... [-f Script_file] ... [File ...] Can it be that everyone else is using GNU-sed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug c++/32241] New: Compiler segmentation fault when trying to call x.~X(); (X x = f();) in a template
/*
$ cat /proc/version
Linux version 2.6.20-15-generic ([EMAIL PROTECTED]) (gcc version 4.1.2 (Ubuntu
4.1.2-0ubuntu4)) #2 SMP Sun Apr 15 06:17:24 UTC 2007
$ gcc --version
gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
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.
$ g++ simplestack.cpp -o simplestack -g
simplestack.cpp: In member function void SimpleStackT, N::pop() [with T =
int, long unsigned int N = 4ul]:
simplestack.cpp:52: instantiated from here
simplestack.cpp:32: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
preprocessed source: http://cpp.sourceforge.net/?show=36942
*/
#include stdexcept
#include memory
template typename T, std::size_t N
class SimpleStack
{
public:
SimpleStack()
: ptr(reinterpret_castT*(buffer[0]))
{
}
void push(const T element)
{
if(num = N) throw std::out_of_range(stack full);
new (ptr + num) T(element);
++num;
}
bool empty() const
{
return num = 0;
}
T top()
{
return *(ptr + num - 1);
}
void pop()
{
top.~T(); // this is the line causing the error!
--num;
}
private:
SimpleStack(const SimpleStack);
SimpleStack operator=(const SimpleStack);
char buffer[N * sizeof(T)];
T *ptr;
std::size_t num;
};
#include iostream
int main()
{
SimpleStackint, 4 stack;
stack.push(3);
std::cout stack.top() std::endl;
stack.pop();
}
--
Summary: Compiler segmentation fault when trying to call x.~X();
(X x = f();) in a template
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsalmin2 at cc dot hut dot fi
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32241
[Bug c++/32241] Compiler segmentation fault when trying to call x.~X(); (X x = f();) in a template
--- Comment #1 from rsalmin2 at cc dot hut dot fi 2007-06-07 10:30 --- Created an attachment (id=13663) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13663action=view) Source code and preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32241
[Bug fortran/32242] New: nternal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:386
current trunk : gfortran -c -O0 test.f90 test.f90: In function pw_integral_a2b: test.f90:251: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:386 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: nternal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:386 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32242
[Bug fortran/32242] nternal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:386
--- Comment #1 from jv244 at cam dot ac dot uk 2007-06-07 10:39 --- Created an attachment (id=13664) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13664action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32242
[Bug fortran/32242] nternal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:386
--- Comment #2 from jv244 at cam dot ac dot uk 2007-06-07 10:40 --- This blocks CP2K (PR 29975) -- jv244 at cam dot ac dot uk changed: What|Removed |Added OtherBugsDependingO||29975 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32242
[Bug fortran/32242] [4.3 Regression] nternal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:386
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|nternal compiler error: in |[4.3 Regression] nternal |gfc_conv_variable, at |compiler error: in |fortran/trans-expr.c:386|gfc_conv_variable, at ||fortran/trans-expr.c:386 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32242
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #109 from jv244 at cam dot ac dot uk 2007-06-07 11:56 --- (In reply to comment #108) Unfortunately the newly updated compiler ICEs now at -O0 this is now PR 32242 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug tree-optimization/32243] New: [4.3 Regression] ICE in vectorizable_type_promotion, at tree-vect-transform.c:2890
I'm getting the following ICE with current trunk. This also fails with
20070303.
(sid)25827:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O3
-ftree-vectorize
mesa-depthstencil.c
mesa-depthstencil.c: In function 'put_mono_values_s8':
mesa-depthstencil.c:13: internal compiler error: in
vectorizable_type_promotion, at tree-vect-transform.c:2890
Please submit a full bug report, [...]
Test case:
typedef struct __GLcontextRec GLcontext;
struct gl_renderbuffer
{
struct gl_renderbuffer *Wrapped;
void (*PutValues) (GLcontext *ctx, struct gl_renderbuffer *rb,
int count, const int x[], const int y[],
const void *values, const char *mask);
};
void
put_mono_values_s8 (GLcontext *ctx, struct gl_renderbuffer *s8rb,
int count, const int x[], const int y[],
const void *value, const char *mask)
{
struct gl_renderbuffer *dsrb = s8rb-Wrapped;
int temp[4096], i;
const char val = *((char *) value);
for (i = 0; i count; i++)
if (!mask || mask[i])
temp[i] = (temp[i] 0xff) | val;
dsrb-PutValues (ctx, dsrb, count, x, y, temp, mask);
}
_mesa_new_s8_renderbuffer_wrapper (void)
{
struct gl_renderbuffer *s8rb;
s8rb-PutValues = put_mono_values_s8;
}
--
Summary: [4.3 Regression] ICE in vectorizable_type_promotion, at
tree-vect-transform.c:2890
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32243
[Bug tree-optimization/32243] [4.3 Regression] ICE in vectorizable_type_promotion, at tree-vect-transform.c:2890
--- Comment #1 from tbm at cyrius dot com 2007-06-07 12:47 --- This worked with 20061214. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32243
[Bug fortran/32242] [4.3 Regression] nternal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:386
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-06-07 13:04 --- Confirmed on i686-darwin. I'll look into it during the week-end if noone beats me to it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-07 13:04:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32242
[Bug fortran/32235] gfortran - incorrectly position text file after backspace
--- Comment #3 from dir at lanl dot gov 2007-06-07 13:13 --- Most compilers assume that you need to backspace back over the End-Of-File. This goes back to the good old days, when the EOF was actually a tape mark. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32235
[Bug libgcj/32227] [4.3 Regression] ../gcc/libjava/classpath/include/config-int.h:7:20: error: stdint.h: No such file or directory
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-07 13:21 --- Subject: Re: [4.3 Regression] ../gcc/libjava/classpath/include/config-int.h:7:20: error: stdint.h: No such file or directoRO removed on sparc and build succeeds :) Same on hppa2.0w-hp-hpux11.11. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32227
[Bug c/32244] New: bit-field: optimization BUG
The output is different by the optimization.
testcase:
#include stdio.h
struct foo
{
unsigned long long b:33;
};
int main()
{
struct foo x = {2};
printf(%llx\n,(x.b32));
return 0;
}
result:
$ gcc bit.c -o bit; ./bit
2
$ gcc -O bit.c -o bit; ./bit
0
--
Summary: bit-field: optimization BUG
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32244
[Bug c++/32245] New: wrong POD type initialization
testcase:
#include cassert
struct foo
{
int mem1;
int foo::* mem2;
};
int main()
{
foo x = {0};
assert(x.mem2 == foo().mem2);
return 0;
}
result:
$ g++42 bug.cpp -o bug; ./bug
assertion x.mem2 == foo().mem2 failed: file bug.cpp, line 12
Aborted (core dumped)
--
Summary: wrong POD type initialization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32245
[Bug libgcj/32227] [4.3 Regression] ../gcc/libjava/classpath/include/config-int.h:7:20: error: stdint.h: No such file or directory
--- Comment #4 from doko at gcc dot gnu dot org 2007-06-07 13:38 --- Subject: Bug 32227 Author: doko Date: Thu Jun 7 13:38:49 2007 New Revision: 125528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125528 Log: 2007-06-07 Matthias Klose [EMAIL PROTECTED] PR libgcj/32227 * include/config-int.h: Delete, it is a generated file. Removed: trunk/libjava/classpath/include/config-int.h Modified: trunk/libjava/classpath/ChangeLog.gcj -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32227
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #12 from rob1weld at aol dot com 2007-06-07 13:42 --- I've done some more testing. With GNU/Linux 4.0 the file: /usr/include/bits/mathdef.h has this in it: # if defined __FLT_EVAL_METHOD__ __FLT_EVAL_METHOD__ == 0 /* When using -mfpmath=sse, values are computed with the precission of the used type. */ typedef float float_t; /* `float' expressions are evaluated as `float'. */ typedef double double_t;/* `double' expressions are evaluated as `double'. */ # else /* The ix87 FPUs evaluate all values in the 80 bit floating-point format which is also available for the user as `long double'. Therefore we define: */ typedef long double float_t;/* `float' expressions are evaluated as `long double'. */ typedef long double double_t; /* `double' expressions are evaluated as `long double'. */ # endif That means, for many people but NOT everyone, that floats and doubles are actually _long_ doubles. I have not examined every line of GCC to determine if in fact GCC is using floats and doubles at the correct size - regardless of the actual size they are stored at. Since Cygwin's GCC 3.4.4 doesn't have long doubles it does not do that. Memory access is quicker but things like sticky bits will not be in the right spot and there will be too much precision. Too much precision is bad when tests rely on an exact implementation - otherwise it is usually OK. I've done a simple hack to the _root_ ./configure file ONLY and NOT changed one line of GCC's source code to alter the manner in which GCC is configured. It will need more testing - you _might_ be able to simulate what I am doing by typing: export CFLAGS=-mfpmath=sse -msse2 After doing that simply configure and make GCC as you normally would. (Note: I am _not_ using the above CFLAGS method but making more complicated changes within the root configuration file - so your results _might_ not be the same). After building GCC all my tests where the SAME, failures and passes were equal. I was also able to compile mpfr without error (as before). The ONLY difference was that Paranoia was in a worse state than before, failing miserably. I altered paranoia to use long doubles instead of doubles and re-ran it. This is what it says now (edited): ... Precision: long double; Version:10 February 1989; ... Searching for Radix and Precision. Radix = 2 . Closest relative separation found is U1 = 5.421010862427522170037264e-20 . The number of significant digits of the Radix is 64 . ... Checking rounding on multiply, divide and add/subtract. Multiplication appears to round correctly. Division appears to round correctly. Addition/Subtraction appears to round correctly. Checking for sticky bit. Sticky bit apparently used correctly. ... Running test of square root(x). Testing if sqrt(X * X) == X for 20 Integers X. Test for sqrt monotonicity. sqrt has passed a test for Monotonicity. Testing whether sqrt is rounded or chopped. Square root appears to be correctly rounded ... Seeking Underflow thresholds UfThold and E0. Smallest strictly positive number found is E0 = 3.6452e-4951 . Since comparison denies Z = 0, evaluating (Z + Z) / Z should be safe. What the machine gets for (Z + Z) / Z is 2 . This is O.K., provided Over/Underflow has NOT just been signaled. Underflow is gradual; it incurs Absolute Error = (roundoff in UfThold) E0. The Underflow threshold is 3.36210314311209350662719777e-4932, below which calculation may suffer larger Relative error than merely roundoff. Since underflow occurs below the threshold UfThold = (2) ^ (-16382) only underflow should afflict the expression (2) ^ (-32764); actually calculating yields: 0 . This computed value is O.K. Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.38905609893065022739794268 as X - 1. Accuracy seems adequate. Testing powers Z^Q at four nearly extreme values. ... no discrepancies found. ... Searching for Overflow threshold: This may generate an error. Can `Z = -Y' overflow? Trying it on Y = -inf . Seems O.K. Overflow threshold is V = 1.18973149535723176502126385e+4932 . Overflow saturates at V0 = inf . No Overflow should be signaled for V * 1 = 1.18973149535723176502126385e+4932 nor for V / 1 = 1.18973149535723176502126385e+4932 . No failures, defects nor flaws have been discovered. Rounding appears to conform to the proposed IEEE standard P854. The arithmetic diagnosed appears to be Excellent! -- Note: Previously I was getting output like this: Searching for Radix and Precision. Radix = 2.00 . Closest relative separation found is U1 = 1.1102230e-16 . Recalculating radix and precision confirms closest relative separation U1 . Radix confirmed. The number of significant digits of the Radix is 53.00 . ... Checking rounding on multiply, divide and add/subtract. * is neither chopped nor correctly
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #13 from rob1weld at aol dot com 2007-06-07 13:48 --- One other thing: When I build and test the origonal (un-modified) Paranoia with GCC I can compile with different flags and get different results - but these are _similar_ flags :( 1 Defect 1 Flaw -mmmx -msse -m3dnow 1 Defect -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -msse4a The code for -mmmx, -msse, and -m3dnow produce worse result on the tests than the other SSE flags - the results should be the same (only the FPU code should differ and that should not alter the result of math operations since they are all SSE and not 387). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug c/32246] New: endless loop due to parsing error
The following code snippet lets gcc (3.4.6) spin in an endless loop and print
out the error message
error: `data_t::anonymous struct::anonymous struct' has no non-static data
member named `a'
again and again:
typedef struct
{
struct {
struct {
unsigned a1;
unsigned a2;
} a;
unsigned b;
};
unsigned foo;
} data_t;
data_t _data = { a:0 }};
--
Summary: endless loop due to parsing error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: frenzel at os dot inf dot tu-dresden dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32246
[Bug libstdc++/32092] Can't create directory link when build libstdc++ (gcc-4.2.0)
--- Comment #4 from dragzhb at yahoo dot com dot cn 2007-06-07 14:02 --- I think mingw32 don't support good to create link of directory. When I check ext\pb_ds\detail in $GCC_BUILD_ROOT\mingw32\libstdc++-v3\include, it create more and more ext\pb_ds\detail\ext\pb_ds\detail\ext\pb_ds\detail\ext\pb_ds\detail\ext\pb_ds\detail\ext\pb_ds\detail ... directory . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32092
[Bug fortran/32242] [4.3 Regression] nternal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:386
--- Comment #4 from jv244 at cam dot ac dot uk 2007-06-07 14:10 --- Reduced: MODULE kahan_sum INTEGER, PARAMETER :: dp=KIND(0.0D0) INTERFACE accurate_sum MODULE PROCEDURE kahan_sum_d1, kahan_sum_z1 END INTERFACE accurate_sum TYPE pw_grid_type REAL (KIND=dp), DIMENSION ( : ), POINTER :: gsq END TYPE pw_grid_type TYPE pw_type REAL (KIND=dp), DIMENSION ( : ), POINTER :: cr COMPLEX (KIND=dp), DIMENSION ( : ), POINTER :: cc TYPE ( pw_grid_type ), POINTER :: pw_grid END TYPE pw_type CONTAINS FUNCTION kahan_sum_d1(array,mask) RESULT(ks) REAL(KIND=dp), DIMENSION(:), INTENT(IN) :: array LOGICAL, DIMENSION(:), INTENT(IN), OPTIONAL :: mask REAL(KIND=dp):: ks END FUNCTION kahan_sum_d1 FUNCTION kahan_sum_z1(array,mask) RESULT(ks) COMPLEX(KIND=dp), DIMENSION(:), INTENT(IN) :: array LOGICAL, DIMENSION(:), INTENT(IN), OPTIONAL :: mask COMPLEX(KIND=dp) :: ks END FUNCTION kahan_sum_z1 FUNCTION pw_integral_a2b ( pw1, pw2 ) RESULT ( integral_value ) TYPE(pw_type), INTENT(IN):: pw1, pw2 REAL(KIND=dp):: integral_value integral_value = accurate_sum ( REAL ( CONJG ( pw1 % cc ( : ) ) * pw2 % cc ( : ) ,KIND=dp) * pw1 % pw_grid % gsq ( : ) ) END FUNCTION pw_integral_a2b END MODULE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32242
[Bug tree-optimization/32220] [4.3 Regression] internal compiler error: in eliminate_temp_copies, at tree-predcom.c:1937
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-06-07 15:34 --- Subject: Bug 32220 Author: rakdver Date: Thu Jun 7 15:34:40 2007 New Revision: 125531 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125531 Log: PR tree-optimization/32220 * tree-predcom.c (eliminate_temp_copies): Handle the case that loop phi node is reached before defining statement. * gfortran.dg/predcom-2.f: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/predcom-2.f Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-predcom.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32220
[Bug fortran/31833] FAIL: gfortran.dg/integer_exponentiation_3.F90 at -O0 and above
--- Comment #4 from sje at cup dot hp dot com 2007-06-07 15:38 --- This is fixed with a testsuite change in version 125510. I forgot to put the PR number in the ChangeLog file. I changed the test to do an approximate comparision instead of an exact one. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31833
[Bug c++/29704] [4.1 Regression] ICE: default non-type template argument of pointer-to-member type
--- Comment #6 from brolley at redhat dot com 2007-06-07 15:48 ---
As Andrew Pinski has noted, 4.2.0 rejects the code with a proper error message.
The latest trunk does the same. The change which fixes this is
2006-08-20 Mark Mitchell [EMAIL PROTECTED]
PR c++/28341
* tree.c (cast_valid_in_integral_constant_expression_p): New
function.
* cp-tree.h (tsubst_copy_and_build): Adjust prototype.
* pt.c (tsubst_expr): Add integral_constant_expression_p
parameter.
(fold_non_dependent_expr): Adjust callers of
tsubst_{expr,copy_and_build}.
(tsubst_friend_function): Likewise.
(tsubst_template_arg): Likewise.
(tsubst_default_argument): Likewise.
(tsubst_decl): Likewise.
(tsubst): Likewise.
(tsubst_omp_clasuses): Likewise.
(regenerate_decl_fromp_template): Likewise.
(instantiate_decl): Likewise.
(tsubst_initializer_list): Likewise.
(tsubst_enum): Likewise.
(tsubst_expr): Use RECUR throughout.
(tsubst_copy_and_build): Change definition of RECUR. Do not allow
invalid casts in integral constant expressions.
I'm attaching a patch for gcc-4_1_branch which brings in this change.
--
brolley at redhat dot com changed:
What|Removed |Added
CC||brolley at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29704
[Bug c++/29704] [4.1 Regression] ICE: default non-type template argument of pointer-to-member type
--- Comment #7 from brolley at redhat dot com 2007-06-07 15:49 --- Created an attachment (id=13665) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13665action=view) Proposed Patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29704
[Bug java/32247] New: -Wall enables -Wunused enables -Wunused-parameter
The latest java compiler (well in Fedora 7) enables -Wunused as part of -Wall. Is this such a good idea as this leads to -Wunused-parameter (a relatively common thing in O-O), -- Summary: -Wall enables -Wunused enables -Wunused-parameter Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cagney at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32247
[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
--- Comment #7 from sje at gcc dot gnu dot org 2007-06-07 16:46 --- Subject: Bug 31850 Author: sje Date: Thu Jun 7 16:46:26 2007 New Revision: 125532 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125532 Log: PR target/31850 * rtl.h (push_to_sequence2): New. * emit-rtl.c (push_to_sequence2): New. * function.c (assign_parm_data_all): Add new fields. (assign_parm_setup_block): Call push_to_sequence2 instead of push_to_sequence. (assign_parm_setup_reg): Ditto. (assign_parm_setup_stack): Ditto. (assign_parms_unsplit_complex): Ditto. (assign_parms): Change field name. Modified: trunk/gcc/ChangeLog trunk/gcc/emit-rtl.c trunk/gcc/function.c trunk/gcc/rtl.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
[Bug testsuite/31828] FAIL: gcc.dg/float-range-[3-5].c (test for excess errors)
--- Comment #2 from sje at cup dot hp dot com 2007-06-07 17:29 --- This is fixed on HP-UX 11.* systems but is still an issue on HP-UX 10.* systems. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com GCC build triplet|hppa64-hp-hpux11.11 |hppa64-hp-hpux10* GCC host triplet|hppa64-hp-hpux11.11 |hppa64-hp-hpux10* GCC target triplet|hppa64-hp-hpux11.11 |hppa64-hp-hpux10* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31828
[Bug tree-optimization/32087] ICE with FORTRAN and -fprefetch-loop-arrays
--- Comment #2 from sje at cup dot hp dot com 2007-06-07 17:49 --- I don't think this defect is related to PR 32716. This problem only occurs when the array size of X is 1. I posted a patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00357.html and tried to address Richard Guenther's question in a follow-up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32087
[Bug tree-optimization/32224] [4.3 Regression] ICE in vect_analyze_operations, at tree-vect-analyze.c:374
--- Comment #4 from dorit at il dot ibm dot com 2007-06-07 18:40 ---
You're right. I'm testing this obvious patch:
Index: tree-vect-analyze.c
===
*** tree-vect-analyze.c (revision 125526)
--- tree-vect-analyze.c (working copy)
*** vect_determine_vectorization_factor (loo
*** 173,181
print_generic_expr (vect_dump, stmt, TDF_SLIM);
}
- if (TREE_CODE (stmt) != GIMPLE_MODIFY_STMT)
- continue;
-
gcc_assert (stmt_info);
/* skip stmts which do not need to be vectorized. */
--- 173,178
*** vect_determine_vectorization_factor (loo
*** 187,192
--- 184,199
continue;
}
+ if (TREE_CODE (stmt) != GIMPLE_MODIFY_STMT)
+ {
+ if (vect_print_dump_info (REPORT_UNVECTORIZED_LOOPS))
+ {
+ fprintf (vect_dump, not vectorized: irregular stmt.);
+ print_generic_expr (vect_dump, stmt, TDF_SLIM);
+ }
+ return false;
+ }
+
if (!GIMPLE_STMT_P (stmt)
VECTOR_MODE_P (TYPE_MODE (TREE_TYPE (stmt
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32224
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #110 from jv244 at cam dot ac dot uk 2007-06-07 19:26 --- After commenting the code leading to PR 32242 compilation leads to the following ICE: /scratch/vondele/clean/cp2k/src/../src/pw_types.F: In function pw_integral_a2b: /scratch/vondele/clean/cp2k/src/../src/pw_types.F:3820: warning: Function return value not set /scratch/vondele/clean/cp2k/src/../src/pw_types.F: In function fft_wrap_pw1pw2: /scratch/vondele/clean/cp2k/src/../src/pw_types.F:2647: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3877 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/32248] New: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3877
another ICE derived from CP2K (PR 29975) gfortran testcase.cell_types.f90 testcase.cell_types.f90: In function pbc3: testcase.cell_types.f90:22: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3877 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED]:/scratch/vondele/tmp cat testcase.cell_types.f90 MODULE cell_types INTEGER, PARAMETER :: dp=KIND(0.0D0) TYPE cell_type !FM to rm REAL(KIND = dp):: unit_of_length REAL(KIND = dp):: subcells !FM should stay LOGICAL:: orthorhombic REAL(KIND = dp), DIMENSION(3,3) :: hmat,h_inv END TYPE cell_type CONTAINS FUNCTION pbc3(ra,rb,cell) RESULT(rab_pbc) REAL(KIND=dp), DIMENSION(3), INTENT(IN) :: ra, rb REAL(KIND=dp), DIMENSION(3) :: rab_pbc INTEGER :: icell, jcell, kcell REAL(KIND=dp):: rab2, rab2_pbc REAL(KIND=dp), DIMENSION(3) :: r, ra_pbc, rab, rb_image, rb_pbc, s2r rb_pbc(:) = pbc(rb(:),cell) rab2_pbc = HUGE(1.0_dp) DO icell=-periodic(1),periodic(1) DO jcell=-periodic(2),periodic(2) DO kcell=-periodic(3),periodic(3) r = REAL((/icell,jcell,kcell/),dp) END DO END DO END DO END FUNCTION pbc3 END MODULE -- Summary: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3877 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32248
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #111 from jv244 at cam dot ac dot uk 2007-06-07 19:36 --- (In reply to comment #110) /scratch/vondele/clean/cp2k/src/../src/pw_types.F:2647: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3877 filed as PR 32248 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/32248] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3877
--- Comment #1 from jv244 at cam dot ac dot uk 2007-06-07 19:38 --- This triggers in many places in CP2K, so, for once, I'll mark it as critical -- jv244 at cam dot ac dot uk changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32248
[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of
--- Comment #8 from laurent at guerby dot net 2007-06-07 19:43 --- Here is a test case that's likely to fail: I just allocate a non zero filled record of the right size before filling the map. Expects no output, but will raise program_error because of the bug (with 4.3.0 20070606 on x86_64-linux). $ gnatmake -g p; ./p gcc -c -g p.adb gnatbind -x p.ali gnatlink p.ali -g raised PROGRAM_ERROR : p.adb:27 explicit raise $ cat p.adb with Ada.Unchecked_Deallocation; with Ada.Containers.Hashed_Maps; procedure P is function H (I : Integer) return Ada.Containers.Hash_Type is begin return Ada.Containers.Hash_Type'Mod (I); end; type Item_Pointer is access Boolean; type R is record X,Y,Z : Integer := 5; end record; type R_Ptr is access R; RR : R_Ptr := new R; procedure Free is new Ada.Unchecked_Deallocation (R, R_Ptr); package M is new Ada.Containers.Hashed_Maps (Integer, Item_Pointer, H, =); Z : M.Map; Position : M.Cursor; Inserted : Boolean; Item : Item_Pointer; begin Free (RR); M.Insert (Z, 2, Position, Inserted); -- default initialization for new item Item := M.Element (Position); if Item /= null then -- Item contains a random value here raise Program_Error; end if; end; -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-06-07 19:43:14 date|| Summary|Default pointer |[Ada] Default pointer |initialization not occuring |initialization not occuring |- due to the use of |- due to the use of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug c++/30759] [4.1/4.2/4.3 Regression] initializer-list accepted for object of non-POD type
--- Comment #3 from simartin at gcc dot gnu dot org 2007-06-07 19:59 --- Subject: Bug 30759 Author: simartin Date: Thu Jun 7 19:59:33 2007 New Revision: 125539 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125539 Log: gcc/ 2007-06-07 Simon Martin [EMAIL PROTECTED] PR c++/30759 * c-common.h (flag_cpp0x): Replaced by... (cxx_dialect): ... this new variable specifying the C++ dialect that is used. * c-common.c (flag_cpp0x): Removed. (cxx_dialect): Defined. * c-cppbuiltin.c (c_cpp_builtins): flag_cpp0x rewritten in terms of cxx_dialect. * c-opts.c (c_common_post_options): Likewise. (set_std_cxx98): Set cxx_dialect to cxx98. (set_std_cxx0x): Set cxx_dialect to cxx0x. gcc/cp/ 2007-06-07 Simon Martin [EMAIL PROTECTED] PR c++/30759 * decl.c (check_initializer): Report an error when a brace enclosed initializer is used for a non-aggregate type in C++98. (redeclaration_error_message): Rewrote flag_cpp0x in terms of cxx_dialect. (grokdeclarator): Likewise. (move_fn_p): Likewise. * typeck.c (check_return_expr): Likewise. * call.c (reference_binding): Likewise. * error.c (cp_cpp_error): Likewise. * pt.c (check_default_tmpl_args): Likewise. (tsubst): Likewise. * lex.c (init_reswords): Likewise. * parser.c (p_parser_primary_expression): Likewise. (TOKEN_PRECEDENCE): Likewise. (cp_parser_init_declarator): Likewise. (cp_parser_ptr_operator): Likewise. (cp_parser_parameter_declaration): Likewise. (cp_parser_enclosed_template_argument_list): Likewise. (cp_parser_skip_to_end_of_template_parameter_list): Likewise. (cp_parser_next_token_ends_template_argument_p): Likewise. gcc/testsuite/ 2007-06-07 Simon Martin [EMAIL PROTECTED] PR c++/30759 * g++.dg/init/brace6.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/brace6.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/c-cppbuiltin.c trunk/gcc/c-opts.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl.c trunk/gcc/cp/error.c trunk/gcc/cp/lex.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30759
[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of
--- Comment #9 from baldrick at gcc dot gnu dot org 2007-06-07 20:12 --- Here is a test case that's likely to fail: I just allocate a non zero filled record of the right size before filling the map. Good idea - thanks for doing this! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug java/32249] New: %s substituted with interface/class can't be properly translated
In gcc/java/parse.y there is this code: parse_error_context (cl, Public %s %qs must be defined in a file called %%s.java%, (is_interface ? interface : class), IDENTIFIER_POINTER (qualified_name), IDENTIFIER_POINTER (raw_name)); The strings substituted for the first %s are not available for translation. But as it is written, they are the English words, not the syntactical tokens. So this can not be properly translated. Even if the words were markes for translation in isolation, composing a sentence like this is not in general possible to do for an arbitrary language. It needs to be split into two separate messages -- Summary: %s substituted with interface/class can't be properly translated Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32249
[Bug java/32250] New: %s substituted with interface/array can't be properly translated
In gcc/java/parse.y there is this code: parse_error_context (wfl, Class %qs can't subclass %s %qs, IDENTIFIER_POINTER (DECL_NAME (this_decl)), (CLASS_INTERFACE (TYPE_NAME (super_type)) ? interface : array), IDENTIFIER_POINTER (DECL_NAME (super_decl))); The strings substituted for the %s are not available for translation. So this can not be properly translated. Even if the words were markes for translation in isolation, composing a sentence like this is not in general possible to do for an arbitrary language. It needs to be split into two separate messages. -- Summary: %s substituted with interface/array can't be properly translated Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32250
[Bug rtl-optimization/29589] incorrect conversion of (ior (ashiftrt (plus ...))) in combine.c
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-07 21:00 ---
And here is a testcase which makes this reproduciable on the trunk (on
powerpc-linux):
extern void abort (void);
extern void exit (int);
_Bool a;
int foo ()
{
int b;
int c = a;
c = __builtin_abs(c);
c = c-1;
c = (c) 31;
b = c | 60;
return b;
}
int main(int argc, char **argv)
{
a = 1;
if (foo() != 0x3c)
abort();
exit(0);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target triplet||powerpc-*-*
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2007-06-07 21:00:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29589
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #53 from manu at gcc dot gnu dot org 2007-06-07 21:01 --- Subject: Bug 25241 Author: manu Date: Thu Jun 7 21:01:41 2007 New Revision: 125543 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125543 Log: 2007-06-07 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR testsuite/25241 testsuite/ * gcc.dg/parm-mismatch-1.c: Use dg-message for notes. * gcc.dg/Wfatal.c: Use dg-message for output that is neither a warning nor an error. * gcc.dg/Wfatal-2.c: Likewise. * gcc.dg/Werror-1.c: Likewise. * gcc.dg/Werror-5.c: Likewise. * gcc.dg/Werror-7.c: Likewise. * gcc.dg/Werror-10.c: Likewise. * gcc.dg/Werror-11.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/Werror-1.c trunk/gcc/testsuite/gcc.dg/Werror-10.c trunk/gcc/testsuite/gcc.dg/Werror-11.c trunk/gcc/testsuite/gcc.dg/Werror-5.c trunk/gcc/testsuite/gcc.dg/Werror-7.c trunk/gcc/testsuite/gcc.dg/Wfatal-2.c trunk/gcc/testsuite/gcc.dg/Wfatal.c trunk/gcc/testsuite/gcc.dg/parm-mismatch-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug tree-optimization/30840] [4.3 Regression] ice for legal code with flags -O3 -fno-strict-aliasing
--- Comment #8 from reichelt at gcc dot gnu dot org 2007-06-07 21:52
---
The following simplified testcase still crashes on mainline when compiled
with -O2:
==
struct A
{
int i, *p;
A* a;
void foo()
{
if (p)
p++;
else
{
if (i)
i = 1;
i++;
}
}
A();
};
A::A()
{
int j;
A* q;
while (j)
{
j--;
while (j--)
{
q = this;
a-foo();
a-foo();
}
q-a++;
a-foo();
a-foo();
}
A b;
}
==
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30840
[Bug c++/32251] New: [4.1/4.2/4.3 regression] ICE on delete operator with ellipsis
The following code snippet triggers a segfault since GCC 3.4.0:
===
struct A
{
A();
void operator delete(void*,...);
};
void foo()
{
new A;
}
===
bug.cc: In function 'void foo()':
bug.cc:9: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Before we got an error message:
bug.cc: In function `void foo()':
bug.cc:9: error: no suitable `operator delete' for `A'
I'm not quite sure, but I think the code is valid after all.
--
Summary: [4.1/4.2/4.3 regression] ICE on delete operator with
ellipsis
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32251
[Bug c++/32251] [4.1/4.2/4.3 regression] ICE on delete operator with ellipsis
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32251
[Bug c++/32252] New: [4.3 regression] ICE with variadic templates and arrays
The following (IMHO valid) code snippet triggers an ICE on mainline:
==
int x[5];
templateint M, int N, int (... p)[N] struct A;
templateint M struct AM,5,x {};
A0,5,x a;
==
bug.cc:7: internal compiler error: tree check: accessed elt 2 of tree_vec with
1 elts in tsubst, at cp/pt.c:8528
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with variadic templates and arrays
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32252
[Bug c++/32253] New: [4.3 regression] ICE with variadic templates and function pointers
The following invalid code snippet triggers an ICE on mainline:
==
templatevoid (*... fp)() struct A
{
A() { fp(); }
};
void foo();
Afoo a;
==
bug.cc: In constructor 'Afp::A()':
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'fp'
bug.cc: In constructor 'Afp::A() [with void (* fp)() = foo]':
bug.cc:8: instantiated from here
bug.cc:3: internal compiler error: in gimplify_expr, at gimplify.c:5961
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with variadic templates and
function pointers
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32253
[Bug c++/32253] [4.3 regression] ICE with variadic templates and function pointers
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32253
[Bug c++/32252] [4.3 regression] ICE with variadic templates and arrays
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32252
[Bug fortran/31832] FAIL: gfortran.dg/integer_exponentiation_2.f90 at -O1 and above
--- Comment #1 from sje at cup dot hp dot com 2007-06-07 22:47 --- I have looked into this bug and I think it is an HP math lib bug. The 64 bit powf function is using %fr12R but not saving/restoring it the way it is supposed to. I have a query in to the math lib folks to see if they can verify my finding. Here is a smaller test case that prints different values at -O1 or -O2 than at -O0. program test real a call run_me (-1.1, -1) a = -1.1 end program test subroutine run_me(a, i) implicit none real, intent(in) :: a integer, intent(in) :: i print *, a**-2.0 print *, (1/a)*(1/a) call check_equal_r (a**-2.0, (1/a)*(1/a)) end subroutine run_me subroutine check_equal_r (a, b) real, intent(in) :: a, b print *, a print *, b end subroutine check_equal_r -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31832
[Bug fortran/25252] ICE on invalid code
--- Comment #12 from reichelt at gcc dot gnu dot org 2007-06-07 22:56 --- Although PR18923 is fixed now, this testcase (from comment#7) is still crashing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug c++/32177] g++ crashes on some valid OpenMP code
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-07 23:11 --- Subject: Bug 32177 Author: jakub Date: Thu Jun 7 23:11:23 2007 New Revision: 125544 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125544 Log: PR c++/32177 * semantics.c (finish_omp_for): Call fold_build_cleanup_point_expr on init, the non-decl cond operand and increment value. * g++.dg/gomp/pr32177.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr32177.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32177
[Bug c++/32241] Compiler segmentation fault when trying to call x.~X(); (X x = f();) in a template
--- Comment #2 from fang at csl dot cornell dot edu 2007-06-08 00:03
---
reduced test case:
==
template typename T
class SimpleStack {
public:
T top() { return *ptr; }
void pop() { top.~T(); }
T *ptr;
};
int main(int, char*[]) {
SimpleStackint stack;
stack.pop();
return 0;
}
==
also ICEs 4.0.1 (apple) and 4.2.0.
keyword: ice-on-invalid
known to fail: 4.0.1, 4.2.0
3.3 (apple) gives:
error: destructor name `~int' does not match type `unknown type' of
expression
error: insufficient contextual information to determine type
3.4.6 silently accepts code and compiles.
Note: author probably meant top().~T() :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32241
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #14 from rob1weld at aol dot com 2007-06-08 00:23 --- Here are the test results. I enabled almost every possible option and all the checking that is functional. Nearly every test passed. I diffed it with a result from a few days ago (before the mod), I do not seem to have caused any failures. I now have more accurate math than a normal build. Results for 4.3.0 20070606 (experimental) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00372.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug libgcj/32227] [4.3 Regression] ../gcc/libjava/classpath/include/config-int.h:7:20: error: stdint.h: No such file or directory
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-08 00:31 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32227
[Bug fortran/25252] ICE on invalid code
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-06-08 00:46 --- Yes, it turns out not to be a complete duplicate. I am still working on this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of
--- Comment #10 from anhvofrcaus at gmail dot com 2007-06-08 01:10 --- Thank you both for your explanation to a newbie having no experience with valgrind tool. I have come up with a simpler version which similar to Laurent's. Here it goes. with Ada.Containers.Hashed_Maps; procedure P is function H (I : Integer) return Ada.Containers.Hash_Type is begin return Ada.Containers.Hash_Type'Mod (I); end; type Item_Pointer is access Boolean; package M is new Ada.Containers.Hashed_Maps (Integer, Item_Pointer, H, =); Z : M.Map; Position : M.Cursor; Inserted : Boolean; Item : Item_Pointer; begin M.Insert (Z, 2, Position, Inserted); -- default initialization for new item Item := M.Element (Position); if not Item.all'Valid then -- equivalent to Item /= null if check raise Program_Error with Failing test; end if; end P; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug fortran/32223] Backslash handling inconsistent
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-06-08 04:49 --- Subject: Bug 32223 Author: jvdelisle Date: Fri Jun 8 04:49:23 2007 New Revision: 125557 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125557 Log: 2007-06-07 Steven G. Kargl [EMAIL PROTECTED] Jerry DeLisle [EMAIL PROTECTED] PR fortran/32223 * match.c (gfc_match_special_char): New function. Match special char. Add handling '\0'. * match.h: Add prototype. * io.c (next_char): Use it. * primary.c (next_string_char): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/fortran/match.c trunk/gcc/fortran/match.h trunk/gcc/fortran/primary.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32223
[Bug fortran/32242] [4.3 Regression] nternal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:386
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-08 04:59 --- I believe that this is also caused by r125316. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32242
[Bug fortran/32238] [4.3 Regression] ICE in gfc_conv_constant (where() with complex arrays)
--- Comment #2 from pault at gcc dot gnu dot org 2007-06-08 04:57 --- This, in fact, worked fine up until GNU Fortran (GCC) 4.3.0 20070602. Since there were only three fortran patches in that time, I reverted each of them and found that the culprit is r125316. 2007-06-04 Lee Millward [EMAIL PROTECTED] FX, you committed this; can you fix or remove, please? Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32238
[Bug fortran/32223] Backslash handling inconsistent
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-06-08 05:32 --- Fixed, not a regression, no backport -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32223
[Bug target/32163] Compiling with stack protector causes reigster spill failure
--- Comment #6 from kkojima at gcc dot gnu dot org 2007-06-08 05:54 --- Subject: Bug 32163 Author: kkojima Date: Fri Jun 8 05:53:57 2007 New Revision: 125558 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125558 Log: PR target/32163 Backport from mainline. * config/sh/sh.md (symGOT_load): Don't schedule insns when the symbol is generated with the stack protector. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/sh/sh.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
[Bug target/32163] Compiling with stack protector causes reigster spill failure
--- Comment #7 from kkojima at gcc dot gnu dot org 2007-06-08 05:56 --- Subject: Bug 32163 Author: kkojima Date: Fri Jun 8 05:56:28 2007 New Revision: 125559 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125559 Log: PR target/32163 Backport from mainline. * config/sh/sh.md (symGOT_load): Don't schedule insns when the symbol is generated with the stack protector. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/sh/sh.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
[Bug target/32163] Compiling with stack protector causes reigster spill failure
--- Comment #8 from kkojima at gcc dot gnu dot org 2007-06-08 05:58 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
