[Bug c/53163] New: crash due to null ptr deref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53163
Bug #: 53163
Summary: crash due to null ptr deref
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
[regehr@dyson r43]$ current-gcc -c -O3 small.c
small.c: In function 'fn2':
small.c:22:1: internal compiler error: Segmentation fault
fn2 ()
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[regehr@dyson r43]$ cat small.c
struct
{
int f0;
} b, f;
int a, c;
void
fn1 ()
{
int d, e;
d = 4;
for (; d < 19; ++d)
{
e = 2;
for (; e >= 0; e--)
{
a = 0;
a = 1;
}
}
}
void
fn2 ()
{
int g, h, i;
i = 1;
for (; i >= 0; i--)
{
b = f;
g = 0;
for (; g <= 1; g++)
{
if (c)
break;
h = 0;
for (; h <= 1; h++)
fn1 ();
fn1 ();
}
}
}
[regehr@dyson r43]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r186946-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.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-r186946-install
--program-prefix=r186946- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120429 (experimental) (GCC)
[Bug middle-end/53161] [4.8 Regression] ICE with weakref function and a function which takes vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53161
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-04-30
Target Milestone|--- |4.8.0
Summary|index domain error, in |[4.8 Regression] ICE with
|ipa_remove_reference at |weakref function and a
|ipa-ref.c:84|function which takes vector
||types
Ever Confirmed|0 |1
--- Comment #3 from Andrew Pinski 2012-04-30
04:14:31 UTC ---
Here is a reduced testcase:
extern int gg (int *__once_control);
static __typeof(gg) __gthrw_gg __attribute__ ((__weakref__("gg")));
typedef float v4sf __attribute__ ((__vector_size__ (16)));
extern v4sf f (float __F);
void g(v4sf,v4sf);
void h(float m_MinValue) {
g(f(1), f(1.0f/2.2f));
}
--- CUT ---
Confirmed.
[Bug rtl-optimization/38412] asm-declared register misnamed when feeding asm, "almost" misallocated.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38412 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.3.3 |4.4.7 Resolution||FIXED --- Comment #2 from Hans-Peter Nilsson 2012-04-30 03:07:40 UTC --- This is fixed at least on the 4.4-branch and later branches including trunk, so closing.
[Bug regression/53149] [4.8 Regression]: gcc.dg/20011021-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53149 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Hans-Peter Nilsson 2012-04-30 02:52:51 UTC --- (In reply to comment #3) > Hi Hans-Peter, could you try with the latest revision? I believe this is > fixed. Confirmed; my autotester picked it up. Closing.
[Bug testsuite/53028] add dg-pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028
--- Comment #11 from Mike Stump 2012-04-30
01:08:24 UTC ---
>> also don't test that the warning goes away with -w. We don't test the
>> warning
>> turns into an error with -Werror.
>
> Don't we?
>
> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01778.html
Two comments. First, this, at most can test just one case, I mean, we don't
test all cases. Second, I don't see -Werror anywhere. I don't see -w
anywhere. Maybe I missed how these test these two options...
> Perhaps we can devise an indirect
> way to test that a warning is enabled by a certain option. We could have
> { dg-warning-with-option "Wlong-long" "ISO C90 does not support 'long long'"
> },
> which will match the option shown with -fdiagnostics-show-option. Can we at
> least have this?
I like the idea that we have a way to write one test case instead of three...
I certainly won't object.
> Fair enough. But the duplicated testcases are still being added!
I'd rather error on the side of letting the FE people do what they want.
[Bug c++/53162] New: unexpanded parameter packs not diagnosed in alias template used in default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53162
Bug #: 53162
Summary: unexpanded parameter packs not diagnosed in alias
template used in default argument
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
template
struct bool_constant
{
static const bool value = B;
};
template struct enable_if { };
template<> struct enable_if { typedef void type; };
template
struct F
{
template
using SameSize = bool_constant;
template>
F(int, B...) { }
template::value>::type>
F(char, B...) { }
};
int main()
{
F f1(1, 2, 3);
F f2('1', 2, 3);
}
$ g++ -std=c++11 t.cc
t.cc: In instantiation of ‘struct F’:
t.cc:27:17: required from here
t.cc:22:3: error: no type named ‘type’ in ‘struct enable_if’
F(char, B...) { }
^
The declaration of f1 should be rejected because the F(int, B...) constructor's
default template argument refers to the parameter pack B without expanding it,
but there is no error.
The declaration of f1 is rejected but with an unhelpful diagnostic, if the
problem was that there's no 'type' in enable_if then it should result in a
substitution failure not an error. The actual problem is that B is not expanded
in SameSize, so the error should say so.
[Bug middle-end/41969] [LTO] 23% slow-down with -flto -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41969 --- Comment #7 from Jan Hubicka 2012-04-30 00:39:08 UTC --- It doesn't help to attach this into a closed bugreport. LTO allows GCC to do a lot more transformations and sometime the transformations hurts the final performance. This is a bug and we will try to fix it. >From information you gave it is however impossible to guess what may possibly go wrong. If you provide some more analysis about why your program gets slower and attach it into a (new) PR, we will try to take a look. Honza
Re: [Bug middle-end/41969] [LTO] 23% slow-down with -flto -fwhole-program
It doesn't help to attach this into a closed bugreport. LTO allows GCC to do a lot more transformations and sometime the transformations hurts the final performance. This is a bug and we will try to fix it. >From information you gave it is however impossible to guess what may possibly >go wrong. If you provide some more analysis about why your program gets slower and attach it into a (new) PR, we will try to take a look. Honza
[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #31 from Paolo Carlini 2012-04-29 23:38:45 UTC --- Completely fixed in mainline.
[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795 --- Comment #30 from paolo at gcc dot gnu.org 2012-04-29 23:36:15 UTC --- Author: paolo Date: Sun Apr 29 23:36:09 2012 New Revision: 186948 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186948 Log: 2012-04-29 Marc Glisse Paolo Carlini PR libstdc++/51795 * include/bits/stl_algobase.h (__lg<>(_Size)): Remove. (__lg(int), __lg(unsigned), __lg(long), __lg(unsigned long), __lg(long long), __lg(unsigned long long)): Define constexpr. * include/bits/random.h (_Mod<>): Overcome Schrage's algorithm limitations. (__mod): Adjust. (linear_congruential): Remove FIXME static_assert. * include/bits/random.tcc (_Mod<>): Adjust. * testsuite/26_numerics/random/linear_congruential_engine/operators/ 51795.cc: New. Added: trunk/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/operators/51795.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/include/bits/random.tcc trunk/libstdc++-v3/include/bits/stl_algobase.h
[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org Target Milestone|--- |4.7.1 Summary|glibc long double math |[4.7 regression] glibc long |tests fail on sparc 64-bit |double math tests fail on ||sparc 64-bit --- Comment #2 from Eric Botcazou 2012-04-29 22:09:24 UTC --- > This is distilled from glibc's math/libm-test.inc:compare_float_internal() > when > built for long double. > > The problem is that, with -ffloat-store, the compiler eliminates the stores > into the stack that setup the stack slots for the arguments passed into > _Qp_div(). Using -ffloat-store is a little strange on the SPARC, but the bug is nevertheless quite annoying. Is it the improved RTL DSE pass?
[Bug c++/51625] -Wconversion should be on by default, or at least included in -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51625 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez 2012-04-29 21:56:23 UTC --- (In reply to comment #4) > I run into this problem today too. Why gcc do not warning by default when we > assign a double to a int? This is even not warned by Wall and Wextra. If you > google the internet, you will find there are many users asking this question. So, what do you think should happen in this case? double d = 1.0; int i; i = d; Should we warn? > > This tied with the fact that there is no data-flow in front-ends (see next > > question) results in hard to avoid warnings for perfectly working and valid > > code. > > This is not convincing for me. Since I think you should do these conversion > explicitly to tell others you know what you are doing. -Wconversion warns for a lot of things that are perfectly ok. If you compile any large project with it (like the Linux kernel), there are lots of invalid warnings. Moreover, there are cases where it is difficult to avoid the warning. See PR 39170. > I hope that there is a day that the developer can change their mind on this > question:) If the accuracy of Wconversion improves enough... One prerequisite is to find a fix for PR 39170. Another would be to find a way to avoid warning for the case above. There are more PRs related to Wconversion. You can help to fix them. Please, see: http://gcc.gnu.org/contribute.html
[Bug target/52684] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 --- Comment #1 from davem at gcc dot gnu.org 2012-04-29 20:48:49 UTC --- Created attachment 27263 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27263 Testcase distilled from glibc's math/libm-test.inc compare_float_internal() This is distilled from glibc's math/libm-test.inc:compare_float_internal() when built for long double. The problem is that, with -ffloat-store, the compiler eliminates the stores into the stack that setup the stack slots for the arguments passed into _Qp_div().
[Bug middle-end/53161] index domain error, in ipa_remove_reference at ipa-ref.c:84
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53161 --- Comment #2 from Andrew Pinski 2012-04-29 20:23:59 UTC --- Reducing ...
[Bug c++/53161] index domain error, in ipa_remove_reference at ipa-ref.c:84
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53161 --- Comment #1 from dcb 2012-04-29 20:15:53 UTC --- Created attachment 27262 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27262 gzipped C++ source code
[Bug c++/53161] New: index domain error, in ipa_remove_reference at ipa-ref.c:84
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53161 Bug #: 53161 Summary: index domain error, in ipa_remove_reference at ipa-ref.c:84 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com I just tried to compile the package luminance-hdr-2.2.1-3 on gcc-4.8 trunk dated 20120429 on an AMD x86_64 box. The compiler said /home/dcb/rpmbuild/BUILD/luminance-hdr-2.2.1/src/Viewers/HdrViewer.cpp:412:1: internal compiler error: vector VEC(ipa_ref_ptr,base) index domain error, in ipa_remove_reference at ipa-ref.c:84 } ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. No special flags required.
[Bug rtl-optimization/53160] [4.8 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53160 Andrew Pinski changed: What|Removed |Added Target||x86_64-*-* i?86-*-* Component|c |rtl-optimization Target Milestone|--- |4.8.0 Summary|likely wrong code bug |[4.8 Regression] likely ||wrong code bug --- Comment #1 from Andrew Pinski 2012-04-29 20:01:37 UTC --- It works correctly on mips64-linux-gnu but fails on x86_64-linux-gnu. The tree level looks exactly the same on both targets
[Bug c/53160] New: likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53160
Bug #: 53160
Summary: likely wrong code bug
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
regehr@regehr-System-Product-Name:~$ current-gcc -O1 small.c ; ./a.out
0
regehr@regehr-System-Product-Name:~$ current-gcc -O2 small.c ; ./a.out
1466236928
regehr@regehr-System-Product-Name:~$ cat small.c
int printf (const char *, ...);
int a, c = 1, d, e, g;
volatile int b;
volatile char f;
long h;
short i;
void
fn1 (p1)
{
e = 0;
for (; e; ++e)
;
}
int
main ()
{
fn1 (g && b);
d = 0;
for (; d >= 0; d--)
{
short j = f;
int k = 0;
i = j ? j : j << k;
}
h = c == 0 ? 0 : i;
a = h;
printf ("%d\n", a);
return 0;
}
regehr@regehr-System-Product-Name:~$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r186920-install/libexec/gcc/x86_64-unknown-linux-gnu/4.8.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-r186920-install
--program-prefix=r186920- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120427 (experimental) (GCC)
[Bug middle-end/41969] [LTO] 23% slow-down with -flto -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41969 travnick changed: What|Removed |Added CC||mikolajmm at gmail dot com --- Comment #6 from travnick 2012-04-29 18:48:49 UTC --- I have the same issue with flags: -fwhole-program -ftlo (-flto: eaven slower, faster (this result) for me: -flto=2) -fuse-linker-plugin In my project: https://github.com/travnick/GKiO-Projekt-GK after applying this flags, default scene renders in 30-32s on my machine. Without them it takes only 19-22 s so this flags make my project slower by 50%. gcc version 4.7.0 20120414 (prerelease) (GCC) Linux 3.3-pf #2 SMP PREEMPT Sat Apr 28 02:09:06 EEST 2012 x86_64 Intel(R) Core(TM)2 Duo CPU T6600 @ 2.20GHz GenuineIntel GNU/Linux
[Bug debug/53145] [4.8 Regression] gcc.dg/pch/save-temps-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53145
--- Comment #2 from H.J. Lu 2012-04-29 16:29:27
UTC ---
/* Return a heap allocated producer string including command line options
if -grecord-gcc-switches. */
static char *
gen_producer_string (void)
{
size_t j;
VEC(dchar_p, heap) *switches = NULL;
const char *language_string = lang_hooks.name;
char *producer, *tail;
const char *p;
size_t len = dwarf_record_gcc_switches ? 0 : 3;
size_t plen = strlen (language_string) + 1 + strlen (version_string);
for (j = 1; dwarf_record_gcc_switches && j < save_decoded_options_count; j++)
Will heap allocation affect PCH? Should we add -gno-record-gcc-switches
to gcc.dg/pch/save-temps-1.c?
[Bug debug/53145] [4.8 Regression] gcc.dg/pch/save-temps-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53145 --- Comment #1 from H.J. Lu 2012-04-29 16:23:05 UTC --- This fixes the regression. But I don't see why it should make a difference. diff --git a/gcc/common.opt b/gcc/common.opt index 14c88bf..cd760fc 100644 --- a/gcc/common.opt +++ b/gcc/common.opt @@ -2237,7 +2237,7 @@ Common JoinedOrMissing Generate debug information in default extended format gno-record-gcc-switches -Common RejectNegative Var(dwarf_record_gcc_switches,0) Init(1) +Common RejectNegative Var(dwarf_record_gcc_switches,0) Init(0) Don't record gcc command line switches in DWARF DW_AT_producer. grecord-gcc-switches
[Bug c++/53157] within lambda, error: lvalue required as unary ‘&’ operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53157 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-29 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2012-04-29 14:41:12 UTC --- (In reply to comment #0) > (1) for the call to f(&N); : error: lvalue required as unary ‘&’ operand This error is wrong, so confirmed. > (2) at the end of the lambda : error: expected ‘;’ before ‘}’ token This error is correct, the example is wrong. I've asked the C++ project editor to fix the working draft: https://github.com/cplusplus/draft/pull/12
[Bug c++/51312] [C++0x] Wrong interpretation of converted constant expressions (for enumerator initializers)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312
--- Comment #5 from Marc Glisse 2012-04-29
14:12:12 UTC ---
Created attachment 27261
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27261
build_enumerator patch
Changes the behavior on g++.dg/cpp0x/enum_base.C from an error to a warning in
the first 2 cases. And reusing the narrowing warning message may look a bit
strange.
enum E4 : char {
val = 500 // { dg-error "too large" }
};
enum_base.C:9:9: warning: narrowing conversion of '500' from 'int' to 'char'
inside { } [-Wnarrowing]
val = 500 // { dg-error "too large" }
^
enum_base.C:9:9: warning: overflow in implicit constant conversion [-Woverflow]
val = 500 // { dg-error "too large" }
^
[Bug middle-end/53089] [4.8 Regression] gfortran.dg/coarray/atomic_1.f90 and gfortran.dg/coarray/registering_1.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53089 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from H.J. Lu 2012-04-29 14:07:33 UTC --- Fixed.
[Bug c++/53159] New: Missing narrowing check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53159
Bug #: 53159
Summary: Missing narrowing check
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
In this example, I get narrowing warnings for a and b but not c.
struct X
{
constexpr operator int() { return __INT_MAX__; }
};
int f(){ return __INT_MAX__; }
signed char a { __INT_MAX__ };
signed char b { f() };
signed char c { X{} };
[Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891 --- Comment #6 from Marc Glisse 2012-04-29 13:15:40 UTC --- I don't think it matters that much whether the return type is int or bool, compared to the inconvenience of having 2 functions that conflict. The constexpr qualifier is nice, but not required by the standard, and not even by gcc which recognizes that extern "C" int isnan(double) is a builtin (note that it doesn't recognize it anymore if you change the return type to bool, that should be fixed). For the same reason (recognized as a builtin), there is no performance advantage to having it inline. So I think: * glibc could change the return type of isnan to bool in C++ (there would be a regression in that ::isnan wouldn't be constexpr and inline until g++ is taught the right prototype) * libstdc++ could import ::isnan in std::, assuming isnan exists. Maybe that requires a configure test. Maybe that test would be rather fragile (depends on feature macros). Maybe that's where this stops being a good idea :-(
[Bug c++/51625] -Wconversion should be on by default, or at least included in -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51625 Yichao Zhou changed: What|Removed |Added CC||broken.zhou at gmail dot ||com --- Comment #4 from Yichao Zhou 2012-04-29 12:16:54 UTC --- I run into this problem today too. Why gcc do not warning by default when we assign a double to a int? This is even not warned by Wall and Wextra. If you google the internet, you will find there are many users asking this question. > This tied with the fact that there is no data-flow in front-ends (see next > question) results in hard to avoid warnings for perfectly working and valid > code. This is not convincing for me. Since I think you should do these conversion explicitly to tell others you know what you are doing. I hope that there is a day that the developer can change their mind on this question:)
[Bug regression/53149] [4.8 Regression]: gcc.dg/20011021-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53149 --- Comment #3 from Manuel López-Ibáñez 2012-04-29 10:01:41 UTC --- Hi Hans-Peter, could you try with the latest revision? I believe this is fixed.
[Bug regression/53149] [4.8 Regression]: gcc.dg/20011021-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53149 --- Comment #2 from Manuel López-Ibáñez 2012-04-29 09:47:47 UTC --- Author: manu Date: Sun Apr 29 09:47:43 2012 New Revision: 186945 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186945 Log: 2012-04-29 Manuel López-Ibáñez PR 53149 * gcc.dg/20011021-1.c: Adjust testcase. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/20011021-1.c
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200 --- Comment #42 from paolo at gcc dot gnu.org 2012-04-29 09:25:24 UTC --- Author: paolo Date: Sun Apr 29 09:25:17 2012 New Revision: 186944 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186944 Log: 2012-04-29 Marc Glisse PR libstdc++/22200 * include/std/limits (numeric_limits<>::is_modulo): False for signed types. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/limits
[Bug middle-end/53100] Optimize __int128 with range information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100 --- Comment #2 from Marc Glisse 2012-04-29 08:42:36 UTC --- (In reply to comment #1) > On the other hand, tree-vrp does have the information that the > differences are in [-4294967295, 4294967295], which comfortably fits in a type > half the size of __int128. It seems a possible strategy would be to have > tree-vrp mark variables that fit in a type half their size (only for TImode?), > try and preserve that information along the way, and finally use it in > expand_doubleword_mult. An other possibility would be, when the range analysis detects this situation, to have it introduce a double-cast: (__int128)(long)var. In the example here, it would give: ((__int128)(long)((__int128)c-(__int128)a))*((__int128)(long)((__int128)f-(__int128)b)) and existing optimizations already handle: (long)((__int128)c-(__int128)a) as (long)c-(long)a and (__int128)mylong1*(__int128)mylong2 as a widening multiplication. But then we'd have to be careful not to introduce too many such casts, not to introduce them too late, and not to introduce them just before an optimization that removes them. And find the appropriate half-sized type to cast to. And possibly do this only for modes not handled natively.
[Bug bootstrap/53112] Fails at Configuring stage 1 in sparc64-sun-solaris2.10/libgcc: error: cannot compute suffix of object files: cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53112 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-04-29 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-04-29 08:37:09 UTC --- > checking for suffix of object files... configure: error: in > `/els/install/biru/gcc4_64/obj/sparc64-sun-solaris2.10/libgcc': > configure: error: cannot compute suffix of object files: cannot compile > See `config.log' for more details. > make[2]: *** [configure-stage1-target-libgcc] Error 1 > make[2]: Leaving directory `/els/install/biru/gcc4_64/obj' > make[1]: *** [stage1-bubble] Error 2 > make[1]: Leaving directory `/els/install/biru/gcc4_64/obj' > make: *** [all] Error 2 > bash-3.00# > > > Kindly please provide the solution for the above error. Follow the above instructions and look into the config.log file.
[Bug middle-end/53100] Optimize __int128 with range information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100 --- Comment #1 from Marc Glisse 2012-04-29 08:05:59 UTC --- (In reply to comment #0) > It would be convenient if I > could just write the whole code with __int128 and let the compiler do the > optimization by tracking the range of numbers. The transformation from an __int128 to a pair of long happens extremely late (optabs.c), so we can't count on tree-vrp to notice that one of them is always zero (and actually it is either 0 or -1, as a sign extension, which would make this hard). On the other hand, tree-vrp does have the information that the differences are in [-4294967295, 4294967295], which comfortably fits in a type half the size of __int128. It seems a possible strategy would be to have tree-vrp mark variables that fit in a type half their size (only for TImode?), try and preserve that information along the way, and finally use it in expand_doubleword_mult. But that seems to imply storing the information in an rtx, and rtx seems a bit too densely packed to add this. Better ideas?
[Bug fortran/53148] [4.7/4.8 Regression] Incorrect intrinsic function parsing on labeled statements when compiled w/ -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53148 --- Comment #3 from Thomas Koenig 2012-04-29 07:12:10 UTC --- Author: tkoenig Date: Sun Apr 29 07:12:03 2012 New Revision: 186942 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186942 Log: 2012-04-29 Thomas Koenig PR fortran/53148 * frontend-passes.c (create_var): If the statement has a label, put the label around the block. 2012-04-29 Thomas Koenig PR fortran/53148 * gfortran.dg/function_optimize_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/function_optimize_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug target/53156] [4.8 Regression]: gcc.target/cris/peep2-andu2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53156 Hans-Peter Nilsson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Hans-Peter Nilsson 2012-04-29 07:06:00 UTC --- fixed.
[Bug fortran/53148] [4.7/4.8 Regression] Incorrect intrinsic function parsing on labeled statements when compiled w/ -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53148 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | --- Comment #2 from Thomas Koenig 2012-04-29 07:03:25 UTC --- I have a patch.
[Bug target/53156] [4.8 Regression]: gcc.target/cris/peep2-andu2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53156 --- Comment #2 from Hans-Peter Nilsson 2012-04-29 07:00:16 UTC --- Author: hp Date: Sun Apr 29 07:00:01 2012 New Revision: 186941 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186941 Log: PR target/53156 * gcc.target/cris/peep2-andu2.c: Tweak expected assembly code to match current output and cover new peephole2 pattern. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/cris/peep2-andu2.c
