[Bug c/47901] -Wall should not imply -Wformat-zero-length by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-04-23 19:58:15 UTC --- There are plenty of warnings in -Wall that relate to things that are unusual but may be OK in some cases, or where -Wall expects a particular coding style to be used. I think -Wformat-zero-length falls into the category of pointing out something that might be OK but is likely not to be intended. So I think it's fine in -Wall - but if a subset of format checking warnings were enabled by default (as in Ubuntu, for example) then maybe that default subset would not include this one.
[Bug tree-optimization/52907] Underflowing floating point expressions wrongly folded to zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52907 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-04-23 20:02:50 UTC --- On Tue, 10 Apr 2012, rguenth at gcc dot gnu.org wrote: Does real.c even communicate this fact? You can identify underflow from the result of multiplication or division being zero or subnormal (unless an operand is zero or infinite), just as overflow is identified from an infinite result. Information about subnormal results may not be conveniently communicated by real.c, but simply handling zero results here would be enough for the use cases in glibc.
[Bug c/47901] -Wall should not imply -Wformat-zero-length by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-23 20:08:09 UTC --- Well, I don't really see how custom_printf() can produce any damage. It may be an oversight when one actually wanted to print something, but it may be as likely that one didn't want to print something and just trigger some side effect of custom_printf. As an alternative, the warning could suggest to use (%s, ) to silence the warning, no?
[Bug c/47901] -Wall should not imply -Wformat-zero-length by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901 --- Comment #4 from Anders Kaseorg andersk at mit dot edu 2012-04-23 20:10:22 UTC --- Yes, I understand what -Wall is supposed to mean. I don’t have a problem with -Wall warning about ‘if (foo = 3)’ when I probably intended ‘if (foo == 3)’ and I could have written ‘if ((foo = 3))’ if that’s what I really wanted. I don’t have a problem with -Wall warning about ‘printf(hello, world)’ when I probably intended ‘printf(hello %s, world)’ and I could have written ‘printf(hello)’ if that’s what I really wanted. But ‘custom_printf_like_function(foo, )’ is something different. What do you think that line indicates I intended? What coding style do you think -Wall is expecting if I really meant the empty string?
[Bug target/53087] [powerpc] Poor code from cstore expander
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53087
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Summary|Poor code for conversion|[powerpc] Poor code from
|from _Bool to int |cstore expander
--- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2012-04-23
20:12:37 UTC ---
The first time round to rs6000.md:cstoremode4, the insn isn't generated
because code==NE. The second time, some insns are emitted:
Breakpoint 11, emit_store_flag_1 (target=0x0, code=EQ, op0=0xfffb5f092c0,
op1=0xfffb5f60470, mode=DImode, unsignedp=0, normalizep=1, target_mode=QImode)
at ../../trunk/gcc/expmed.c:5363
5363 do_pending_stack_adjust ();
(gdb) next
5364 tem = emit_cstore (target, icode, code, mode, compare_mode,
(gdb)
5366 if (tem)
(gdb) p tem
$67 = (rtx) 0xfffb5f094a0
(gdb) p debug_rtx(tem)
(reg:QI 132)
$68 = void
(gdb) p debug_rtx_list (get_last_insn(), -7)
(insn 15 14 16 (set (reg:CC 134)
(compare:CC (reg:DI 123 [ D.2005 ])
(const_int 0 [0]))) t.c:16 -1
(nil))
(insn 16 15 17 (set (reg:DI 135)
(eq:DI (reg:CC 134)
(const_int 0 [0]))) t.c:16 -1
(nil))
(insn 17 16 18 (set (reg:SI 133)
(subreg:SI (reg:DI 135) 4)) t.c:16 -1
(nil))
(insn 18 17 0 (set (reg:QI 132)
(subreg:QI (reg:SI 133) 3)) t.c:16 -1
(nil))
$69 = void
(gdb) next
5367return tem;
(gdb)
5381}
(gdb)
emit_store_flag (target=0xfffb5f09460, code=NE, op0=0xfffb5f092c0,
op1=0xfffb5f60470, mode=DImode, unsignedp=1, normalizep=1) at
../../trunk/gcc/expmed.c:5578
5578 if (tem != 0)
(gdb) p tem
$70 = (rtx) 0xfffb5f094a0
(gdb) l
5573rtx_cost (trueval, XOR, 1,
5574optimize_insn_for_speed_p ()) == 0)
5575{
5576 tem = emit_store_flag_1 (subtarget, rcode, op0, op1, mode, 0,
5577 normalizep, target_mode);
5578 if (tem != 0)
5579tem = expand_binop (target_mode, xor_optab, tem, trueval,
target,
5580INTVAL (trueval) = 0, OPTAB_WIDEN);
5581}
So the problem is not the _Bool-int conversion but the cstore for
;; D.2013_7 = D.2005_5 != 0;
[Bug target/53087] [powerpc] Poor code from cstore expander
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53087
--- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-04-23
20:13:29 UTC ---
Smaller test case:
_Bool
foo (long unsigned int a)
{
return (((1L a) 217579583UL) != 0);
}
==
.file t.c
.section.toc,aw
.section.text
.align 2
.p2align 4,,15
.globl foo
.section.opd,aw
.align 3
foo:
.quad .L.foo,.TOC.@tocbase,0
.previous
.type foo, @function
.L.foo:
li 10,1
lis 9,0xcf8
sld 3,10,3
ori 9,9,63
and. 10,3,9
mfcr 3
rlwinm 3,3,3,1
xori 3,3,1
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size foo,.-.L.foo
.ident GCC: (GNU) 4.8.0 20120418 (experimental) [trunk revision
186580]
[Bug c++/53094] New: vector literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094
Bug #: 53094
Summary: vector literal
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
Hello,
VECTOR_TYPE should be a literal type in C++11, so we can have for instance:
constexpr __m128i v = { 1, 0 };
constexpr __m128i s = v + v;
Once PR c++/51033 is fixed, ideally, the following would also work:
constexpr long long i = v[1];
constexpr __m128i w = __builtin_shuffle (m, m);
but I guess this can be made in several steps as long as the compiler doesn't
ICE on those.
[Bug middle-end/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53084 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org 2012-04-23 20:14:05 UTC --- This patch fixes issues for noticed for mingw targets on trunk and for 4.7.
[Bug c/47901] -Wall should not imply -Wformat-zero-length by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901 --- Comment #5 from Anders Kaseorg andersk at mit dot edu 2012-04-23 20:22:20 UTC --- I’m not sure (%s, ) is a suitable replacement in general. Maybe this is a far-fetched example, but what the purpose of custom_printf is to shell-quote all its arguments, so that custom_printf(foo, ) writes some_command with no arguments but custom_printf(foo, %s, ) writes some_command '' with a single empty argument? In any event, (%s, ) is certainly different code with a potential runtime cost, and it’s not fair for -Wall to complain about the more straightforward () unless it’s reasonably likely for that code to be hiding some class of bugs. Is it? (Another real-world example from a project I help maintain: https://github.com/barnowl/barnowl/blob/barnowl-1.8.1/keys.c#L337 )
[Bug target/53087] [powerpc] Poor code from cstore expander
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53087 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #5 from David Edelsohn dje at gcc dot gnu.org 2012-04-23 20:23:42 UTC --- XLC produces: addi r0,r0,1 addis r4,r0,3320 slwr0,r0,r3 addi r3,r4,63 andr0,r0,r3 cntlzw r3,r0 addi r0,r3,-32 rlwinm r3,r0,1,31,31 blr
[Bug c++/49152] pretty printer cannot handle iterators and other complex expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #45 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-23 20:27:39 UTC --- (In reply to comment #44) On Sun, 1 Apr 2012, manu at gcc dot gnu.org wrote: moving line-map out of libcpp to create a source-location library has been rejected in the past. I've reviewed my contributions to that discussion http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00658.html and I at least did not reject that move; I wanted the new library not to contain any translatable messages (so it doesn't need another message domain), and I wanted motivation for the patch in terms of modularity and better interfaces being the goal and physical separation into a library simply being a means to that goal, but I did not object to a move as such. Re-reading that very old discussion, and with four years of more experience, I basically agree with everything you and others say there, including the fact that a new library is probably not needed. However, I still think that physical separation, be a directory along-side libcpp or under gcc, helps to clarify module boundaries. Nevertheless, since it turns out I did not need a source-location library to implement the caret, I am not planning to work on that patch. Getting that patch approved is likely going to be a bikesheding exercise of epic proportions. It would be nice if GCC became more modular, but now I don't see that patch making a huge difference.
[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53091 --- Comment #9 from Andreas Schwab sch...@linux-m68k.org 2012-04-23 20:36:10 UTC --- enum constants are not objects, they don't have an address.
[Bug c/53095] New: std=gnu99 atof x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53095
Bug #: 53095
Summary: std=gnu99 atof x86
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joaquinmonl...@gmail.com
Created attachment 27227
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27227
the preprocessed file (*.i*) that triggers the bug
/*
Exact version of GCC: That I know that version 4.3, 4.6 and 4.7 has this bug.
System Type: x86_32, i686, 32BITS Intel architecture. It don't occurs in 64 bit
intel architectures.
Options given when GCC was configured/build: The error happen when you use
-std=gnu99 ¡¡BY DEFAULT :O!! standar or -std=gnu89, but not when you use other
standar like -std=c99
The complete command line that triggers the bug: gcc main.c -o main
The compiler output (error messages, warnings, etc.): None.
the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below): As
attachment
Thank's I love GNU your work a million of thanks.
*/
#include stdio.h
#include stdlib.h
int main(){
char *cadena = -25.9;
//USING A TEMP VARIABLE
double d = atof(cadena) * 10;
short s1 = (short) d;
printf(%d\n,s1); //I GET -259
//WITHOUT A TEMP VARIABLE
short s2 = atof(cadena) * 10;
printf(%d\n,s2); //I GET -258? WTF?
}
[Bug c/47901] -Wall should not imply -Wformat-zero-length by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-04-23 20:49:38 UTC --- -Wall is expecting printf-like functions where empty strings are useless as arguments and might indicate e.g. cruft you hadn't completely cleaned up from your program. Or a style where you have separate specialized functions for such cases (like the style where you carefully use fputs, fputc etc. for cases that can be covered by those functions, instead of using printf universally). There's nothing wrong with using a -Wno- option (or associated pragmas) if the stylistic choices for your program are different from those for -Wall. Wall tries to strike a reasonable balance, but won't be perfect for everyone; it's a good starting point for both enabling further warnings, and disabling other warnings, to taste.
[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53091 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-23 20:50:21 UTC --- (In reply to comment #3) Hey. I attached it as well. I didn't just provide a URL. Yeah, sorry, I wrote my comment before you attached it. (In reply to comment #6) Can rewrite both const int and enum, so I don't really see why enum is permitted but const int isn't, they both offer about the same amount of safety. http://c-faq.com/ansi/constasconst.html Take it up with the C committee, not GCC. (In reply to comment #8) Not that you are likely to care, but the Standard states that enumeration types are of a type that is compatible with an implementation-defined one of the integral types. Enumeration TYPES are compatible with integral TYPES. But enumerators are constant, const-qualified variables are not constants. So. you can rewrite enum values just as easily as you can a const int by taking a pointer to it. And that site claims it behaves like a const int. The site's wrong.
[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53091 --- Comment #11 from bugs at m8y dot org 2012-04-23 21:01:03 UTC --- Yeah, I get the difference now. Ok. Fair. So, I guess clang is just taking the values of the const ints at the time the assignment occurs (0x01 and 0x02) and assigning 0x03. If RIGHT or UP were changed, RIGHTUP would not change. Ok, what gcc is doing *does* make sense I 'spose :)
[Bug c/53095] std=gnu99 atof x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53095 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-23 21:05:38 UTC --- http://gcc.gnu.org/bugs/#nonbugs_general
[Bug c/51712] -Wtype-limits should not trigger for types of implementation-defined signedness
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51712 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-04-23 21:11:33 UTC --- On Tue, 17 Apr 2012, manu at gcc dot gnu.org wrote: Unfortunately, I cannot see any way to know that FOO is a constant that comes from an enum. Joseph, is this possible to do in the C FE? The original types of expressions that came from enums are already tracked for use of -Wc++-compat (checking if C code is compatible with stricter C++ rules for enums). (This is what c-typeck.c:build_external_ref uses the type pointer for: storing the original type of an enum.) So the information is available in at least parts of the C front end.
[Bug c/29467] -ansi -pedantic accepts _Bool without diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29467 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-04-23 21:22:38 UTC --- I'd say it's a quality-of-implementation issue, but it probably would be best to diagnose this. I've added such diagnostics for C11 keywords such as _Noreturn and _Static_assert outside C11 mode when adding support for those keywords, for example.
[Bug c/47901] -Wall should not imply -Wformat-zero-length by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901 --- Comment #7 from Anders Kaseorg andersk at mit dot edu 2012-04-23 21:31:18 UTC --- That’s a _much_ higher-level style decision than assumed by any of the other -Wall warnings (or indeed any other warning switches at all), and a questionable one at that. -Wall should not encourage me to duplicate all my custom printf-like functions just so they can be used with the empty string. I understand that I can turn this warning off, but this bug is about the defaults, and defaults are important.
[Bug testsuite/53028] add dg-pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028 --- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-04-23 21:38:00 UTC --- On Wed, 18 Apr 2012, mikestump at comcast dot net wrote: I don't see much value in this. The primary idea of the gcc testsuite is as a regression suite. For a regression, there is just one bit of code that you're testing, with one set of options. For more than a decade it's been established that the testsuite should verify that features or fixes added work as intended; it's not just testing a particular bug fix, but comprehensively covering the area of a change. If the intended semantics are pedwarn-if-pedantic, that does mean testing what happens in three cases. If it's a matter of differences between standard versions, similarly, testing for each version (and see the discussion referenced in http://gcc.gnu.org/ml/gcc-patches/2000-07/msg00262.html when I started adding such tests). I think features such as dg-pedwarn-if-pedantic or similar would be a useful addition to the testsuite infrastructure.
[Bug target/47197] ICE in gimplify_expr, at gimplify.c:7153 on AltiVec code (vec_dst)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47197 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-04-23 21:46:23 UTC --- On Wed, 18 Apr 2012, wschmidt at gcc dot gnu.org wrote: Joseph, could you please take a look? Or let me know if you think it's not a front end problem. In rs6000-c.c, when you put an argument inside a CALL_EXPR or SAVE_EXPR as part of resolving an AltiVec built-in function, you need to use c_fully_fold because subsequent calls to c_fully_fold won't look inside that expression. In such a case, you can do bool maybe_const = true; if (!c_dialect_cxx ()) expr = c_fully_fold (expr, false, maybe_const); before using the new value of expr (and ignore whatever value maybe_const may have been set to).
[Bug c/29467] -ansi -pedantic accepts _Bool without diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29467 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-23 21:47:30 UTC --- So confirmed.
[Bug c/53095] std=gnu99 atof x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53095 --- Comment #2 from q2p0 JoaquinMonleon at gmail dot com 2012-04-23 22:04:15 UTC --- But if: I use one architecture of 64 bits OR I use the standard -std=99 OR I use a temporal double variable OR I compile other compiler that is not GCC I don't get this error. Ok I acept the response This is the result of rounding. All we know that the nearest representable number for a double (-259.) in a short is (-258). I answering me if you really take a look to the code of main.
[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797 Matt Hargett matt at use dot net changed: What|Removed |Added CC||matt at use dot net --- Comment #3 from Matt Hargett matt at use dot net 2012-04-23 22:19:35 UTC --- Can you please back port this to 4.6 as well? Running into this on Scientific Linux 6.1 on x64 with GCC 4.6 trunk and latest cloog-isl and ppl. Thanks!
[Bug c/53095] std=gnu99 atof x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53095
--- Comment #3 from q2p0 JoaquinMonleon at gmail dot com 2012-04-23 22:53:56
UTC ---
#include iostream
int main()
{
// Error.
double a = 0.5;
double b = 0.01;
std::cout (int)(a / b) std::endl;
// No error.
double c = a/b;
std::cout (int)c std::endl;
return 0;
}
* I compile with other...
Sory, about my last sarcastic expresions, and my bad english.
I take a look to the paper when I have time.
Thanks for improve the GNU compiler GCC.
[Bug c++/53096] New: [c++11] should be possible to default a copy ctor that takes non-const arg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53096
Bug #: 53096
Summary: [c++11] should be possible to default a copy ctor that
takes non-const arg
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eric.nieb...@gmail.com
The following code does not compile:
struct foo
{
foo() = default;
foo(foo ) = default; // ERROR HERE
foo(foo const ) = default;
};
The error is:
error: ‘foo::foo(foo)’ declared to take non-const reference
cannot be defaulted in the class body
This was correct for the FDIS, but is now incorrect given the resolution for
core issue 1333:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1333
The code above should be accepted.
[Bug bootstrap/52878] [4.8 regression] bootstrap failure: MASK_LONG_DOUBLE_128 redefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #16 from Richard Henderson rth at gcc dot gnu.org 2012-04-23 23:20:43 UTC --- (In reply to comment #14) The patch looks hackish, as if there's an artificial distinction between normal masks and extra masks. Why is that? That said, please commit the tested patch as-is, so that we repair the bootstrap breakage. Cleanups to extra can come later.
[Bug c++/53096] [DR 1333] [c++11] should be possible to default a copy ctor that takes non-const arg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53096 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||rejects-valid Last reconfirmed||2012-04-23 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 Summary|[c++11] should be possible |[DR 1333] [c++11] should be |to default a copy ctor that |possible to default a copy |takes non-const arg |ctor that takes non-const ||arg
[Bug bootstrap/52878] [4.8 regression] bootstrap failure: MASK_LONG_DOUBLE_128 redefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878 --- Comment #17 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-04-23 23:32:58 UTC --- Author: hjl Date: Mon Apr 23 23:32:54 2012 New Revision: 186729 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186729 Log: Check if MASK_/TARGET_ macros defined for extra_masks 2012-04-23 H.J. Lu hongjiu...@intel.com PR bootstrap/52878 * opth-gen.awk: Check if MASK_ and TARGET_ macros are defined for extra_masks. Modified: trunk/gcc/ChangeLog trunk/gcc/opth-gen.awk
[Bug testsuite/53028] add dg-pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028
--- Comment #9 from Mike Stump mikestump at comcast dot net 2012-04-24
00:31:35 UTC ---
Since little proof was added to support the assertion that the additional
testing is useful, I can remain skeptical about it, though, the CFE people
certainly are free to require it, what they say goes. I like the idea of
testing new code, just I think it could be over done.
I'll give you an example, I think we all can agree on.
Let's say we add a warning. The code goes in, and a single testcase:
main() {
i = code to produce warning; // warning
}
but, we don't also test:
-pedantic-errors
main() {
i = code to produce warning; // warning
}
even though, it is reasonable. We could, but don't. Why don't we, because it
isn't worth the testing time and the maintenance time. Testing it once, and
assuming that no one will accidentally change the warning is reasonable. We
also don't test that the warning goes away with -w. We don't test the warning
turns into an error with -Werror.
How many times has one of these tests caught someone modifying a pedantic into
a warning? How many times has one of these tests caught someone modifying a
pedantic into an error? How many times did someone modify a pedantic in one of
the two ways because a testcase wasn't present?
Feel free to use your best recollection for the above answers. I can't help
but think the numbers are so low, as to not be worth the cost of the additional
testcases.
[Bug target/53087] [powerpc] Poor code from cstore expander
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53087 --- Comment #6 from David Edelsohn dje at gcc dot gnu.org 2012-04-24 00:40:28 UTC --- GCC 4.1 produced: lis 9,0xcf8 li 0,1 ori 9,9,63 slw 0,0,3 and 0,0,9 neg 0,0 srwi 3,0,31 blr The branch code is better than the code using mfcr, but the straight-line code from XLC or GCC avoiding CR is better than both.
[Bug c++/53097] New: [c++0x] Missed optimization: lambda closure object could be smaller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53097
Bug #: 53097
Summary: [c++0x] Missed optimization: lambda closure object
could be smaller
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@mit.edu
This code:
include stdio.h
int main(int argc, char **argv)
{
int a, b;
auto foo = [](){return a + b;};
printf(%d\n, (int)sizeof(foo));
return 0;
}
prints 16 (on x86-64) on gcc 4.6 and something quite close to 4.7 at -O2 and
-Ofast. This is as expected if the closure object is implemented as imagined
in the spec.
In this particular case, accessing a from the lambda is defined behavior iff
accessing b is defined (because either a and b are both in scope or both out of
scope, so the lambda could be optimized based on the knowledge that a and b are
at a fixed offset from each other. This would give size 8.
(It sounds like this could be rather difficult. clang++ 2.9 works the same way
as g++. I don't really expect to see this optimization implemented anytime
soon.)
[Bug target/47197] ICE in gimplify_expr, at gimplify.c:7153 on AltiVec code (vec_dst)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47197 --- Comment #3 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-24 01:12:07 UTC --- Thanks, Joseph -- I'll get that fixed up. Appreciate the help.
[Bug tree-optimization/53098] New: [4.8 Regression] tree-vect-loop.c:1414:19: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53098 Bug #: 53098 Summary: [4.8 Regression] tree-vect-loop.c:1414:19: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu /home/dave/gnu/gcc/objdir/./prev-gcc/g++ -B/home/dave/gnu/gcc/objdir/./prev-gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.7.0/hppa-linux-gnu/bin/ -nostdinc++ -B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber../../gcc/gcc/tree-vect-loop.c -o tree-vect-loop.o ../../gcc/gcc/tree-vect-loop.c: In function ‘bool vect_analyze_loop_operations(loop_vec_info, bool)’: ../../gcc/gcc/tree-vect-loop.c:1414:19: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] max_niter vectorization_factor)) ^ cc1plus: all warnings being treated as errors make[3]: *** [tree-vect-loop.o] Error 1
[Bug c++/53097] [c++0x] Missed optimization: lambda closure object could be smaller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53097
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-04-24
Ever Confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24
01:45:51 UTC ---
The easy way to implement this would be something like:
include stdio.h
int main(int argc, char **argv)
{
struct {
int a, b;
};
auto foo = [](){return a + b;};
printf(%d\n, (int)sizeof(foo));
return 0;
}
and then only the pointer to the struct needs to be done for the closure.
[Bug c/53064] -Wsequence-point behaves inconsistently
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53064 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 03:51:32 UTC --- a + (++a ? 0 : 0); Hmm, I don't think there is a sequence point issue here compared to the other case where it might cause an undefined code. (++a ? 0 : 0) is all in done in one sequence point so that is defined and then added to a. a might be accessed before or after the sequence point where a is modified but there is a sequence point between the access and the modification.
[Bug c/53064] -Wsequence-point behaves inconsistently
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53064 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 03:52:18 UTC --- Note in the other case there is no sequence point because function arguments are in the same sequence as the addition.
[Bug middle-end/53093] [4.8 Regression]: tls/alias-1.c ICE, emutls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53093 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug driver/52863] Enable -Wall by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52863 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 03:57:17 UTC --- I think we should not. I did not write in the thread on the email list because I was busy at the time. I have only seen two bug reports asking for it in the last 6 years (this is one of them). I think we should spend more time in improving our documentation rather than enabling -Wall by default.
[Bug bootstrap/52850] Linker path ends up using wrong zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52850 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 03:58:50 UTC --- The problem is that there is an unsuitable copy of libz installed That sounds like an user problem rather than a GCC issue.
[Bug bootstrap/52847] case shell quoting problem in top-level makefile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52847 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||powerpc-*-aix* Component|other |bootstrap --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:00:41 UTC --- CC=gcc -mminimal-toc You should not need -mminimal-toc because of this toplevel makefile part.
[Bug bootstrap/52847] case shell quoting problem in top-level makefile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52847 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-24 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:01:49 UTC --- Index: config/mh-ppc-aix === --- config/mh-ppc-aix(revision 186738) +++ config/mh-ppc-aix(working copy) @@ -5,4 +5,4 @@ # don't do it any more. BOOT_ADAFLAGS = -gnatapg BOOT_LDFLAGS = -Wl,-bbigtoc -LDFLAGS = `case $(CC) in *gcc*) echo -Wl,-bbigtoc ;; esac;` +LDFLAGS = `case $(CC) in *gcc*) echo -Wl,-bbigtoc ;; esac;` Is the full patch.
[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:03:38 UTC --- GCC is not a mind reader. There is no way for GCC to know if you want to do PIC or PIE code.
[Bug c++/52875] ADL failure + ICE in decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52875 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-24 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:04:59 UTC --- Confirmed.
[Bug other/52930] quadmath: missing logbq, modfq, nexttowardq, exp2q
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52930 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug driver/52982] add option to select particular linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52982 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:17:58 UTC --- http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00402.html
[Bug translation/52984] Different information message in Turkish locale.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52984 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||MOVED --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:21:16 UTC --- The translations are handled by the translation project. Translation issues should be reported directly to them rather to us.
[Bug bootstrap/51969] [4.6 regression] trunk gcc unable to build gcc 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51969 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||kallisti5 at unixzen dot ||com --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:22:19 UTC --- *** Bug 52986 has been marked as a duplicate of this bug. ***
[Bug c/52986] x86_64 GCC 4.7.0 can't compile x86 GCC 4.6.2; gtype-desc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52986 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:22:19 UTC --- Dup so closing as such. *** This bug has been marked as a duplicate of bug 51969 ***
[Bug c++/52987] bogus expected ; before for undeclared type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52987 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-24 Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:23:33 UTC --- Confirmed. The C front-end handles this much better: t.c: In function ‘foo’: t.c:2:3: error: unknown type name ‘x’ x var; ^
[Bug target/52989] Installation error on OS X (arm-eabi) cross-compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52989 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||build Target||arm-eabi Component|other |target --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:26:31 UTC --- --with-multilib-list=interwork Maybe that is broken.
[Bug libgomp/52993] gomp_init_nest_lock_25: possible bad call to memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52993 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-24 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:32:17 UTC --- For LP64I32 targets, the code will most likely just work correctly as the struct will be two ints which is the same size as one pointer. While for LPI32 targets, it will be broken. So confirmed.
[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 --- Comment #3 from Jeffrey Walton noloader at gmail dot com 2012-04-24 04:32:35 UTC --- (In reply to comment #2) GCC is not a mind reader. I kind of knew that. There is no way for GCC to know if you want to do PIC or PIE code. Forgive my ignorance, but why does it matter at the code generation stage? How are relocations different in the object code of a program versus a shared object? At code generation, I did not think there was even the concept of program or shared object.
[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 --- Comment #4 from Jeffrey Walton noloader at gmail dot com 2012-04-24 04:34:42 UTC --- (In reply to comment #1) Also how can you tell the difference between compiling for executable and shared library if you don't supply -fPIC? So adding -aslr is not going to be useful really. The compiler driver would make the determination at link time, and pass the appropriate switch to the linker. I did not think it was a difficult concept. My apologies.
[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:35:57 UTC --- Forgive my ignorance, but why does it matter at the code generation stage? Easy. With PIE, global variables and functions are considered to bind local while with PIC they are considered to bind globally (aka override able). At code generation, I did not think there was even the concept of program or shared object. And this is where you are wrong. GCC has a concept of program vs shared library.
[Bug preprocessor/52998] caret and -ftrack-macro-expansion don't mix well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52998 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-24 Ever Confirmed|0 |1 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:36:42 UTC --- Confirmed.
[Bug middle-end/53010] [4.8 Regression] crash due to null ptr deref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53010 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end Target Milestone|--- |4.8.0 Summary|crash due to null ptr deref |[4.8 Regression] crash due ||to null ptr deref --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-24 04:38:16 UTC --- I think this has been fixed already.
[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 --- Comment #6 from Jeffrey Walton noloader at gmail dot com 2012-04-24 04:38:54 UTC --- (In reply to comment #5) At code generation, I did not think there was even the concept of program or shared object. And this is where you are wrong. GCC has a concept of program vs shared library. My apologies. I was not aware that object code had a gender (program versus shared object).
[Bug middle-end/53010] [4.8 Regression] crash due to null ptr deref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53010 --- Comment #2 from John Regehr regehr at cs dot utah.edu 2012-04-24 04:51:01 UTC --- Yes, this has gone away as of the last couple days.
[Bug middle-end/53082] local malloc/free optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53082 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23 06:51:34 UTC --- Dup of an older bug 19831. *** This bug has been marked as a duplicate of bug 19831 ***
[Bug tree-optimization/19831] Missing DSE/malloc/free optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19831 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||xinliangli at gmail dot com --- Comment #13 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23 06:51:34 UTC --- *** Bug 53082 has been marked as a duplicate of this bug. ***
[Bug middle-end/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #5 from Alexander Monakov amonakov at gcc dot gnu.org 2012-04-23 06:53:11 UTC --- The memset part can be handled by -ftree-loop-distribution (not enabled at -O3)
[Bug middle-end/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23 06:54:43 UTC --- (In reply to comment #4) LLVM's version also tries to merge smaller memsets into a larger one. That is filed as PR 49872. And the original issue is related to PR 30442.
[Bug middle-end/53082] local malloc/free optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53082 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-04-23 07:11:14 UTC --- (In reply to comment #1) Dup of an older bug 19831. The second part (coalescing mallocs and/or replacing them with alloca) doesn't look like a dup of 19831.
[Bug c/53083] New: gcc bug in moving from the SSE registers back onto the heap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083 Bug #: 53083 Summary: gcc bug in moving from the SSE registers back onto the heap. Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: da_...@mad.scientist.com After investigation of a suspected graphics-driver bug, it was found that the issue lay with gcc. Please see https://bugs.freedesktop.org/show_bug.cgi?id=47559 . The problem as I understand is that gcc-4.6.0 miscompiles miarc.c from the xorg-server package if -ftree-vectorize is enabled. This flag is enabled with -O3. The following minimal set of CFLAGS worked: -g -O2 Adding the -ftree-vectorize separately, -g -O2 -ftree-vectorize, caused the program to misbehave at runtime. I am running gentoo, the default CFLAGS for my system are: CFLAGS=-march=native -O3 -pipe -fomit-frame-pointer -fweb -ffast-math -mtune=native -mfpmath=sse I don't know if these match exactly with what is passed by portage for compiling GCC. Software versions (gentoo package versions): sys-devel/gcc-4.6.0 x11-base/xorg-server-1.11.2-r2 My hardware is a Dell XPS 15 (L502x) laptop with a 'Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz' I additional information is required please let me know.
[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-04-23 07:55:29 UTC --- (In reply to comment #0) I additional information is required please let me know. Please provide all necessary information, as outlined in [1]. [1] http://gcc.gnu.org/bugs/#report
[Bug middle-end/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-23 08:18:42 UTC --- Note that -ftree-loop-distribution for some weird reason only handles clearing, but not initialization by arbitrary constants that are convertible to memset (i.e. all bytes have the same constant stored, such as 0x0a0a0a0a etc.).
[Bug fortran/53077] suggestion to add the .f extension to the list of file extensions that trigger enabling of the preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-23 08:27:05 UTC --- Hmm... apparently the PGI compiler uses the same rule for enabling preprocessor with .f and .F extensions. I think most compilers follow that pattern, which can be overridden by -cpp and -no-cpp, respectively. Then, if there's some important reason behind it (?) Well, the C preprocessor is not part of the Fortran standard, thus, a compiler can expect that no C preprocessing has to be done. (Though, most compilers do support CPP preprocessing; there are some caveats with regards to newer CPP features: The preprocessor has then to be aware of Fortran. Thus, many compilers do not support the CPP of newer C standards.) Side note: The Fortran 95 standard actually defines in Part 3 Conditional Compilation (ISO/IEC 1539-3:1998), however, this Fortran-specific way was never widely used and it is not implemented in any compiler (to my knowledge). However, there exists a preprocessor coco (written in Fortran). perhaps at least the warning message could be improved by indicating that the preprocessor is off. I concur. Untested patch. Remark: At some point, gfortran needs to follow GCC with regards to -f(no-)diagnostics-show-caret. I now keep the file:line: with -cpp but the caret diagnostic without. --- a/gcc/fortran/scanner.c +++ b/gcc/fortran/scanner.c @@ -1792,4 +1792,9 @@ preprocessor_line (gfc_char_t *c) bad_cpp_line: - gfc_warning_now (%s:%d: Illegal preprocessor directive, - current_file-filename, current_file-line); + if (gfc_cpp_enabled ()) +gfc_warning_now (%s:%d: Illegal preprocessor directive, +current_file-filename, current_file-line); + else +gfc_warning_now (Ignoring preprocessor directive at %C. Used -cpp to , +enable the C preprocessor); + current_file-line++;(In reply to comment #2)
[Bug libstdc++/53080] tuple interface to std::array doesn't check bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53080
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-04-23
Summary|std::array - std::get() and |tuple interface to
|std::tuple_element is |std::array doesn't check
|nothing bounds check|bounds
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-23
08:35:41 UTC ---
Testcase:
#include array
int main()
{
typedef std::tuple_element1, std::arrayint, 1 type;
std::arrayint, 1 a;
std::get1(a);
}
[Bug middle-end/53032] [4.8 Regression] 447.dealII in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53032 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 09:15:26 UTC --- It might be a duplicate of PR53050.
[Bug middle-end/53047] [4.8 Regression] 482.sphinx3 in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53047 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-23 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 09:16:35 UTC --- I am pretty sure that it is sphinx3s fault. Investigating.
[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |testsuite --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 09:17:10 UTC --- I belive those are likely out-of-bound accesses in the testcases.
[Bug middle-end/53073] [4.8 Regression] 464.h264ref in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 09:20:37 UTC --- Well, I'm sure it is h264refs fault.
[Bug c++/53078] [C++11] Wrong diagnostic no return statement in function returning non-void on lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53078 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-23 09:30:18 UTC --- Ok (4_7-branch is also fine)
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 --- Comment #3 from Rich Felker bugdal at aerifal dot cx 2012-04-23 09:37:45 UTC --- Compiling with the -mno-ieee-fp option fixes this bug. It seems like the behavior of this option is reversed from the documentation; -mno-ieee-fp gives IEEE conformant comparisons (raising exception on unordered) and -mieee-fp gives non-conformant comparisons (silent on unordered)...
[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||chris at bubblescope dot ||net --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-23 09:37:08 UTC --- Chris, can you have a look to the mem_check tests?
[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046 --- Comment #6 from Chris Jefferson chris at bubblescope dot net 2012-04-23 09:44:11 UTC --- Yes, will check.
[Bug other/53065] ICE replace_reg_with_saved_mem, at caller-save.c:1125
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53065 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-04-23 09:56:24 UTC --- Also confirmed with 4.8.0 from 2012-04-16 under i686-pc-linux-gnu.
[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046 --- Comment #7 from Chris Jefferson chris at bubblescope dot net 2012-04-23 09:57:12 UTC --- While I haven't yet got a recent copy of gcc trunk compiled, it does indeed look like an out-of-bounds error, but just a 'testsuite' problem. At the top of both mem_check tests as a 'const int A[]' array with 29 elements, which we read 30 elements of. If doesn't matter what the extra element is, we just want an array of any 30 integers, which is why this hasn't caused problems before.
[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52999 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-23 09:58:38 UTC --- Created attachment 27219 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27219 gcc48-pr52999.patch This patch avoids the ICE when diagnosing the section conflict, but not sure what to do to actually compile the testcase without errors. What ld.so does is not exactly kosher from GCC POV (it wants to put non-constant, writable variables into a section that GCC assumes is for constant variables that need relocations).
[Bug c/53060] Typo in build_binary_op for scalar-vector ops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53060 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-23 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 10:00:52 UTC --- Mine.
[Bug c/53084] New: GCC cannot handle array initialization of string constant with point arithmetic properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53084
Bug #: 53084
Summary: GCC cannot handle array initialization of string
constant with point arithmetic properly
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ray_l...@hotmail.com
Consider the following code:
#include stdio.h
int main() {
static const char *const aa[] = {foo+1};
printf(aa[0] = %s\n,aa[0]);
return 0;
}
works fine on GCC 4.5.2 and 4.6.1
C:\workgcc --version
gcc (tdm-1) 4.5.2
Copyright (C) 2010 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.
C:\workgcc a.c -oa.exe
C:\worka
aa[0] = oo
C:\workgcc --version
gcc (tdm-1) 4.6.1
Copyright (C) 2011 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.
C:\workgcc a.c -oa.exe
C:\worka
aa[0] = oo
On GCC 4.7.0, it fails with segmentation fault.
C:\workgcc --version
gcc (GCC) 4.7.0
Copyright (C) 2012 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.
C:\workgcc a.c -oa.exe
C:\worka
(error dialog)
Please go there to find the original bug threads:
http://bugs.ruby-lang.org/issues/6333
[Bug tree-optimization/52891] [4.8 Regression] ICE in adjust_bool_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52891 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-23 10:13:46 UTC --- Author: jakub Date: Mon Apr 23 10:13:39 2012 New Revision: 186694 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186694 Log: PR tree-optimizations/52891 * tree-vect-patterns.c (adjust_bool_pattern): Use build_nonstandard_type even if rhs1 has unsigned INTEGER_TYPE, but with non-standard precision. * gcc.c-torture/compile/pr52891-1.c: New test. * gcc.c-torture/compile/pr52891-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr52891-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr52891-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug tree-optimization/52891] [4.8 Regression] ICE in adjust_bool_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52891 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-23 10:17:08 UTC --- Author: jakub Date: Mon Apr 23 10:16:57 2012 New Revision: 186695 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186695 Log: PR tree-optimizations/52891 * tree-vect-patterns.c (adjust_bool_pattern): Use build_nonstandard_type even if rhs1 has unsigned INTEGER_TYPE, but with non-standard precision. * gcc.c-torture/compile/pr52891-1.c: New test. * gcc.c-torture/compile/pr52891-2.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/compile/pr52891-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/compile/pr52891-2.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-vect-patterns.c
[Bug c/53060] Typo in build_binary_op for scalar-vector ops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53060 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 10:20:13 UTC --- Author: rguenth Date: Mon Apr 23 10:20:05 2012 New Revision: 186696 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186696 Log: 2012-04-23 Richard Guenther rguent...@suse.de PR c/53060 * c-typeck.c (build_binary_op): Fix typo. * gcc.dg/pr53060.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr53060.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53084 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2012-04-23 Ever Confirmed|0 |1 Summary|GCC cannot handle array |[4.7/4.8 Regression] GCC |initialization of string|cannot handle array |constant with point |initialization of string |arithmetic properly |constant with point ||arithmetic properly Target Milestone|--- |4.7.1 Severity|critical|normal --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 10:22:34 UTC --- Confirmed.
[Bug c/53060] Typo in build_binary_op for scalar-vector ops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53060 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 10:24:25 UTC --- Author: rguenth Date: Mon Apr 23 10:24:14 2012 New Revision: 186698 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186698 Log: 2012-04-23 Richard Guenther rguent...@suse.de PR c/53060 * c-typeck.c (build_binary_op): Fix typo. * gcc.dg/pr53060.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr53060.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/c-typeck.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-04-23 Ever Confirmed|0 |1
[Bug c/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53084 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2012-04-23 10:25:05 UTC --- I can confirm it with trunk version for -O0, too. Issue is that there seems to be a wrong-code generation bug for O0 and read-only section data. ... movqaa.2567(%rip), %rax movq%rax, %rdx leaq.LC0(%rip), %rcx callprintf ... ... .data .align 8 aa.2567: .section .rdata,dr .LC1: .ascii foo\0 .quad .LC1+1 ... The aa.2567 label is emitted in data, but its definition in .rdata
[Bug tree-optimization/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-23 CC||rguenth at gcc dot gnu.org Component|middle-end |tree-optimization Version|unknown |4.8.0 Ever Confirmed|0 |1 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 10:26:45 UTC --- clearing recognition is enabled by default at -O2+ with -ftree-loop-distribute-patterns. I agree more general memset handling would be nice, as well as memcpy and memmove recognition.
[Bug c/53079] Unwanted optimization occurs on function with the same name as a math.h function without including math.h nor linking with libm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53079 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 10:27:13 UTC --- Indeed.
[Bug regression/53076] [4.8 Regression]: gcc.dg/torture/builtin-explog-1.c, gcc.dg/torture/builtin-power-1.c at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53076 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug tree-optimization/53070] ICE: in execute_cse_reciprocals, at tree-ssa-math-opts.c:513 with -O -ffast-math -ftree-loop-if-convert -fno-tree-loop-im
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53070 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-23 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 10:32:41 UTC --- Confirmed. #1 0x00cd5750 in execute_cse_reciprocals () at /space/rguenther/src/svn/trunk/gcc/tree-ssa-math-opts.c:513 513 gcc_assert (!bb-aux); likely somebody (if-conversion) leaves bb-aux initialized. Mine.
[Bug target/53071] Wrong instruction replacement when compiling for xop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53071 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-23 Depends on||52908, 52910 Ever Confirmed|0 |1
[Bug tree-optimization/53058] [4.8 Regression] Another ice in remove_range_assertions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53058 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|c |tree-optimization Target Milestone|--- |4.8.0 Summary|Another ice in |[4.8 Regression] Another |remove_range_assertions |ice in ||remove_range_assertions
[Bug middle-end/53032] [4.8 Regression] 447.dealII in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53032 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 10:37:27 UTC --- Failed and worked again in our testers. Dup. *** This bug has been marked as a duplicate of bug 53050 ***
[Bug c/53060] Typo in build_binary_op for scalar-vector ops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53060 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 10:36:28 UTC --- Fixed. Thanks for spotting.
[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-23 10:36:28 UTC --- Oops, thanks a lot Chris!! I'll do the change.
[Bug c++/53050] ssa_forward_propagate_and_combine: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53050 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-23 10:37:28 UTC --- *** Bug 53032 has been marked as a duplicate of this bug. ***
