[Bug ada/71911] [Cygwin] "gnatclean program" will remove the standard package .ali file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71911 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-08-10 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- How was the compiler configured? Which permissions have the ALI files?
[Bug ipa/65483] bzip2 bsR/bsW should be auto-inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483 --- Comment #5 from Andrew Pinski --- Does this still happen or do we need to crank up the inlining limits still?
[Bug c/72859] New: Building GCC Cross-Compiler on cygwin for PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72859 Bug ID: 72859 Summary: Building GCC Cross-Compiler on cygwin for PowerPC Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: 993870b5 at opayq dot com Target Milestone: --- Following the instructions on http://wiki.osdev.org/GCC_Cross-Compiler I have been trying to build a GCC C language cross-compiler for Powerpc-eabi architecture using Cygwin on Windows 7 32bit. I downloaded following software Cygwin 2.5.2 GCC version 5.4.0 binutils 2.26 I have successfully bulit and installed binutils-2.26 I have executed following configure command: ../gcc-5.4.0/configure --target=powerpc-eabi --prefix=/home/user/opt/cross --disable-nls --enable-languages=c --without-headers when I execute the command: make all-gcc after a while, the following error is generated. ... g++ -c-g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-5.4.0/gcc -I../../gcc-5.4.0/gcc/build -I../../gcc-5.4.0/gcc/../include -I../../gcc-5.4.0/gcc/../libcpp/include -o build/genpreds.o ../../gcc-5.4.0/gcc/genpreds.c In file included from ../../gcc-5.4.0/gcc/rtl.h:26:0, from ../../gcc-5.4.0/gcc/genpreds.c:27: ../../gcc-5.4.0/gcc/real.h:43:35: warning: division by zero [-Wdiv-by-zero] #define SIGSZ (SIGNIFICAND_BITS / HOST_BITS_PER_LONG) ^ ../../gcc-5.4.0/gcc/real.h:56:21: note: in expansion of macro ‘SIGSZ’ unsigned long sig[SIGSZ]; ^ ../../gcc-5.4.0/gcc/real.h:56:26: error: size of array ‘sig’ is not an integral constant-expression unsigned long sig[SIGSZ]; ^ make[1]: *** [Makefile:2429: build/genpreds.o] Error 1 make[1]: Leaving directory '/home/user/build-gcc/gcc' make: *** [Makefile:4100: all-gcc] Error 2 The cause of error seems to be the missing definition of HOST_BITS_PER_LONG in file rtl.h. removing the -pedantic option from the Makefile did not result in any difference.
[Bug c/72860] New: Building GCC Cross-Compiler on cygwin for PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72860 Bug ID: 72860 Summary: Building GCC Cross-Compiler on cygwin for PowerPC Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: 993870b5 at opayq dot com Target Milestone: --- Following the instructions on http://wiki.osdev.org/GCC_Cross-Compiler I have been trying to build a GCC C language cross-compiler for Powerpc-eabi architecture using Cygwin on Windows 7 32bit. I downloaded following software Cygwin 2.5.2 GCC version 5.4.0 binutils 2.26 I have successfully bulit and installed binutils-2.26 I have executed following configure command: ../gcc-5.4.0/configure --target=powerpc-eabi --prefix=/home/user/opt/cross --disable-nls --enable-languages=c --without-headers when I execute the command: make all-gcc after a while, the following error is generated. ... g++ -c-g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-5.4.0/gcc -I../../gcc-5.4.0/gcc/build -I../../gcc-5.4.0/gcc/../include -I../../gcc-5.4.0/gcc/../libcpp/include -o build/genpreds.o ../../gcc-5.4.0/gcc/genpreds.c In file included from ../../gcc-5.4.0/gcc/rtl.h:26:0, from ../../gcc-5.4.0/gcc/genpreds.c:27: ../../gcc-5.4.0/gcc/real.h:43:35: warning: division by zero [-Wdiv-by-zero] #define SIGSZ (SIGNIFICAND_BITS / HOST_BITS_PER_LONG) ^ ../../gcc-5.4.0/gcc/real.h:56:21: note: in expansion of macro ‘SIGSZ’ unsigned long sig[SIGSZ]; ^ ../../gcc-5.4.0/gcc/real.h:56:26: error: size of array ‘sig’ is not an integral constant-expression unsigned long sig[SIGSZ]; ^ make[1]: *** [Makefile:2429: build/genpreds.o] Error 1 make[1]: Leaving directory '/home/user/build-gcc/gcc' make: *** [Makefile:4100: all-gcc] Error 2 The cause of error seems to be the missing definition of HOST_BITS_PER_LONG in file rtl.h. removing the -pedantic option from the Makefile did not result in any difference.
[Bug c/72859] Building GCC Cross-Compiler on cygwin for PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72859 --- Comment #1 from Andrew Pinski --- *** Bug 72860 has been marked as a duplicate of this bug. ***
[Bug c/72860] Building GCC Cross-Compiler on cygwin for PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72860 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 72859 ***
[Bug bootstrap/72859] Building GCC Cross-Compiler on cygwin for PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72859 Andrew Pinski changed: What|Removed |Added Target||powerpc-eabi Host||*-cygwin Build||*-cygwin --- Comment #2 from Andrew Pinski --- Can you attach the config.log from the gcc subdirectory?
[Bug tree-optimization/63586] x+x+x+x -> 4*x in gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63586 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #10 from Andrew Pinski --- Fixed.
[Bug target/63596] Saving of GPR/FPRs for stdarg even though the variable argument is not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63596 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0
[Bug gcov-profile/36412] gcov -l -p exceeds maximum file name length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36412 --- Comment #3 from Martin Liška --- (In reply to Peter Klotz from comment #2) > Hello Martin > > It's great that you came up with a solution! > > Meanwhile I removed "-l" from the command line to avoid the error and use an > additional script to rename files as soon as they are generated by gcov. > This way file name collisions leading to overwritten files are prevented. > > Once your solution is present in a binary distribution I'm happy to remove > all these workarounds. > > Regards, Peter. Hi Peter. I'm happy that you're using GCC and that the request is still more than valid. I expect it's going to be accepted to trunk soon: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00721.html What compiler version are you using, I may backport the patch if you are interested (cause GCC 7.1 is going to be released in ~May 2017)?
[Bug tree-optimization/71691] [6/7 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691 --- Comment #10 from rguenther at suse dot de --- On Tue, 9 Aug 2016, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691 > > --- Comment #9 from Jeffrey A. Law --- > Based on c#6 I started thinking about how to make tree-ssa-loop-unswitch.c > appropriately conservative when a condition references a maybe-undefined > SSA_NAME. > > To recap, tree_may_unswitch_on has this test: > > /* Unswitching on undefined values would introduce undefined > behavior that the original program might never exercise. */ > if (ssa_undefined_value_p (use, true)) > return NULL_TREE; > > The problem is ssa_undefined_value_p returns an optimistic result -- ie, it > will returns true iff the definition statement is empty. So it will return > false for an SSA_NAME that is set from a PHI node where one or more arguments > have undefined values. ssa_undefined_value_p returns a conservative result for the must-be-undefined question which it is used for. It doesn't conservatively answer maybe-undefined. > ISTM this can be pretty easily fixed. > > Create a bitmap and initialize it to all the SSA_NAMEs where > ssa_undefined_value_p is true. > > Examine each PHI, if the PHI has an argument on its RHS that has the bit set > in > the bitmap, then set the bit for the LHS of the PHI > > Iterate on the PHIs until nothing has changed. Simpler: in dominator order walk all PHIs and stmts, for PHIs mark the def defined if all args are defined, for stmts mark all defs defined no iteration necessary, no pre-seeding with ssa_undefined_value_p needed, simply fall back to it when looking at PHI args (for parameter handling). > [ Yes, this isn't the most efficient. Implementation would be different to > improve efficiency. ] > > The result is the conservative set of SSA_NAMEs that may be undefined. This > satisfies the need of unswitching and potentially other passes that really > want > the conservative set. Yeah, though it computes undefinedness in the strict SSA sense. OTOH what unswitching wants to know is whether the value is either known to be defined or is known to be already used in the path leading from function entry to the place we want to place the new condition. That can be tested with iterating over all immediate uses and a dominance check which should improve things a bit.
[Bug target/72861] New: [7 Regression] 25% tramp3d-v4 performance regression on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72861 Bug ID: 72861 Summary: [7 Regression] 25% tramp3d-v4 performance regression on ppc64le Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- Host: powerpc64le-unknown-linux-gnu Target: powerpc64le-unknown-linux-gnu Build: powerpc64le-unknown-linux-gnu Performance of tramp3d-v4 regressed more than 25% compared to gcc-6 on ppc64le (gcc112): gcc-6: trippels@gcc2-power8 ~ % ~/gcc_6/usr/local/bin/g++ -w -Ofast -mlra -mcpu=power8 tramp3d-v4.cpp Performance counter stats for './a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20' (5 runs): 1972.550946 task-clock (msec) #0.999 CPUs utilized ( +- 0.22% ) 159 context-switches #0.081 K/sec ( +- 0.90% ) 0 cpu-migrations#0.000 K/sec 1,224 page-faults #0.621 K/sec ( +- 0.02% ) 6,748,308,064 cycles#3.421 GHz ( +- 0.22% ) [66.46%] 102,294,018 stalled-cycles-frontend #1.52% frontend cycles idle ( +- 3.23% ) [49.91%] 4,241,962,795 stalled-cycles-backend# 62.86% backend cycles idle ( +- 0.42% ) [50.41%] 7,902,269,951 instructions #1.17 insns per cycle #0.54 stalled cycles per insn ( +- 0.17% ) [67.10%] 740,198,353 branches # 375.249 M/sec ( +- 0.12% ) [50.14%] 12,209,406 branch-misses #1.65% of all branches ( +- 0.25% ) [49.82%] 1.973964281 seconds time elapsed ( +- 0.22% ) gcc-7: trippels@gcc2-power8 ~ % ~/gcc_7/usr/local/bin/g++ -w -Ofast -mlra -mcpu=power8 tramp3d-v4.cpp Performance counter stats for './a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20' (5 runs): 2677.865248 task-clock (msec) #0.999 CPUs utilized ( +- 0.84% ) 163 context-switches #0.061 K/sec ( +- 1.77% ) 0 cpu-migrations#0.000 K/sec ( +-100.00% ) 2,092 page-faults #0.781 K/sec ( +- 0.03% ) 9,149,015,944 cycles#3.417 GHz ( +- 0.92% ) [66.65%] 105,804,553 stalled-cycles-frontend #1.16% frontend cycles idle ( +- 5.21% ) [50.12%] 6,383,265,282 stalled-cycles-backend# 69.77% backend cycles idle ( +- 1.30% ) [50.31%] 8,980,496,614 instructions #0.98 insns per cycle #0.71 stalled cycles per insn ( +- 0.32% ) [66.96%] 682,369,238 branches # 254.818 M/sec ( +- 0.25% ) [49.93%] 10,159,864 branch-misses #1.49% of all branches ( +- 0.61% ) [49.82%] 2.679415575 seconds time elapsed ( +- 0.84% )
[Bug fortran/72832] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 vehre at gcc dot gnu.org changed: What|Removed |Added CC||vehre at gcc dot gnu.org --- Comment #2 from vehre at gcc dot gnu.org --- There are two bugs in one here: - the shape is selected from source= and not from the b(1:4), and - the shape of a and new b is not conformable, which can only be deduced at runtime (and is already when the class(t) is replaced by type(t) and -fcheck=all is used).
[Bug web/72856] Trottle bug creation for newly created accounts (to limit spam)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72856 Gerald Pfeifer changed: What|Removed |Added CC||gerald at pfeifer dot com --- Comment #2 from Gerald Pfeifer --- Thanks for looking into this, Frédéric! As for rate throttling, how about only allowing for a single bug report per day until a bug report has been "processed" (for some suitable definition of "processed" - perhaps even any action that is different from simply marking it as spam)?
[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 amker at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #1 from amker at gcc dot gnu.org --- Among all loops in the large function, how many loops can be doloop optimized successfully? Function doloop__optimize has some valid checks on doloop optimizations. Is it possible to move most (some) of checks outside of the per-loop function. Looks like targetm.invalid_within_doloop can be moved. As a result, we can know some loops can't be doloop optimized, so the iv_analysis/df_analysis can be skipped for those loops. For checks on loop analysis result: if (!desc->simple_p || desc->assumptions || desc->infinite) I think it's possible to avoid per-loop analysis behavior too. Since we don't change code, there is no need to do df analysis for each loop before iv_analysis. As a result, df_verify can be saved. We may need a new interface analyzing iv/loop_desc for all loops in loop-iv.c Of course, if most loops can be doloop optimized, this may not be able to help.
[Bug fortran/72832] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 --- Comment #3 from vehre at gcc dot gnu.org --- This patch fragment fixes the first issue: diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c index 5884e7a..8e5428a 100644 --- a/gcc/fortran/trans-stmt.c +++ b/gcc/fortran/trans-stmt.c @@ -5485,7 +5485,8 @@ gfc_trans_allocate (gfc_code * code) desc = tmp; tmp = gfc_class_data_get (tmp); } - e3_is = E3_DESC; + if (code->ext.alloc.arr_spec_from_expr3) + e3_is = E3_DESC; } else desc = !is_coarray ? se.expr
[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
--- Comment #2 from Richard Biener ---
If we have release checking enabled then we shuould hit
static void
df_analyze_1 (void)
{
...
#ifndef ENABLE_DF_CHECKING
if (df->changeable_flags & DF_VERIFY_SCHEDULED)
#endif
df_verify ();
so I wonder why df->changeable_flags & DF_VERIFY_SCHEDULED is ever true
for release checking. Can you track that down? I can't reproduce
df_verify being called on the 4.9 branch with release checking on x86_64
(OTOH x86_64 doesn't have a doloop pattern). Compile-time is 186s for 4.9,
main offenders:
df reaching defs: 24.61 (13%) usr
alias stmt walking : 13.72 ( 7%) usr
dominator optimization : 33.26 (18%) usr
expand vars : 48.89 (26%) usr
GCC 5 seems to be quite a bit worse with 400s:
df reaching defs: 13.16 ( 3%) usr
alias stmt walking : 216.73 (54%) usr
expand vars : 25.86 ( 6%) usr
load CSE after reload : 83.96 (21%) usr
GCC 6 uses a _load_ more memory on this testcase (I end up swapping with 8GB
ram
and finally get killed). So even on x86_64 the testcase looks interesting.
Note that
static bool
doloop_optimize (struct loop *loop)
{
...
iv_analysis_loop_init (loop);
/* Find the simple exit of a LOOP. */
desc = get_simple_loop_desc (loop);
performs iv_analysis_loop_init and thus df_analyze_loop twice ...
But yes, performing df_verify for each loop in a function is excessive,
we seem to lack ever clearing said flag. Does
Index: gcc/df-core.c
===
--- gcc/df-core.c (revision 239276)
+++ gcc/df-core.c (working copy)
@@ -1833,6 +1833,7 @@ df_verify (void)
if (df_live)
df_live_verify_transfer_functions ();
#endif
+ df->changeable_flags &= ~DF_VERIFY_SCHEDULED;
}
#ifdef DF_DEBUG_CFG
help in the non-DF-checking case?
[Bug rtl-optimization/72831] [7 Regression] Conditional jump or move depends on uninitialised value: regno_in_use_p (lra-spills.c:701)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72831 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Doesn't r239241 fix this?
[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- tree-ssa-threadedge.c has some BUILT_IN_CONSTANT_P code already, but clearly it isn't enough. "Similarly for __builtin_constant_p: r = PHI <1(2), 2(3)> __builtin_constant_p (r) Both PHI arguments are constant, but x ? 1 : 2 is still not constant." is what it does right now, but we have instead: # iftmp.0_2 = PHI b = iftmp.0_2; _1 = __builtin_constant_p (iftmp.0_2); where thread1 turns it into: # iftmp.0_8 = PHI <1(2)> b = iftmp.0_8; _10 = __builtin_constant_p (iftmp.0_8); ... # iftmp.0_2 = PHI b = iftmp.0_2; _1 = __builtin_constant_p (iftmp.0_2); This is undesirable, iftmp.0_2 really isn't constant, so we shouldn't turn it into sometimes constant, sometimes non-constant.
[Bug ipa/71981] [6/7 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu (internal compiler error: in get_dynamic_type, at ipa-polymorphic-call.c:1667)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71981 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Jambor --- Fixed on trunk and gcc-6-branch, so hopefully everywhere (I did not verify gcc 5 is OK but let's trust the bug title).
[Bug ipa/71981] [6/7 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu (internal compiler error: in get_dynamic_type, at ipa-polymorphic-call.c:1667)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71981 --- Comment #7 from Martin Liška --- (In reply to Martin Jambor from comment #6) > Fixed on trunk and gcc-6-branch, so hopefully everywhere (I did not verify > gcc 5 is OK but let's trust the bug title). Yeah, I've just verified that GCC 5 branch is OK.
[Bug rtl-optimization/72831] [7 Regression] Conditional jump or move depends on uninitialised value: regno_in_use_p (lra-spills.c:701)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72831 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #2) > Doesn't r239241 fix this? Indeed it does. Thanks.
[Bug target/72851] [6/7 Regression] memory hog with -O3 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72851 Andreas Krebbel changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-10 Ever confirmed|0 |1 --- Comment #1 from Andreas Krebbel --- Reghunt indicates that this was introduced with: Author: rguenth Date: Tue Jul 7 07:59:40 2015 New Revision: 225504 URL: https://gcc.gnu.org/viewcvs?rev=225504&root=gcc&view=rev Log: 2015-07-07 Richard Biener * tree-ssa-propagate.c (add_ssa_edge): Dump what edge list we add which use to. (add_control_edge): Remove excessive vertical space in dumping. (process_ssa_edge_worklist): Simulate at most one statement and return whether we did. Do not simulate PHIs if they are in a BB not yet simulated. (ssa_propagate): Adjust to always drain the BB worklist whenever a BB is available there, likewise the VARYING edges list before the interesting edge list.
[Bug gcov-profile/44779] The gcov library does not adequately handle functions with constructor/destructor attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44779 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #7 from Martin Liška --- Looks I've got working solution for situation 2).
[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 --- Comment #3 from amker at gcc dot gnu.org --- (In reply to amker from comment #1) > Among all loops in the large function, how many loops can be doloop > optimized successfully? Function doloop__optimize has some valid checks on > doloop optimizations. Is it possible to move most (some) of checks outside > of the per-loop function. Looks like targetm.invalid_within_doloop can be > moved. As a result, we can know some loops can't be doloop optimized, so > the iv_analysis/df_analysis can be skipped for those loops. For checks on > loop analysis result: > if (!desc->simple_p > || desc->assumptions > || desc->infinite) > I think it's possible to avoid per-loop analysis behavior too. Since we > don't change code, there is no need to do df analysis for each loop before > iv_analysis. As a result, df_verify can be saved. We may need a new > interface analyzing iv/loop_desc for all loops in loop-iv.c > > Of course, if most loops can be doloop optimized, this may not be able to > help. As suspected, most loop can't be doloop optimized by the target dependent insn check. I am testing a simple refactoring patch to see if it can reduce compile time.
[Bug testsuite/72850] [7 Regression] FAIL: gcc.dg/tree-ssa/pr69270-3.c scan-tree-dump-times uncprop1 ", 1" 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72850 Yuri Rumyantsev changed: What|Removed |Added CC||ysrumyan at gmail dot com --- Comment #3 from Yuri Rumyantsev --- We also noticed huge regression on coremark-pro/core benchmark after this revision. I attach test-case to reproduce.
[Bug testsuite/72850] [7 Regression] FAIL: gcc.dg/tree-ssa/pr69270-3.c scan-tree-dump-times uncprop1 ", 1" 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72850 --- Comment #4 from Yuri Rumyantsev --- Created attachment 39093 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39093&action=edit test-case to reproduce It is safficient use -Ofast option to compile on x86 machine.
[Bug fortran/72832] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 --- Comment #4 from Dominique d'Humieres --- For the record, the following test program allocate_source type :: t end type t type, extends(t) :: tt end type tt type(t), allocatable, dimension(:) :: a, b allocate(a(1:2)) write(*,*) size(a,1) allocate(b(1:4), source=a) write(*,*) size(b,1) end program allocate_source gives the "expected" output and at runtime the error 2 At line 11 of file pr72832_db_1.f90 Fortran runtime error: Array bound mismatch for dimension 1 of array 'b' (4/2) when compiled with -fcheck=bounds.
[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741 --- Comment #5 from Thomas Schwinge --- (In reply to cesar from comment #4) > I could be mistaken, but I don't think there's anything we can do about that > test case because fortran doesn't have file scope. Specifically, in your > example, > > SUBROUTINE r_w > IMPLICIT NONE > INTEGER :: i > !$ACC ROUTINE WORKER > > !$ACC LOOP > DO i = 1, 12345 > END DO > END SUBROUTINE r_w > > PROGRAM main > IMPLICIT NONE > EXTERNAL :: r_w > !$ACC ROUTINE (r_w) GANG > > !$ACC PARALLEL > CALL r_w > !$ACC END PARALLEL > END PROGRAM main > > from program main's perspective, r_w should be an acc routine with a gang > attribute, but that's only because the end user included an explicit > 'external' function declaration. I'm not sure how to catch mismatched > function declarations in fortran Maybe I'm assuming too much about the Fortran front end, but I assumed that the "SUBROUTINE r_w" would create some kind of decl, and the later "!$ACC ROUTINE (r_w)" would look up some kind of decl (that is, the gfc_find_function/gfc_find_subroutine/gfc_find_symtree stuff in gfc_match_oacc_routine), and these decls both have some kind of "attributes" attached to them, and once these two decls are "paired"/"merged", we can then see whether these "attributes" match or conflict. I assume some very similar verification is done in the Fortran front end for other checking between definition and use of any kind of routines, for example? Are you saying that's not how the Fortran front end operates, and the "SUBROUTINE r_w" and the later "PROGRAM main" do see completly detached "decl spaces"? Then indeed, we can't verify this in the Fortran front end, but... > especially if lto is not enabled. If lto > is enabled, we could add some more checking in pass oacc_device_lower. ..., as discussed before, something like that is the final goal that I'm working on, and for that... > But I > don't think there's anything else to do in the fortran front end. ..., please implement the changes I asked you to implement in Comment 3, #c3, or elaborate why that doesn't make sense.
[Bug fortran/72832] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 --- Comment #5 from Daan van Vugt --- Thanks for the quick responses. Just out of interest: what is the recommended way to allocate a class(t) variable of the same type as a but different size? Do I need to select type and list all of the types? that would be inconvenient.
[Bug web/72856] Trottle bug creation for newly created accounts (to limit spam)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72856 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez --- (In reply to Frédéric Buclin from comment #0) > GCC Bugzilla suffered vandalism again between July 25 and 27. 709 spam bugs > have been filed during this 48 hours window. 103 different email addresses > have been used to avoid being blocked too quickly. This gives a ratio on > average of 7 spam per account. I wonder about the effort required to do such a thing. Some of those emails seem fake, is there some kind of confirmation email for newly created accounts? Limiting the number of bug reports per new account seems a good measure, but also easily circumvented as long as someone can create as many new users as they wish and each user stays below the limit.
[Bug web/72856] Trottle bug creation for newly created accounts (to limit spam)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72856 --- Comment #4 from Frédéric Buclin --- (In reply to Manuel López-Ibáñez from comment #3) > I wonder about the effort required to do such a thing. Some of those emails > seem fake, is there some kind of confirmation email for newly created > accounts? Yes. When a user requests a new account, an email is sent to that email address, and the user must click on the link which is in the email to confirm that 1) the email address is valid, and 2) it belongs to the user who wants to create the bugzilla account. Clicking on this link will display a page where the user must type his new password, and only after that is the bugzilla account activated. It is not possible to create bugzilla accounts automatically using the API (to prevent such problems). > Limiting the number of bug reports per new account seems a good measure, but > also easily circumvented as long as someone can create as many new users as > they wish and each user stays below the limit. I agree, that's a problem. But I think there isn't one single solution which fixes all cases, but rather multiple solutions which, when combined together, can give a reasonable level of spam prevention.
[Bug target/72861] [7 Regression] 25% tramp3d-v4 performance regression on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72861 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |7.0
[Bug tree-optimization/72824] [5/6 Regression] Signed floating point zero semantics broken at optimization level -O3 (tree-loop-distribute-patterns)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72824 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Wed Aug 10 12:16:39 2016 New Revision: 239319 URL: https://gcc.gnu.org/viewcvs?rev=239319&root=gcc&view=rev Log: Backported from mainline 2016-08-09 Jakub Jelinek PR tree-optimization/72824 * tree-loop-distribution.c (const_with_all_bytes_same): Verify real_zerop is not negative. * gcc.c-torture/execute/ieee/pr72824.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/execute/ieee/pr72824.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-loop-distribution.c
[Bug bootstrap/72848] profiledbootstrap: internal compiler error: in streamer_write_gcov_count_stream, at data-streamer-out.c:366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72848 --- Comment #3 from Richard Biener --- (In reply to mikulas from comment #2) > gcc/hwint.h always defines HOST_WIDE_INT as 64-bit value. How could it be > 32-bit? Ah, didn't remember we fixed it to 64bit already with GCC 5.
[Bug bootstrap/72859] Building GCC Cross-Compiler on cygwin for PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72859 --- Comment #3 from 993870b5 at opayq dot com --- Created attachment 39094 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39094&action=edit config.log from the gcc subdirectory
[Bug target/72851] [6/7 Regression] memory hog with -O3 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72851 --- Comment #2 from Richard Biener --- Huh, if the reghunt is correct it points at some latent issue. Will try to reproduce with a cross.
[Bug web/72856] Trottle bug creation for newly created accounts (to limit spam)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72856 --- Comment #5 from Frédéric Buclin --- (In reply to Gerald Pfeifer from comment #2) > As for rate throttling, how about only allowing for a single bug > report per day until a bug report has been "processed" Isn't one bug per day a bit rude for legit users? I would be tempted to say that above 2 or 3 new bug reports, it's reasonable to question if the user is trying to spam Bugzilla or not. This is why I made the proposal in comment 0 to use something exponential. This would give us something like: 3**n-1 5**n == T0 : account created T0 : account created T0 : 1st bug created T0+1min : 1st bug created T0+2min : 2nd bug created T0+6min : 2nd bug created T0+10min: 3rd bug created T0+31min: 3rd bug created T0+36min: 4th bug created T0+2.5h : 4th bug created T0+2h : 5th bug created T0+13h : 5th bug created T0+6h : 6th bug created T0+65h : 6th bug created T0+18h : 7th bug created etc... T0+55h : 8th bug created etc... So a spammer could file at most 6-8 bugs in a week, but a legit user could still easily file his first 2-3 bugs in a half hour. Of course, this rate limit would only apply to users without editbugs privileges, so e.g. @gcc.gnu.org accounts would not be affected.
[Bug target/72851] [6/7 Regression] memory hog with -O3 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72851 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Doesn't reproduce with a cross. I've configured with just --target=s390x-suse-linux thus end up with > ./xgcc -B. -S des.i -g -O3 -std=c99 -fPIC -pthread -v Reading specs from ./specs COLLECT_GCC=./xgcc Target: s390x-suse-linux Configured with: /space/rguenther/src/svn/gcc-6-branch/configure --target=s390x-suse-linux --enable-languages=c,c++ --enable-checking=yes Thread model: posix gcc version 6.1.1 20160719 [gcc-6-branch revision 238088] (GCC) COLLECT_GCC_OPTIONS='-B' '.' '-S' '-g' '-O3' '-std=c99' '-fPIC' '-pthread' '-v' '-m64' '-mzarch' '-march=z900' ./cc1 -fpreprocessed des.i -quiet -dumpbase des.i -m64 -mzarch -march=z900 -auxbase des -g -O3 -std=c99 -version -fPIC -o des.s not sure if -march is the one you see this with. Ah, using -march=z10 is required to reproduce it and it iterates forever in VRP. Investiating.
[Bug web/72856] Trottle bug creation for newly created accounts (to limit spam)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72856 --- Comment #6 from Frank Ch. Eigler --- Per-account rate limits seem so easy to overcome, with spammers already creating numerous verified junk accounts with ease. I would suggest focusing on spam-prevention content analysis (spamassassin style), and post-spam cleanup (blacklisting, history editing, bug hiding?) efforts.
[Bug target/71873] ICE in push_reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71873 --- Comment #1 from Senthil Kumar Selvaraj --- Author: saaadhu Date: Wed Aug 10 12:35:57 2016 New Revision: 239321 URL: https://gcc.gnu.org/viewcvs?rev=239321&root=gcc&view=rev Log: Fix PR 71873 - ICE in push_reload Extend computation of subreg_in_class to constants and plus expressions inside SUBREGs, before recursively calling push_reload. SYMBOL_REFs are also CONSTANT_P, so remove explicit handling of SYMBOL_REFs. gcc/ChangeLog PR target/71873 * reload.c (push_reload): Compute subreg_in_class for subregs of constants and plus expressions. Remove special handling of SYMBOL_REFs. gcc/testsuite/ChangeLog PR target/71873 * gcc.target/avr/pr71873.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/pr71873.c Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c trunk/gcc/testsuite/ChangeLog
[Bug target/72851] [6/7 Regression] memory hog with -O3 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72851
--- Comment #4 from Richard Biener ---
Reduced testcase:
typedef unsigned char uint8_t;
typedef unsigned long int uint64_t;
union unaligned_64 {
uint64_t l;
}
__attribute__((packed)) __attribute__((may_alias));
typedef struct AVDES {
uint64_t round_keys[3][16];
} AVDES;
static const uint8_t PC1_shuffle[] = {
64-57,64-49,64-41,64-33,64-25,64-17,64-9,
64-1,64-58,64-50,64-42,64-34,64-26,64-18,
64-10,64-2,64-59,64-51,64-43,64-35,64-27,
64-19,64-11,64-3,64-60,64-52,64-44,64-36,
64-63,64-55,64-47,64-39,64-31,64-23,64-15,
64-7,64-62,64-54,64-46,64-38,64-30,64-22,
64-14,64-6,64-61,64-53,64-45,64-37,64-29,
64-21,64-13,64-5,64-28,64-20,64-12,64-4 };
static const uint8_t PC2_shuffle[] = {
56-14,56-17,56-11,56-24,56-1,56-5, 56-3,56-28,56-15,56-6,56-21,56-10,
56-23,56-19,56-12,56-4,56-26,56-8, 56-16,56-7,56-27,56-20,56-13,56-2,
56-41,56-52,56-31,56-37,56-47,56-55, 56-30,56-40,56-51,56-45,56-33,56-48,
56-44,56-49,56-39,56-56,56-34,56-53, 56-46,56-42,56-50,56-36,56-29,56-32
};
static uint64_t shuffle(uint64_t in, const uint8_t *shuffle, int shuffle_len)
{
int i;
uint64_t res = 0;
for (i = 0; i < shuffle_len; i++)
res += res + ((in >> *shuffle++) & 1);
return res;
}
void gen_roundkeys(uint64_t K[16], uint64_t key)
{
int i;
uint64_t CDn = shuffle(key, PC1_shuffle, sizeof(PC1_shuffle));
for (i = 0; i < 16; i++)
K[i] = shuffle(CDn, PC2_shuffle, sizeof(PC2_shuffle));
}
[Bug target/72851] [6/7 Regression] memory hog with -O3 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72851 --- Comment #5 from Matthias Klose --- configured --with-arch=zEC12, I can reproduce it with a cross as well. so maybe check with -march=zEC12?
[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
--- Comment #4 from amker at gcc dot gnu.org ---
Here is a simple refactoring patch.
diff --git a/gcc/loop-doloop.c b/gcc/loop-doloop.c
index c311516..9fb04cf 100644
--- a/gcc/loop-doloop.c
+++ b/gcc/loop-doloop.c
@@ -254,18 +254,51 @@ doloop_condition_get (rtx doloop_pat)
return 0;
}
-/* Return nonzero if the loop specified by LOOP is suitable for
- the use of special low-overhead looping instructions. DESC
- describes the number of iterations of the loop. */
+/* Check all insns of LOOP to see if the loop is suitable for the use of
+ special low-overhead looping instructions. Return TRUE if yes, false
+ otherwise. */
static bool
-doloop_valid_p (struct loop *loop, struct niter_desc *desc)
+doloop_insn_valid_p (struct loop *loop)
{
- basic_block *body = get_loop_body (loop), bb;
- rtx_insn *insn;
unsigned i;
- bool result = true;
+ rtx_insn *insn;
+ basic_block *body = get_loop_body (loop), bb;
+ for (i = 0; i < loop->num_nodes; i++)
+{
+ bb = body[i];
+
+ for (insn = BB_HEAD (bb);
+ insn != NEXT_INSN (BB_END (bb));
+ insn = NEXT_INSN (insn))
+ {
+ /* Different targets have different necessities for low-overhead
+looping. Call the back end for each instruction within the loop
+to let it decide whether the insn prohibits a low-overhead loop.
+It will then return the cause for it to emit to the dump file. */
+ const char * invalid = targetm.invalid_within_doloop (insn);
+ if (invalid)
+ {
+ if (dump_file)
+ fprintf (dump_file, "Doloop: %s\n", invalid);
+
+ free (body);
+ return false;
+ }
+ }
+}
+ free (body);
+ return true;
+}
+
+/* Check the number of iterations described by DESC of a loop to see if
+ the loop is suitable for the use of special low-overhead looping
+ instructions. Return true if yes, false otherwise. */
+
+static bool
+doloop_niter_valid_p (struct loop *, struct niter_desc *desc)
+{
/* Check for loops that may not terminate under special conditions. */
if (!desc->simple_p
|| desc->assumptions
@@ -295,38 +328,10 @@ doloop_valid_p (struct loop *loop, struct niter_desc
*desc)
enable count-register loops in this case. */
if (dump_file)
fprintf (dump_file, "Doloop: Possible infinite iteration case.\n");
- result = false;
- goto cleanup;
-}
-
- for (i = 0; i < loop->num_nodes; i++)
-{
- bb = body[i];
-
- for (insn = BB_HEAD (bb);
- insn != NEXT_INSN (BB_END (bb));
- insn = NEXT_INSN (insn))
- {
- /* Different targets have different necessities for low-overhead
-looping. Call the back end for each instruction within the loop
-to let it decide whether the insn prohibits a low-overhead loop.
-It will then return the cause for it to emit to the dump file. */
- const char * invalid = targetm.invalid_within_doloop (insn);
- if (invalid)
- {
- if (dump_file)
- fprintf (dump_file, "Doloop: %s\n", invalid);
- result = false;
- goto cleanup;
- }
- }
+ return false;
}
- result = true;
-
-cleanup:
- free (body);
- return result;
+ return true;
}
/* Adds test of COND jumping to DEST on edge *E and set *E to the new fallthru
@@ -621,17 +626,25 @@ doloop_optimize (struct loop *loop)
if (dump_file)
fprintf (dump_file, "Doloop: Processing loop %d.\n", loop->num);
+ if (!doloop_insn_valid_p (loop))
+{
+ if (dump_file)
+ fprintf (dump_file, "Doloop: The loop is not suitable.\n");
+
+ return false;
+}
+
iv_analysis_loop_init (loop);
/* Find the simple exit of a LOOP. */
desc = get_simple_loop_desc (loop);
/* Check that loop is a candidate for a low-overhead looping insn. */
- if (!doloop_valid_p (loop, desc))
+ if (!doloop_niter_valid_p (loop, desc))
{
if (dump_file)
- fprintf (dump_file,
-"Doloop: The loop is not suitable.\n");
+ fprintf (dump_file, "Doloop: The loop is not suitable.\n");
+
return false;
}
mode = desc->mode;
It reduces compile time for powerpc-elf on x86_64 machine from 54m to 5m. The
compiler is configured with checking. With "--enable-checking=release", the
current trunk compiles for ~5m too, but gcc in Ubuntu has the issue even it's
configured as release?
[Bug target/72863] New: Powerpc64le: redundant swaps when using vec_vsx_ld/st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863
Bug ID: 72863
Summary: Powerpc64le: redundant swaps when using vec_vsx_ld/st
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
CC: amodra at gcc dot gnu.org, bergner at gcc dot gnu.org,
meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux
I notice swaps to and from memory with the following test case:
void b(void)
{
int i;
unsigned char *s8 = src;
unsigned char *d8 = dst;
for (i = 0; i < 100; i++) {
vector unsigned char vs = vec_vsx_ld(0, s8);
vector unsigned char vd = vec_vsx_ld(0, d8);
vector unsigned char vr = vec_xor(vs, vd);
vec_vsx_st(vr, 0, d8);
s8 += 16;
d8 += 16;
}
}
70: 98 56 00 7c lxvd2x vs0,0,r10
74: 98 4e 80 7d lxvd2x vs12,0,r9
78: 10 00 4a 39 addir10,r10,16
7c: 50 02 60 f1 xxswapd vs11,vs0
80: 50 62 0c f0 xxswapd vs0,vs12
84: d0 04 0b f0 xxlxor vs0,vs11,vs0
88: 50 02 00 f0 xxswapd vs0,vs0
8c: 98 4f 00 7c stxvd2x vs0,0,r9
90: 10 00 29 39 addir9,r9,16
94: dc ff 00 42 bdnz70
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #27 from Martin Liška --- Author: marxin Date: Wed Aug 10 13:14:56 2016 New Revision: 239324 URL: https://gcc.gnu.org/viewcvs?rev=239324&root=gcc&view=rev Log: Add new *_atomic counter update function PR gcov-profile/58306 * Makefile.in: New functions (modules) are added. * libgcov-profiler.c (__gcov_interval_profiler_atomic): New function. (__gcov_pow2_profiler_atomic): New function. (__gcov_one_value_profiler_body): New argument is instroduced. (__gcov_one_value_profiler): Call with the new argument. (__gcov_one_value_profiler_atomic): Likewise. (__gcov_indirect_call_profiler_v2): Likewise. (__gcov_time_profiler_atomic): New function. (__gcov_average_profiler_atomic): Likewise. (__gcov_ior_profiler_atomic): Likewise. * libgcov.h: Declare the aforementioned functions. PR gcov-profile/58306 * gcc.dg/tree-prof/val-profiler-threads-1.c: New test. PR gcov-profile/58306 * tree-profile.c (gimple_init_edge_profiler): Create conditionally atomic variants of profile update functions. Added: trunk/gcc/testsuite/gcc.dg/tree-prof/val-profiler-threads-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-profile.c trunk/libgcc/ChangeLog trunk/libgcc/Makefile.in trunk/libgcc/libgcov-profiler.c trunk/libgcc/libgcov.h
[Bug ada/72740] gnat.dg/specs/access[12].ads ICE when compiling with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72740 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-10 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- > the issue is that we have recursive pointer types and blow the stack when > dwarf2out calls verify_type which calls variably_modified_type_p: > > (gdb) p type->typed.type->typed.type > $3 = > (gdb) p type->typed.type->typed.type->typed.type > $4 = > (gdb) p type->typed.type->typed.type->typed.type->typed.type > $5 = > > not sure how to best represent such a structure. Maybe > variably_modified_type_p needs adjustment? Do you mean something similar to what Jan added in get_alias_set?
[Bug fortran/72832] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Known to work||5.4.0 Summary|[OOP] ALLOCATE with SOURCE |[6/7 Regression] [OOP] |fails to allocate requested |ALLOCATE with SOURCE fails |dimensions |to allocate requested ||dimensions Known to fail||6.1.0, 7.0 --- Comment #6 from Dominique d'Humieres --- BTW this is a regression. Compiling the code with 5.4.0 gives at runtime the output 2 4 if compiled without -fcheck=bounds and 2 At line 11 of file pr72832.f90 Fortran runtime error: Array bound mismatch for dimension 1 of array 'b' (4/2) with it. > Just out of interest: what is the recommended way to allocate a class(t) > variable of the same type as a but different size? Not 100% sure, but may be you can use a scalar (it does seem to work for me).
[Bug gcov-profile/28441] Need atomic increment of gcov counters for MP programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28441 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Martin Liška --- Implemented by r239324.
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #28 from Martin Liška --- Fixed on trunk.
[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863 --- Comment #1 from Bill Schmidt --- Egad. How appalling. I'll have a look soon.
[Bug target/72851] [6/7 Regression] memory hog with -O3 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72851 --- Comment #6 from Richard Biener --- Ok, so with clever stmt / SSA use ordering you can get to quadratic propagation as VRP allows ranges to arbitrarily grow: Found new range for res_561: [0, 20368] Found new range for res_561: [0, 20370] Found new range for res_561: [0, 20372] Found new range for res_561: [0, 20374] Found new range for res_561: [0, 20376] Found new range for res_561: [0, 20378] Found new range for res_561: [0, 20380] Found new range for res_561: [0, 20382] Found new range for res_561: [0, 20384] Found new range for res_561: [0, 20386] Found new range for res_561: [0, 20388] Found new range for res_561: [0, 20390] Found new range for res_561: [0, 20392] Found new range for res_561: [0, 20394] Found new range for res_561: [0, 20396] ... the SSA worklist in the SSA propagator is just a stack that is pushed/popped to/from. Ideally that worklist would be processed in stmt order but that requires sorting the worklist vector or changing the worklist data structure to sth "better" (a balanced tree?). Slightly "randomizing" the worklist processing, say by Index: gcc/tree-ssa-propagate.c === --- gcc/tree-ssa-propagate.c(revision 238469) +++ gcc/tree-ssa-propagate.c(working copy) @@ -422,7 +422,8 @@ process_ssa_edge_worklist (vec basic_block bb; /* Pull the statement to simulate off the worklist. */ - gimple *stmt = worklist->pop (); + gimple *stmt = (*worklist)[0]; + worklist->unordered_remove (0); /* If this statement was already visited by simulate_block, then we don't need to visit it again here. */ fixes the testcase. Of course it's just a matter of pure luck that it re-appears (with the current processing order it's just most likely given its depth-first processing nature). Picking a truly random element from the worklist would be better than the above (but truly random has to be predictable to not break bootstrap).
[Bug target/72853] gcc/testsuite/gcc.c-torture/execute/20021120-1.c generates incorrect stxssp op with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72853 --- Comment #6 from Michael Meissner --- Author: meissner Date: Wed Aug 10 13:49:12 2016 New Revision: 239325 URL: https://gcc.gnu.org/viewcvs?rev=239325&root=gcc&view=rev Log: [gcc] 2016-08-10 Michael Meissner PR target/72853 * config/rs6000/rs6000.c (mem_operand_ds_form): Add check for op being an offsettable address. [gcc/testsuite] 2016-08-10 Michael Meissner PR target/72853 * gcc.target/powerpc/pr72853.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr72853.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug ada/72740] gnat.dg/specs/access[12].ads ICE when compiling with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72740 --- Comment #2 from rguenther at suse dot de --- On Wed, 10 Aug 2016, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72740 > > Eric Botcazou changed: > >What|Removed |Added > > Status|UNCONFIRMED |NEW >Last reconfirmed||2016-08-10 > CC||ebotcazou at gcc dot gnu.org > Ever confirmed|0 |1 > > --- Comment #1 from Eric Botcazou --- > > the issue is that we have recursive pointer types and blow the stack when > > dwarf2out calls verify_type which calls variably_modified_type_p: > > > > (gdb) p type->typed.type->typed.type > > $3 = > > (gdb) p type->typed.type->typed.type->typed.type > > $4 = > > (gdb) p type->typed.type->typed.type->typed.type->typed.type > > $5 = > > > > not sure how to best represent such a structure. Maybe > > variably_modified_type_p needs adjustment? > > Do you mean something similar to what Jan added in get_alias_set? Yeah, or maybe mark the "forward" reference (the "backedge") tree type in some way in the FE? POINTER_TYPE_CYCLE_CLOSING_P?
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #29 from Artem S. Tashkinov --- (In reply to Martin Liška from comment #28) > Fixed on trunk. Thanks! Will GCC 6.1.1 include these patches?
[Bug fortran/72832] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 --- Comment #7 from Dominique d'Humieres --- Likely caused by r229294 (PRs 67044 and 66927).
[Bug c/72857] incorrect caret location in -Wformat for width and precision given by asterisk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72857 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-08-10 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/72864] New: gcc.c-torture/compile/pr72802.c fails on x86_64-apple-darwin15 with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72864 Bug ID: 72864 Summary: gcc.c-torture/compile/pr72802.c fails on x86_64-apple-darwin15 with -m32 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: amodra at gcc dot gnu.org, iains at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin15 Target: x86_64-apple-darwin15 Build: x86_64-apple-darwin15 The test gcc.c-torture/compile/pr72802.c fails on x86_64-apple-darwin15 with -m32 Running target unix/-m32 FAIL: gcc.c-torture/compile/pr72802.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/pr72802.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/pr72802.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/pr72802.c -O2 -flto (test for excess errors) FAIL: gcc.c-torture/compile/pr72802.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/compile/pr72802.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/pr72802.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/pr72802.c -Os (test for excess errors) The error is [book15] f90/bug% gcc-fsf-6 /opt/gcc/_clean/gcc/testsuite/gcc.c-torture/compile/pr72802.c -w -c -m32 /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cc30nAcT.s:152:2: error: symbol '_a' can not be undefined in a subtraction expression leal_a-L3$pb(%ebx), %eax ^ with all the gcc versions I have tried from 4.8 up to trunk (7.0), i.e. latent bug. Compiling with clang, Apple LLVM version 7.3.0 (clang-703.0.31), I get /opt/gcc/_clean/gcc/testsuite/gcc.c-torture/compile/pr72802.c:53:5: error: non-void function 'fn3' should return a value [-Wreturn-type] return; ^ 1 error generated.
[Bug gcov-profile/35543] Add more strOp for value profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35543 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Confirmed, I'm going to prepare a patch.
[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741 --- Comment #6 from cesar at gcc dot gnu.org --- (In reply to Thomas Schwinge from comment #5) > (In reply to cesar from comment #4) > Are you saying that's not how the Fortran front end operates, and the > "SUBROUTINE r_w" and the later "PROGRAM main" do see completly detached > "decl spaces"? Then indeed, we can't verify this in the Fortran front end, > but... Yes, the address spaces are completely detached in separate, external function. Internal functions, i.e. those that are places after "contains:" share the same scope as the main program/module block. Keep in mind that fortran has a lot of intrinsic procedures, so those find function/subroutine functions mostly resolve those intrinsic procedures or procedures explicitly declared by the user. > > especially if lto is not enabled. If lto > > is enabled, we could add some more checking in pass oacc_device_lower. > > ..., as discussed before, something like that is the final goal that I'm > working on, and for that... > > > But I > > don't think there's anything else to do in the fortran front end. > > ..., please implement the changes I asked you to implement in Comment 3, > #c3, or elaborate why that doesn't make sense. That's a good idea in principle, but there are a couple of reasons why I'm hesitant to pursue it. a) The fortran pretty printer doesn't know about generic tree notes. Consequently, I don't think build_oacc_routine_dims would be able to report any errors unless we add support for tree notes in that pretty printer. b) The fortran FE handle errors slightly differently from the c FE. Instead of catching the error early and aborting immediately, you're method will defer the error handling to after the FE has parsed everything. I'm not sure if this is a problem or not. c) That oacc_function information needs to be captured for fortran module .mod files, and those .mod files don't require tree node attributes. Postponing that attribute requires separate functions to manipulate the routine clauses. d) gfc_oacc_routine_dims is already creating an oacc_function attribute for routines. This attribute is a single enum instead of the individual clauses. I like that because its more self contained.
[Bug bootstrap/72859] Building GCC Cross-Compiler on cygwin for PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72859 --- Comment #4 from Andrew Pinski --- Comment on attachment 39094 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39094 config.log from the gcc subdirectory configure:5756: checking size of short configure:5776: result: 0 ... configure:5824: checking size of long configure:5844: result: 0 That is why this is failing ...
[Bug c++/72865] New: Adding __may_alias__ attribute triggers a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72865
Bug ID: 72865
Summary: Adding __may_alias__ attribute triggers a compilation
error
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: root at zta dot lk
Target Milestone: ---
The following (correct) code triggers a compilation error when compiled with
gcc. It does compiles under clang.
Removing __attribute__((__may_alias__)) clause fixes the problem.
$ cat sf.cpp
template
class rv: public T
{
rv();
~rv() throw();
rv(rv const&);
void operator=(rv const&);
} __attribute__((__may_alias__));
class A
{
A(A &);
A& operator=(A &);
public:
explicit A(rv& safetyCamera);
A& operator=(rv& safetyCamera);
operator const rv&() const { return *static_cast*>(this); }
};
A::A(rv&) {}
A& A::operator=(rv&) { return *this; }
The error message
=
$ g++ -c sf.cpp
sf.cpp:20:1: error: prototype for ‘A::A(rv&)’ does not match any in class
‘A’
A::A(rv&) {}
^
sf.cpp:15:12: error: candidates are: A::A(rv&)
explicit A(rv& safetyCamera);
^
sf.cpp:12:3: error: A::A(A&)
A(A &);
^
sf.cpp:21:4: error: prototype for ‘A& A::operator=(rv&)’ does not match any
in class ‘A’
A& A::operator=(rv&) { return *this; }
^
sf.cpp:16:6: error: candidates are: A& A::operator=(rv&)
A& operator=(rv& safetyCamera);
^
sf.cpp:13:6: error: A& A::operator=(A&)
A& operator=(A &);
^
[Bug c++/72865] Adding __may_alias__ attribute triggers a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72865 --- Comment #1 from Aleksej Lebedev --- Forgot to tell what platform I'm running this: $ uname -a Linux zhtw-pc 4.2.0-41-generic #48-Ubuntu SMP Fri Jun 24 11:28:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Exact version of the GCC: $ g++ --version g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug middle-end/71734] [7 Regression] FAIL: libgomp.fortran/simd4.f90 -O3 -g execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71734 --- Comment #13 from hjl at gcc dot gnu.org --- Author: hjl Date: Wed Aug 10 15:03:02 2016 New Revision: 239326 URL: https://gcc.gnu.org/viewcvs?rev=239326&root=gcc&view=rev Log: Fix PR tree-optimization/71734 2016-08-10 Yuri Rumyantsev PR tree-optimization/71734 * tree-ssa-loop-im.c (ref_indep_loop_p): Add new argument REF_LOOP, invoke ref_indep_loop_p_1. (outermost_indep_loop): Pass LOOP argumnet where REF was defined to ref_indep_loop_p. (ref_indep_loop_p_1): Fix commentary, add argument REF_LOOP, combine it with ref_indep_lopp_p_2, update SAFELEN if only REF is inside LOOP, do not cache dpendence value for loops with non-zero SAFELEN. (ref_indep_loop_p_2): Delete function. (can_sm_ref_p): Pass LOOP as additional argument to ref_indep_loop_p. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-im.c
[Bug c++/72865] Adding __may_alias__ attribute triggers a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72865 --- Comment #2 from Aleksej Lebedev --- Just tried it with gcc-6.0.0 under DragonflyBSD. It seems that the bug is fixed. $ uname -a DragonFly kl.zta.lk 4.4-RELEASE DragonFly v4.4.3.1.gf6df7-RELEASE #8: Thu Apr 21 17:59:21 CEST 2016 r...@kl.zta.lk:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 $ g++6 --version g++6 (FreeBSD Ports Collection) 6.0.0 20160410 (experimental) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ $ g++6 sf.cpp -c $ echo $? 0 Not sure what's your policy in this case. You decide if you want to close this as "Won't fix", but this bug prevents us from using boost::move for classes with move constructors (in some cases).
[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
--- Comment #5 from Bill Schmidt ---
(In reply to Richard Biener from comment #2)
> If we have release checking enabled then we shuould hit
>
> static void
> df_analyze_1 (void)
> {
> ...
> #ifndef ENABLE_DF_CHECKING
> if (df->changeable_flags & DF_VERIFY_SCHEDULED)
> #endif
> df_verify ();
>
> so I wonder why df->changeable_flags & DF_VERIFY_SCHEDULED is ever true
> for release checking. Can you track that down?
df_finish_pass has the following unguarded code at the end of the function:
if (flag_checking && verify)
df->changeable_flags |= DF_VERIFY_SCHEDULED;
This is the only way that DF_VERIFY_SCHEDULED gets turned on by itself.
> But yes, performing df_verify for each loop in a function is excessive,
> we seem to lack ever clearing said flag. Does
>
> Index: gcc/df-core.c
> ===
> --- gcc/df-core.c (revision 239276)
> +++ gcc/df-core.c (working copy)
> @@ -1833,6 +1833,7 @@ df_verify (void)
>if (df_live)
> df_live_verify_transfer_functions ();
> #endif
> + df->changeable_flags &= ~DF_VERIFY_SCHEDULED;
> }
>
> #ifdef DF_DEBUG_CFG
>
> help in the non-DF-checking case?
It should, since df_finish_pass isn't called (indirectly from iv_analysis_done)
by the doloop code until after all of the loops have been processed.
[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 --- Comment #6 from Bill Schmidt --- (In reply to amker from comment #4) > It reduces compile time for powerpc-elf on x86_64 machine from 54m to 5m. > The compiler is configured with checking. With "--enable-checking=release", > the current trunk compiles for ~5m too, but gcc in Ubuntu has the issue even > it's configured as release? Yes -- I can reproduce this with: Target: powerpc64le-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libsanitizer --disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-ppc64el/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-ppc64el --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-ppc64el --with-arch-directory=ppc64el --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-secureplt --with-cpu=power7 --with-tune=power8 --enable-targets=powerpcle-linux --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu Thread model: posix gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) I also reproduced it with latest gcc-6-branch, which should be built with release checking, and with trunk (but that should use extra checking). The guy who spotted this originally reported it on 4.8.4, 4.9.?, and 5.4 also. For his purposes, he recognized that he should just remove the silly --param, but this uncovered a rather interesting test in any event.
[Bug bootstrap/72859] Building GCC Cross-Compiler on cygwin for PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72859 --- Comment #5 from 993870b5 at opayq dot com --- Thank you. How can I fix the checking of size for short and long types? configure:5756: checking size of short configure:5776: result: 0 ... configure:5824: checking size of long configure:5844: result: 0
[Bug tree-optimization/71815] SLSR misses several PHI candidate cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815 --- Comment #9 from Bill Schmidt --- I'm not comfortable with the results of the patch. Overall I see a slight improvement for SPECint CPU2006 and a slightly larger degradation for SPECfp CPU2006. But there are some individual slowdowns that are unacceptable: 435.gromacs: -8.7% 436.cactusADM: -3.0% On the other hand: 403.gcc: +4.6% All other results within +/- 2%. I'm going to hold off on this until I can investigate the 435.gromacs slowdown.
[Bug rtl-optimization/71956] [7 Regression] 176.gcc fails on 32 bits when compiled with -march=core-avx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71956 Yuri Rumyantsev changed: What|Removed |Added CC||ysrumyan at gmail dot com --- Comment #2 from Yuri Rumyantsev --- Jakub, I removed both your revisions in cse.c (c1) but it did not help - 176.gcc stll gets RF on avx2 but not on avx. I assume that masked stores are responsible for it since we have them in binaries: .L2437: vmovd %ecx, %xmm1 vpxor %xmm5, %xmm5, %xmm5 addl-40(%ebp), %eax movl-28(%ebp), %edx vpbroadcastd-36(%ebp), %ymm4 vpaddd .LC1, %ymm4, %ymm2 vpbroadcastd%xmm1, %ymm1 leal(%edx,%eax,4), %eax vpsrlvd %ymm2, %ymm1, %ymm2 vpaddd %ymm7, %ymm4, %ymm3 vpand %ymm6, %ymm2, %ymm2 vpcmpeqd%ymm5, %ymm2, %ymm2 vpcmpeqd%ymm5, %ymm2, %ymm2 vptest %ymm2, %ymm2 je .L2446 vpmaskmovd %ymm0, %ymm2, (%eax) .L2446: vpsrlvd %ymm3, %ymm1, %ymm2 vpxor %xmm3, %xmm3, %xmm3 leal32(%eax), %edx vpaddd .LC3, %ymm4, %ymm4 vpand %ymm6, %ymm2, %ymm2 vpcmpeqd%ymm3, %ymm2, %ymm2 vpcmpeqd%ymm3, %ymm2, %ymm2 vptest %ymm2, %ymm2 je .L2447 vpmaskmovd %ymm0, %ymm2, (%edx) Will try to determine the correct revision responsible for it.
[Bug tree-optimization/72866] New: [7 Regression] Compile time hog w/ -O3 (-Ofast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72866
Bug ID: 72866
Summary: [7 Regression] Compile time hog w/ -O3 (-Ofast)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-7.0.0-alpha20160807 takes large (or infinite?) time when compiling the
following reduced testcase w/ -O3 or -Ofast:
unsigned int dl;
int rx, lb;
void
fo (int jv, int be)
{
const unsigned int xw = 16;
unsigned int ya, wo;
for (ya = 0; ya < 2; ++ya)
for (wo = 0; wo < xw; ++wo)
{
dl += (jv ? be : rx);
rx += ((lb == 0) + 1);
}
}
Compilation time appears to be dependent on the value stored in `xw'.
[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
--- Comment #7 from rguenther at suse dot de ---
On August 10, 2016 5:15:43 PM GMT+02:00, "wschmidt at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
>
>--- Comment #5 from Bill Schmidt ---
>(In reply to Richard Biener from comment #2)
>> If we have release checking enabled then we shuould hit
>>
>> static void
>> df_analyze_1 (void)
>> {
>> ...
>> #ifndef ENABLE_DF_CHECKING
>> if (df->changeable_flags & DF_VERIFY_SCHEDULED)
>> #endif
>> df_verify ();
>>
>> so I wonder why df->changeable_flags & DF_VERIFY_SCHEDULED is ever
>true
>> for release checking. Can you track that down?
>
>df_finish_pass has the following unguarded code at the end of the
>function:
>
> if (flag_checking && verify)
>df->changeable_flags |= DF_VERIFY_SCHEDULED;
>
>This is the only way that DF_VERIFY_SCHEDULED gets turned on by itself.
Yes, but that is guarded by flag_checking which defaults to 0.
>> But yes, performing df_verify for each loop in a function is
>excessive,
>> we seem to lack ever clearing said flag. Does
>>
>> Index: gcc/df-core.c
>> ===
>> --- gcc/df-core.c (revision 239276)
>> +++ gcc/df-core.c (working copy)
>> @@ -1833,6 +1833,7 @@ df_verify (void)
>>if (df_live)
>> df_live_verify_transfer_functions ();
>> #endif
>> + df->changeable_flags &= ~DF_VERIFY_SCHEDULED;
>> }
>>
>> #ifdef DF_DEBUG_CFG
>>
>> help in the non-DF-checking case?
>
>It should, since df_finish_pass isn't called (indirectly from
>iv_analysis_done)
>by the doloop code until after all of the loops have been processed.
If you manage to test that it's pre-approved.
[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-10 Ever confirmed|0 |1 --- Comment #8 from David Edelsohn --- > Yes, but that is guarded by flag_checking which defaults to 0. How can flag_checking be 0 if -fno-checking has an effect?
[Bug tree-optimization/72866] [7 Regression] Compile time hog w/ -O3 (-Ofast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72866 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-10 CC||amker at gcc dot gnu.org, ||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Started with r235808.
[Bug gcov-profile/36412] gcov -l -p exceeds maximum file name length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36412 --- Comment #4 from Peter Klotz --- Hi Martin The company I work for makes heavy use of Red Hat Enterprise Linux 7. According to this article, a GCC 6 based Red Hat Developer Toolset should be available in the not too distant future. http://developers.redhat.com/blog/2016/02/23/upcoming-features-in-gcc-6/ So a backport to the GCC 6 release series would help. Regards, Peter.
[Bug libstdc++/69565] Heap operations could surely be faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69565 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-08-10 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Do you have the benchmark that goes with the graph?
[Bug target/72867] New: SSE/AVX/AVX512: incorrect optimization of VMINPS/VMAXPS at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72867
Bug ID: 72867
Summary: SSE/AVX/AVX512: incorrect optimization of
VMINPS/VMAXPS at compile time
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
The Intel intrinsics provide a family functions for computing the minimum and
maximum of two floating point vectors of different SIMD widths.
For the most part, these are symmetric. They are not, however, when given a NaN
argument: in particular,
min(1, nan) == 1
min(nan, 1) == nan
Whether that is pretty is arguable, but it's what the hardware implements (and
numerical libraries depend on this behavior).
The program below computes the expected output at optimization level 0.
$ g++ test.c -o test -msse4.2 -O0 && ./test
min(1, nan) = [nan nan nan nan]
min(nan, 1) = [1.00 1.00 1.00 1.00]
At optimization level 1, the minimum is computed at compile time, and the NaN
value is incorrectly propagated. This problem occurs both on GCC trunk and on
GCC 5.0 (I have not tested other versions).
$ g++ test.c -o test -msse4.2 -O1 && ./test
min(1, nan) = [nan nan nan nan]
min(nan, 1) = [nan nan nan nan]
/// Program to reproduce the issue
#include
#include
#include
int main(int argc, char *argv[]) {
__m128 x = _mm_min_ps(_mm_set1_ps(1.f), _mm_set1_ps(NAN));
printf("min(1, nan) = [%f %f %f %f]\n", x[0], x[1], x[2], x[3]);
x = _mm_min_ps(_mm_set1_ps(NAN), _mm_set1_ps(1.f));
printf("min(nan, 1) = [%f %f %f %f]\n", x[0], x[1], x[2], x[3]);
return 0;
}
[Bug target/72782] AVX512: No support for scalar broadcasts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782 --- Comment #1 from Wenzel Jakob --- Looks like this issue was first reported in 2014 but got stuck -- see Bug 63351.
[Bug target/72853] gcc/testsuite/gcc.c-torture/execute/20021120-1.c generates incorrect stxssp op with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72853 --- Comment #7 from Michael Meissner --- Author: meissner Date: Wed Aug 10 18:15:37 2016 New Revision: 239331 URL: https://gcc.gnu.org/viewcvs?rev=239331&root=gcc&view=rev Log: Backport from mainline: [gcc] 2016-08-10 Michael Meissner PR target/72853 * config/rs6000/rs6000.c (mem_operand_ds_form): Add check for op being an offsettable address. [gcc/testsuite] 2016-08-10 Michael Meissner PR target/72853 * gcc.target/powerpc/pr72853.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr72853.c - copied unchanged from r239330, trunk/gcc/testsuite/gcc.target/powerpc/pr72853.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/rs6000/rs6000.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/63351] Optimization: contract broadcast intrinsics when AVX512 is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63351 Wenzel Jakob changed: What|Removed |Added CC||wen...@mitsuba-renderer.org --- Comment #5 from Wenzel Jakob --- Any news on this? I've also run into GCC's lack of broadcast support (Bug 72782).
[Bug target/72853] gcc/testsuite/gcc.c-torture/execute/20021120-1.c generates incorrect stxssp op with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72853 Michael Meissner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Michael Meissner --- Fixed in trunk (subversion id 239325) and gcc-6-branch (subversion id 239331).
[Bug tree-optimization/72824] [5/6 Regression] Signed floating point zero semantics broken at optimization level -O3 (tree-loop-distribute-patterns)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72824 --- Comment #8 from Wenzel Jakob --- Thank you, I can confirm that the issue is fixed on my end.
[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 --- Comment #9 from rguenther at suse dot de --- On August 10, 2016 7:20:00 PM GMT+02:00, "dje at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855 > >David Edelsohn changed: > > What|Removed |Added > > Status|UNCONFIRMED |NEW > Last reconfirmed||2016-08-10 > Ever confirmed|0 |1 > >--- Comment #8 from David Edelsohn --- >> Yes, but that is guarded by flag_checking which defaults to 0. > >How can flag_checking be 0 if -fno-checking has an effect? It can't have an effect with release checking unless sth is seriously botched. Which is why I asked this to be investigated (I can't reproduce it on x86_64 Linux)
[Bug c++/72868] New: Constexpr expressions mistreat case ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72868 Bug ID: 72868 Summary: Constexpr expressions mistreat case ranges Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: amarquez at sigovs dot com Target Milestone: --- When performing compile-time constexpr evaluation (under gnu++1y), G++ silently treats case ranges as if they were a case with the first element of the range.
[Bug ada/72869] New: $@$@^^^18557092847@$$@$$^^^^*** Epson printer technical support number.....
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72869 Bug ID: 72869 Summary: $@$@^^^18557092847@$$@$$*** Epson printer technical support number. Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jhakasbaba76 at gmail dot com Target Milestone: --- Created attachment 39095 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39095&action=edit ((moti))Call @@@++ USA I8557O92847 EPSON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l EPSON h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a EPSON s.u.p.p.o.r.t p.h.o.n. ((moti))Call @@@++ USA I8557O92847 EPSON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l EPSON h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a EPSON s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa USA 1 I8557O92847 EPSON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l EPSON h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a EPSON s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa canada 1-1855-709-2847 USA, EPSON printer Tech Support phone number,EPSON technical support phone number 1 I8557O92847 .EPSON Tech Support Number EPSON Tech EPSON tech support, EPSON tech support number, EPSON tech support phone number, EPSON technical support, EPSON technical support number, EPSON technical support phone number, EPSON tech support number, EPSON support number, EPSON Tech support phone number, EPSON support phone number, EPSON technical support phone number, EPSON technical support number,Support Phone Number for EPSON printer Phone Number for EPSON CustomerService Technical Support Telephone Number EPSON printer support number EPSON EPSON printer tech support number EPSON EPSON printer technical support number EPSON EPSON printer technical support phone number EPSON EPSON printer customer service number EPSON EPSON internet security technical support EPSON technical support phone number EPSON EPSON tech support phone number EPSON EPSON customer support phone number I-855-709-2847 EPSON EPSON printer support phone number EPSON EPSON support phone EPSON tech support EPSON customer support EPSON phone support EPSON support number EPSON EPSON technical support EPSON printer customer support phone number EPSON EPSON printer tech support phone number EPSON contact EPSON support EPSON printer technical support phone number ~!~I8557092847++ EPSON EPSON phone number EPSON tech support EPSON support ticket EPSON customer support number EPSON EPSON tech support number EPSON EPSON technical support number EPSON EPSON support center EPSON telephone support call EPSON support EPSON printer support support EPSON EPSON billing support EPSON printer technical support number EPSON support EPSON printer EPSON online support EPSON contact support EPSON printer support number EPSON EPSON printer customer support number EPSON EPSON printer tech support number EPSON support for EPSON EPSON phone number EPSON EPSON customer service phone number EPSON EPSON contact phone number EPSON EPSON printer phone number EPSON EPSON printer customer service phone number EPSON phone number EPSON for EPSON customer service EPSON software phone number EPSON phone number EPSON for EPSON EPSON customer service telephone number EPSON EPSON helpline phone number EPSON EPSON contact number EPSON EPSON customer service number EPSON EPSON customer service phone number ~!~I8557092847++ EPSON us EPSON customer service phone number EPSON usa EPSON telephone number EPSON EPSON phone number EPSON usa EPSON printer contact number EPSON EPSON number EPSON EPSON contact number EPSON usa EPSON printer helpline number EPSON EPSON helpline number EPSON EPSON customer number EPSON EPSON printer customer service number EPSON EPSON contact telephone number EPSON contact number EPSON for EPSON EPSON software contact number EPSON EPSON toll free number EPSON EPSON telephone number EPSON uk EPSON registration number EPSON EPSON toll free number EPSON usa EPSON customer service EPSON software customer service contact EPSON customer service EPSON customer service phone EPSON printer customer service EPSON service EPSON printer technical support EPSON printer customer support EPSON technical support reviews telephone EPSON printer EPSON tech support phone number EPSON EPSON printer tech support phone number EPSON EPSON printer customer service EPSON technical support phone number EPSON EPSON printer free printer support EPSON customer service billing EPSON customer service email address EPSON customer service reviews contact EPSON customer service EPSON tech support number EPSON usa EPSON printer support number EPSON EPSON printer contact number EPSON EPSON customer service phone number EPSON EPSON technical support usa EPSON technical support number EPSON EPSON tech support phone EPSON t
[Bug c++/72865] Adding __may_alias__ attribute triggers a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72865 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #3 from Daniel Krügler --- The code is also accepted by the current gcc HEAD 7.0.0 20160807 (experimental).
[Bug ada/72872] New: $@$@^^^18557092847@$$@$$^^^^*** Lexmark printer technical support number.....
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72872 Bug ID: 72872 Summary: $@$@^^^18557092847@$$@$$*** Lexmark printer technical support number. Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jhakasbaba76 at gmail dot com Target Milestone: --- Created attachment 39097 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39097&action=edit ((moti))Call @@@++ USA I8557O92847 LEXMARK p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l LEXMARK h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a LEXMARK s.u.p.p.o.r.t p. ((moti))Call @@@++ USA I8557O92847 LEXMARK p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l LEXMARK h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a LEXMARK s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa USA 1 I8557O92847 LEXMARK p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l LEXMARK h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a LEXMARK s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa canada 1-1855-709-2847 USA, LEXMARK printer Tech Support phone number,LEXMARK technical support phone number 1 I8557O92847 .LEXMARK Tech Support Number LEXMARK Tech LEXMARK tech support, LEXMARK tech support number, LEXMARK tech support phone number, LEXMARK technical support, LEXMARK technical support number, LEXMARK technical support phone number, LEXMARK tech support number, LEXMARK support number, LEXMARK Tech support phone number, LEXMARK support phone number, LEXMARK technical support phone number, LEXMARK technical support number,Support Phone Number for LEXMARK printer Phone Number for LEXMARK CustomerService Technical Support Telephone Number LEXMARK printer support number LEXMARK LEXMARK printer tech support number LEXMARK LEXMARK printer technical support number LEXMARK LEXMARK printer technical support phone number LEXMARK LEXMARK printer customer service number LEXMARK LEXMARK internet security technical support LEXMARK technical support phone number LEXMARK LEXMARK tech support phone number LEXMARK LEXMARK customer support phone number I-855-709-2847 LEXMARK LEXMARK printer support phone number LEXMARK LEXMARK support phone LEXMARK tech support LEXMARK customer support LEXMARK phone support LEXMARK support number LEXMARK LEXMARK technical support LEXMARK printer customer support phone number LEXMARK LEXMARK printer tech support phone number LEXMARK contact LEXMARK support LEXMARK printer technical support phone number ~!~I8557092847++ LEXMARK LEXMARK phone number LEXMARK tech support LEXMARK support ticket LEXMARK customer support number LEXMARK LEXMARK tech support number LEXMARK LEXMARK technical support number LEXMARK LEXMARK support center LEXMARK telephone support call LEXMARK support LEXMARK printer support support LEXMARK LEXMARK billing support LEXMARK printer technical support number LEXMARK support LEXMARK printer LEXMARK online support LEXMARK contact support LEXMARK printer support number LEXMARK LEXMARK printer customer support number LEXMARK LEXMARK printer tech support number LEXMARK support for LEXMARK LEXMARK phone number LEXMARK LEXMARK customer service phone number LEXMARK LEXMARK contact phone number LEXMARK LEXMARK printer phone number LEXMARK LEXMARK printer customer service phone number LEXMARK phone number LEXMARK for LEXMARK customer service LEXMARK software phone number LEXMARK phone number LEXMARK for LEXMARK LEXMARK customer service telephone number LEXMARK LEXMARK helpline phone number LEXMARK LEXMARK contact number LEXMARK LEXMARK customer service number LEXMARK LEXMARK customer service phone number ~!~I8557092847++ LEXMARK us LEXMARK customer service phone number LEXMARK usa LEXMARK telephone number LEXMARK LEXMARK phone number LEXMARK usa LEXMARK printer contact number LEXMARK LEXMARK number LEXMARK LEXMARK contact number LEXMARK usa LEXMARK printer helpline number LEXMARK LEXMARK helpline number LEXMARK LEXMARK customer number LEXMARK LEXMARK printer customer service number LEXMARK LEXMARK contact telephone number LEXMARK contact number LEXMARK for LEXMARK LEXMARK software contact number LEXMARK LEXMARK toll free number LEXMARK LEXMARK telephone number LEXMARK uk LEXMARK registration number LEXMARK LEXMARK toll free number LEXMARK usa LEXMARK customer service LEXMARK software customer service contact LEXMARK customer service LEXMARK customer service phone LEXMARK printer customer service LEXMARK service LEXMARK printer technical support LEXMARK printer customer support LEXMARK technical support reviews telephone LEXMARK printer LEXMARK tech support phone number LEXMARK LEXMARK printer tech support phone number LEXMARK LEXMARK printer customer service LEXMARK technical support phone number LEXMARK LEXMARK printer free printer support LEXMARK customer service billing LEXMARK customer
[Bug c++/72868] Constexpr expressions mistreat case ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72868 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- This is an incomplete bug report, please read https://gcc.gnu.org/bugs/#need and provide a test case
[Bug rtl-optimization/72873] New: error: ‘asm’ operand has impossible constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72873
Bug ID: 72873
Summary: error: ‘asm’ operand has impossible constraints
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: vmakarov at redhat dot com
Target Milestone: ---
On x86-64, I got
[hjl@gnu-6 asm-2]$ cat x.i
void foo (int disks, int start, int stop, unsigned long bytes, void **ptrs)
{
unsigned char **dptr = (unsigned char **)ptrs;
unsigned char *p, *q;
int d, z, z0;
z0 = stop;
p = dptr[disks-2];
q = dptr[disks-1];
for ( d = 0 ; d < bytes ; d += 512 ) {
asm volatile("#"
:
: "m" (p[d]), "m" (p[d+64]), "m" (p[d+128]), "m" (p[d+192]),
"m" (p[d+256]), "m" (p[d+320]), "m" (p[d+384]),
"m" (p[d+448]), "m" (q[d]), "m" (q[d+64]),
"m" (q[d+128]), "m" (q[d+192]), "m" (q[d+256]),
"m" (q[d+320]), "m" (q[d+384]), "m" (q[d+448]));
for ( z = z0-1 ; z >= start ; z-- ) {
asm volatile("#"
:
:
"m" (dptr[0][d]));
}
asm volatile("#"
:
: "m" (p[d]), "m" (p[d+64]), "m" (p[d+128]), "m" (p[d+192]),
"m" (p[d+256]), "m" (p[d+320]), "m" (p[d+384]),
"m" (p[d+448]), "m" (q[d]), "m" (q[d+64]),
"m" (q[d+128]), "m" (q[d+192]), "m" (q[d+256]),
"m" (q[d+320]), "m" (q[d+384]), "m" (q[d+448]));
}
}
[hjl@gnu-6 asm-2]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2
-fno-asynchronous-unwind-tables -S -o x.s x.i
x.i: In function ‘foo’:
x.i:10:5: error: ‘asm’ operand has impossible constraints
asm volatile("#"
^~~
x.i:23:5: error: ‘asm’ operand has impossible constraints
asm volatile("#"
^~~
Makefile:23: recipe for target 'x.s' failed
make: *** [x.s] Error 1
[hjl@gnu-6 asm-2]$
[Bug ada/72874] New: $@$@^^^18557092847@$$@$$^^^^*** KOdak printer technical support number.....
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72874 Bug ID: 72874 Summary: $@$@^^^18557092847@$$@$$*** KOdak printer technical support number. Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jhakasbaba76 at gmail dot com Target Milestone: --- Created attachment 39098 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39098&action=edit ((moti))Call @@@++ USA I8557O92847 KODAK p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l KODAK h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a KODAK s.u.p.p.o.r.t p.h.o.n. ((moti))Call @@@++ USA I8557O92847 KODAK p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l KODAK h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a KODAK s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa USA 1 I8557O92847 KODAK p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l KODAK h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a KODAK s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa canada 1-1855-709-2847 USA, KODAK printer Tech Support phone number,KODAK technical support phone number 1 I8557O92847 .KODAK Tech Support Number KODAK Tech KODAK tech support, KODAK tech support number, KODAK tech support phone number, KODAK technical support, KODAK technical support number, KODAK technical support phone number, KODAK tech support number, KODAK support number, KODAK Tech support phone number, KODAK support phone number, KODAK technical support phone number, KODAK technical support number,Support Phone Number for KODAK printer Phone Number for KODAK CustomerService Technical Support Telephone Number KODAK printer support number KODAK KODAK printer tech support number KODAK KODAK printer technical support number KODAK KODAK printer technical support phone number KODAK KODAK printer customer service number KODAK KODAK internet security technical support KODAK technical support phone number KODAK KODAK tech support phone number KODAK KODAK customer support phone number I-855-709-2847 KODAK KODAK printer support phone number KODAK KODAK support phone KODAK tech support KODAK customer support KODAK phone support KODAK support number KODAK KODAK technical support KODAK printer customer support phone number KODAK KODAK printer tech support phone number KODAK contact KODAK support KODAK printer technical support phone number ~!~I8557092847++ KODAK KODAK phone number KODAK tech support KODAK support ticket KODAK customer support number KODAK KODAK tech support number KODAK KODAK technical support number KODAK KODAK support center KODAK telephone support call KODAK support KODAK printer support support KODAK KODAK billing support KODAK printer technical support number KODAK support KODAK printer KODAK online support KODAK contact support KODAK printer support number KODAK KODAK printer customer support number KODAK KODAK printer tech support number KODAK support for KODAK KODAK phone number KODAK KODAK customer service phone number KODAK KODAK contact phone number KODAK KODAK printer phone number KODAK KODAK printer customer service phone number KODAK phone number KODAK for KODAK customer service KODAK software phone number KODAK phone number KODAK for KODAK KODAK customer service telephone number KODAK KODAK helpline phone number KODAK KODAK contact number KODAK KODAK customer service number KODAK KODAK customer service phone number ~!~I8557092847++ KODAK us KODAK customer service phone number KODAK usa KODAK telephone number KODAK KODAK phone number KODAK usa KODAK printer contact number KODAK KODAK number KODAK KODAK contact number KODAK usa KODAK printer helpline number KODAK KODAK helpline number KODAK KODAK customer number KODAK KODAK printer customer service number KODAK KODAK contact telephone number KODAK contact number KODAK for KODAK KODAK software contact number KODAK KODAK toll free number KODAK KODAK telephone number KODAK uk KODAK registration number KODAK KODAK toll free number KODAK usa KODAK customer service KODAK software customer service contact KODAK customer service KODAK customer service phone KODAK printer customer service KODAK service KODAK printer technical support KODAK printer customer support KODAK technical support reviews telephone KODAK printer KODAK tech support phone number KODAK KODAK printer tech support phone number KODAK KODAK printer customer service KODAK technical support phone number KODAK KODAK printer free printer support KODAK customer service billing KODAK customer service email address KODAK customer service reviews contact KODAK customer service KODAK tech support number KODAK usa KODAK printer support number KODAK KODAK printer contact number KODAK KODAK customer service phone number KODAK KODAK technical support usa KODAK technical support number KODAK KODAK tech support phone KODAK t
[Bug c++/72868] Constexpr expressions mistreat case ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72868 --- Comment #2 from Alex Marquez --- Created attachment 39099 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39099&action=edit Test case
[Bug ada/72875] New: $@$@^^^18557092847@$$@$$^^^^*** Brother printer technical support number.....
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72875 Bug ID: 72875 Summary: $@$@^^^18557092847@$$@$$*** Brother printer technical support number. Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jhakasbaba76 at gmail dot com Target Milestone: --- Created attachment 39100 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39100&action=edit ((moti))Call @@@++ USA I8557O92847 BROTHER p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l BROTHER h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a BROTHER s.u.p.p.o.r.t p. ((moti))Call @@@++ USA I8557O92847 BROTHER p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l BROTHER h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a BROTHER s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa USA 1 I8557O92847 BROTHER p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l BROTHER h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a BROTHER s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa canada 1-1855-709-2847 USA, BROTHER printer Tech Support phone number,BROTHER technical support phone number 1 I8557O92847 .BROTHER Tech Support Number BROTHER Tech BROTHER tech support, BROTHER tech support number, BROTHER tech support phone number, BROTHER technical support, BROTHER technical support number, BROTHER technical support phone number, BROTHER tech support number, BROTHER support number, BROTHER Tech support phone number, BROTHER support phone number, BROTHER technical support phone number, BROTHER technical support number,Support Phone Number for BROTHER printer Phone Number for BROTHER CustomerService Technical Support Telephone Number BROTHER printer support number BROTHER BROTHER printer tech support number BROTHER BROTHER printer technical support number BROTHER BROTHER printer technical support phone number BROTHER BROTHER printer customer service number BROTHER BROTHER internet security technical support BROTHER technical support phone number BROTHER BROTHER tech support phone number BROTHER BROTHER customer support phone number I-855-709-2847 BROTHER BROTHER printer support phone number BROTHER BROTHER support phone BROTHER tech support BROTHER customer support BROTHER phone support BROTHER support number BROTHER BROTHER technical support BROTHER printer customer support phone number BROTHER BROTHER printer tech support phone number BROTHER contact BROTHER support BROTHER printer technical support phone number ~!~I8557092847++ BROTHER BROTHER phone number BROTHER tech support BROTHER support ticket BROTHER customer support number BROTHER BROTHER tech support number BROTHER BROTHER technical support number BROTHER BROTHER support center BROTHER telephone support call BROTHER support BROTHER printer support support BROTHER BROTHER billing support BROTHER printer technical support number BROTHER support BROTHER printer BROTHER online support BROTHER contact support BROTHER printer support number BROTHER BROTHER printer customer support number BROTHER BROTHER printer tech support number BROTHER support for BROTHER BROTHER phone number BROTHER BROTHER customer service phone number BROTHER BROTHER contact phone number BROTHER BROTHER printer phone number BROTHER BROTHER printer customer service phone number BROTHER phone number BROTHER for BROTHER customer service BROTHER software phone number BROTHER phone number BROTHER for BROTHER BROTHER customer service telephone number BROTHER BROTHER helpline phone number BROTHER BROTHER contact number BROTHER BROTHER customer service number BROTHER BROTHER customer service phone number ~!~I8557092847++ BROTHER us BROTHER customer service phone number BROTHER usa BROTHER telephone number BROTHER BROTHER phone number BROTHER usa BROTHER printer contact number BROTHER BROTHER number BROTHER BROTHER contact number BROTHER usa BROTHER printer helpline number BROTHER BROTHER helpline number BROTHER BROTHER customer number BROTHER BROTHER printer customer service number BROTHER BROTHER contact telephone number BROTHER contact number BROTHER for BROTHER BROTHER software contact number BROTHER BROTHER toll free number BROTHER BROTHER telephone number BROTHER uk BROTHER registration number BROTHER BROTHER toll free number BROTHER usa BROTHER customer service BROTHER software customer service contact BROTHER customer service BROTHER customer service phone BROTHER printer customer service BROTHER service BROTHER printer technical support BROTHER printer customer support BROTHER technical support reviews telephone BROTHER printer BROTHER tech support phone number BROTHER BROTHER printer tech support phone number BROTHER BROTHER printer customer service BROTHER technical support phone number BROTHER BROTHER printer free printer support BROTHER customer service billing BROTHER customer
[Bug ada/72876] New: $@^^1=855=709=2847^^@@%@%@$$ Kodak Printer tech support phone number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72876 Bug ID: 72876 Summary: $@^^1=855=709=2847^^@@%@%@$$ Kodak Printer tech support phone number Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jhakasbaba76 at gmail dot com Target Milestone: --- Created attachment 39101 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39101&action=edit ((moti))Call @@@++ USA I8557O92847 KODAK p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l KODAK h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a KODAK s.u.p.p.o.r.t p.h.o.n. ((moti))Call @@@++ USA I8557O92847 KODAK p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l KODAK h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a KODAK s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa USA 1 I8557O92847 KODAK p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l KODAK h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a KODAK s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa canada 1-1855-709-2847 USA, KODAK printer Tech Support phone number,KODAK technical support phone number 1 I8557O92847 .KODAK Tech Support Number KODAK Tech KODAK tech support, KODAK tech support number, KODAK tech support phone number, KODAK technical support, KODAK technical support number, KODAK technical support phone number, KODAK tech support number, KODAK support number, KODAK Tech support phone number, KODAK support phone number, KODAK technical support phone number, KODAK technical support number,Support Phone Number for KODAK printer Phone Number for KODAK CustomerService Technical Support Telephone Number KODAK printer support number KODAK KODAK printer tech support number KODAK KODAK printer technical support number KODAK KODAK printer technical support phone number KODAK KODAK printer customer service number KODAK KODAK internet security technical support KODAK technical support phone number KODAK KODAK tech support phone number KODAK KODAK customer support phone number I-855-709-2847 KODAK KODAK printer support phone number KODAK KODAK support phone KODAK tech support KODAK customer support KODAK phone support KODAK support number KODAK KODAK technical support KODAK printer customer support phone number KODAK KODAK printer tech support phone number KODAK contact KODAK support KODAK printer technical support phone number ~!~I8557092847++ KODAK KODAK phone number KODAK tech support KODAK support ticket KODAK customer support number KODAK KODAK tech support number KODAK KODAK technical support number KODAK KODAK support center KODAK telephone support call KODAK support KODAK printer support support KODAK KODAK billing support KODAK printer technical support number KODAK support KODAK printer KODAK online support KODAK contact support KODAK printer support number KODAK KODAK printer customer support number KODAK KODAK printer tech support number KODAK support for KODAK KODAK phone number KODAK KODAK customer service phone number KODAK KODAK contact phone number KODAK KODAK printer phone number KODAK KODAK printer customer service phone number KODAK phone number KODAK for KODAK customer service KODAK software phone number KODAK phone number KODAK for KODAK KODAK customer service telephone number KODAK KODAK helpline phone number KODAK KODAK contact number KODAK KODAK customer service number KODAK KODAK customer service phone number ~!~I8557092847++ KODAK us KODAK customer service phone number KODAK usa KODAK telephone number KODAK KODAK phone number KODAK usa KODAK printer contact number KODAK KODAK number KODAK KODAK contact number KODAK usa KODAK printer helpline number KODAK KODAK helpline number KODAK KODAK customer number KODAK KODAK printer customer service number KODAK KODAK contact telephone number KODAK contact number KODAK for KODAK KODAK software contact number KODAK KODAK toll free number KODAK KODAK telephone number KODAK uk KODAK registration number KODAK KODAK toll free number KODAK usa KODAK customer service KODAK software customer service contact KODAK customer service KODAK customer service phone KODAK printer customer service KODAK service KODAK printer technical support KODAK printer customer support KODAK technical support reviews telephone KODAK printer KODAK tech support phone number KODAK KODAK printer tech support phone number KODAK KODAK printer customer service KODAK technical support phone number KODAK KODAK printer free printer support KODAK customer service billing KODAK customer service email address KODAK customer service reviews contact KODAK customer service KODAK tech support number KODAK usa KODAK printer support number KODAK KODAK printer contact number KODAK KODAK customer service phone number KODAK KODAK technical support usa KODAK technical support number KODAK KODAK tech support phone KODAK tech sup
[Bug ada/72877] New: $@$@^^^18557092847@$$@$$^^^^*** CANon printer technical support number.....
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72877 Bug ID: 72877 Summary: $@$@^^^18557092847@$$@$$*** CANon printer technical support number. Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jhakasbaba76 at gmail dot com Target Milestone: --- Created attachment 39102 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39102&action=edit ((moti))Call @@@++ USA I8557O92847 CANON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l CANON h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a CANON s.u.p.p.o.r.t p.h.o.n. ((moti))Call @@@++ USA I8557O92847 CANON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l CANON h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a CANON s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa USA 1 I8557O92847 CANON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l CANON h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a CANON s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa canada 1-1855-709-2847 USA, CANON printer Tech Support phone number,CANON technical support phone number 1 I8557O92847 .CANON Tech Support Number CANON Tech CANON tech support, CANON tech support number, CANON tech support phone number, CANON technical support, CANON technical support number, CANON technical support phone number, CANON tech support number, CANON support number, CANON Tech support phone number, CANON support phone number, CANON technical support phone number, CANON technical support number,Support Phone Number for CANON printer Phone Number for CANON CustomerService Technical Support Telephone Number CANON printer support number CANON CANON printer tech support number CANON CANON printer technical support number CANON CANON printer technical support phone number CANON CANON printer customer service number CANON CANON internet security technical support CANON technical support phone number CANON CANON tech support phone number CANON CANON customer support phone number I-855-709-2847 CANON CANON printer support phone number CANON CANON support phone CANON tech support CANON customer support CANON phone support CANON support number CANON CANON technical support CANON printer customer support phone number CANON CANON printer tech support phone number CANON contact CANON support CANON printer technical support phone number ~!~I8557092847++ CANON CANON phone number CANON tech support CANON support ticket CANON customer support number CANON CANON tech support number CANON CANON technical support number CANON CANON support center CANON telephone support call CANON support CANON printer support support CANON CANON billing support CANON printer technical support number CANON support CANON printer CANON online support CANON contact support CANON printer support number CANON CANON printer customer support number CANON CANON printer tech support number CANON support for CANON CANON phone number CANON CANON customer service phone number CANON CANON contact phone number CANON CANON printer phone number CANON CANON printer customer service phone number CANON phone number CANON for CANON customer service CANON software phone number CANON phone number CANON for CANON CANON customer service telephone number CANON CANON helpline phone number CANON CANON contact number CANON CANON customer service number CANON CANON customer service phone number ~!~I8557092847++ CANON us CANON customer service phone number CANON usa CANON telephone number CANON CANON phone number CANON usa CANON printer contact number CANON CANON number CANON CANON contact number CANON usa CANON printer helpline number CANON CANON helpline number CANON CANON customer number CANON CANON printer customer service number CANON CANON contact telephone number CANON contact number CANON for CANON CANON software contact number CANON CANON toll free number CANON CANON telephone number CANON uk CANON registration number CANON CANON toll free number CANON usa CANON customer service CANON software customer service contact CANON customer service CANON customer service phone CANON printer customer service CANON service CANON printer technical support CANON printer customer support CANON technical support reviews telephone CANON printer CANON tech support phone number CANON CANON printer tech support phone number CANON CANON printer customer service CANON technical support phone number CANON CANON printer free printer support CANON customer service billing CANON customer service email address CANON customer service reviews contact CANON customer service CANON tech support number CANON usa CANON printer support number CANON CANON printer contact number CANON CANON customer service phone number CANON CANON technical support usa CANON technical support number CANON CANON tech support phone CANON t
[Bug ada/72878] New: Get Help @+***1..855..709..2847**$$@@ Canon Printer Technical Support Contact Number,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72878 Bug ID: 72878 Summary: Get Help @+***1..855..709..2847**$$@@ Canon Printer Technical Support Contact Number, Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jhakasbaba76 at gmail dot com Target Milestone: --- ((moti))Call @@@++ USA I8557O92847 CANON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l CANON h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a CANON s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa USA 1 I8557O92847 CANON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l CANON h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a CANON s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa canada 1-1855-709-2847 USA, CANON printer Tech Support phone number,CANON technical support phone number 1 I8557O92847 .CANON Tech Support Number CANON Tech CANON tech support, CANON tech support number, CANON tech support phone number, CANON technical support, CANON technical support number, CANON technical support phone number, CANON tech support number, CANON support number, CANON Tech support phone number, CANON support phone number, CANON technical support phone number, CANON technical support number,Support Phone Number for CANON printer Phone Number for CANON CustomerService Technical Support Telephone Number CANON printer support number CANON CANON printer tech support number CANON CANON printer technical support number CANON CANON printer technical support phone number CANON CANON printer customer service number CANON CANON internet security technical support CANON technical support phone number CANON CANON tech support phone number CANON CANON customer support phone number I-855-709-2847 CANON CANON printer support phone number CANON CANON support phone CANON tech support CANON customer support CANON phone support CANON support number CANON CANON technical support CANON printer customer support phone number CANON CANON printer tech support phone number CANON contact CANON support CANON printer technical support phone number ~!~I8557092847++ CANON CANON phone number CANON tech support CANON support ticket CANON customer support number CANON CANON tech support number CANON CANON technical support number CANON CANON support center CANON telephone support call CANON support CANON printer support support CANON CANON billing support CANON printer technical support number CANON support CANON printer CANON online support CANON contact support CANON printer support number CANON CANON printer customer support number CANON CANON printer tech support number CANON support for CANON CANON phone number CANON CANON customer service phone number CANON CANON contact phone number CANON CANON printer phone number CANON CANON printer customer service phone number CANON phone number CANON for CANON customer service CANON software phone number CANON phone number CANON for CANON CANON customer service telephone number CANON CANON helpline phone number CANON CANON contact number CANON CANON customer service number CANON CANON customer service phone number ~!~I8557092847++ CANON us CANON customer service phone number CANON usa CANON telephone number CANON CANON phone number CANON usa CANON printer contact number CANON CANON number CANON CANON contact number CANON usa CANON printer helpline number CANON CANON helpline number CANON CANON customer number CANON CANON printer customer service number CANON CANON contact telephone number CANON contact number CANON for CANON CANON software contact number CANON CANON toll free number CANON CANON telephone number CANON uk CANON registration number CANON CANON toll free number CANON usa CANON customer service CANON software customer service contact CANON customer service CANON customer service phone CANON printer customer service CANON service CANON printer technical support CANON printer customer support CANON technical support reviews telephone CANON printer CANON tech support phone number CANON CANON printer tech support phone number CANON CANON printer customer service CANON technical support phone number CANON CANON printer free printer support CANON customer service billing CANON customer service email address CANON customer service reviews contact CANON customer service CANON tech support number CANON usa CANON printer support number CANON CANON printer contact number CANON CANON customer service phone number CANON CANON technical support usa CANON technical support number CANON CANON tech support phone CANON tech support number CANON CANON customer service telephone number CANON CANON printer customer support number CANON CANON printer phone number CANON CANON printer online support CANON customer service number CANON CANON tech support center CANON customer service CANON software customer se
[Bug c++/72868] Constexpr expressions mistreat case ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72868 --- Comment #3 from Daniel Krügler --- The quoted essentials also require you to provide the full command line (A range in a switch case is not Standard C++), please read about what's needed in the quoted document.
[Bug ada/72881] New: $@^^1=855=709=2847^^@@%@%@$$ Canon Printer tech support phone number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72881 Bug ID: 72881 Summary: $@^^1=855=709=2847^^@@%@%@$$ Canon Printer tech support phone number Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jhakasbaba76 at gmail dot com Target Milestone: --- Created attachment 39103 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39103&action=edit ((moti))Call @@@++ USA I8557O92847 CANON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l CANON h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a CANON s.u.p.p.o.r.t p.h.o.n. ((moti))Call @@@++ USA I8557O92847 CANON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l CANON h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a CANON s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa USA 1 I8557O92847 CANON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l CANON h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a CANON s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa canada 1-1855-709-2847 USA, CANON printer Tech Support phone number,CANON technical support phone number 1 I8557O92847 .CANON Tech Support Number CANON Tech CANON tech support, CANON tech support number, CANON tech support phone number, CANON technical support, CANON technical support number, CANON technical support phone number, CANON tech support number, CANON support number, CANON Tech support phone number, CANON support phone number, CANON technical support phone number, CANON technical support number,Support Phone Number for CANON printer Phone Number for CANON CustomerService Technical Support Telephone Number CANON printer support number CANON CANON printer tech support number CANON CANON printer technical support number CANON CANON printer technical support phone number CANON CANON printer customer service number CANON CANON internet security technical support CANON technical support phone number CANON CANON tech support phone number CANON CANON customer support phone number I-855-709-2847 CANON CANON printer support phone number CANON CANON support phone CANON tech support CANON customer support CANON phone support CANON support number CANON CANON technical support CANON printer customer support phone number CANON CANON printer tech support phone number CANON contact CANON support CANON printer technical support phone number ~!~I8557092847++ CANON CANON phone number CANON tech support CANON support ticket CANON customer support number CANON CANON tech support number CANON CANON technical support number CANON CANON support center CANON telephone support call CANON support CANON printer support support CANON CANON billing support CANON printer technical support number CANON support CANON printer CANON online support CANON contact support CANON printer support number CANON CANON printer customer support number CANON CANON printer tech support number CANON support for CANON CANON phone number CANON CANON customer service phone number CANON CANON contact phone number CANON CANON printer phone number CANON CANON printer customer service phone number CANON phone number CANON for CANON customer service CANON software phone number CANON phone number CANON for CANON CANON customer service telephone number CANON CANON helpline phone number CANON CANON contact number CANON CANON customer service number CANON CANON customer service phone number ~!~I8557092847++ CANON us CANON customer service phone number CANON usa CANON telephone number CANON CANON phone number CANON usa CANON printer contact number CANON CANON number CANON CANON contact number CANON usa CANON printer helpline number CANON CANON helpline number CANON CANON customer number CANON CANON printer customer service number CANON CANON contact telephone number CANON contact number CANON for CANON CANON software contact number CANON CANON toll free number CANON CANON telephone number CANON uk CANON registration number CANON CANON toll free number CANON usa CANON customer service CANON software customer service contact CANON customer service CANON customer service phone CANON printer customer service CANON service CANON printer technical support CANON printer customer support CANON technical support reviews telephone CANON printer CANON tech support phone number CANON CANON printer tech support phone number CANON CANON printer customer service CANON technical support phone number CANON CANON printer free printer support CANON customer service billing CANON customer service email address CANON customer service reviews contact CANON customer service CANON tech support number CANON usa CANON printer support number CANON CANON printer contact number CANON CANON customer service phone number CANON CANON technical support usa CANON technical support number CANON CANON tech support phone CANON tech sup
[Bug ada/72884] New: Contact U$$D ***@@18557092847$$$****HP p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72884 Bug ID: 72884 Summary: Contact U$$D ***@@18557092847$$$HP p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jhakasbaba76 at gmail dot com Target Milestone: --- ((moti))Call @@@++ USA I8557O92847 HP p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l HP h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a HP s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa USA 1 I8557O92847 HP p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l HP h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a HP s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa canada 1-1855-709-2847 USA, HP printer Tech Support phone number,HP technical support phone number 1 I8557O92847 .HP Tech Support Number HP Tech HP tech support, HP tech support number, HP tech support phone number, HP technical support, HP technical support number, HP technical support phone number, HP tech support number, HP support number, HP Tech support phone number, HP support phone number, HP technical support phone number, HP technical support number,Support Phone Number for HP printer Phone Number for HP CustomerService Technical Support Telephone Number HP printer support number HP HP printer tech support number HP HP printer technical support number HP HP printer technical support phone number HP HP printer customer service number HP HP internet security technical support HP technical support phone number HP HP tech support phone number HP HP customer support phone number I-855-709-2847 HP HP printer support phone number HP HP support phone HP tech support HP customer support HP phone support HP support number HP HP technical support HP printer customer support phone number HP HP printer tech support phone number HP contact HP support HP printer technical support phone number ~!~I8557092847++ HP HP phone number HP tech support HP support ticket HP customer support number HP HP tech support number HP HP technical support number HP HP support center HP telephone support call HP support HP printer support support HP HP billing support HP printer technical support number HP support HP printer HP online support HP contact support HP printer support number HP HP printer customer support number HP HP printer tech support number HP support for HP HP phone number HP HP customer service phone number HP HP contact phone number HP HP printer phone number HP HP printer customer service phone number HP phone number HP for HP customer service HP software phone number HP phone number HP for HP HP customer service telephone number HP HP helpline phone number HP HP contact number HP HP customer service number HP HP customer service phone number ~!~I8557092847++ HP us HP customer service phone number HP usa HP telephone number HP HP phone number HP usa HP printer contact number HP HP number HP HP contact number HP usa HP printer helpline number HP HP helpline number HP HP customer number HP HP printer customer service number HP HP contact telephone number HP contact number HP for HP HP software contact number HP HP toll free number HP HP telephone number HP uk HP registration number HP HP toll free number HP usa HP customer service HP software customer service contact HP customer service HP customer service phone HP printer customer service HP service HP printer technical support HP printer customer support HP technical support reviews telephone HP printer HP tech support phone number HP HP printer tech support phone number HP HP printer customer service HP technical support phone number HP HP printer free printer support HP customer service billing HP customer service email address HP customer service reviews contact HP customer service HP tech support number HP usa HP printer support number HP HP printer contact number HP HP customer service phone number HP HP technical support usa HP technical support number HP HP tech support phone HP tech support number HP HP customer service telephone number HP HP printer customer support number HP HP printer phone number HP HP printer online support HP customer service number HP HP tech support center HP customer service HP software customer service HP customer care number HP usa HP customer number HP HP customer support number HP HP customer care number HP HP customer care toll free number HP HP tech support HP technical support HP printer support HP printer tech support HP support center HP .com customer service HP printer customer care number HP HP customer care HP phone number HP
[Bug c++/72868] Constexpr expressions mistreat case ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72868 --- Comment #4 from Alex Marquez --- (In reply to Daniel Krügler from comment #3) > The quoted essentials also require you to provide the full command line (A > range in a switch case is not Standard C++), please read about what's needed > in the quoted document. Cmdline: g++ -std=gnu++1y test.cpp Output: test.cpp:12:1: error: static assertion failed: Oops! static_assert(is_single_decimal_digit(3), "Oops!"); System GCC: COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) Alternate GCC (also fails): COLLECT_GCC=avr-g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/avr/6.1.1/lto-wrapper Target: avr Configured with: ../gcc-6-20160714/configure --prefix=/usr/local/ --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-avrlibc --enable-target-optspace --disable-threads --program-prefix=avr- --enable-lto --with-multilib-list=avr5 --disable-tls --disable-libstdcxx Thread model: single gcc version 6.1.1 20160714 (GCC)
[Bug c++/72868] Constexpr expressions mistreat case ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72868 --- Comment #5 from Alex Marquez --- Created attachment 39104 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39104&action=edit Preprocessed test case
