https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92096
--- Comment #5 from Roger Orr ---
Hello Jakub, I've checked; I no longer see this fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92096
--- Comment #3 from Roger Orr ---
A binary chop shows the fault starts with r276878.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358
--- Comment #23 from Roger Orr ---
That's good to hear -- thank you very much!
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Created attachment 30547
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30547&action=edit
sample program -- I believe this should compi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57973
--- Comment #2 from Roger Orr ---
Thank you. Aoplogies for the noise.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
If a function is declared with a default argument of a template type the
compiler fails if the constructor cannot be instantiated at the point of
definition of the function.
As I understand it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68957
Roger Orr changed:
What|Removed |Added
CC||rogero at howzatt dot
demon.co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68957
--- Comment #3 from Roger Orr ---
Thanks Jon.
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
I using this invocation:
../gcc-trunk/configure --disable-bootstrap --enable-languages=c,c++
--enable-threads=posi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92096
--- Comment #2 from Roger Orr ---
Hello Richard,
PR92037 appears to be resolved in revision 276804, which precedes the first of
my failing revisions (276902).
FWIW it was still failing last night with 276968
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
CC: marxin at gcc dot gnu.org
Target Milestone: ---
When object modules compiled with -std=c+14 and -std=c++17 are linked together
with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506
--- Comment #1 from Roger Orr ---
See also http://permalink.gmane.org/gmane.os.cygwin/156987
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
A complete build of gcc on cygwin, with change 232071 backed out (see pr66655),
works with revision 232453 but fails with revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506
--- Comment #3 from Roger Orr ---
Tested: bootstrap build on cygwin with your patch completed successfully.
I used:
../gcctrunk/configure --enable-languages=c,c++ --prefix=/usr/share/gcc-trunk
make -j5
make install
Thank you :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #39 from Roger Orr ---
The resolution of this issue causes a problem for me as it results in
compilation errors in our build.
We are compiling with distcc which AIUI distributes the pre-processed
intermediate output.
With revision 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #41 from Roger Orr ---
I have seen the message before: for example from a build with revision
line-map.c: file "/usr/include/asm/sockios.h" left but not entered
I've only noticed it with builds from gcc-trunk, which I tested with b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #44 from Roger Orr ---
Created attachment 38218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38218&action=edit
Intermediate file
I am as yet unable to upload the code for an example.
However, I've attached a file containing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #45 from Roger Orr ---
While investigating the problem I am experiencing I have found it is stable
across g++ builds - I have tried a build using revision 234741 which has the
identical diagnostic output from the compilation.
However
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #47 from Roger Orr ---
Sorry, I wasn't clear enough. I'm unfortunately not at present able to post the
whole source file.
The file I posted *only* contains the line directives, so people can confirm
whether there were any problems wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #49 from Roger Orr ---
Alas, valgrind finds nothing untoward.
make MAKEINFO=true STAGE1_CXXFLAGS="-g -O0" clean-stage1
make MAKEINFO=true STAGE1_CXXFLAGS="-g -O0" all-stage1
valgrind /var/tmp/gcc-trunk-234481/build/gcc/cc1plus -fpre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #51 from Roger Orr ---
Thanks, I hope to try that on Monday.
The function gets called multiple times, so I need to identify the last time.
The memory must have changed *during* the call to do_linemarker as the new_file
variable is se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #52 from Roger Orr ---
Ah - added print of *pfile->line_table at line 978 and compared with the value
when we error.
978 struct line_maps *line_table = pfile->line_table;
$3702 = {info_ordinary = {maps = 0x7fffec65d000, alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #54 from Roger Orr ---
Unfortunately the patch does not help: the cached 'from' pointer is a pointer
into the old maps entry -- the one which has now been deallocated.
The first test, main_file_p, now (correctly) fails.
The second t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #55 from Roger Orr ---
Note - I should have added that I am not at all sure the fix above is
*correct*, simply that it prevents accessing the freed entry.
I don't know enough about how the code works to know whether the value obtaine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #57 from Roger Orr ---
Created attachment 38232
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38232&action=edit
Stripped down intermediate file
I've managed to reproduce the problem without including any proprietary code -
cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #60 from Roger Orr ---
Thanks; I can now confirm that a full build of our application with distcc
works without problems.
ty: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70712
--- Comment #5 from Roger Orr ---
Thank you.
I can confirm that the fix also resolves the original problem from which I
derived the sample program.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53984
--- Comment #5 from Roger Orr ---
Still fails with gcc 6.1
Are there any plans on how (and when) to fix this, fairly serious, fault?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71059
--- Comment #4 from Roger Orr ---
Thanks, fixes the ICE I had.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71015
Roger Orr changed:
What|Removed |Added
CC||rogero at howzatt dot
demon.co.uk
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
Created attachment 38545
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38545&action=edit
Example code, fai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71240
--- Comment #1 from Roger Orr ---
(The example code compiles with gcc revision 236175, dated 20160512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71240
--- Comment #11 from Roger Orr ---
Thanks.
I can confirm this also successfully compiles the original code from which I
derived the simplified example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269
Roger Orr changed:
What|Removed |Added
CC||rogero at howzatt dot
demon.co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269
--- Comment #6 from Roger Orr ---
Created attachment 38563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38563&action=edit
compiler invocation and output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269
--- Comment #7 from Roger Orr ---
I've got a very similar problem, building valgrind with trunk revision 236644:
m_mallocfree.c: In function 'sanity_check_malloc_arena':
m_mallocfree.c:1055:13: internal compiler error: Segmentation fault
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71252
--- Comment #13 from Roger Orr ---
The patch sadly does not appear to fix the (very similar looking) valgrind
compilation failure I posted in pr71269.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269#c7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269
--- Comment #13 from Roger Orr ---
Ok, I'll try with trunk (I'd not noticed a relevant change had already been
submitted)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71252
--- Comment #15 from Roger Orr ---
Sorry for the noise; I'd not noticed there had been a relevant commit.
I'll re-check against trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269
--- Comment #14 from Roger Orr ---
Confirmed: valgrind now builds successfully with revision 236769.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
The following code fails to compile:
CODE
template
void sizeof_mismatch()
{
static_assert(T == 0, "sizeof mismatch");
}
int main()
{
if constexpr(s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65525
--- Comment #7 from Roger Orr ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64181
--- Comment #1 from Roger Orr ---
The optimization is also broken in the 5.0 head (5.0.0.20150328)
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
Target: x86_64-redhat-linux
Created attachment 35667
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35667&acti
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
When declaring a variable with a bracketed constructor call, and using the same
external name for the first argument and a template instantiation u
NCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67515
--- Comment #4 from Roger Orr ---
Ah - apologies -- I'd got the example by stripping down a call in boost::format
and didn't do a full enough check that the code was well formed: I'll report
that UB to boost.
However as Markus says the seg fault
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
When -fsanitize=address is supplied the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63559
--- Comment #2 from Roger Orr ---
Hi Dmitry,
the false positives I've investigated seem to be down to spin-locked queues and
use of intel tbb concurrency data structures - AFAICT we don't have source for
the latter so I wouldn't expect tsan to re
: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63627
--- Comment #1 from Roger Orr ---
Created attachment 33792
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33792&action=edit
Example using __atomic_exchange_n that does not generate tsan warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917
Roger Orr changed:
What|Removed |Added
CC||rogero at howzatt dot
demon.co.uk
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Created attachment 34188
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34188&action=edit
Demonstration of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66259
Roger Orr changed:
What|Removed |Added
CC||rogero at howzatt dot
demon.co.uk
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
I notice that is no longer consistently prefixing forward with
std:: and this means ADL gets invoked, which causes trouble when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68982
--- Comment #2 from Roger Orr ---
Created attachment 37082
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37082&action=edit
Example of failure, against code using boost 1.57.0
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
Created attachment 37093
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37093&action=edit
ice-example.cpp: Example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69000
--- Comment #2 from Roger Orr ---
Thanks: apologies that my bugzilla-fu failed to find the duplicate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66808
--- Comment #8 from Roger Orr ---
Thank you.
I've tested the fix and it successfully compiles works both the sample program
uploaded to my duplicate pr69000 and also my original presenting case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68982
--- Comment #5 from Roger Orr ---
Thank you ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67515
--- Comment #10 from Roger Orr ---
Hello Yury, yes the problem with boost was reported as
https://svn.boost.org/trac/boost/ticket/11632
and the ticket contains a proposed solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
Roger Orr changed:
What|Removed |Added
CC||rogero at howzatt dot
demon.co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #14 from Roger Orr ---
I don't know I'm afraid: I'm a very occasional mingw user and I haven't
(yet...) tried building gcc on mingw...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #17 from Roger Orr ---
As you say, there seems to be another, unrelated, problem with the current
trunk and cygwin.
However, I have now successfully built gcc version 232300 under cygwin with
this patch.
Unfortunately, if I try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #18 from Roger Orr ---
What is the correct way forward with this issue?
Should we reopen this issue, or open a fresh one? (I'm not familiar enough with
the gcc use of bugzilla to know.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #24 from Roger Orr ---
Thanks Nick.
I've tried the patch (applied to 232400 as trunk seems to have other problems
on cygwin) and the build now completes successfully.
Additionally, the test case no longer crashes.
$ /usr/share/gcc-
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
The initialization of a VLA char array from a string literal in C++ mode is
surprising: the code appears to copy a string literal starting with the NUL
char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69487
--- Comment #2 from Roger Orr ---
A braced initializer of characters appears to work consistently with both
compile time and run time arrays.
char buffer[size] = { 'a', 'b' };
produces a buffer with 'a', 'b' and zero padded whether size is a co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #32 from Roger Orr ---
(In reply to Nick Clifton from comment #26)
> Hi Roger,
>
> > I've tried the patch (applied to 232400 as trunk seems to have other
> > problems on cygwin) and the build now completes successfully.
>
> Includin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65152
--- Comment #3 from Roger Orr ---
Note that this has been fixed in gcc-trunk (tested 22-Aug-2015)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66343
--- Comment #1 from Roger Orr ---
Fails for me (with a very slightly different label: Lubsan_type0) on gcc-trunk
(as of 2015-08-22) without needing the -m32:
$ /usr/share/gcc-trunk/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/share/gcc-trun
: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
The following code generates -Wodr warnings wih gcc 5.2.0
$ cat common.hxx
template
struct values{
typedef T const CT;
};
$ cat test1.cxx
#include "commo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67357
--- Comment #2 from Roger Orr ---
The fault still occurs on gcc-5-branch, does not occur on gcc trunk.
I have also found that making a small change to the example in comment 5 of PR
66180 makes that fail with gcc 5.2.0: adding const to the type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67357
--- Comment #3 from Roger Orr ---
The following code block also gives an ODR violation with the same versions of
gcc; in this case only a *single* translation unit is involved.
$ cat test.cxx
#include
template
class D : public T {
using mf
75 matches
Mail list logo
