[Bug rtl-optimization/61629] [4.10 regression] FAIL: gcc.dg/20020312-2.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61629 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-16 CC||rsandifo at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from rsandifo at gcc dot gnu.org --- I see the same thing on MIPS for different testcases (e.g. gcc.dg/tree-ssa/pr43491.c). As you probably know, it's caused by: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01584.html Testing a fix.
[Bug c++/47346] access control for nested type is ignored in class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346 Andrew Pinski changed: What|Removed |Added CC||myriachan at gmail dot com --- Comment #14 from Andrew Pinski --- *** Bug 61816 has been marked as a duplicate of this bug. ***
[Bug c++/61816] Member functions of a template class can access private classes without permission
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61816 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 47346. *** This bug has been marked as a duplicate of bug 47346 ***
[Bug c++/61816] Member functions of a template class can access private classes without permission
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61816 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- The problem also exists in gcc trunk version 4.10.0 20140715 (experimental)
[Bug sanitizer/61771] Regressions in ASan testsuite on ARM Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 --- Comment #4 from Yury Gribov --- > It should be possible to detect fp layout on the frame basis - > there is a slot (don't know which one off the top of my head) > that is FP in one compiler and return address in the other. > Comparing its contents with the current stack limits > (readily available in ASan) should do the trick. Unless program uses nested functions (and so LR may point to trampoline which is located on stack). > Of course, it would be awesome if we could synchronize > (and document somewhere) FP stack layout between GCC and Clang Let me ping LLVM list for this.
[Bug bootstrap/61809] [4.10 regression] fold-const.c:14865:47: error: 'DECL_ARGUMENT' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809 --- Comment #5 from Dmitry G. Dyachenko --- (In reply to Dominique d'Humieres from comment #2) > Are you sure that r212549 fails? I'ld rather suspect a typo in r212550, > i.e., DECL_ARGUMENT instead of DECL_ARGUMENT_FLD. Oh, for r212549 and r212550 err.messages are different :)
[Bug bootstrap/61809] [4.10 regression] fold-const.c:14865:47: error: 'DECL_ARGUMENT' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809 --- Comment #4 from Dmitry G. Dyachenko --- (In reply to Dominique d'Humieres from comment #2) > Are you sure that r212549 fails? I'ld rather suspect a typo in r212550, > i.e., DECL_ARGUMENT instead of DECL_ARGUMENT_FLD. Sorry, err in err.message. Correct error message for r212549 /home/dimhen/src/gcc_r212549/gcc/fold-const.c: In function 'void fold_checksum_tree(const_tree, md5_ctx*, hash_table >*)': /home/dimhen/src/gcc_r212549/gcc/fold-const.c:14865:47: error: 'DECL_ARGUMENT_FLD' was not declared in this scope fold_checksum_tree (DECL_ARGUMENT_FLD (expr), ctx, ht); ^
[Bug c++/61015] Stack corruption with templates and pass-by-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61015
Melissa changed:
What|Removed |Added
CC||myriachan at gmail dot com
--- Comment #1 from Melissa ---
Your code is doing something bad - it's retaining a pointer to a temporary
object across a function call.
Although pointers to a derived class are convertible to pointers to a parent
class, that is not true for double-pointers. For example, the following code
is not legal:
struct Base {};
struct Derived : Base {};
int main()
{
// I don't normally use so-called Hungarian notation, but here it's clearer
Derived *pDerived = new Derived();
Derived **ppDerived = &pDerived;
// This is legal.
Base *pBase = pDerived;
// This is not legal, and will cause a compiler error.
Base **ppBase = ppDerived;
return 0;
}
So back to your code, the problem is visible in this small part:
template
class ArrayRef
{
private:
const T* data;
ArrayRef( const T& oneElt ) // <--- important
{
this->data = &oneElt;
...
}
};
int main()
{
SpecialObj specialObj;
SpecialObj* pSpecialObj = &specialObj;
ArrayRef arrayRef( pSpecialObj );
...
}
The important thing is the const T & parameter. T is Obj *, not SpecialObj *,
so the constructor takes Obj *const &. (The const ends up on the right side of
the asterisk in this notation when expanding out T.) References are really
pointers in alternate syntax, and just like pointers, it is not legal to have a
double-pointer conversion from derived to base. Just like how SpecialObj **
can't be assigned to type Obj *const *, it's also the case that SpecialObj *
can't be bound to Obj *const &.
But why does it compile when the double-pointer case didn't? It's because
const references have another property: they also take temporaries. If an
object cannot be bound as a const lvalue to the const reference, the compiler
will instead try to create a temporary using an implicit conversion,
constructor call, or similar, then bind the temporary to the const reference.
Here, the temporary it can create is of type Obj *. And sure enough,
SpecialObj * can be implicitly converted to Obj *. So the compiler is going to
create a temporary Obj * on the stack containing a copy of the SpecialObj *
cast to Obj *, then pass *that* to to the ArrayRef constructor. Then you
save a pointer to the passed const Obj * inside the ArrayRef constructor.
References are really just pointers behind the scenes - and you just saved a
pointer to a temporary object. Now your ArrayRef class has a pointer to an
arbitrary location in the caller's stack.
I'm going to guess that the compilers that don't crash are actually not
crashing because of the optimizer. The inlining of the optimizer may actually
cause the temporary to remain in the current stack frame, possibly preventing
the pointer from corrupting anything. It's when the pointer stored in
ArrayRef points to a temporary whose memory was freed and reused that you
have a problem.
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #19 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #15) > > Its sort of like Steve said earlier. The coder is choosing to ignore an > > error condition so anything gfortran does is valid. In this case the > > output got writen to buffer before the error occurred. You are bypassing > > all of the normal error handling when you do this. The buffer got flushed. > > > > Its not worth the time to change any of it really. > > > > The program should exit, its invalid. I simply mean the Fortran code in the test case is invalid Fortran. Fix the Fortran code. Now suppose the error is a disk full. Should the user just ignore that and keep trying to write to the disk? > > Well, I disagree with this interpretation: I did not find anywhere in the > standard that the variable set by iostat has to be used. In addition, the > following code should be valid upon Steve's rules and still prints 'YYY' ---snip--- Regarding the "YYY". Why not print it? the error occurs after it is written. If you do not "catch" the error, the runtime leaves early, out of all the various processing loops, and exits the program. Whereas when the error is caught, we continue execution in the library where we detected the error and happily proceeds. The transfer is directed by the format string, it went as far as it could go. (As opposed to list directed I/O) > > IMO this PR boils down to the fact that the I/O processing is not reset to a > clean state after an error is handled with ERR, IOSTAT, ... , as it should. The standard uses the term indeterminate. You prefer it to be determined. OK Person A wants the file buffers flushed, the file closed, and reopened with status="append". Person B wants to grab the file position, clear the buffers, rewind the file, read it back in, parse it for bad content, and signal an alarm on the console. The user can do these things if they want to. > > Along this line, I have found that 'parse_format' is called only once even > if 'ss' is called twice. This is by design. The string is parsed once for efficiency and reused for performance purposes. Its a choice we made some time ago. The runtime checks the string for a match to previously parsed strings. Saves a lot of run time. The parsed (tokenized) format is saved elsewhere and reused.
[Bug libfortran/59513] [4.8/4.9/4.10 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513 --- Comment #24 from Jerry DeLisle --- (In reply to Manfred Schwarb from comment #22) --- snip --- > Jerry, concerning your cited standard: > "If the file contains an endfile record" suggests that there is some > special marker in the file to be read/written. > In this example, we are doing some formatted IO to a plain text file, > there are no special markers. > Do I miss something? > > What does/should ftell() report in such a case? That we are one > character beyond EOF? I think Dominique has answered as far as the physical aspect. FTELL just returns the current physical location.
[Bug c++/61816] New: Member functions of a template class can access private classes without permission
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61816
Bug ID: 61816
Summary: Member functions of a template class can access
private classes without permission
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: myriachan at gmail dot com
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
There exists a case in which a member function of a forward-declared template
can access a private inner class without permission. Possible duplicate of bug
41437.
class ClassWithEverythingPrivate {
class InnerClass {
public:
static int InnerFunction() {
return 123;
}
};
};
template class TemplateClass {
public:
static int StaticFunction() {
return ClassWithEverythingPrivate::InnerClass::InnerFunction();
}
};
int main() {
return TemplateClass::StaticFunction();
}
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 --- Comment #9 from Dominique d'Humieres --- > and val_gmp.h only exists in isl-0.13. I have val_gmp.h for isl-0.12.1 and isl-0.12.2: [Book15] f90/bug% find /opt/libs -name val_gmp.h /opt/libs/cloog-0.18.1/isl/include/isl/val_gmp.h /opt/libs/isl-0.12.1/include/isl/val_gmp.h /opt/libs/isl-0.12.2/include/isl/val_gmp.h and they are all the same.
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
--- Comment #8 from Manfred Schwarb ---
The graphite-isl-ast-to-gimple.c code reads
#ifdef HAVE_cloog
#include
#include
#include
#include
#if defined(__cplusplus)
extern "C" {
#endif
#include
#if defined(__cplusplus)
}
#endif
#endif
and val_gmp.h only exists in isl-0.13.
So maybe things work when disabling/not using cloog?
Will have to check tomorrow.
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 --- Comment #7 from Dominique d'Humieres --- For the record, I have done a clean bootstrap of r212523 on x86_64-apple-darwin13 with cloog-0.18.1 and isl-0.12.2.
[Bug libfortran/59513] [4.8/4.9/4.10 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513 --- Comment #23 from Dominique d'Humieres --- > Jerry, concerning your cited standard: > "If the file contains an endfile record" suggests that there is some > special marker in the file to be read/written. >From the standard: > NOTE 9.2 > An endfile record does not necessarily have any physical embodiment. The > processor may use a record count or other means to register the position > of the file at the time an ENDFILE statement is executed, so that it can take > appropriate action when that position is reached again during a read > operation. The endfile record, however it is implemented, is considered > to exist for the BACKSPACE statement (9.8.2).
[Bug libfortran/59513] [4.8/4.9/4.10 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513 Manfred Schwarb changed: What|Removed |Added CC||manfred99 at gmx dot ch --- Comment #22 from Manfred Schwarb --- I just encountered the same issue, with some convoluted legacy code. The scheme seems to be the same: READ(lun,END=100) buffer 100 WRITE(lun,*) "whatever" As the used code definitely was used in practice, mainly before the year 2000, I guess that older compiler supported this. And yes, the BACKSPACE() trick works. However, common sense suggest that with END= we are at the end of the file. This sounds a bit like the old joke, where you have a room with 5 people, you are taking 6 out, so someone has to go in for the room to be empty. Beyond EOF simply does not exist. Jerry, concerning your cited standard: "If the file contains an endfile record" suggests that there is some special marker in the file to be read/written. In this example, we are doing some formatted IO to a plain text file, there are no special markers. Do I miss something? What does/should ftell() report in such a case? That we are one character beyond EOF?
[Bug c++/61811] [4.10 Regression] Firefox LTO build error due to undefined symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61811 --- Comment #1 from Jason Merrill --- Author: jason Date: Tue Jul 15 21:38:48 2014 New Revision: 212576 URL: https://gcc.gnu.org/viewcvs?rev=212576&root=gcc&view=rev Log: PR c++/61811 * decl2.c (maybe_emit_vtables): Return true for -fuse-all-virtuals. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c
[Bug c++/61723] [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723 --- Comment #7 from Jason Merrill --- (In reply to Paul Pluzhnikov from comment #6) > This appears to be a different ICE. > Should I reduce it? Please. And open a new PR for it.
[Bug c++/61723] [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723 --- Comment #6 from Paul Pluzhnikov --- It turns out that the original unreduced test case does not error on trunk @r212277; it only ICEs on gcc-4.8 and gcc-4.9 branches. But once I creduced it using 4.9, the reduced test also ICEd on trunk. I have just verified that the latest 4.9 @r212536 crashes like so on non-reduced test: gcc-svn-4_9-r212536/bin/g++ -c -std=c++11 t.ii -O2 t.cc: In function ‘’: t.cc:22:24: internal compiler error: Segmentation fault 0xb947ff crash_signal ../../gcc/toplev.c:337 0x952096 fold_comparison ../../gcc/fold-const.c:9074 0x95be35 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) ../../gcc/fold-const.c:13563 0xbca30d cleanup_control_expr_graph ../../gcc/tree-cfgcleanup.c:112 0xbca30d cleanup_control_flow_bb ../../gcc/tree-cfgcleanup.c:187 0xbca30d cleanup_tree_cfg_bb ../../gcc/tree-cfgcleanup.c:630 0xbcbd48 cleanup_tree_cfg_1 ../../gcc/tree-cfgcleanup.c:675 0xbcbd48 cleanup_tree_cfg_noloop ../../gcc/tree-cfgcleanup.c:731 0xbcbd48 cleanup_tree_cfg() ../../gcc/tree-cfgcleanup.c:786 0xaea194 execute_function_todo ../../gcc/passes.c:1811 0xaeaa83 execute_todo ../../gcc/passes.c:1887 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. This appears to be a different ICE. Should I reduce it?
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 --- Comment #6 from Manfred Schwarb --- There is ./configure --disable-isl-version-check, but I doubt that it will help. The thing is, isl-0.13 needs cloog-0.18.2 (or rather, cloog-0.18.1 needs isl-0.12.2 and does not build with isl-0.13), which is not yet released. Now I heard that the goal is to do without cloog, but I guess the configure machinery (and probably, the rest of the graphite code) is not yet up to it. There really needs an immediate solution to this issue, I think ATM there is no way to build graphite without resorting to non-released libraries. I suggest to revert all these isl-0.13 dependencies until cloog-0.18.2 is released, or there is shown some way to build graphite without cloog. Roman, how is one supposed to build GCC with graphite support?
[Bug c++/50961] Fails to decay template function properly(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50961 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini --- Mine.
[Bug c++/61723] [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723 --- Comment #5 from Paul Pluzhnikov --- (In reply to Paolo Carlini from comment #1) > I find this testcase rather weird It's the result of creduce over a preprocessed original. > std::initializer_list isn't a random user type In the non-reduced test (which is 15MB in size), it's the full type. > OK, now GCC will reject the definition of std::initializer_list rather than > ICE. I'll check whether original test still ICEs, and re-reduce if it still does.
[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754
Ed Smith-Rowland <3dw4rd at verizon dot net> changed:
What|Removed |Added
CC||3dw4rd at verizon dot net
--- Comment #2 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
On the ## line is the use of the deprecated *type* that is causing the error.
struct __attribute__((deprecated)) Old1 {};
Old1 old1 __attribute__((deprecated));
struct [[deprecated("deprecated type Old2")]] Old2 {};
Old2 old2 [[deprecated("deprecated global old2")]]; // ##
int
main()
{
//old1;
//Old1 newold1 [[gnu::unused]];
//old2;
//Old2 newold2 [[gnu::unused]];
}
Gives:
/home/ed/bin/bin/g++ -std=c++14 -Wall -Wextra -pedantic -o test_pr61754
test_pr61754.cpp
test_pr61754.cpp:7:50: warning: ‘Old2’ is deprecated (declared at
test_pr61754.cpp:5): deprecated type Old2 [-Wdeprecated-declarations]
Old2 old2 [[deprecated("deprecated global old2")]]; // ##
^
The [[deprecated]] is parsed and immediately calls the [[gnu::deprecated]]
code. Which in turn should do __attribute__((deprecated)). This might
(should) be easy to isolate.
[Bug c++/61807] genautomata.c fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61807 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- The compiler diagnostics looks right to me. Why do you expect that void* could be implicitly converted to const char*?
[Bug web/61782] always_inline incorrectly documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782 --- Comment #6 from Daniel Santos --- (In reply to Richard Biener from comment #3) > Note that if such function is called indirectly the compiler may > or may not inline it dependent on optimization level and a failure > to inline an indirect call may or may not be diagnosed. OMG!! Thank you SO much for this clarification! I'm the crazy C metaprogramming guy and I depend upon -findirect-inline and always_inline to facilitate what I'm calling "C pseudo-templates." This would explain some odd circumstances where I've seen such functions not get inlined. I've been able to remedy this (thus far) by marking the calling function with __attribute__((flatten)), but I have to take great care to catch this, ensuring that that I check each value that I expect to be constant with __builtin_constant_p and generate an error when they aren't. Portions of these functions (often the majority) I expect to be executed by the compiler and the result emitted, rather than having the whole of the function emitted as generated code. As the complexity of such functions grows, the cost of failing to inline by indirection can be the explosion of the function to 10, 20 times or more of it's size when all inlining happens. (sorry, that's a little off topic). I like the verbiage and thank you!
[Bug fortran/56218] [OOP] Segfault with allocatable intent(out) derived type argument having allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56218 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED CC||bur...@net-b.de Resolution|--- |FIXED --- Comment #5 from Dominique d'Humieres --- > Seems to work fine on 4.10 (20140710). Confirmed for 4.10 and 4.9. Revision r199435 (2013-05-30) segfault, r199960 (2013-06-11) does not. The fix found be related to Tobias' work on finalization (pr37336, r199643 or r199851). Closing.
[Bug c++/61723] [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #4 from Jason Merrill --- OK, now GCC will reject the definition of std::initializer_list rather than ICE.
[Bug c++/61723] [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723 --- Comment #3 from Jason Merrill --- Author: jason Date: Tue Jul 15 19:16:29 2014 New Revision: 212574 URL: https://gcc.gnu.org/viewcvs?rev=212574&root=gcc&view=rev Log: PR c++/60848 PR c++/61723 * call.c (is_std_init_list): Don't check CLASSTYPE_TEMPLATE_INFO. * class.c (finish_struct): Reject invalid definition of std::initializer_list. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist87.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/testsuite/g++.dg/cpp0x/initlist85.C
[Bug c++/60848] [4.7/4.8/4.9/4.10 Regression] Crash while experimenting with c++-0x initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60848 --- Comment #6 from Jason Merrill --- Author: jason Date: Tue Jul 15 19:16:29 2014 New Revision: 212574 URL: https://gcc.gnu.org/viewcvs?rev=212574&root=gcc&view=rev Log: PR c++/60848 PR c++/61723 * call.c (is_std_init_list): Don't check CLASSTYPE_TEMPLATE_INFO. * class.c (finish_struct): Reject invalid definition of std::initializer_list. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist87.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/testsuite/g++.dg/cpp0x/initlist85.C
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- It wouldn't be that much of a band-aid, as we can't do anything reasonable with asm in debug_insn anyway, there is no way to emit it into DWARF4 nor upcoming DWARF version.
[Bug c/61815] precedence of operators is not being followed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61815 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Just compile with -Wsequence-point or read the C standard on sequence points.
[Bug c/61815] precedence of operators is not being followed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61815 --- Comment #3 from saisusheelsunkara at hotmail dot com --- if it is following the precedence then output must have been 216?
[Bug c/61815] precedence of operators is not being followed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61815 --- Comment #2 from saisusheelsunkara at hotmail dot com --- its from left to right order? (In reply to Andrew Pinski from comment #1) > The precedence of operators is being followed but what the C standard does > not say which side of the * is evaluated first.
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 Thomas Koenig changed: What|Removed |Added Severity|normal |blocker --- Comment #5 from Thomas Koenig --- Installing a more recent (0.1.3) libisl makes configure fail with checking for version 0.11 of ISL... no checking for version 0.12 of ISL... no configure: error: Unable to find a usable ISL. See config.log for details. Is there a way that I can revert bootstrap capability, short of reverting revision 212455?
[Bug debug/49090] provide a way to recognize defaulted template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #13 from Jason Merrill --- The DWARF attribute was in GCC 4.9.
[Bug c/61815] precedence of operators is not being followed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61815 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- The precedence of operators is being followed but what the C standard does not say which side of the * is evaluated first.
[Bug c/61815] New: precedence of operators is not being followed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61815
Bug ID: 61815
Summary: precedence of operators is not being followed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: saisusheelsunkara at hotmail dot com
int i=3,y;
y=++i*++i*++i;
printf("%d",y);
here the output being printed is 150? but as per precedence of operators the
output must have been 216 but instead of considering precedence they are simply
excuting in the order they are to be done in the evaluation of postfix notation
where operands like ++i are treated literaly as a string.
where as on performing
y=++i*++i;
the output i am getting is 25 which is as per precedence of operators in c
[Bug fortran/60898] [4.8/4.9/4.10 Regression] model compile error with gfortran 4.7 and gcc 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #13 from Harald Anlauf --- (In reply to Dominique d'Humieres from comment #11) > The only revisions that compiles the code without error is 4.5.4 on darwin10 > and 4.5.0 (r157963) on darwin13. I am marking the PR as a regression > although the bug is probably latent in 4.5. As pointed by Jerry DeLisle in > comment 9, the tests fail on x86_64-*-linux. Funny. I see a failure with -m64 with 4.3.5, 4.4.5 etc., but never with -m32 or with i686-pc-linux-gnu.
[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812 --- Comment #6 from Jakub Jelinek --- This is with the original version of the http://gcc.gnu.org/ml/gcc-patches/2014-07/msg00819.html As discussed on IRC, the issue is that the RTL includes host address in the stderr output, which due to stack randomization differs in between runs. Supposedly either we should append -fdump-noaddr option to cc1/cc1plus when we retry, or turn off address space randomization for the retries (through personality syscall on Linux).
[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812
--- Comment #5 from dhowells at redhat dot com ---
(In reply to Andrew Pinski from comment #4)
> Also even though it might be a true gcc issue, it does not say it is a
> hardware issue, the message says likely. This could also mean a gc or a
> memory issue inside gcc. Except detecting that vs a memory issue is much
> harder.
It's a bug with the code on the redhat/ branch that generates this message.
The problem is that when it detects an ICE, the gcc driver runs the cc1 binary
twice more and compares the output - but the output contains a userspace
pointer from within gcc itself, eg:
(call (mem:QI (symbol_ref:SI ("abort") [flags 0x41] ) [0 __builtin_abort S1 A8])
and this may legitimately differ due to the kernel mapping things in different
places during execve() and mmap().
[Bug target/61662] Incorrect value calculated for _lrotl on LLP64 systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61662 --- Comment #2 from David --- Sent July 9, 2014: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00604.html
[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812 --- Comment #4 from Andrew Pinski --- Also even though it might be a true gcc issue, it does not say it is a hardware issue, the message says likely. This could also mean a gc or a memory issue inside gcc. Except detecting that vs a memory issue is much harder.
[Bug libfortran/59513] [4.8/4.9/4.10 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513 --- Comment #21 from Dominique d'Humieres --- (In reply to Jerry DeLisle from comment #20) > Based on this I believe the resolution of this bug is 'INVALID'. ... I fully agree. If there is no objection before next Wednesday (July 23, 21014), I'll close the PR.
[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812 --- Comment #3 from dhowells at redhat dot com --- Hmmm... It appears you're right. The 'upstream tarball' in the Fedora gcc SRPM seems already to be altered from what's upstream - even before the spec file applies any patches to it. I wonder where it is coming from.
[Bug fortran/60898] [4.8/4.9/4.10 Regression] model compile error with gfortran 4.7 and gcc 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 --- Comment #12 from Dominique d'Humieres --- Created attachment 33126 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33126&action=edit Session showing erratic behavior of gfortran gfortran-fsf-4.5 is 4.5.4, gfortran-fsf-4.6 is 4.6.4, gfortran-fsf-4.7 is 4.7.3, /opt/gcc/gcc4.xp-y are 4.x revision y.
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 --- Comment #16 from Tom Tromey --- I've tripped across this enough that I've actually filed dups twice now. I think it would be best to change the ordering here. That is, the initial error ought to generally be the location of the outermost expansion. Then, the remaining notes ought to delineate the macro expansions. While it is true that this will yield a sub-optimal result in some cases, I think that it will have better results in the preponderance of cases. That is, there's no way to be perfect here but gcc could be more useful.
[Bug fortran/60898] [4.8/4.9/4.10 Regression] model compile error with gfortran 4.7 and gcc 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Version|unknown |4.10.0 Summary|model compile error with|[4.8/4.9/4.10 Regression] |gfortran 4.7 and gcc 4.9 on |model compile error with |Mac OS 10.9 |gfortran 4.7 and gcc 4.9 --- Comment #11 from Dominique d'Humieres --- I have tried to compile the original and reduced tests with various version on Mac OS 10.6 and 10.9 in order to bisect the revisions. However I have found that for a given revision the tests compile or not depending on the "state" of my computer (I'll attach a "session" showing this behavior). The only revisions that compiles the code without error is 4.5.4 on darwin10 and 4.5.0 (r157963) on darwin13. I am marking the PR as a regression although the bug is probably latent in 4.5. As pointed by Jerry DeLisle in comment 9, the tests fail on x86_64-*-linux. >From the reduced test, I am inclined to blame INTERFACE for ENTRY.
[Bug c++/61803] error reports macro location first, but should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803 Tom Tromey changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Tom Tromey --- Hah, not only is this a dup, but I've filed a different dup of 55252 in the past. *** This bug has been marked as a duplicate of bug 55252 ***
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 --- Comment #15 from Tom Tromey --- *** Bug 61803 has been marked as a duplicate of this bug. ***
[Bug c++/61803] error reports macro location first, but should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803 --- Comment #3 from Manuel López-Ibáñez --- (In reply to Tom Tromey from comment #2) > > In this case yes, but this is not always the case: See PR5252. > > I think that's the wrong PR number but I couldn't easily find the > correct one. Sorry, that should have been PR55252 Another relevant one is PR52998
[Bug sanitizer/61771] Regressions in ASan testsuite on ARM Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 --- Comment #3 from Evgeniy Stepanov --- Yes, FP on ARM is non-standard and differs in GCC and Clang implementations. Disabling fast unwind is not really an option, as you are looking at 10x, maybe 100x slowdown (depending of the app, of course). It should be possible to detect fp layout on the frame basis - there is a slot (don't know which one off the top of my head) that is FP in one compiler and return address in the other. Comparing its contents with the current stack limits (readily available in ASan) should do the trick. Of course, it would be awesome if we could synchronize (and document somewhere) FP stack layout between GCC and Clang - after all, there is no strong reason to do it one way or the other.
[Bug fortran/60898] model compile error with gfortran 4.7 and gcc 4.9 on Mac OS 10.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 --- Comment #10 from Dominique d'Humieres --- (In reply to Dominique d'Humieres from comment #4) > > After providing all the missing 'USE' items: > > Where did you get them? Adding the following at the beginning of the original test allows to get the error. MODULE kinds integer, parameter :: i_kind = 4, r_single = 4, r_double = 8 END MODULE kinds MODULE constants use kinds, only: r_kind => r_double real(r_kind), parameter :: zero=0.0 real(r_kind), parameter :: one=1.0 real(r_kind), parameter :: two=2.0 real(r_kind), parameter :: three=3.0 real(r_kind), parameter :: four=4.0 real(r_kind), parameter :: five=5.0 real(r_kind), parameter :: half=0.5 END MODULE constants MODULE MODULE_pmat1 END MODULE MODULE_pmat1
[Bug sanitizer/61771] Regressions in ASan testsuite on ARM Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 --- Comment #2 from Maxim Ostapenko --- So looks like fast unwinding in libsanitizer is not portable to GCC for ARM Linux target because of incompatible frame pointer value. But how is libsanitizer going to identify functions/object files compiled by GCC? Perhaps we should just disable fast unwind on ARM? -Maxim
[Bug c++/61814] New: [c++1y] cannot use decltype on captured arg-pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61814
Bug ID: 61814
Summary: [c++1y] cannot use decltype on captured arg-pack
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tongari95 at gmail dot com
The code below has a lambda that captures the outer params t, for forwarding
matter, decltype on t has to be used.
```
auto const pack = [](auto&&... t)
{
return [&](auto&& f)->decltype(auto)
{
return f(static_cast(t)...);
};
};
int main(int argc, char** argv) {
pack(1)([](int){});
return 0;
}
```
It works with clang 3.5, but g++ 4.9.0 complains:
error: 't' was not declared in this scope
The same also applies to `sizeof` or that kind of compile-time thing.
[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andreas Schwab --- You must be using some distro patch.
[Bug c++/25992] conditional expression and strings literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25992 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org
[Bug c/61813] New: __attribute__((__packed__)) does not pack struct containing uint16_t with uint32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61813
Bug ID: 61813
Summary: __attribute__((__packed__)) does not pack struct
containing uint16_t with uint32_t
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: steven.spark at gmail dot com
Created attachment 33125
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33125&action=edit
preprocessed bugreport_packed.c
Test case:
typedef struct __attribute__((__packed__)) {
uint16_t a;/// 2
uint32_t b; /// +4
uint32_t c[8]; /// +4*8 = 38
} foo_t;
but the size of foo_t is 40 (instead of the 38 which it should be). (It does
not matter where I put the packed attribute.)
I'm using the latest released mingw to date (4.8.1 rev 5).
I'm compiling on Windows 7 x64 (with mingw).
GCC config:
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.8.1/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/tmp/x64-481-win32-seh-r5/mingw64 --enable-shared
--enable-static --disable-multilib
--enable-languages=ada,c,c++,fortran,objc,obj-c++,lto
--enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp
--enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--disable-isl-version-check --disable-cloog-version-check
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-mpfr=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-mpc=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-isl=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-cloog=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--enable-cloog-backend=isl --with-pkgversion='rev5, Built by MinGW-W64 project'
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-I/tmp/x64-481-win32-seh-r5/libs/include -I/tmp/mingw-prereq/x64-zlib/include
-I/tmp/mingw-prereq/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe
-I/tmp/x64-481-win32-seh-r5/libs/include -I/tmp/mingw-prereq/x64-zlib/include
-I/tmp/mingw-prereq/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe
-L/tmp/x64-481-win32-seh-r5/libs/lib -L/tmp/mingw-prereq/x64-zlib/lib
-L/tmp/mingw-prereq/x86_64-w64-mingw32-static/lib
-L/tmp/x64-481-win32-seh-r5/mingw64/opt/lib '
Thread model: win32
gcc version 4.8.1 (rev5, Built by MinGW-W64 project)
command line
gcc bugreport_packed.c
or
gcc -v -save-temps -Wall -Wextra bugreport_packed.c
complete comiler output:
Using built-in specs.
COLLECT_GCC=C:\MinGW\x64-4.8.1-win32-seh-rev5\mingw64\bin\gcc
COLLECT_LTO_WRAPPER=c:/mingw/x64-4.8.1-win32-seh-rev5/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.8.1/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/tmp/x64-481-win32-seh-r5/mingw64 --enable-shared
--enable-static --disable-multilib
--enable-languages=ada,c,c++,fortran,objc,obj-c++,lto
--enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp
--enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--disable-isl-version-check --disable-cloog-version-check
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-mpfr=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-mpc=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-isl=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-cloog=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--enable-cloog-backend=isl --with-pkgversion='rev5, Built by MinGW-W64 project'
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-I/tmp/x64-481-win32-seh-r5/libs/include -I/tmp/mingw-prereq/x64-zlib/include
-I/tmp/mingw-prereq/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe
-I/tmp/x64-481-win32-seh-r5/libs/include -I/tmp/mingw-prereq/x64-zlib/include
-I/tmp/mingw-prereq/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe
-L/tmp/x64-481-win32-seh-r5/libs/lib -L/tmp/mingw-prereq/x64-zlib/lib
-L/tmp/mingw-prereq/x86_64-w64-mingw32-static/lib
-L/tmp/x64-481-win32-seh-r5/mingw64/opt/lib '
Thread model: win32
gcc version 4.8.1 (rev5, Built by MinGW-W64 project)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '
[Bug c++/61723] [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723 Jason Merrill changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #2 from Jason Merrill --- Agreed.
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #18 from Dominique d'Humieres --- > I did not say that iostat had to be used. However, one can find > things like: > > 9.10.1 Error conditions and the ERR= specifier > > If an error condition occurs during execution of an input/output > statement, the position of the file becomes indeterminate. > > 9.2.3.3 File position after data transfer > > If an error condition (9.10) occurred, the position of the file > is indeterminate. > > If one explicitly uses IOSTAT= in an IO statement, it may be > prudent to actually check its value. AFAICT this does not change the problem (see the tests in comments 2, 3, and 15). Now if "the position of the file becomes indeterminate", I believe it should be restored to a defined state after the error as been processed, either after the jump to the error label for ERR= or after setting the value of IOSTAT, see my comment > Along this line, I have found that 'parse_format' is called only once even > if 'ss' is called twice. in comment 15.
[Bug sanitizer/61771] Regressions in ASan testsuite on ARM Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 --- Comment #1 from Richard Earnshaw --- The ABI does not document a model for stack chains, so any use of a frame pointer is, by definition, purely private to that function.
[Bug c/61779] gcc -Og fails with impossible constraint on legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
--- Comment #7 from Vittorio Zecca ---
I forgot to mention that my code fragment comes from
#include
void
f(void)
{
for (;;)
_SDT_PROBE(0, 0, 1,(0));
}
Maybe you can find intelligent ways to exercise this code and find
more -Og bugs?
[Bug c++/61803] error reports macro location first, but should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803 Tom Tromey changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Tom Tromey --- > I would suggest file it against C++, just because there are more regular > contributors to C++ (Jason and Paolo) than to C (only Joseph and not nearly > as regular). I added the "diagnostic" keyword. > In this case yes, but this is not always the case: See PR5252. I think that's the wrong PR number but I couldn't easily find the correct one. I think the approach in this bug will yield the desired result more often. It seems to me that no approach can be perfect as the "real" location of the bug depends on human judgment and also the way that the macro is written. However, I believe the preponderance of macros are written in such a way that the error is at the point of use.
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #17 from Steve Kargl --- On Tue, Jul 15, 2014 at 09:08:44AM +, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 > > --- Comment #15 from Dominique d'Humieres --- > > Its sort of like Steve said earlier. The coder is choosing to ignore an > > error condition so anything gfortran does is valid. In this case the > > output got writen to buffer before the error occurred. You are bypassing > > all of the normal error handling when you do this. The buffer got flushed. > > > > Its not worth the time to change any of it really. > > > > The program should exit, its invalid. > > Well, I disagree with this interpretation: I did not find anywhere in the > standard that the variable set by iostat has to be used. I did not say that iostat had to be used. However, one can find things like: 9.10.1 Error conditions and the ERR= specifier If an error condition occurs during execution of an input/output statement, the position of the file becomes indeterminate. 9.2.3.3 File position after data transfer If an error condition (9.10) occurred, the position of the file is indeterminate. If one explicitly uses IOSTAT= in an IO statement, it may be prudent to actually check its value.
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #15 from dhowells at redhat dot com --- (In reply to Hans-Peter Nilsson from comment #14) > Could you please consider open a separate PR for the "is not reproducible" > misdisagnosis? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812
[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812 --- Comment #1 from dhowells at redhat dot com --- For an example ICE, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 This is easily reproducible, so the line is incorrect. It might be better stated conditionally: "If the bug is not reproducible, it is likely a hardware or OS problem."
[Bug c/61812] New: gcc ICE says "The bug is not reproducible, so it is likely a hardware or OS problem."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812 Bug ID: 61812 Summary: gcc ICE says "The bug is not reproducible, so it is likely a hardware or OS problem." Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dhowells at redhat dot com gcc ICE says "The bug is not reproducible, so it is likely a hardware or OS problem." at the end - even when this isn't true.
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #16 from Dominique d'Humieres ---
> This:
>
> +fmt->format_string_len = strrchr (f->source, ')') - f->source + 1;
>
>Is taking the difference between two string pointers, ie memory addresses
>
> This:
>
> printf("pos 0 =%x, pos ) =%x\n",strchr (f->source, '\0'),strrchr (f->source,
> ')'));
>
> Is printing the value of the pointers, the addresses.
>
> Are you expecting something different?
Well, I am fully aware that I am C challenged (the kind who can forget two
semicolons while writing a single line!). However the above is more or less
part of what I understand.
To clarify my question, let me summarize what I understand:
(1) This PR occurs iff 'f != NULL',
(2) The beginning of f->source is the unprocessed part of the format when the
error occurs, the last character of it being the closing ')' of the format,
(3) while I was expecting f->source being
unprocessed_part\0garbage
I have examples for which I see
unprocessed_partxxx\0garbage
where xxx are some extra characters (from 1 to ~15). My question was about the
origin of these characters.
Indeed I was not happy with 'strrchr (f->source, ')')' because it could find a
')' in the garbage after '\0'. In addition, valgrind complained about it.
I have regtested and ran my own tests with the following change
if (f != NULL)
-fmt->format_string = f->source;
+{
+ width = strlen (f->source);
+ for (i = width - 1; i > 0; i--)
+ {
+ if (f->source[i] == ')')
+ break;
+ width--;
+ }
+ fmt->format_string_len = width;
+}
This makes valgrind happy without regression (I know that this will fail if the
extra characters contain a ')', so far I did not crossed this situation).
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #14 from Hans-Peter Nilsson --- (In reply to dhowe...@redhat.com from comment #10) > (In reply to Hans-Peter Nilsson from comment #7) > > (In reply to dhowe...@redhat.com from comment #0) > > > I'm also very intrigued by that last line - I can reproduce it quite > > > easily. > > > > This is a RH local patch in your host gcc (by Jakub, IIRC) to help users > > re-running the actual ICEing command adding -save-temps. I'm guessing it > > has a bug and accidentally drops some option required to reproduce the > > ICE... > > It's in the gcc-4.9.0-20140702 tarball. Oh it finally made into the FSF repo, good! Could you please consider open a separate PR for the "is not reproducible" misdisagnosis?
[Bug c++/61811] New: [4.10 Regression] Firefox LTO build error due to undefined symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61811
Bug ID: 61811
Summary: [4.10 Regression] Firefox LTO build error due to
undefined symbols
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: hubicka at ucw dot cz, jason at gcc dot gnu.org
Firefox doesn't build with -flto on trunk. It fails due to undefined symbols
during linking of libxul. This only happens if -flto, -fno-rtti and
-fuse-all-virtuals are all enabled during the build.
Reduced testcase:
markus@x4 signaling_ecc % cat CC_SIPCCLine.ii
template class nsRefPtr
{
T *mRawPtr;
public:
typedef T element_type;
~nsRefPtr () { mRawPtr->Release (); }
void get ();
};
namespace CSF
{
class CC_Call
{
public:
void Release () { delete this; }
virtual ~CC_Call ();
};
class CC_SIPCCCallMediaData
{
public:
void Release ();
};
class A : public CC_Call
{
public:
static nsRefPtr wrap (int);
nsRefPtr pMediaData;
};
}
using namespace CSF;
void fn1 () { A::wrap (0).get (); }
markus@x4 signaling_ecc % c++filt
_ZN8nsRefPtrIN3CSF21CC_SIPCCCallMediaDataEED1Ev
nsRefPtr::~nsRefPtr()
markus@x4 signaling_ecc % c++ -o CC_SIPCCLine.o -c -fno-rtti -flto -O2
CC_SIPCCLine.ii
markus@x4 signaling_ecc % nm CC_SIPCCLine.o | grep
_ZN8nsRefPtrIN3CSF21CC_SIPCCCallMediaDataEED1Ev
U _ZN8nsRefPtrIN3CSF21CC_SIPCCCallMediaDataEED1Ev
markus@x4 signaling_ecc % c++ -o CC_SIPCCLine.o -c -flto -O2 CC_SIPCCLine.ii
markus@x4 signaling_ecc % nm CC_SIPCCLine.o | grep
_ZN8nsRefPtrIN3CSF21CC_SIPCCCallMediaDataEED1Ev
markus@x4 signaling_ecc % c++ -o CC_SIPCCLine.o -c -O2 CC_SIPCCLine.ii
markus@x4 signaling_ecc % nm CC_SIPCCLine.o | grep
_ZN8nsRefPtrIN3CSF21CC_SIPCCCallMediaDataEED1Ev
markus@x4 signaling_ecc % c++ -o CC_SIPCCLine.o -c -fno-rtti -O2
CC_SIPCCLine.ii
markus@x4 signaling_ecc % nm CC_SIPCCLine.o | grep
_ZN8nsRefPtrIN3CSF21CC_SIPCCCallMediaDataEED1Ev
markus@x4 signaling_ecc % c++ -o CC_SIPCCLine.o -c -fno-use-all-virtuals
-fno-rtti -flto -O2 CC_SIPCCLine.ii
markus@x4 signaling_ecc % nm CC_SIPCCLine.o | grep
_ZN8nsRefPtrIN3CSF21CC_SIPCCCallMediaDataEED1Ev
markus@x4 signaling_ecc %
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 --- Comment #4 from ktkachov at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #3) > how those tests fail? They seem to hit abort (); signal 6 in the emulator
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #13 from Hans-Peter Nilsson --- (In reply to dhowe...@redhat.com from comment #12) > (In reply to Hans-Peter Nilsson from comment #6) > > Created attachment 33121 [details] > > Patch to config.gcc > > > > Correct patch to config.gcc required to actually build the compiler proper. > > Okay, I've tried that. I can't see that it makes any obvious difference. > Is there something I should look for? Oh, it wasn't meant as a fix to the problem at hand, just a replacement for the prerequisite patch. The differences to *that* one is that the duplicate t-slibgcc t-linux are removed and the comment too, after checking why I had it; likely a libgcc-related issue with headers (and so moot after the libgcc split years ago).
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 --- Comment #3 from Jan Hubicka --- how those tests fail?
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
--- Comment #5 from Richard Biener ---
;; --- Region Dependences --- b 12 bb 0
;; insn codebb dep prio cost reservation
;; -- --- ---
...
;; 2399012 1 5 1
athlon-direct,athlon-agu,athlon-store : 127 123n 122nm 240
...
;; 122-112 7 0 0 nothing : 124 123nm 243 216m
;; 2169012 0 5 3 athlon-direct,athlon-load : 127
123nm 243
...
which maps to:
(insn 239 116 240 12 (set (mem/c:SI (reg/f:SI 7 sp) [11 %sfp+-16 S4 A32])
(reg:SI 0 ax [orig:127 cmdp_14(D)->syscall_no ] [127]))
bug-887141_pthread_create.1.min.i:77 90 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 0 ax [orig:127 cmdp_14(D)->syscall_no ] [127])
(nil)))
...
(debug_insn 122 120 216 12 (var_location:SI resultvar (asm_operands/v:SI
("xchgl %%ebx, %%edi
int $0x80
xchgl %%edi, %%ebx
") ("=a") 0 [
(mem/c:SI (reg/f:SI 7 sp) [11 %sfp+-16 S4 A32])
(reg:SI 5 di [orig:128 cmdp_14(D)->id ] [128])
(reg:SI 2 cx [orig:129 cmdp_14(D)->id+4 ] [129])
(reg:SI 1 dx [orig:130 cmdp_14(D)->id+8 ] [130])
]
[
(asm_input:SI ("0") bug-887141_pthread_create.1.min.i:77)
(asm_input:SI ("D") bug-887141_pthread_create.1.min.i:77)
(asm_input:SI ("c") bug-887141_pthread_create.1.min.i:77)
(asm_input:SI ("d") bug-887141_pthread_create.1.min.i:77)
]
[] bug-887141_pthread_create.1.min.i:77))
bug-887141_pthread_create.1.min.i:77 -1
(nil))
(insn 216 122 243 12 (set (reg/v:SI 4 si [orig:84 result ] [84])
(mem/c:SI (reg/f:SI 7 sp) [11 %sfp+-16 S4 A32]))
bug-887141_pthread_create.1.min.i:77 90 {*movsi_internal}
(nil))
insn 123 is the real asm. Not sure if the dependence of 239 via 122 to 216
is supposed to prevent scheduling 216 before 239. If so, then dependence
information is correct. The only forward dependence to 216 is really from
the debug insn.
But then:
;; dependencies resolved: insn 238
;; tick updated: insn 238 into ready
;; dependencies resolved: insn 216
;; tick updated: insn 216 into ready
;; Advanced a state.
;; Ready list after queue_to_ready: 216:67:prio=5 238:59:prio=11
what? 216 is already ready?
;; Ready list (t = 0):216:67:prio=5 238:59:prio=11
;;0--> b 0: i 238 ax=[sp+0x30]
:athlon-direct,athlon-load
;; dependencies resolved: insn 116
;; Ready-->Q: insn 116: queued for 3 cycles (change queue index).
;; tick updated: insn 116 into queue with cost=3
;; Ready list after ready_sort: 216:67:prio=5
;; Ready list (t = 0):216:67:prio=5
;;0--> b 0: i 216 si=[sp]
:athlon-direct,athlon-load
;; resetting: debug insn 122
yeah, so we reset the debug insn. But ignored the indirect dependence from
239.
Now, of course I'm lost in the scheduler code, not knowing how it is intended
to work with debug-insns.
As a band-aid fix I'd simply never generate debug_insns with asms ...
[Bug bootstrap/61809] [4.10 regression] fold-const.c:14865:47: error: 'DECL_ARGUMENT' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809 --- Comment #3 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809 > > --- Comment #2 from Dominique d'Humieres --- > Are you sure that r212549 fails? I'ld rather suspect a typo in r212550, i.e., > DECL_ARGUMENT instead of DECL_ARGUMENT_FLD. Should be DECL_ARGUMENTS. Will commit the obvious patch. Honza
[Bug rtl-optimization/61772] RTL if-conversion removes asm volatile goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61772 --- Comment #2 from Michael Matz --- Author: matz Date: Tue Jul 15 14:11:06 2014 New Revision: 212563 URL: https://gcc.gnu.org/viewcvs?rev=212563&root=gcc&view=rev Log: PR rtl-optimization/61772 * ifcvt.c (dead_or_predicable): Check jump to be free of side effects. testsuite/ * gcc.dg/torture/pr61772.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61772.c Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/61723] [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini --- I find this testcase rather weird: std::initializer_list isn't a random user type: we have non-trivial "magic" in the front-end which *assumes* the actual definition in our header. You can see this in the testcase here too, because the ICEs disappear if _M_len is declared as an (unsigned) __SIZE_TYPE__ (not as an int) and an additional field _M_array is added too (see our actual std::initializer_list for details). If you ask me, the Bug Report seems invalid to me or at least very low priority, unless a version of it not redefining std::initializer_list exists.
[Bug debug/49090] provide a way to recognize defaulted template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090 --- Comment #12 from Jonathan Wakely --- r212555 addresses this issue for certain std::lib types, but not for the general case
[Bug bootstrap/61809] [4.10 regression] fold-const.c:14865:47: error: 'DECL_ARGUMENT' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809 --- Comment #2 from Dominique d'Humieres --- Are you sure that r212549 fails? I'ld rather suspect a typo in r212550, i.e., DECL_ARGUMENT instead of DECL_ARGUMENT_FLD.
[Bug bootstrap/61809] [4.10 regression] fold-const.c:14865:47: error: 'DECL_ARGUMENT' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809 Dmitry G. Dyachenko changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Dmitry G. Dyachenko --- r212549 FAIL r212540 PASS
[Bug target/61810] New: init-regs.c papers over issues elsewhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61810
Bug ID: 61810
Summary: init-regs.c papers over issues elsewhere
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: missed-optimization, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target: x86_64-*-*, i?86-*-*
Earlier this year Uli complained about undefined uses generating
code in the context of implementing _mm_undefined x86 intrinsics
in the "GCC way". Example:
extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_undefined_pd (void)
{
__m128d __Y = __Y;
return __Y;
}
and the culprit was found to be the init-regs pass which initializes
all must-undefined but used pseudos with zero. That has been
introduced with the dataflow-merge with some big handwaving
comment (and no testcase as far as we could see):
/* Check all of the uses of pseudo variables. If any use that is MUST
uninitialized, add a store of 0 immediately before it. For
subregs, this makes combine happy. For full word regs, this makes
other optimizations, like the register allocator and the reg-stack
happy as well as papers over some problems on the arm and other
processors where certain isa constraints cannot be handled by gcc.
These are of the form where two operands to an insn my not be the
same. The ra will only make them the same if they do not
interfere, and this can only happen if one is not initialized.
There is also the unfortunate consequence that this may mask some
buggy programs where people forget to initialize stack variable.
Any programmer with half a brain would look at the uninitialized
variable warnings. */
Of course earlier this year it wasn't the appropriate time to
kill off init-regs (which doesn't run at -O0 btw...). But now
it is.
All of the issues in the comment at the top of init-regs.c
point to issues elsewhere - papering over them by means
of init-regs.c isn't a correct solution - especially as
passes between init-regs and $issue may expose must-undefined
but used pseudos (if-conversion for example).
Disabling init-regs.c by adjusting its gate to always return 0 causes
FAIL: gcc.dg/vect/vect-strided-a-u8-i8-gap7.c execution test
on x86_64 and
FAIL: gcc.dg/vect/vect-strided-a-u16-i4.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i8-gap7.c execution test
FAIL: gcc.dg/vect/vect-strided-u8-i8-gap7-big-array.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i4.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-a-u8-i8-gap7.c -flto -ffat-lto-objects execution
test
on x86_64 -m32
no other FAILs (the comment hints at more issues on other targets).
Patch to disable init-regs (apart from the above bootstraps/tests ok
on x86_64)
Index: gcc/init-regs.c
===
--- gcc/init-regs.c (revision 212520)
+++ gcc/init-regs.c (working copy)
@@ -147,7 +147,7 @@ public:
{}
/* opt_pass methods: */
- virtual bool gate (function *) { return optimize > 0; }
+ virtual bool gate (function *) { return 0; }
virtual unsigned int execute (function *)
{
initialize_uninitialized_regs ();
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target|aarch64-none-elf|aarch64-none-elf, arm* --- Comment #2 from ktkachov at gcc dot gnu.org --- Appears on arm as well. It seems like every execution test with -flto fails
[Bug bootstrap/61809] New: [4.10 regression] fold-const.c:14865:47: error: 'DECL_ARGUMENT' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809 Bug ID: 61809 Summary: [4.10 regression] fold-const.c:14865:47: error: 'DECL_ARGUMENT' was not declared in this scope Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dimhen at gmail dot com r212556 FAIL r212517 PASS ~/src/gcc_current/configure --enable-checking=fold --disable-multilib make [...] make[3]: Entering directory `/home/dimhen/build/gcc_current/gcc' g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/home/dimhen/src/gcc_current/gcc -I/home/dimhen/src/gcc_current/gcc/. -I/home/dimhen/src/gcc_current/gcc/../include -I/home/dimhen/src/gcc_current/gcc/../libcpp/include -I/home/dimhen/build/gcc_current/./gmp -I/home/dimhen/src/gcc_current/gmp -I/home/dimhen/build/gcc_current/./mpfr -I/home/dimhen/src/gcc_current/mpfr -I/home/dimhen/src/gcc_current/mpc/src -I/home/dimhen/src/gcc_current/gcc/../libdecnumber -I/home/dimhen/src/gcc_current/gcc/../libdecnumber/bid -I../libdecnumber -I/home/dimhen/src/gcc_current/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/dimhen/build/gcc_current/./cloog/include -I/home/dimhen/src/gcc_current/cloog/include -I/home/dimhen/build/gcc_current/./isl/include -I/home/dimhen/src/gcc_current/isl/include -o fold-const.o -MT fold-const.o -MMD -MP -MF ./.deps/fold-const.TPo /home/dimhen/src/gcc_current/gcc/fold-const.c /home/dimhen/src/gcc_current/gcc/fold-const.c: In function 'void fold_checksum_tree(const_tree, md5_ctx*, hash_table >*)': /home/dimhen/src/gcc_current/gcc/fold-const.c:14865:47: error: 'DECL_ARGUMENT' was not declared in this scope fold_checksum_tree (DECL_ARGUMENT (expr), ctx, ht); ^ make[3]: *** [fold-const.o] Error 1 make[3]: Leaving directory `/home/dimhen/build/gcc_current/gcc'
[Bug c++/25992] conditional expression and strings literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25992 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|anton.kirillov@rd-software. | |com, gcc-bugs at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #6 from Paolo Carlini --- Mine.
[Bug web/61782] always_inline incorrectly documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782 Richard Biener changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- Patch posted.
[Bug c++/61808] New: Linking error with explicit template instantiation and default template param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61808
Bug ID: 61808
Summary: Linking error with explicit template instantiation and
default template param
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gael.guennebaud at gmail dot com
Created attachment 33124
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33124&action=edit
Tarball of the files to reproduce the issue.
Here is small example which fails to compile with gcc but works well with other
compilers. Compiling the files with:
$ g++ func.cpp main.cpp
produces the following error:
Undefined symbols for architecture x86_64:
"void foo<2>(Bar::Matrix<2, (2)+((int)((Bar::._1)0))>&)", referenced from:
_main in ccZW4Wal.o
You can workaround the issue doing either:
1 - In main.cpp, line 3: remove the declaration"enum { fifi = sizeof(int) };"
2 - In main.cpp, move the above declaration after including func.h
3 - In either func.h or main.cpp, replace one (or both) anonymous enum
declaration with a non-anonymous one.
4 - Move the explicit template declaration from func.cpp to main.cpp.
A real-word use case is described there:
http://stackoverflow.com/questions/24730981/undefined-reference-error-from-gcc-using-a-template-with-a-stdvector-and-an-ei
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 --- Comment #4 from Richard Biener --- Created attachment 33123 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33123&action=edit more reduced On trunk reproduces with the following slightly more manual reduced testcase and -O2 -m32 -g (so even without -fPIC).
[Bug c++/61807] New: genautomata.c fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61807 Bug ID: 61807 Summary: genautomata.c fails to compile Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: y.rajesh.4683 at gmail dot com I am compiling GCC for Octeon board. I keep getting the following errors. /mnt/data/archive/GCC/gcc_4.9_1/prev-mips64-octeon-linux-gnu/libstdc++-v3/include/mips64-octeon-linux-gnu/bits/mathcalls.h:364:1: warning: invoking macro __MATH_PRECNAME argument 2: empty macro arguments are undefined in ISO C90 and ISO C++98 In file included from .././../gcc-4.9.0/gcc/system.h:642:0, from .././../gcc-4.9.0/gcc/genautomata.c:108: /mnt/data/archive/GCC/gcc_4.9_1/prev-mips64-octeon-linux-gnu/libstdc++-v3/include/mips64-octeon-linux-gnu/dlfcn.h:167:21: warning: comma at end of enumerator list [-Wpedantic] RTLD_DI_MAX = 10, ^ .././../gcc-4.9.0/gcc/genautomata.c: In function 'char* next_sep_el(const char**, int, int)': .././../gcc-4.9.0/gcc/genautomata.c:1181:11: error: invalid conversion from 'void*' to 'char*' [-fpermissive] out_str = obstack_base (&irp); ^ In file included from .././../gcc-4.9.0/gcc/genautomata.c:112:0: .././../gcc-4.9.0/gcc/genautomata.c: In function 'const char* regexp_representation(regexp_t)': /mnt/data/archive/GCC/gcc_4.9_1/prev-mips64-octeon-linux-gnu/libstdc++-v3/include/mips64-octeon-linux-gnu/obstack.h:206:51: error: invalid conversion from 'void*' to 'const char*' [-fpermissive] #define obstack_base(h) ((void *) (h)->object_base) ^ .././../gcc-4.9.0/gcc/genautomata.c:6876:10: note: in expansion of macro 'obstack_base' return obstack_base (&irp); ^ Can I case the return value of the obstack_base to avoid this problem.
[Bug web/61782] always_inline incorrectly documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #4 from Jonathan Wakely ---
(In reply to Richard Biener from comment #3)
> Like
>
> @item always_inline
> @cindex @code{always_inline} function attribute
> Generally, functions are not inlined unless optimization is specified.
> For functions declared inline, this attribute inlines the function
> independent of any restrictions that otherwise apply to inlining.
> Failure to inline such function is diagnosed as error.
Failure to inline such a function is diagnosed as an error.
^ ^^
> Note that if such function is called indirectly the compiler may
Note that if such a function is called indirectly the compiler may
^
> or may not inline it dependent on optimization level and a failure
I think I'd say s/dependent/depending/ here.
> to inline an indirect call may or may not be diagnosed.
[Bug c/61779] gcc -Og fails with impossible constraint on legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779 --- Comment #6 from rguenther at suse dot de --- On Tue, 15 Jul 2014, zeccav at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779 > > --- Comment #5 from Vittorio Zecca --- > I just applied your fix and now gcc compiles succesfully with -Og. Thanks for the feedback on -Og btw - it hasn't seen very much testing coverage yet. Probably because the advertised fast compile-time is still much slower than with -O0.
[Bug c/61779] gcc -Og fails with impossible constraint on legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779 --- Comment #5 from Vittorio Zecca --- I just applied your fix and now gcc compiles succesfully with -Og.
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 Richard Biener changed: What|Removed |Added Keywords||missed-optimization, ra CC||aoliva at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Known to fail||4.10.0, 4.8.3, 4.9.1 --- Comment #3 from Richard Biener --- Reduced testcase also reproduces the bug with 4.9 and trunk (but not 4.7): movl64(%esp), %eax # cmdp, tmp206 movl4(%esp), %esi # %sfp, result .LVL36: movl(%eax), %eax# cmdp_30(D)->syscall_no, cmdp_30(D)->syscall_no movl%eax, 4(%esp) # cmdp_30(D)->syscall_no, %sfp .LVL37: movl64(%esp), %eax # cmdp, tmp208 movl4(%eax), %edi # cmdp_30(D)->id, cmdp_30(D)->id movl8(%eax), %ecx # cmdp_30(D)->id, cmdp_30(D)->id movl12(%eax), %edx # cmdp_30(D)->id, cmdp_30(D)->id movl%esi, %eax # result, result #APP # 75 "bug-887141_pthread_create.1.min.i" 1 xchgl %ebx, %edi int $0x80 xchgl %edi, %ebx Note that 4.7 doesn't spill %eax but generates movl0(%ebp), %esi # cmdp_18(D)->syscall_no, result .LVL45: movl4(%ebp), %edi # cmdp_18(D)->id, cmdp_18(D)->id movl8(%ebp), %ecx # cmdp_18(D)->id, cmdp_18(D)->id movl12(%ebp), %edx # cmdp_18(D)->id, cmdp_18(D)->id movl%esi, %eax # result, #APP # 75 "bug-887141_pthread_create.1.min.i" 1 xchgl %ebx, %edi int $0x80 xchgl %edi, %ebx which would be an IRA issue?
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 --- Comment #2 from Richard Biener --- Created attachment 33122 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33122&action=edit autoreduced testcase Autoreduced testcase.
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #12 from dhowells at redhat dot com --- (In reply to Hans-Peter Nilsson from comment #6) > Created attachment 33121 [details] > Patch to config.gcc > > Correct patch to config.gcc required to actually build the compiler proper. Okay, I've tried that. I can't see that it makes any obvious difference. Is there something I should look for?
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #11 from dhowells at redhat dot com --- (In reply to Hans-Peter Nilsson from comment #3) > > libgcc is built with: > > make -C cris-linux-gnu tooldir=/usr all-target-libgcc > > I'd expect "make all-target-libgcc" to Just Work. So would I. However, it doesn't work for all arches that the SRPM builds a cross-compiler for. I need the compiler to build the kernel, but not normally libgcc, however, I've been asked to build libgcc if I can. The arches for which I can't build libgcc include: cris, sh, sh64 and tile.
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 --- Comment #1 from Richard Biener --- Auto-reduring (matching the bogus assembler pattern).
[Bug ipa/61671] [4.10 regression] lto1: ICE in types_same_for_odr, at ipa-devirt.c:365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61671 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jan Hubicka --- Fixed. I will commit the testcase
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #10 from dhowells at redhat dot com --- (In reply to Hans-Peter Nilsson from comment #7) > (In reply to dhowe...@redhat.com from comment #0) > > I'm also very intrigued by that last line - I can reproduce it quite easily. > > This is a RH local patch in your host gcc (by Jakub, IIRC) to help users > re-running the actual ICEing command adding -save-temps. I'm guessing it > has a bug and accidentally drops some option required to reproduce the ICE... It's in the gcc-4.9.0-20140702 tarball.
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 --- Comment #1 from ktkachov at gcc dot gnu.org --- There's actually quite a lot of -flto failures (all of them?) besides the ones posted here all over the gcc testsuite
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 Richard Biener changed: What|Removed |Added Keywords||lto, wrong-code Priority|P3 |P1 Target Milestone|--- |4.10.0 Summary|AArch64 execute.exp |[4.10 Regression] AArch64 |failures with LTO after |execute.exp failures with |r212467 |LTO after r212467
[Bug web/61782] always_inline incorrectly documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #3 from Richard Biener ---
Like
@item always_inline
@cindex @code{always_inline} function attribute
Generally, functions are not inlined unless optimization is specified.
For functions declared inline, this attribute inlines the function
independent of any restrictions that otherwise apply to inlining.
Failure to inline such function is diagnosed as error.
Note that if such function is called indirectly the compiler may
or may not inline it dependent on optimization level and a failure
to inline an indirect call may or may not be diagnosed.
which matches how GCC behaves (last sentence)?
Corrections welcome (I am not a native speaker).
